How I actually code with AI

An engineer on the team recently asked me how to become more "AI native". How do you build plans you can trust? How deep should you still be in the code? It's a fair question, because nobody teaches this in coding school, and most of us are figuring it out as we go.

So I gave him a brain dump of my current workflow. It was the first time I'd said it all out loud in one go, so I'm writing it down here. You can copy all of it, or take the pieces that fit.

The principle underneath everything is simple. Humans are not great with large context. We're great with small, bite-sized context. If you're going to orchestrate an agent doing an enormous amount of work, you need to consume what it's doing in pieces you can actually understand. Otherwise you can't steer it.

Step 1: Plan with the best model you can get

This is where I spend the money. For planning, I use the most capable model I have access to, usually Claude Fable or Gemini Pro, because the quality of the plan decides the quality of everything after it. That's where the upfront cost is.

I ask for epics, user stories and tasks first. No implementation, no execution. Then I ask it to organise those tasks into an implementation plan, grouped into phases using dependency ordering: what's blocking, what isn't, and what has to happen first. You often find that phase one needs task two of story two before task three of story one. Finally, for each task, I ask for the jobs to be done, a mini design spec and any code examples, so every ticket carries what the agent intends to do.

Then I review it, again and again. When it's too texty, I hand it back: simplify, use plain language, be concise. I keep going until I'm comfortable with every epic, story and task. By then I've loaded the whole plan into my own head, and I know what I'm doing each day.

I'd expect this to take a whole day on a big piece of work. That's not wasted time. You've separated confidence in the plan from the implementation itself, and the plan is where engineers should be spending their time. (How you cut the epic into pieces is a topic of its own, and I've written about it separately.)

Step 2: Let the premium model orchestrate, and farm out the mechanical work

When it's time to execute, the premium model becomes the orchestrator. It manages the work and checks it. The mechanical work, where you already know what needs to happen, goes to sub-agents running Sonnet, because it's cheaper and it doesn't need super intelligence. The orchestrator checks each piece. If the issue is low severity, it sends it back to Sonnet to fix. If it's a one- or two-line fix, it just fixes it and moves on.

Two cost rules live in my protocol. First, never more than about five sub-agents. I once left it alone and it spun up around 30. It finished the work, but a couple of the agents hit my limits and couldn't wrap up. Second, once usage gets to 98 or 99% of my limits, pause all work until the next reset window. Since adding that, my overnight runs haven't hit the limits.

Step 3: Give it a coding protocol

I keep a written coding protocol the agent loads at the start of every session. If your team's rules aren't in the repository, keep your own in a folder that isn't checked in, and tell the agent to read it every time. Three rules do most of the work:

1. Explore the codebase before implementing. That way it doesn't reimplement a pattern that already exists, and the code stays DRY.
2. Don't trust your training data for frameworks. Always read the latest documentation before implementing an integration.
3. When I'm not there, make the call and tell me. I have an unattended mode for when I'm going to bed. The agent researches best practice and makes its best judgement call. Then it surfaces every decision it took, sure or unsure, in the end-of-session summary. In the morning, I read the summary and ask it to change anything I disagree with.

Step 4: Make it prove the work

Then a set of general rules, which matter most if you're going to review the code yourself:

• Conventional commits and atomic commits, with no AI attribution in the messages.
• PRs grouped into small, bite-sized changes, small enough for a human to review. (I've written separately about why PR size matters so much.)
• A first review from another agent. Part of my protocol is to get the agent to add another agent to the PR for review, running a model from a different provider, never one from the same provider that wrote the code. It reviews the PR first and gives initial approval, and I can see the history of its comments and resolved comments.
• Unit tests always, plus integration tests, because not everything has a UI. For anything with a UI, end-to-end tests, browser tests and screenshots.

That last one is underrated. There's nothing as delightful as seeing the screenshots in the PR before you've even tested it yourself. It gives you a first level of confidence that it's working.

Then run it in parallel

With the plan done up front, the day becomes simple. I ask the agent what's next, pick one item, and start it in its own session. I use git worktrees, so I can run three or four sessions at the same time without them stepping on each other. Then it becomes a waiting game. I read documentation, or do anything else, and come back to PRs ready for review. When stacked PRs need rebasing, I get the agent to do it, because it understands what the conflict actually is.

Why bother?

You can just YOLO it: give the agent a goal, say "go do it", and hope it does what you need. Sometimes that works, especially on greenfield work. But I'd rather take the small, bite-sized approach, because to steer and govern what the agent is doing, I need to understand it in small pieces too. Over time, these rules have given me real confidence in what I build, and that's what lets me ship quickly.

If you take one thing from this, write your protocol down. Start with three rules, and add one every time the agent surprises you.