The implementer never reviews its own code

Every substantive day in this repo went to a read-only review by a model that did not write the code. Making that automatic took me until day three.

The interesting round is never the first one.

TL;DR — the review is automatic, routed to whichever model did not write the code, and read-only. Day three needed six rounds before it went quiet. The expensive lesson came later, when a fix closed the finding it was aimed at and silently killed the feature it was fixing. The project answers questions out of aircraft maintenance manuals — one person, toy scale, synthetic XML.

On day three the review only happened because I asked for it. That is a bad place for a quality gate to live. Remembering is not a control, so the rule went in that week. As soon as the day's tests and lint are green, and before anything is proposed for merge, the review runs. Nobody asks for it.

The reviewer is never the model that wrote the code. Here the implementer is Claude, so the review is routed to Codex. I did not choose that for fairness. An implementer has already committed to a solution, and I did not want a second opinion from the thing that formed the first one.

It also cannot edit. It reports findings and stops, which sounds like friction until you notice that a reviewer allowed to fix things is a second implementer, and nobody has read the result.

And the stopping rule is not a score. A review ends when it stops producing new high-severity findings. On day three the instruction was to loop until the verdict came back SHIP, and that took six rounds. I did not enjoy watching the count go up. New blockers stopped after the third round, and rounds four to six still changed the code.

The part I had not thought about showed up later, on a deployment change. Eleven findings came back, all fixed. Then a second review ran on the fixes, told that they were unreviewed and to look for what they had broken.

One of the fixes had made a log line print with a timestamp and a level in front of it. The finding it was aimed at was closed. But the line was no longer pure JSON, so the log pipeline stopped parsing it into a queryable field, so the query written into both runbooks would have matched nothing in production. The feature was gone and the finding it belonged to was marked fixed.

Every test was green. The test that shipped with the fix split the line on " INFO " before parsing it. It asserted the bug.

That round came back with nine findings of its own. A round of fixes is code nobody has reviewed, written by someone who has just been told exactly what to look for. That is new surface, not closure.

Here, review quality came from the wiring. Not from anyone trying harder.