Claude Code changes fast. I wrote this on 7 September 2026. Some commands, defaults and model names will have moved by the time you read it. The habits should hold longer.
Since January, 3,091 of the 3,567 commits on my current project are co-signed by Claude. That is 86%.
During summer 2025, I started to use Claude code, as a very good coding assistant,
→ A bug, Claude fixed it.
→ A component, Claude built it.
→ A refactor, Claude did it.
But the more I use it, the less I think that is the interesting part.
The interesting part is what happens when you stop asking Claude to write code and start asking it to do work.
→ Investigate this bug.
→ Understand this codebase.
→ Build this feature.
→ Run the tests.
→ Look at the screenshots.
→ Try another approach.
→ Review what you just did.
→ Open a PR.
That is a different mental model.
And with the latest Claude Code features, it is becoming obvious. Anthropic is pushing Claude Code toward longer, more autonomous work: subagents, agent teams, hooks, worktrees, persistent memory, goals.
So here are the things I care about when using Claude Code on a real product.
The ones that changed how I work, with the actual bugs and files they come from.
1. Give Claude a problem (better than a task)
The old way:
Fix the trip save function, some trips have no points.
The better way:
Some multi-day trips arrive in the database with a real distance and zero GPS points. Don’t change anything yet. Find every path where a recording can be saved without its track.
The first asks for code in a function I had already blamed. The second asks Claude to understand something.
It found three ways a save could lose its data. I would have fixed the first one and shipped.
The expensive thing is not Claude generating 500 lines of code. It is Claude generating 500 lines of the wrong code.
2. Let it explore before you tell it where the bug is
Long trips showed up cropped on the shared web page. I was sure it was the mobile recorder, again. Instead of “fix the recorder”:
Find out why traces longer than a few hours are cut on the share page.
Claude followed the chain from the page to the database and came back with: the recorder is fine, the API layer caps every response at 1,000 rows, including stored procedures. Then it checked something I would not have, that the usual paging header is ignored on those calls, so the fix had to be explicit paging. A second, unrelated page had the same bug.
Autocomplete helps me write what I already decided. Claude Code helps me decide what should be written.
3. Explore and plan before implementing
For anything that touches the boat, I do not skip the first two. For an anchor alarm (drop a virtual anchor, get woken up if the boat drifts):
Explore how background GPS tracking and notifications work in this app. Don’t modify anything.
Give me a plan for an anchor drag alarm on top of it. Phone locked, bad GPS, keep the existing architecture unless there’s a strong reason not to.
The plan is where the decisions surfaced: a default radius of four boat lengths, a breach that must persist twelve seconds, and a rule that a GPS gap can delay the alarm but never suppress it. I would have discovered that rule at three in the morning, from a false alarm.
Plan mode adds overhead. If you can describe the diff in one sentence, skip it.
4. Context
Claude Code sends the whole conversation on every turn, and quality drops as the window fills.
An hour on a database test, then a landing page to rewrite? /clear. New session.
Same for files. Point Claude at the two files that matter. The folder with 38 of them can stay closed.
Same for tools. Run /context once in a fresh session and look at what is loaded before you type. Every MCP server in there should have a job in this session.
When the problem is the same but the conversation got huge, /compact. What has to survive lives elsewhere: rules in CLAUDE.md, workflows in skills, learnings in memory.
Memory is the part that changed recently. Claude Code keeps a memory folder per project, and mine has about forty files. One says: if a database test passes locally and fails in CI, reset the local database first, because new migrations only get applied on a fresh start. Claude wrote that down after it cost us a round-trip to CI, and the lesson has held since.
After a long investigation, I ask for it explicitly:
Write down what we learned so the next session can continue without repeating this.
The conversation is temporary. The knowledge is permanent.
5. CLAUDE.md
Mine answers one question: what would I explain to a new developer on their first day? The lines that earn their place are the ones Claude could only learn from me. “This is a B2C app, no team accounts” is there because the boilerplate is B2B and Claude kept building team features. “Regenerate the types after every migration” is there because it forgot.
If I have said it twice, it goes in. If it only matters for one workflow, it becomes a skill, because every line of the file rides along in every session, including the ones where it is dead weight.
The file gets better through corrections. Claude once proposed a new enum value to fix a calculation. I said no. Three days later it proposed a heuristic to detect the same case. This time I wrote the refusal down, with the reason, and the idea has stayed away since.
6. Skills
If I say the same thing three times, it should be a skill.
Most of mine live outside the code. One writes product descriptions. It is mostly rules: every adjective comes with a number, every section rests on a verified fact, and a list of words stays out. A validation script greps the output for all of it. A rule with a script behind it is a test. The rest is prayer.
Subagents are the same idea with their own context window. Mine are canned prompts with a name: database, tests, forms, code review. They earn their place because a schema review’s noise stays in their window and out of mine.
7. Hooks
A hook turns “please run the formatter” into “the formatter runs”.
I have zero. CLAUDE.md asks Claude to run typecheck, lint and format after every task. It is an instruction, so it is optional. A commit from July is titled “fix pre-existing errors surfaced by the unblocked Lint gate”. That is what optional looks like.
First hook to add: after every edit, run the formatter. Second: before every test run, rewrite the command so only failures come back. Start with one annoying manual step. The framework can wait.
8. Choose the model
My default is Fable, 1M context, xhigh effort. Expensive, and right for my codebase. When it fails, it is because it knew too little about an SDK’s internals, and a bigger model fixes that. Anthropic’s rule: too little knowledge, bigger model. Too little effort, higher effort.
I go cheaper wherever the thinking is already done. All my subagents run on Sonnet.
Set it once. Changing model or effort mid-session drops the prompt cache and re-reads the whole conversation at full price.
9. Git
Claude commits and writes the message. That is where the rationale lives now: the commit lists what failed and why, and a comment in the recorder says “this is exactly how multi-day trips lost their trace”. Written for the next agent as much as for me.
Reverting is free. A follow-up looked right in the session and did not work on the boat. Reverted, and the memory file says: dead end, here is the unsolved problem if you retry.
Checkpoints and /rewind are for the session. Git is for the product.
10. Parallelize only parallel work
Generating 32,000 descriptions was parallel work: waves of 200, ten subagents at a time, one merge agent per wave.
A bug in one recorder is the opposite. Five agents would each have needed to understand the same three modules before deciding anything.
When the work is parallel, worktrees: a refactor in one, a content loop in another, main free for a hotfix. Each agent gets its own filesystem.
11. /usage
A long loop hits the plan’s five-hour limit, waits, resumes. That works because the loop knows where the limit is. /usage shows it, and now attributes usage to each skill, subagent and MCP server.
One consequence: content generation runs inside Claude Code sessions rather than through the API. Same models, one bill.
Bonus: spend your weekly allowance early
The weekly cap expires, and Anthropic resets it early for everyone more often than you would expect. Each reset replaces whatever was left with a full allowance. Spent early, your week counts twice. Saved, it gets overwritten.
So run the heavy jobs in the first three days after a reset: migrations, content loops, large refactors. Keep the tail of the week for reviews and small fixes. /usage shows the reset time, and a session stopped by a limit now waits and resumes on its own.
The skill is now delegating
What to give it, what to keep, when to let it run, when to hit Escape.
Delegation works when the repository is ready for it. For me that meant a short CLAUDE.md, a few subagents, skills with validators, a memory folder, tests named like specs, commits that explain why. All of it is engineering, and all of it compounds: every mistake makes the next run better.
The goal is Claude doing more of the work while I keep control of the result.
Thanks for reading The Buildup. Robin and I share what we are building: the code, the failures, the numbers, and what is worth following in tech that week.
We are the two people co-founder at Moqa Studio, an AI agency in Paris. We build AI agents and systems for businesses, and we help engineering teams work the way this article describes. If your team wants to get there faster, say hello.
One last thing, I'm using cmux to get the most of claude code, a native Mac terminal built for running several coding agents at once.
Every session sits in a sidebar with its git branch and folder. When one is waiting for my input, its tab lights up, so I look only where I'm needed
Nice article thanks ! Great onboarding on how to start using claude code to it’s real extent !