'Nobody Reads the Code' Is Not the Flex You Think It Is

Ankit Jain, writing for Latent.Space, argues that code reviews are a dead practice walking:

Human-written code died in 2025. Code reviews will die in 2026.

He's got data to back up the bottleneck claim: teams using AI heavily are merging almost twice as many pull requests, but review time has nearly doubled too. The maths doesn't close. You can't review your way out of exponential output with linear eyeballs.

So far, fair enough. Anyone who's watched a 400-line diff sit in a review queue for three days while the author context-switches onto something else knows the ritual was already strained. Jain's right that the honest name for most code review is "skimming with good intentions."

His proposed replacement is a layered verification stack: specs as the source of truth, competing agents, deterministic guardrails, BDD-style acceptance criteria authored by humans, adversarial agents red-teaming each other. The Swiss-cheese model. No single gate catches everything, but stack enough imperfect filters and the holes stop aligning.

It's a useful framework. The BDD revival angle is the best part — specs were always a good idea that felt like extra work when you also had to write the code. If agents handle the implementation, the spec stops being overhead and becomes the primary artifact.

Here's where it falls apart.

The entire pyramid rests on one assumption: that humans will write correct, complete specs. But anyone who's spent a week in software knows that the hardest bugs don't live in the code — they live in the gap between what you specified and what you forgot to specify. "The agent implemented the spec perfectly" and "the system does the right thing" are not the same sentence. Jain's framework catches the first failure mode and waves at the second.

There's also the commercial angle. Jain is the CEO of Aviator, which sells infrastructure for AI-native engineering teams. Several of his "verification layers" link to Aviator products. That doesn't make the argument wrong, but it does explain why the piece is more confident about the destination than the journey. When you sell shovels, every problem looks like a gold rush.

The closing line is telling: "If agents can handle the code just fine, what does it matter if we can read it or not?" It's presented as a mic drop. It's actually the hardest open question in the entire essay, and treating it as rhetorical is doing the reader's thinking for them.

Nobody's arguing we can manually review every line of agent-generated code. That ship has sailed. But "we can't read all of it" is not the same as "we don't need to read any of it." The space between those two claims is where the interesting — and difficult — engineering decisions actually live.

The piece diagnoses a real problem, proposes a reasonable direction, then overshoots the landing by about three years of earned confidence.