Code Is No Longer the Scarce Resource

I can already see a scene at work that would have seemed unusual not long ago. A team builds AI tools for pull request analysis, supplying repository context, agents, and skills. Meanwhile, the developer who opened the PR uses agents of their own to interpret findings, propose fixes, and even argue with the automated reviewer.

One machine writes. Another machine reviews. The first responds.

A person remains in the middle, responsible for deciding whether the change belongs in the product.

Automation on both sides is not what concerns me. I use it, and I find it valuable. The less visible problem is that a conversation can grow until it looks rigorous without producing the same growth in human understanding.

A thread full of comments, tests, and explanations is not yet a mental model. Review activity is not necessarily oversight.

Scarcity moved downstream

For a long time, we treated code as the expensive part of software development. Someone had to translate an intention into an implementation, navigate the system, and keep enough decisions in their head to make the change work.

Agents reduce some of that cost. They can explore a repository, produce a first version, add tests, and respond to feedback at a speed that changes the economics of the work. But every change they generate creates a downstream obligation: someone must establish what it does, what it could break, and whether the evidence offered deserves trust.

Production accelerates. Responsibility does not.

That is why I have started to think that code is no longer the scarce resource. Reviewer attention is not the whole constraint either. The scarce resource is our ability to turn evidence into understanding, and understanding into responsibility.

I use verification debt to describe the distance that appears when we accumulate changes faster than we can understand and justify them. It is not an established metric or a new name for defects. It is a way to recognize work that tends to disappear from planning: reconstructing intent, checking assumptions, assessing blast radius, and deciding who is willing to own the result.

The paradox predates LLMs

In 1983, Lisanne Bainbridge published Ironies of Automation. Written about industrial processes, its argument remains uncomfortable: automation can expand the human operator’s problems instead of eliminating them. The system handles routine work and leaves people with abnormal conditions, precisely when preserving context and skill is hardest.

A pull request is not an industrial plant. But I recognize the same structure. We delegate production and some analysis, then ask a person to intervene in the ambiguous and consequential decisions with less time to reconstruct how the system arrived there.

Automatic explanations do not necessarily solve the problem. An experiment presented at ICIS 2025 studied 3,002 decisions from 228 people screening early-stage innovations. Evaluators receiving AI assistance were 19% more likely to align with its recommendation. Narrative explanations increased that alignment, but did not improve decision quality over a black-box recommendation.

The study was not about code. The mechanism is what matters to me: a coherent explanation can become a shortcut for accepting a conclusion. A narrative supports understanding only when we test it. It can also make us feel that understanding has already happened.

The table does not prove that AI makes every team worse. It does not show that automated comments have no value. It shows something more useful: producing more changes and more signals does not eliminate the cost of deciding which ones matter.

More review does not always produce more understanding

The temptation is natural. If one agent can introduce mistakes, add another agent to find them. If its comments create noise, add a third to rank them. If two agents disagree, ask both to make their case.

This can work. It can also create a simulation of independence.

Two agents given similar context, built on related models, or checking the same incomplete test suite may agree because they share blind spots. Their consensus does not become independent evidence simply because it appears in two messages.

Human participation has a similar failure mode. Anthropic reported that its users approved roughly 93% of permission prompts. The company describes this as approval fatigue and has moved some safety work toward deterministic boundaries in the environment.

A permission prompt is not a code review, but both can degrade into ceremony. When a system asks for too many confirmations, human presence stops guaranteeing human attention. In a PR, that state resembles review theater: comments, replies, and an approval button are all present, but no one can clearly explain which evidence changed the decision.

I do not want to measure process quality by the number of reviewers, agents, or messages. I want to know which claims were confirmed, which were contradicted, and which uncertainty remains open.

From verdict to review contract

The usual instruction to an agent is too broad: “review this PR.” It delegates both the investigation and the implicit definition of what being correct means.

