Essay
The acceptance layer
Coding agents made producing software cheap. They did not make accepting autonomous changes safe.
acceptance · verification · governance
Originally published
Article history
No released revision history is available for this article. The original publication date is preserved; no revision events are implied. Any editorial clarification in the article is separate from admitted revision history.
The expensive part of software is no longer producing it. It is accepting it. A competent agent now produces a plausible change to a large system in minutes, and it can produce another immediately after. What did not get cheaper is the decision to accept that change: the judgment that this diff, against this codebase, at this moment, makes the software better rather than worse. That decision, and the machinery that makes it, is the acceptance layer - and it is where autonomous engineering succeeds or fails.
For decades the economics ran the other way: production was the scarce, expensive part of engineering, and review rode on the back of a slow supply of changes. Coding agents removed the scarcity. The bottleneck moved. The machinery has not.
Acceptance is where autonomy actually fails
Most agent setups answer the acceptance question in a couple of ways, and both break at agent pace.
Letting the same system that produced the change judge the change. This is circular. A generator's confidence in its own output is not evidence about the output, and a system that grades its own homework will eventually award itself marks it has not earned - fluently, and with citations.
A human skim is the other. At a careful pace of pull requests, a careful engineer can hold the whole change in their head. At a plausible agent pace - many runs an hour, say, as an illustration rather than a measured rate - review becomes rubber-stamping with extra steps: the diff looks reasonable, the description is well written, the tests the author chose to run are green.Illustration, not a benchmark: carefully reviewing a long diff can take substantial time. An agent can produce the next change immediately.
Notice that in both cases the failure is not in production. The code is often fine. The failure is that nothing in the system can say, with grounds, that it is fine.
What real acceptance requires
The properties are structural:
- Separation. The machinery that accepts a change is not the machinery that proposed it. The worker does not control the evidence, the rules or the judge.
- Rules stated in advance. The properties a change must preserve - and the ones it is trying to improve - are fixed before the run begins. Criteria written after the output exists are negotiation, not acceptance.
- Evidence, not narrative. The verdict comes from running the software: the target's own tests, in a clean environment, against the actual candidate. And the evidence is an artifact - sealed, addressed to a specific state of the repository, and replayable by someone who was not in the room. A verdict you cannot replay is an opinion.
Acceptance is infrastructure
The industry mostly treats acceptance as a step: a review gate at the end of a pipeline optimised for production. We think that is backwards. Acceptance is the load-bearing structure, and production is the step. When acceptance is rigorous, production can be cheap and fast, because producing more candidates never dilutes the standard they must meet. When acceptance is weak, faster production just ships risk sooner.
That inversion is why Apex exists. Producing software is no longer the bottleneck. Trusting it is. The acceptance layer is where that trust gets engineered.
Claim
The post argues that acceptance, not production, is now the bottleneck when coding agents write software. It argues that self-grading and a human skim both fail at agent pace, and that real acceptance needs separation, rules stated in advance and replayable evidence. On this view, acceptance belongs in the infrastructure, not in a review step at the end.
Method
This is an essay. It argues from reasoning about how changes are produced and accepted. No experiment was run for this post. The links below are the public record that bears on the argument.
Evidence
Limitations
- This is an argument, not a measurement.
- The agent pace in the text is an illustration, not a measured rate.
- The public evidence is a development-only calibration summary. It does not establish general performance across customer codebases.
- Checking the summary's signature does not rerun or validate the acceptance decision. The primary run receipts remain private, not publicly accessible; access requires separate authorization.
- Parts of the acceptance path are implemented. A sealed repair of a real outside defect has not yet landed.