How I work with AI coding agents

I built the projects on this site with AI coding agents. Early on, my biggest problem was that an agent given a loose task would come back fast with something that looked finished and was wrong in ways I only found later. I got better results once I added some process, so I wrote that process down as a set of reusable instructions that I now install in every project.

None of it is new. It’s roughly what I’d do with a team: write the plan down, have someone else read it, agree on what has to be fixed before going ahead, and keep the final say myself.

One model plans, another does the work

I use a stronger, slower model to write the plan and a faster, cheaper one to review it and carry it out. The plan is saved as a file, so either model can go back and re-read it, and so can I.

It goes in four steps:

1. Plan. The planning model writes the steps, the choices it made, and how we’ll know each step worked.
2. Review. The second model reads the plan before it touches anything. It lists what it’s assuming, what it wants to ask, and what it would change.
3. Align. That feedback goes back to the planner, which answers each point (agree, disagree or partly agree) and updates the plan.
4. Execute. The second model re-reads the plan file, and only then does the work.

The second model catches different things from the first, because it’s the one that has to follow the plan. It notices a file that isn’t where the plan says it is, or a step with no way to check it. I’ve also found that making it re-read the plan right before starting helps more than a second round of review, because otherwise it sometimes works from an older version.

Only some feedback is allowed to block

Every piece of review feedback gets one of three labels:

• Blocking: the result would be wrong, or going ahead would be unsafe.
• Verify: something has to be checked by looking at the files or running it.
• Polish: it would read better, nothing more.

Polish never holds anything up. Before I had that rule, two models would trade wording suggestions for as long as I let them. Now a review is over when the blocking and verify items are dealt with.

Small tasks skip most of this

I don’t do any of this for a one-line fix. Plans come in three sizes. The smallest is just the plan. The two larger sizes also need a short spec that lists what will be produced, and which decisions a script makes and which the agent makes. I pick the size by counting things, like how many scripts and how many decisions are involved, so I’m not deciding by how I feel that day.

A second opinion, and I approve the changes

For work that’s already done, I have a second agent review it cold. It gets the files and nothing else, so it isn’t influenced by the conversation that produced them. Its findings come back numbered, with the first agent’s opinion on each one.

Then everything waits for me. Nothing gets changed until I say which findings to apply. If I reject one, it goes on a list so it isn’t raised again in later rounds. And if two rounds in a row end with the same open issues, the agents stop and tell me, so they don’t keep going round.

What I’ve taken from it

Writing down how each step will be checked has been the most useful habit. If I can’t say how I’d check a step, I usually haven’t thought the task through yet.

The labels make it easier to tell when something is ready, because I can count what’s still open.

I spend the expensive model on the plan, where the thinking is, and use the cheap one for most of the typing.

There are three places where I always stay involved: approving the plan, choosing which review findings to apply, and saving the final changes. The rest I’m happy to leave running.