The code got cheaper. The reading didn't

Writing code is now close to free. Reading it costs exactly what it cost in 2019.

I have not seen a workflow that has reconciled those two facts, including my own, and I think the gap is the most interesting thing happening in day-to-day engineering right now.

The two costs used to be the same number#

For most of my career, generation capacity and review capacity were the same quantity, because the same person paid both. By the time a function compiled I had read it four or five times. Understanding was not a separate stage anyone scheduled. It fell out of the act of typing.

Code review existed on top of that, and it worked, but it was never load-bearing in the way we now need it to be. It was a second opinion on something that had already been understood once. It was also rate-limited by a person writing at human speed, which meant review capacity was never seriously tested. It was never the constraint.

It is the constraint now. The producing half got an order of magnitude faster and the reading half got nothing at all.

The failure is quiet#

Nobody decides to stop reviewing. That is what makes this worth naming.

What happens instead is that the definition of "reviewed" softens. You read the diff on Monday. On Thursday you scan it, because there are four more behind it and each one looks broadly like something you have already approved. The shape is right. The naming matches. It probably does what the summary says it does.

There is no moment where you chose to trust the machine. There is only a standard that dropped a little each day while the throughput number went up, which is exactly the kind of drift that does not show up until something is in production.

"It passes the tests" answers a different question#

The most common reply is that reading code is the wrong altitude. Test the behaviour, not the implementation. If the suite is green and the thing works, what exactly was gained by a human parsing every line?

Taken on its own terms this is a good argument, and for a genuine black box I agree with it entirely. I use libraries every day whose internals I have never read.

But a test suite encodes the failures somebody thought of. The bugs that have cost me the most were never in that set. A permission check that is correct for four roles and quietly wrong for the fifth. A retry that is harmless until the dependency is slow rather than down. An integration that rejects a document without saying which element failed, so the error surface you are testing against is not the one production has. None of those are boundary problems. You find them by understanding the thing, or you find them from a customer.

There is also a second-order cost. Code that nobody has read is code that nobody can change confidently later. That bill arrives months after the commit, which is why it never gets attributed to the decision that caused it.

What I actually changed#

None of this is clever. All of it points the same direction.

• Ask for a plan before code, and reject the plan when it is wrong. A wrong paragraph costs a paragraph. A wrong file costs a file plus everything built on it.
• Cap the diff at what I can hold in my head in one sitting. If I cannot, the task was too big, and that is a scoping failure rather than a review failure.
• Prefer the smaller version of the change, even when the larger one is free to produce. Free to produce is not free to own.
• Read hardest where I can check least. Anything touching permissions, money, or data that leaves the building gets read line by line or it does not ship.

The uncomfortable summary is that the only real lever is asking for less. Reading does not have a faster setting.

Where I might be wrong#

I hold this loosely, and there are two arguments I keep taking seriously.

The first is that I am defending a skill rather than an outcome. Nobody reads the assembly their compiler emits, and the people who insisted on it in 1975 were not wrong about the risk, they were wrong about where the abstraction line would settle. It is entirely possible that "reads every line of generated code" is a 2026 attachment that looks quaint in five years, and that the correct investment is in verification rather than comprehension.

The second is that my sample is small and specific. I build enterprise systems where the hard parts are integration edges and permissions, and those are exactly the areas where reading pays. Someone shipping a product with a clean domain model and a serious property-based test suite has a different economy, and might reasonably conclude the opposite.

So a genuine question rather than a rhetorical one, because I do not think this is settled and I would rather be corrected now than in production:

What proportion of the agent-written code on your main branch has actually been read line by line by a human, and is that the number you would put in writing?