# The bottleneck moved to code review

Senior engineers keep telling me the code smell in their own repositories has never been worse, and these are people paying for the best models on the market.

The frontier models are very good at producing code that clears a test run and lands awkwardly in review. Code arrives faster than the hours available for reading it, and that gap is the half of the problem worth writing about.

## The queue that never got faster

A change that took a day to write used to take an hour to read, and that ratio was survivable.

Generation collapsed the first number and left the second exactly where it was. What a team can ship is capped by how many diffs a human will genuinely read in a week, and genuinely is carrying the sentence. Skimming scales beautifully. Careful reading costs what it cost in 2019, out of the same eight hours as everything else.

I have no numbers of my own here and I distrust most of the ones going around, so the question I can answer is smaller.

Of the review habits I already had, which ever caught a defect, and do those defects look like the ones a model produces? Two of them do. The rest are decoration.

## A green suite is a weak signal

Ask a model to cover a controller and it hands back this shape every time, because this shape is the one you can infer from the controller and nothing else about the requirement is inferable from it at all.

// green forever, on correct and incorrect implementations alike
public function test_creates_a_leave_request(): void
{
    $res = $this->postJson('/api/leave', $this->validPayload());
    $res->assertStatus(201);
    $this->assertDatabaseHas('leave_requests', ['id' => $res['id']]);
}

The test and the implementation share an author now, and they share that author's reading of the requirement. When the reading is wrong the two agree, the suite goes green, and the reviewer sees a checkmark manufactured by the same process that made the mistake.

That is the mechanism behind code that clears a test run and stalls in review. The green tick reports agreement between two artefacts that came out of one reading of the ticket.

The tests that ever did catch something in that suite were the ones I had to leave the editor to write, because the answer lived in a labour regulation or in a table of who belongs to whom. A reviewer scrolling a hundred changed lines rarely has either loaded, and an assistant reading the same diff works from the same hole.

## The defects that live between the boxes

A rate limiter I shipped was correct in every file it touched and still waved the thirtieth request of a burst straight through, because one default in one bootstrap line meant every request opened a counter of its own. No file in that repository described the thing that was wrong.

Paste that diff into any model and ask what is wrong with it. You get a competent answer about the guard, and the guard was never the problem.

Same for an activity engine with thirteen handler types behind one config column, where the failures worth having came from renaming a handler while old rows kept pointing at the old key. Faster review does nothing for a defect whose only evidence sits in a running system.

## What I do at the top of a diff

The best habit I have picked up belongs to reviewers drowning in junior pull requests. Read the code yourself first, mark the lines you are unsure about, and only then hand the diff to a model pointed at those lines.

The ordering does the work. Read a summary first and you are anchored to it, checking the summary against the code instead of checking the code.

The second habit annoys whoever wrote the change. A pull request should carry the command someone ran against the deployed service and the output that came back, which for a rate limiter is six status codes in a row. Authors hate this.

It is the one artefact a generation step cannot manufacture, because the model has no deployed thing to point a request at. The reviewer stops guessing whether the change was ever exercised outside a test process.

Neither habit scales the way generation scales, and that is exactly what recommends them. The evidence I want at the top of a pull request is one line copied out of a terminal that was talking to production: 200 200 200 200 200 429.