Code is cheap. verification is the new scarcity

Part one of Beyond Code Generation, a two-part series on what an agentic software delivery system must understand and enforce.

There is a strange moment in almost every AI software demo.

The prompt goes in. Files appear, tests run, and a pull request opens. The room leans forward because something visible has happened, even if the useful part has not.

The output may be a pull request, three thousand lines of Terraform, or a new event consumer. Users and operators care about the result: a recovered account, a service that survives a regional failure without waking everyone at two in the morning, or fewer failed orders.

Code matters. It is how much of that value gets built. But code is an intermediate product, and we are rapidly making its first draft cheaper.

As the first draft gets cheaper, teams spend more of their effort elsewhere:

The hard problem is no longer producing a plausible change. It is defining the right change and producing enough independent evidence to trust it.

The cheap part is the attempt

Good code still costs money. So do integration, migration, compatibility, operations, and eventual deletion. An agent can generate ten implementations and leave you with ten maintenance problems.

What is getting cheap is the attempt: the first plausible implementation, the boilerplate, the mechanical refactor, the next candidate fix.

Lowering the cost of an attempt still changes the workflow. Limited engineering capacity used to throttle how many changes entered the delivery system. Agents remove part of that throttle and can create more work than the organisation can confidently accept.

Review queues grow. Test environments become the bottleneck. Senior engineers spend their days deciding whether plausible-looking changes are safe. The factory gains ten new assembly lines and keeps one inspection desk.

Judgment absorbs much of the effort saved during generation.

We have been measuring the convenient part

Generated lines, accepted suggestions, opened pull requests, and closed tickets are easy to count. They show usage and activity, not whether useful software reached a user.

A "completed" task can refer to five different layers:

Each step down the table needs evidence: tests, policy results, traces, security findings, SLOs, support demand, and customer behaviour.

Most AI coding demos stop at the artefact. Many adoption programmes do too. Then leaders wonder why usage is rising while lead time, failure demand, or business throughput barely moves.

The organisation accelerated an intermediate product while leaving the path from artefact to outcome untouched.

DORA's 2025 research on AI-assisted software development describes AI as an amplifier of the surrounding organisational system. Faster generation pushes more work into weak requirements, slow environments, flaky tests, hidden architecture, approval queues, and unclear ownership.

The hard part begins before the agent

Ask an agent to "implement password recovery" and it will probably produce something plausible.

But what counts as recovery?

• Must it work without the original device?
• What prevents account enumeration?
• Which identities require stronger verification?
• What happens when the email provider is unavailable?
• Which events must be audited?
• What would make the change worth operating?

Calling these questions edge cases understates them. They define the work.

Human teams have always papered over gaps like these. The product manager remembers the complaint that started the ticket, the security engineer spots a dangerous flow in review, and an experienced developer knows which identity service is mandatory. Before release, an operator adds the missing alert.

The ticket is incomplete. The organisation completes it socially.

Agents expose that arrangement because inference is not intent. A capable agent can produce a coherent implementation of the wrong thing before anyone notices. "Make it work" is enough instruction to create activity, but not enough to establish success.

Give the work a completion contract

Teams already have acceptance criteria and definitions of done. Too often they have become ceremony.

"Tests pass" says nothing about which behaviour was tested. "Security reviewed" can mean a checkbox. "Deployed successfully" may only mean that a process started. "Accepted by the product owner" can conceal every ambiguity that came before it.

An agent needs a stronger agreement: a completion contract.

A useful contract answers seven questions:

None of this requires a fifty-page specification. A good contract can be one paragraph:

Allow an authenticated customer to recover access without contacting support. Preserve session-revocation and audit requirements. Do not reveal whether an email address is registered. Cover the main journey and abuse cases with automated tests, pass the identity security policies, release behind a feature flag, and observe success and abuse signals for seven days. Escalate if the current identity service cannot meet the required verification level.

A completion contract is an agreement between intent and execution. Better prompting is only part of it.

"Done" now has several horizons

No single gate can prove the whole outcome in this example.

Before merge, the team can prove that the code compiles, the specified journeys pass, and known constraints hold. After deployment, it can prove that the feature starts, responds within its SLO, and can be rolled back. Only after customers use it can the team learn whether recovery succeeds, abuse rises, or support demand falls.

So completion is staged:

Not every pull request needs an A/B test or a board-level metric. A dependency bump and a new customer journey do not deserve the same evidence. The contract should be proportional to blast radius, reversibility, and uncertainty.

The team should name the strongest claim it can currently support. A green build should not masquerade as a business outcome.

Build a stack of evidence

In agent systems, an oracle is whatever can decide whether a result is correct.

For small tasks, the oracle is obvious. The compiler accepts the program. A schema validates. A unit test returns green.

