# Code readability is no longer the bar

**Topic:** Engineering practice · **Published:** October 2026 · **Reading time:** 6 min

For most of my career, code review started with one question: can the next engineer read this? We argued about names, function length, comments and file layout. A human had to understand the code before anyone could change it safely, so it made sense.

I don't think it's the right first question anymore. My AI agents shipped about 4,000 changes in under six months. Before each one merged, an independent AI reviewer approved it, not a human.

What decided whether a change shipped was whether it met the business rules, whether it was secure, whether it was fast enough, and whether the output was right on the screen, in the stored data and in the API response. Readability for humans never made that list. I'll explain why, and where structure still matters for a different reason.

## Models read what humans struggle with

A current model can work through a 2,000-line file, a long chain of calls or a framework it has never seen, and a human reviewer would slow down on all of that. It doesn't get tired at the end of a long review and it doesn't skip the boring file. When a builder agent needed to change a screen, it read the files its brief named and made the change.

So a review comment asking to rename a variable or split a function "for clarity" is now an expensive comment. It costs a round of review and changes nothing the user sees.

In October I ran four pilots with a small, cheap model (Claude Haiku 5.5) as the builder. From the second pilot on, a strong planner split each task into small items, and an independent reviewer checked every result. I tracked everything the reviewer rejected in the first round.

None of the misses came from code the model couldn't understand. The planner fixed one page and missed a sibling page with the same pattern. A builder didn't know a shared table component couldn't wrap text, because the brief never said so. A test that searched the source for a string passed while the text on the rendered screen was still wrong. Those are requirements and verification problems. The fix was a better brief and a better check.

## The months I spent on clean code

I learned this the expensive way. For months I tuned the agent workflows to keep the codebase clean: no repeated code, lean modules, shared components, strict formatting. I wrote briefs about it, ran detectors for it and sent changes back in review for it.

Some of that was worth doing. Much of it was really a bet on cost. If the code is lean, every agent reads less and every task is cheaper.

That bet loses to the price curve, because the newest levels of intelligence usually get cheaper fastest. In September 2026, [Epoch AI](https://epoch.ai/publications/the-plunging-price-of-thought) measured the cost of a performance level falling about 75 times a year right after it first becomes state of the art. On one science benchmark, the cost per question for the same score fell 725 times in under 18 months. In October 2026, [Artificial Analysis](https://x.com/ArtificialAnlys/status/2112582116651466965) reported that the cost per task to reach a score of 30 on its intelligence index fell 86 times in about eight months, from $2.49 in February 2026 to $0.03. A score of 40 got 33 times cheaper in about five months. A lower score of 20, reached earlier, got 123 times cheaper in about 13 months. Each level got about 100 times cheaper within roughly a year of first being reached, and score 30 came close to 100 times in only eight months.

My own numbers show how cheap good-enough building already is. In the October pilots, the cheapest builder cost about $0.015 per item and missed fewer items than a mid-tier model at about $0.24 per item. Making a codebase leaner saves a share of a cost that has kept shrinking on its own.

The top models do cost more per task, about 11 times more than a year ago, but they are far smarter: the top score on that index rose from 21 to 58 in the same year. A task that needed last year's best model now runs on a much cheaper one, and a builder rarely needs the frontier.

![Bars show cost per task falling 123, 86 and 33 times for scores 20, 30 and 40.](/assets/writing/readability-is-not-the-bar-1.svg)

Weeks of an engineer's time spent making code cheaper to read don't pay back when reading gets that much cheaper on its own.

## What replaces readability

If a model reviews the code, the code has to prove itself some other way. Each change ran its affected tests in the build phase, and the full suite ran every night. A red nightly result became a new task. A builder never reviewed its own work. The reviewer checked every item of the task against the diff and approved one exact version, so if the change moved, the approval didn't move with it.

On changes that touch sign-in, infrastructure or security, the reviewer checked the server path and not only the screen, and had to say what it didn't verify. A dependency-security scan ran before a change went up for review. For anything a user sees, screenshots of the affected screen went to the reviewer, because a passing build doesn't prove the screen is right. And on a regular schedule, a staging gate built, deployed and ran smoke tests and sign-in scenarios before a human decided on production.

None of this cares whether a human finds the code pleasant to read. All of it cares whether the code does the right thing.

## What cheaper models don't fix

Falling prices weaken the cost reason for clean code. They don't remove every reason. I keep two, because they're about correctness and not cost.

The first is one rule in one place. When the same business rule lives in five places, the agent has to find all five. The planner missed same-pattern sibling pages more than once, and a cheaper model doesn't make a missed copy any less wrong.

The second is small changes. A reviewer, human or model, checks a 50-line diff better than a 5,000-line one. In my pilots, small, clear items gave fewer first-round misses (4) than whole-task briefs (7).

![Whole-task briefs had 7 first-round misses; small, clear items had 4.](/assets/writing/readability-is-not-the-bar-2.svg)

Formatting I hand to a tool. A formatter rewrites every changed file and the gate checks it, so reviewers don't block a change for formatting. Everything else I used to enforce for readability, I now let go. I spend effort on what proves the output is right.

If you're starting with agents, I'd stop spending review rounds on style, write the business rules down as tests before an agent touches the code that holds them, and look at the rendered screen, the API response and the stored data, not only the diff. I'd also count your misses. If they come from scope and checks like most of mine did, fix the brief and the tests, not the naming.

How the agent team itself works is in [Where I still stand in an agent team](/writing/near-the-loop/), and the builder pilots are in [How I cut 45 AI agents to 10+ long-running lanes](/writing/45-agents-to-10/).

Email [hello@jeffkent.dev](mailto:hello@jeffkent.dev) to talk about shipping AI-written code you can trust.