AI coding agents make code abundant — and verification scarce

For most of software history, writing the code was the expensive part. A feature could wait days for an engineer to find the time, understand the system, and turn an idea into a pull request.

AI coding agents are compressing that step. Give one a ticket and enough context and it can produce a plausible implementation before the next meeting starts. That looks like the bottleneck disappearing.

It isn’t. It moved.

The scarce resource is no longer the ability to produce a diff. It is the ability to prove that the diff is correct, safe, and worth shipping.

A pull request is not progress

Generated code has a dangerous property: it arrives looking finished. The files are changed, the types pass, the explanation sounds confident. The visible work is complete, so the remaining work feels like ceremony.

But a plausible implementation is only a hypothesis.

It may satisfy the ticket while violating an assumption that never appeared in the ticket. It may handle the happy path and quietly corrupt an edge case. It may duplicate a capability already present elsewhere, add a dependency nobody wants to own, or turn a cheap request into an expensive one.

The agent does not need to be incompetent for this to happen. It only needs an incomplete model of the system — which is exactly what tickets, repositories, and documentation usually provide.

Before agents, the cost of writing code limited how many hypotheses a team could produce. Now that limit is weaker. A team can generate changes faster than it can understand their consequences.

More pull requests can therefore mean less progress.

The queue moved downstream

Imagine a team that used to open ten meaningful pull requests per week. Review, testing, and release could absorb roughly ten, so the system remained balanced.

Now agents help the same team open thirty.

If review capacity is still ten, throughput has not tripled. The queue has. Work sits longer, reviewers skim larger batches, and authors context-switch while waiting. Eventually the team lowers the review bar just to keep the board moving.

That is not AI leverage. It is inventory accumulation.

Software has its own version of work in progress: unreviewed diffs, untested assumptions, unreleased branches, and changes whose original context is already fading. Each item creates coordination cost and risk. Generating it faster does not make the system faster unless the downstream stages improve too.

The metric that matters is not code produced. It is verified change in production.

Verification is more than testing

Tests matter, but passing tests do not prove that a change should ship. They only prove that it satisfies the assertions someone thought to write.

Real verification has at least four layers:

Intent. Does the change solve the actual user or business problem, or merely the literal wording of the ticket?

Behavior. Does it work across expected inputs, failure modes, permissions, and state transitions?

System fit. Does it respect the architecture, security model, performance budget, and conventions that keep the codebase operable?

Operational safety. Can the team observe it, limit its blast radius, and roll it back when reality disagrees with the test suite?

An agent can help collect evidence at every layer. It can write tests, inspect call sites, run static analysis, and summarize risk. But it cannot decide what evidence is sufficient unless the team has made that standard explicit.

Without a verification policy, “the agent says it works” becomes the new vibe check.

Build a system that can absorb speed

The answer is not to reject generated code or force every change through a slower human ritual. It is to redesign the delivery system around a higher rate of change.

Start with smaller diffs. Agents make it cheap to generate broad solutions, but broad solutions are expensive to verify. Constrain the task, cap the change surface, and separate refactoring from behavior changes. A small diff is not just easier to review; it is easier to reason about.

Require executable evidence. Every change should arrive with the tests, checks, or reproducible commands that support its claims. “Implemented” is a statement. A failing test before the change and a passing test after it is evidence.

Make constraints machine-readable. Architecture rules that live only in a senior engineer’s memory cannot guide an agent. Encode what you can in types, linters, dependency boundaries, schemas, security policies, and CI. Documentation explains the rule; automation enforces it.

Use risk-based review. A copy change and a new authorization path do not need the same process. Classify changes by blast radius, reversibility, data exposure, and operational impact. Automate the low-risk path and spend human attention where judgment is actually scarce.

Finally, close the loop in production. Feature flags, telemetry, staged rollouts, and rollback paths turn deployment from a leap of faith into another verification step. Pre-merge confidence will never be perfect. The system must be able to learn safely after release.

The new engineering advantage

Access to code generation will not be a durable advantage. Every team will have capable models, integrated tools, and cheap tokens.

The advantage will belong to teams that can verify and deploy machine-produced changes without losing control of the system. They will know which constraints to encode, which evidence to demand, which risks require human judgment, and which changes can move automatically.

AI makes code abundant. Abundance does not remove engineering discipline; it makes discipline the limiting factor.

Do not optimize for how quickly an agent can open a pull request. Optimize for how quickly your system can turn an uncertain change into verified value.

Systems > Emotions.