AI is making code cheaper to produce. That however doesn’t make software cheaper to own.
AI has dramatically increased the amount of code an engineer can produce. It hasn’t necessarily increased the amount of software an organization can safely own. Agents implement features, write tests, review their own work and fix the defects they find. So why should anyone read every line?
In Migrating Scarcity, I argued that when technology makes something abundant, scarcity moves to the next constraint. Code production is becoming abundant. The ability to establish that code is correct, safe and worth deploying is not expanding at the same rate. Code review needs to be rethought around that gap.
Passing tests is not the same as being correct
Let’s say we have an agent that implements a pricing change. It writes the code, generates the tests, runs static analysis and reports that everything passes.
Should a human read the diff? Maybe not. But someone still has to confirm the pricing rules are right. The implementation may faithfully execute a specification that left out an important business exception. The tests may cover every requirement in that specification. The agent may review its own work and find nothing wrong.
Everything passes, and the business still loses money.
Automated verification is only as good as the properties it checks. A type checker establishes certain facts about a program. A test suite shows that specific behaviors work under specific conditions. Neither shows that the right problem was solved. Automate verification wherever you can, but someone still has to decide what correct means. That decision matters more as code gets cheaper.
Three questions that decide where humans belong
Most organizations still run code review as a uniform ritual: someone writes, someone reads, the pull request merges. It was never a precise way to spend engineering judgment, and AI makes that obvious. A thousand lines of generated boilerplate may carry almost no risk. A five-line change to an authorization rule can expose customer data. Reviewing both the same way makes no sense.
I use three questions.
What happens if this is wrong? A defect in an internal prototype is not a defect in a payment system. Reversibility, blast radius and security exposure matter far more than line count.
Can correctness be verified independently? Some changes have clear contracts, strong tests and well-defined invariants. Others involve ambiguous requirements or business rules that are hard to state completely.
Who can recover the system when it breaks? A change can be correct today and still become a liability if nobody understands it well enough to diagnose it during an incident.
The principle that follows: the greater the consequence of failure, the stronger the independent evidence we should demand. Human attention belongs wherever that evidence is insufficient, whether that means reviewing code, specifications, architecture or operational readiness.
The 2 AM test
Imagine an agent builds a new subsystem. Every test passes, performance is excellent, security scans are clean. Six months later it fails at 2 AM.
Can the team explain the system’s critical assumptions, isolate the failure and recover service, even if the agents that built it are unavailable?
Nobody needs to understand every line. But if the team can’t operate the system without the agent that wrote it, what did the organization actually acquire? Cheap code with expensive ownership. In my native language Malayalam – we say you just bought an expensive dog that bites you 🙂
AI reviewing AI is not necessarily independent evidence
Suppose one agent writes the code, another writes the tests, a third reviews the implementation and a fourth fixes what the third finds. That sounds thorough.
But different agents are not necessarily independent reviewers. They may share training biases, assumptions or misunderstandings of the specification. Four checks can still miss the same error.
Agent review is valuable and should be used heavily. But count the confidence your checks justify, not the number of checks performed. Independent specifications, adversarial tests, production observation, fault injection and explicit business invariants can provide stronger evidence than asking a second model whether the first one did a good job.
The honest objection: human review was already unreliable
Plenty of human review is just rubber-stamping. Nobody reads a 3,000-line diff carefully. Approval is often a formality.
That is true, and it strengthens the case for reallocation. Reading everything produces the appearance of assurance. Reading the right things, with the authority to stop a release, produces the real thing. Humans should be reviewing specifications, business invariants, security boundaries, architecture and recoverability, and periodically sampling the automated process to catch failures in the process itself.
Accountability belongs here too. Every production change needs an accountable owner who accepts the evidence for deploying it and knows how the system will be operated. Removing manual review doesn’t remove that responsibility.
Who gets to learn?
Code review was never a perfect training mechanism, but it was one way engineers met unfamiliar code, questioned design choices and learned how a system fit together. If senior engineers only review the hardest problems and agents handle the rest, junior engineers lose the path to becoming the people who can handle those problems.
Watching agents succeed does not build judgment, and preserving low-value review rituals just to keep juniors busy is no answer either. Judgment comes from making decisions and living with the consequences. That means owning bounded changes, predicting failure modes before seeing an agent’s analysis, joining production diagnostics, and explaining why an implementation satisfies a business requirement.
This is no longer just a code review problem. Who gets the difficult work? How do we establish readiness for greater authority? Who pays to develop expertise when AI produces the immediate output more cheaply? Without deliberate answers, productivity can improve while engineering capability erodes.
The next scarcity
A company can have excellent automated tests and poor architecture. It can have secure code that nobody knows how to recover. It can have strong senior engineers today and no credible way to develop their successors. Reading every diff solves none of these, and neither does eliminating review.
The irony is that AI makes engineering judgment more important while potentially removing the work through which engineers learned to develop it.
The goal is not less human review. It is putting human judgment where it changes the outcome, and being able to say why the rest can be trusted.
Stop measuring how much code humans review. Start asking what justifies trusting the code they don’t.