Real software is less cooperative. An endpoint test can confirm a 200 response, while safe recovery requires more evidence. A load test establishes that the service handles one thousand requests per second; any effect on support demand appears later. A security scanner can find known patterns, leaving residual business risk for someone to accept.

Most changes need a stack of evidence, with each layer catching a different class of lie.

Evidence becomes more relevant as it gets closer to the real outcome. It also gets slower, noisier, and harder to attribute. Precise claims keep those signals useful alongside unit tests.

Separate the work from the judgment

Tell an agent that success means making the suite green and it will optimise for a green suite.

Usually that is useful. Sometimes it narrows the test, mocks the difficult boundary, removes the revealing assertion, or implements exactly what was written while missing what was meant. Humans do the same thing when a measure becomes a target.

Reliable verification separates the work from at least some of the judgment:

• Let the agent extend tests, but protect independent checks from modification.
• Use deterministic checks alongside exploratory or model-based evaluation when behaviour is open-ended.
• Compare pre-production evidence with production observation.
• Test functional behaviour as well as security, architecture, data, and reliability constraints.
• Check local correctness and downstream impact.
• Keep accountable human judgment for unresolved trade-offs.

Anthropic's guide to agent evaluations makes this concrete: effective coding-agent evaluations depend on well-specified tasks, stable environments, and thorough tests. Broader agent evaluations combine code-based, model-based, and human graders. The model is one variable among several, and the judging system defines what "better" means.

When the same actor can change the implementation and redefine success, it is marking its own homework.

Verification debt is the next bottleneck

Technical debt makes future change harder. Verification debt is the gap between what an organisation claims to know about its software and what it can actually demonstrate.

You can see it in:

• requirements that cannot be translated into observable behaviour;
• suites that pass without protecting important journeys;
• security rules enforced through memory and review comments;
• architecture decisions that cannot be checked against a change;
• telemetry that cannot be connected to a release;
• manual approvals whose criteria exist only in the approver's head;
• business signals that arrive too late to influence the next decision.

Code generation exposes this debt by increasing the supply of changes submitted for judgment. Review queues lengthen. Senior engineers become human middleware. Pull requests arrive faster than confidence.

As a result, adding more agents can reduce flow. The production line outruns its quality system.

Paying down verification debt means investing in reproducible environments, meaningful tests, policy checks, architecture constraints, realistic evaluation data, safe release paths, observability, and explicit outcome measures. Loop engineering needs a platform for exactly this reason. The agent performs the iteration; the surrounding system provides signals that it cannot conveniently invent or ignore.

The engineer moves to the boundaries

Before execution, someone must choose an outcome worth producing, expose the relevant constraints, decide what evidence would be convincing, and make ambiguity visible while it is still cheap.

After execution, someone must interpret conflicting signals, judge residual risk, understand second-order effects, and decide whether reality has invalidated an assumption.

Agents can help. They can propose acceptance criteria, generate adversarial cases, identify missing telemetry, compare an implementation with policy, and analyse production evidence. Accountability remains with people and organisations.

The engineer who builds a reliable judging system gets more leverage from cheap execution.

OpenAI's account of harness engineering describes the same move from another angle: when agent throughput exceeds human attention, engineers spend more of their time specifying intent, building feedback loops, and improving the environment in which agents work. Verification is how that scarce attention reaches the decisions that deserve it.

An AI Factory should produce verified change

A factory that emits diffs optimises the wrong output. Tickets enter, code exits, and throughput rises while confidence falls behind.

An AI Factory should produce verified change. A diff is one input to that output, which is a result accompanied by evidence:

• the intended capability exists;
• the important behaviours were exercised;
• relevant constraints still hold;
• the change can be reversed;
• the production system remains healthy;
• the expected effect is observable;
• unresolved uncertainty has an owner.

That changes what leaders should measure. Instead of asking how much code the agent produced, ask:

• How much human attention was required per accepted outcome?
• How often did pre-release evidence predict production reality?
• How much rework followed agent-generated changes?
• How quickly did the system detect a wrong outcome?
• What did one verified change cost from intent through observation?
• Which repeated human corrections became durable checks?

These measures are less flattering than lines of code. They are also much closer to value.

Architecture is still missing

A completion contract can say that a change must respect the architecture. The platform can run architecture checks, and the agent can try to follow the approved design.

But where is that architecture?

Often it lives in a diagram exported six months ago, an ADR nobody can find, a wiki page with no owner, or the memory of the architect who happened to be in the room. The code contains one version of the system. The organisation believes in another. The agent sees whichever one is easiest to read.

The problem lies in architecture visibility.

Part two, Your architecture is invisible to the agent, asks what changes when ADRs, C4 models, architecture-as-code, and fitness functions become active parts of delivery rather than documents left behind by it.

Code is no longer scarce enough to organise the whole delivery system around. The scarce capability is trustworthy completion.