A coding agent can produce a change faster than a responsible person can decide whether to accept it. Give the agent more capacity and the immediate result may be a longer queue of changes waiting for that person. The software factory has expanded. Its shipping department is still one nervous engineer.

This is why I find the question behind Sphinx more interesting than another claim about code-generation speed. The public tool asks developers to explain a change before a protected push proceeds. It brings a neglected part of production into view: someone must understand what the organization is about to make its problem.

The human is not a free input

The Sphinx README, “Before you install”, describes a reviewer model that examines a committed change and questions the developer. Its own warning is unusually useful:

This is practice, not a security gate.

Sphinx README Sphinx project documentation · inspected 18 October 2026 Before you install.

The same section explains why: a local user can bypass hooks, passing does not establish unaided understanding, and the examiner can be wrong. The documentation supports a claim about the tool’s design, not its effectiveness in a deployment. That is enough to make it an interesting experiment in comprehension, and insufficient to make it a release authority.

The idea nevertheless exposes a real design choice. As generating code becomes easier, the organization can spend its scarce attention on reading more code, or it can change the unit it asks people to review.

Reading every line has a reassuring physicality. There are lines; someone has looked at them. But the economic unit is the change in behavior. Can this payment be executed twice? Can this access rule expose another customer’s records? Can the system recover after writing half of the intended state?

A reviewer who understands the syntax but misses that behavior has completed the ceremony while leaving the risk untouched.

My three emulator fixes made the distinction unusually clear. In the restart correction, two assignments incorrectly changed bookkeeping for a live eviction list. The recorded reproduction aborted on the unmodified build’s first restart; the corrected build completed three consecutive guest restarts. That is concrete evidence for the reproduced path, not every possible memory remapping. Printer and audio faults required different tests. The code size was a poor guide to the evidence required.

The general lesson I draw is that review should purchase uncertainty reduction. Time spent looking at an artifact is a cost, not a measure of how much uncertainty disappeared.

Package a decision, not a pile of work

Consider a hypothetical change to order processing. An agent adds a retry after a timeout. The implementation passes its existing tests. The person accepting it asks one question: what if the order was placed, but the acknowledgement never arrived?

That question identifies the missing boundary. The change needs evidence about duplicate execution, not another demonstration of the happy path. A useful acceptance package would show the relevant state transition, a test that interrupts it, the observed result, and how to reverse the release if the assumption fails.

The reviewer can then make a bounded decision. Without that package, the reviewer first has to become an investigator. Cheap generation has transferred work to the most expensive stage.

There is a strategic consequence. An organization that can reliably package this evidence may get more benefit from the same model than an organization with a larger agent budget. Its scarce experts can accept more consequential work because each decision requires less reconstruction.

That does not mean eliminating expert attention. It means reserving it for the uncertainty that remains after reproducible checks. The objective is a smaller, better question, not an unattended rubber stamp.

Acceptance can become an asset

The evidence also has a second use. A recorded failure becomes a test for the next change. An exception becomes a routing rule. A misunderstanding reveals which instruction was absent or ambiguous. If retained properly, today’s review reduces the cost of tomorrow’s review.

This is the part I would try to make cumulative. The growing asset is a record of what acceptable work means in this business, including where automated checks stop and someone must exercise authority.

Anthropic’s January 9, 2026 essay Demystifying evals for AI agents, in its guidance on graders, makes the failure concrete: an agent can produce a valid solution and still fail because a task specification is ambiguous or a test demands an unstated detail. The article recommends checking tasks with known working reference solutions. That supports a narrower engineering point: acceptance machinery needs its own evidence. A green result cannot become authoritative simply because checking the checker is inconvenient.

The operating design therefore needs three distinct judgments. Does the implementation behave as required? Does someone understand the consequential uncertainty? Who is authorized to accept what remains? A correct answer to one does not answer the other two.

Correctness, comprehension and release authority are independent judgments with different evidence.
The three judgments answer different questions. An explanation, a behavioral test and an authorized risk decision cannot substitute for one another.

Don’t build an examination industry

There is an obvious way to ruin this: require a miniature oral examination for every change. The organization then employs faster agents to finance a larger internal school. Output rises, review time rises, and everybody becomes very articulate about why nothing has shipped.

I would concentrate comprehension checks on changed invariants, unfamiliar dependencies, and expensive-to-reverse consequences. Routine work should increasingly travel with reusable evidence. Exceptional work should arrive with a clear reason it is exceptional.

The test is whether accepted work per hour of expert attention improves without worsening important failures. Count abandoned changes and later repairs too. Otherwise the organization can make the approval queue look healthier by moving its problems to production.

This also explains why the evidence should belong to the enterprise rather than exist only inside a supplier’s chat history. When the model changes, the definition of acceptable work should remain. A new supplier can write the next implementation; it should not have to rediscover which mistakes the business has already paid to understand.