To the builder who is worn out from reviewing their agent's code

Someone told Seth recently that they were worn out. Their agents write a lot of code now, more than they can comfortably read, and the review has become the tiring part of the day. They don't want to stop reviewing by hand. They want it to stop feeling like a wall.

Seth knows the feeling from the other side. "I still review all of my code at work," he said when he passed the question on. So this is our answer, written to that person. Is there a way to keep reading every change without reading slower, or skimming?

Dear tired reviewer,

Keep reviewing by hand. Seth still reviews all of his code at work, and we think a careful person needs to read the change. What we changed is what reaches you.

Think about the last few comments you left on an agent's work. Some of them are probably about things a machine could have told the agent first: a name that doesn't say what it holds, a method that doesn't exist, a missing type, a framework rule broken. And then there are the two questions only the agent could answer: why is it built this way, and did you actually run it?

Each of those has an earlier place to be caught, before the change gets to you:

• Names and framework rules are checked as the agent writes each file, by our naming check and language checker.
• Methods that might not exist are ones we ask the agent to look up before it writes the call.
• "Why is it like this?" is answered by the notes the agent writes with the change, saved in the project next to the code.
• "Did you run it?" is asked by the loop itself, and a check at the end builds the project before the agent is allowed to call the job done. That proves it builds, not that it works; more on that below.

What's left for you, and the order we read it in

What remains is the part worth a person's attention: does this do the right thing for the person who will use it, is this an approach you can live with, is the data handled the way your business needs? We read each change in four passes, always in this order:

1. The plan, and the check the agent recorded for each step. You see what it meant to do.
2. The notes the change added. That is the "why", written while the agent still knew it.
3. One run of each thing a user does that the change touches. Click through it yourself.
4. The diff, read for behavior and decisions rather than names and types.

We haven't timed our reviews before and after this change, so we won't promise you an hour back. What we can say is that by the time we open the diff, we already know what it is supposed to do, so our attention can go to the product instead of the spelling.

The part no check caught

We ran a small test that keeps us honest about all this. A small model built a pet tracker four times in our own app template, twice with our naming setup and twice without. The agents weren't allowed to run the app, so every one of the four finished on the type checker's word, and all four passed it. Then a larger model read each one's code and judged which of the five things a user does with a pet tracker would work: two and four of five with our setup, none in either try without it. Even the best try had a bad bug: clicking Delete would have quietly edited the pet instead and said it worked.

That bug came from one mistake that got past our checks in both of the better tries. The agents assumed a habit from Rails, a hidden form field that turns a form into an edit or a delete, and our framework doesn't support it. Our template hadn't written that down anywhere, and the naming and type checks didn't flag it. The model grading the tries found it by reading the framework's own code. That fact is now written into the template, where the next agent will read it.

That is why clicking through the change yourself is never optional, and it is the second job of your review: when you find something a check could have caught, write it down as a lesson and build the check, so you are less likely to write the same comment twice.

Try this on your next pull request

Before you open the diff, ask the agent: "List what you checked by running it, and what you only checked by reading it." Then click through one of the "only read it" items yourself. Step 8 of the lesson has the four passes and the two commands that show the plan and notes for a branch.

You will still read every line. You just won't be the first one to.

How we tested it

• The question: passed to us by Seth on November 1, 2026, from a person who wants to keep reviewing their agents' code by hand. The quote from Seth is from the same message.
• The pet tracker: August 11, 2026. Claude Haiku in headless Claude Code, two runs with our naming conventions, instructions and check, two without, one task and one machine. The task told the agents not to run migrations, tests or the server. All four passed the type check. A larger model reviewed each try's code and judged the five user actions 0 and 0 workable without, 2 and 4 with; it confirmed the form-field problem by reading the framework's router. In the 4-of-5 try, clicking Delete would silently update the pet and report success. The "with" tries changed names, instructions and tooling together, so we can't credit any one part. The data is public.
• Not measured: how long our reviews take, or how many review comments the checks prevent. The four passes are how we work, not a tested method.

Back to the start: Set up an agent harness that gets code right the first time