What changed in delivery: engineering with AI agents

My 21 years of career — 15 in corporate financial governance, 6 in software engineering — left me with one criterion for judging any change: what it does to the balance sheet. The arrival of AI agents in software delivery passes that criterion without difficulty, which is why I find the discussion unproductive when it drifts from the useful question. Nobody has to believe that agents write code. The question is what happens to the act of review once the amount of plausible code stops being the scarce resource.

When I started, delivery was constrained by three things at once: typing, reviewing, and holding domain context. Typing stopped being the bottleneck, and domain context was never written down anywhere — it always lived in whoever was reviewing. What is still scarce is review attention, and that resource shows up on no dashboard. That is why delivery changed in shape: not because writing got faster, but because reviewing got more expensive.

The unit of work is no longer the diff

A large diff is not a large delivery; it is a large cost of reading. With agents the natural temptation is to delegate the implementation and review at the end. That works until the first time review stops being reading and becomes an audit, because nobody in the process knows why each decision was made. What I can safely delegate is the implementation. The acceptance criterion never is.

Verification replaced authorship

For decades, authorship was the quality signal: the one who wrote it understood it. With agents, the strongest signal becomes the test that proves the behavior. The asymmetry favors engineering: writing 300 lines of test is far cheaper than writing 3,000 lines of implementation, and it is the exact inverse of what urgency rewards. The craft did not shrink; it moved to the artifact that code cannot replace.

1. Write the assertion before you delegate. Without an executable acceptance criterion, an agent optimizes for looking correct — and looking correct is the hardest failure mode to catch in code review.
2. Treat the test suite as an executable specification. It is the only artifact that survives regeneration of the code, and the only one an auditor accepts without redoing the work.
3. Automate whatever you do not want to read. A cheap automatic check is worth more than a block of code reviewed at partial attention.

Cost per attempt is a line on the statement

An agent that calls a third-party API, runs paid inference, or touches a production system charges you per attempt. And a retry, in that context, is not recovery: it is expense. In accounting terms that is cost per attempt, and it is exactly the number that goes missing when delivery appears to be free.

The remedy is not to police the team; it is to make the attempt visible: a budget per operation, idempotency wherever a side effect exists, and cost recorded along the same path as the latency metric. Where the team cannot see the cost, the team cannot reduce it.

Context is the new design bottleneck

Design used to live in the code and in the head of whoever drew it. Now it has to live in the brief — which is an improvement, because a written and reviewed brief beats implicit design. It is also more work, and work that cannot be skipped. An agent delivers exactly the scope it was given, no more and no less. Scope quality is now delivery quality.

task:
  context: "<the domain in three lines>"
  invariants:
    - "<what must not break>"
  interface: "<public signature, no internal detail>"
  examples:
    - "<input> -> <expected output>"
  do_not:
    - "<what is out of scope>"
  acceptance: "<the command that proves it is done>"

The item most prompts omit is do_not. Without it, an agent optimizes for appearing complete and hands you refactoring, extra coverage and abstractions nobody asked for. A declared scope is the engineering equivalent of a reconciliation: without it, every number looks clean and means nothing.

What did not change

Accountability for the outcome still belongs to a person, and the difference is that this person now has to understand enough to disagree. Someone who cannot evaluate what was generated should not be approving what was generated. That was true five years ago. It matters more now, because the volume being approved is much larger.

• Ownership of the outcome. Signing the merge means owning the production behavior, including the part the agent suggested.
• The accounting of the decision. Every change is a liability with interest. Agents do not change that equation; they only raise the speed at which you take on the liability.
• The craft of review. Judging code rigorously takes years and does not outsource to a machine that produces plausible code faster than a human can read it.

The arithmetic is simple: 15 years taught me to read a financial statement, 6 years taught me to read code. The combination makes me skeptical of any promise that technical work no longer requires judgment. It now requires more judgment per line of code, which is why the next decade belongs to whoever knows what not to review.