How I ship code I never read

Whatever model you use, it will make mistakes. That is the starting point, and it has not changed. What has changed is what you do about it.

The obvious answer is that a human verifies everything the AI produces. The obvious answer is also wrong, or at least it does not scale, because the human becomes the bottleneck. If every pull request waits for me, then my output is capped at how fast I can read code, and all the leverage I just bought is gone.

So the AI has to check the AI. There is an asterisk on that, and I want to be honest about it: a model might miss things I would catch, and I might miss things it would catch. That is a leap of faith we are all taking right now. I think it was a riskier leap two years ago than it is today, and I think the risk keeps falling as models get better.

Different eyes

Here is the thing I keep coming back to: I am not the best person to review my own code.

When I review something I wrote, I review it as the same person who wrote it. Same blind spots, same assumptions, same experience. I will overlook the same things twice. That is why it has always been an advantage to have somebody else look at my work, and it is exactly as true for a model.

So I split the providers. If I am coding with Claude Code, then I review with OpenAI's Codex. Completely different model, completely different provider, looking at the same implementation. In practice it finds far more than a model reviewing its own output does, because it brings a different skill set, or a different experience, or whatever you want to call the thing a model has instead of experience.

One provider writes. A different one reviews.

Plan first, then implement

The second piece is about where the quality actually comes from.

Implementation by a frontier model is expensive. It is also, in my experience, not better. When a strong model starts implementing without a plan, it tends to discover halfway through that something does not match what it assumed, and then it patches. It undoes a bit, adds a comment explaining what it just did, and its train of thought ends up sprinkled through the logic. It usually gets there, and the thing usually works, but the code carries the shape of the discovery process.

Handing a model a plan it did not have to invent produces better results. So the plan comes first, written by the best model I have access to, which as of writing is Fable 5.1. Then the implementation is close to mechanical, and a smaller model such as Sonnet 5 is plenty for following a plan.

Fable plans. Sonnet implements. Codex reviews.

Two more gates

That worked for months, and it still left me with code reviews that found six, seven, sometimes ten issues.

Those issues come from one of two places: the plan or the implementation. One of the two did not produce enough quality to pass review. So I put a gate on each.

The first is a plan review. Codex reads the plan the way it would read code, before any of it exists, and points out the weak spots. That catches a whole class of problems that would otherwise surface much later, as review findings on an implementation that faithfully built the wrong thing.

The second is a verifier on the implementation. After Sonnet writes the code, and before Codex reviews it, a frontier model checks that the implementation actually follows the plan, and that it did not introduce anything new on the way. Whatever it flags goes straight back to the agent that wrote the code.

Those two gates are what finally brought the review findings down far enough that the output is good enough to ship without a thorough human read.

What I still do myself

I do look at pull requests, just not all of them, and not the way I used to.

What I am looking for is shape, not correctness. Small methods. Things doing what they say they are doing. Comments where a decision needs explaining and nowhere else. Not seven parameters. Not seven levels of indentation. You can tell whether something was implemented elegantly by looking at it, even when you do not fully follow what it does.

The thing I actually lean on is tests. Every piece of work has to come with them. Some projects carry a coverage target that has to be met. And on a couple of projects I have played with having the agent break the code at random to see whether the tests notice. That is a good game, and a much better one when you do not have to play it by hand. If your agent can go and break things to prove the tests are testing rather than just existing, then you know something real about them.

The most incredible part is that I was not the one to come up with the mutation game. My chief of staff AI did. Credits are due.

Four of those nine survived, and the first one is the one worth staring at. M1 is the exact bug the code review had found an hour earlier. The fix was correct and the test written for it was green, and the test did not notice when the bug came back.

This is what lets me ship products without reading every pull request. And honestly, the things I have shipped lately have had fewer bugs than what I shipped in the past. I am not certain whether that is skill, or attention, or just the fact that a different set of eyes is always on the code. For now it is working.

None of this is about the tools

The flow is model agnostic. Review with GitHub Copilot and code with Codex. Code with a local model. Use whatever harness you like: Claude Code, opencode, pi.dev, anything. The principle stands.

What you do need is a harness and at least two models, ideally from different providers. Which does mean two subscriptions. Worth saying: this runs on subscriptions, not metered API billing. I have a Claude subscription and a ChatGPT subscription, and that is enough for the whole loop.

If you want to run the cycle rather than read about it, the whole thing is written out at claude-dev-cycle: ten numbered steps, the incident that produced each rule, and three small scripts. It names the tools on purpose, so you do not have to translate it before you can try it.

Where this goes

At some point the models will be better developers than I am. When that happens, me reading the code stops making sense, because I would be the one learning from them rather than the other way around.

Until then, I keep the checks in place, because they are what gives me confidence that what I ship is good.

I am currently playing with other harnesses and with open weights models. That is probably its own post.

References and credits

The mutation game is not mine. Ezri, the chief of staff AI I run my day through, proposed it on 4 September 2026 after four separate tests that day turned out to describe their own fix rather than test it. The suggestion was to break the fix, confirm the specific assertion goes red, then restore. I said make it happen, and it has been standard since.

Both screenshots are real runs, not mock-ups. The plan review finding is one of eight on a single task from 12 September 2026. The mutation run is nine deliberate breakages of one feature from 11 September 2026, five caught and four survived.

Tools named in the post: Claude Code, OpenAI's Codex, Fable 5.1 and Sonnet 5, GitHub Copilot, opencode, and pi.dev. The cycle itself is at claude-dev-cycle.