I would change the order. Before seeing the agent’s verdict, the reviewer should write a review contract:

1. What I expect to change
2. Which risks matter
3. What evidence I would need to approve it
4. What cannot be resolved automatically
5. Who owns the final decision

I would not ask an agent to decide whether a PR is good. I would give it a contract and ask it to investigate whether the conditions exist for me to take responsibility for the change.

The example is fictional, but the difference is concrete. “Find bugs” produces an open-ended list of possibilities. The contract directs the investigation toward properties that can support a decision.

1. 01IntentThe author explains what should change and what remains out of scope.
2. 02ContractThe reviewer defines risks and evidence before seeing a verdict.
3. 03InvestigationThe agent inspects the diff, context, tests, and runtime.
4. 04FindingsIt separates evidence, contradictions, gaps, and unknowns.
5. 05DecisionA person decides whether they can own the change.

This sequence introduces friction on purpose. Research on cognitive forcing functions shows that asking people to form a judgment before seeing an AI recommendation can reduce overreliance, though people also rate the experience less favorably.

I would not apply that friction equally to every change. A copy correction does not require the same contract as a change to authorization, money movement, concurrency, or a data schema. Rigor should grow with blast radius and difficulty of reversal.

The agent delivers evidence, not the verdict

The contract also changes the shape of the response. A useful result does not end with “LGTM” or an abstract score. It should distinguish at least four categories:

• Confirmed: properties supported by executed code, tests, invariants, or observable behavior.
• Contradicted: contract conditions for which contrary evidence exists.
• Missing: plausible claims that still lack sufficient verification.
• Unknown: questions that the repository and available tools cannot answer.

This separation matters because evidence does not have uniform weight. A generated explanation can help me navigate. An executed test, a database constraint, or a runtime observation can support a stronger claim. None of them removes the need to ask whether the evidence covers the right property.

It also returns responsibility to the author. Whoever opens a PR should be able to explain intent, decisions, boundaries, blast radius, and evidence even when an agent wrote every line. Delegating implementation should not allow us to delegate comprehension to the reviewer.

The contract does not solve the deeper problem

It would be convenient to stop here and turn these five questions into another template. That would repeat the solutionist bias I am trying to avoid.

The deeper problem is capacity and incentives. If an organization rewards change volume while treating review as a stage to compress, no prompt will restore lost attention. The contract only makes visible that every PR consumes a budget of understanding.

When that budget runs out, the answer cannot always be another automated reviewer. Sometimes it must be:

• split the change;
• reduce work in progress;
• run the cheapest deterministic evidence first;
• reserve deep review for material risk;
• reject changes whose proof cost exceeds their value;
• or accept that producing less is the technically responsible decision.

Recent work on agentic review reinforces the need for caution. An analysis of 1.02 million reviewed PRs across 207 projects found faster decisions in some agent-involved patterns, but not a consistent improvement in quality. Another study of AI-generated pull requests warns that recorded activity may be dominated by automation and should not automatically be interpreted as human oversight.

Both are recent preprints. I do not treat them as a final verdict. I read them as a reason to stop using speed, comment count, or the presence of a reviewer as proxies for understanding.

Approval means accepting responsibility

I do not want to slow down the use of agents. I want to reserve their capacity for the work they do best: exploring large surfaces, checking explicit conditions, running tests, connecting changes, and exposing contradictions.

Human judgment begins where that evidence ends.

To me, approving a PR should mean something more demanding than exhausting an automated conversation:

I understand the intent, I reviewed the evidence, I know the blast radius, and I accept responsibility for integrating this change.

That standard does not guarantee perfect software. Human reviewers make mistakes too. Its advantage is different: it makes explicit who formed the judgment and what supported it.

When code becomes abundant, review stops being an administrative stage in the process. It becomes the capacity that determines how much software an organization can truly own.

We do not need an agent to have the last word. We need it to help assemble the evidence that allows a person to have theirs—and stand behind it.