Six months ago I was losing arguments with Claude.
I’d describe a feature, watch it produce code, then spend the rest of the hour walking back assumptions. Wrong state library. Wrong API shape. Code that compiled but didn’t fit anything else in the repo. The “10x productivity” pitch felt like someone else’s tweet.
The thing that eventually changed wasn’t the model. It was that I stopped treating Claude like a faster keyboard and started treating it like a new engineer on the team.
The mismatch
Most of the friction I see — in myself, in people I pair with — comes from prompting an AI assistant the way you’d prompt autocomplete. Give it a sentence, get a snippet, paste it in. When the snippet doesn’t fit, the reaction is “the model is dumb.” But the model isn’t being asked to do the right job.
Think about how onboarding actually works. You don’t dictate every line to a new hire. You explain the goal, point them at the parts of the codebase that matter, answer their questions, look at their plan before they spend a day coding the wrong thing, then review what they produce. The “what” and “why” are yours. The “how” is theirs, with checkpoints.
That’s the job AI assistants are good at. Not the snippet job.
Tech lead, not typist
The shift, when I name it for myself, is: I’m directing work, not producing keystrokes. My job is requirements, context, plan review, unblocking, verification. The assistant’s job is questions, proposals, code, iteration.
This was uncomfortable for a while. For a long time I measured myself by the code I wrote. Stepping back to review plans instead of typing them felt like I was slacking off. What I noticed, eventually, was that the thinking didn’t disappear — it just moved. Instead of “how do I implement this validator,” I was thinking about how three features were going to interact, where the seams were, what I was going to have to undo in a month if I didn’t catch it now. That’s harder, not easier. It’s also the part of the job I was always supposed to be doing more of.
The context problem, and steering docs
Every conversation starts from zero. The model doesn’t know the stack, the conventions, the half-broken pattern in auth/ that nobody’s allowed to touch yet. So you either re-paste context every time, or it guesses, and the guesses are wrong in the same boring ways.
The thing that worked for me was committing context to the repo. Three documents, kept alongside the code:
- One on the product — what we’re building, who uses it, what the actual business rules are.
- One on the stack and conventions — frameworks, patterns we use, patterns we’ve banned, how we test.
- One on the layout — where things live, what each directory is for, naming.
The assistant reads these before it does anything. Most of the “wrong state library, wrong API shape” failures stop happening, because the answers are in the docs. The docs aren’t elegant. They get edited every time the assistant gets something wrong in a way the docs should have prevented — that’s the maintenance loop.
Plan first, code second
The habit that took longest to build: forcing a plan before any code gets written.
The shape of it is simple. I describe what I want. The assistant asks questions. I answer them. It proposes an approach. I push back on the parts that look wrong — wrong abstraction, missed edge case, doesn’t match how we did the last similar thing. Only after that do we start writing.
Ten minutes of planning catches the half-hour of rework that would have happened otherwise. It also catches the worse failure mode, which is when the rework doesn’t happen and the bad design ships.
Working in parallel
Once I wasn’t typing the code, I noticed I had bandwidth. Not in a “look at me multitasking” way — in a literal way. The assistant is doing the work; I’m reviewing it. There’s slack while it runs.
Git worktrees turned that slack into parallel features:
git worktree add ../feature-payment-form feature/payment-form
git worktree add ../feature-user-settings feature/user-settingsA Claude session per worktree. I rotate: review one plan, approve, switch to the next, review code on the third, back to the first to look at what came back. It’s not faster typing. It’s a different shape of work — closer to managing a small team than to coding.
A few things to flag if you try this. Three is roughly my ceiling; past that the context-switching tax gets real. The features need to be genuinely independent — two streams touching the same files is worse than doing them serially. And reviewing code carefully gets harder when you’ve been doing it for hours. I batch review, take breaks, and don’t trust myself to spot subtle issues at the end of a long stretch.
MCP and closing the loop
The other thing worth doing is giving the assistant access to the tools it needs to verify itself. Database, API docs, test runner, logs — through MCP servers, it can check its own work instead of waiting for me to copy-paste output back.
This is the difference between “here’s some code, run it and tell me what happened” and “I ran it, here’s what failed, here’s the fix.” The feedback loop tightens. Most of the time-sink in AI-assisted work used to be me being the message bus between the model and the rest of the system. Less of that now.
Where to start
If you want to try this, the shortest path I’d suggest: write the steering docs, then on the next feature, force yourself to plan before coding. Don’t try to do parallel worktrees yet. The plan-first habit is the one that pays off, and it takes practice to stop reflexively jumping to implementation. Worktrees and MCP are amplifiers — they don’t help if the underlying workflow is still “prompt, paste, debug.”
The hardest part of this transition wasn’t tooling. It was accepting that the value I was producing wasn’t measured by the lines I typed. Once I stopped checking that box, the rest of it got easier.