The Acceptance Gap

A team can produce more work while making the organization slower.

Sales sends more proposals. Finance reviews more exceptions. Engineering opens more pull requests. The people responsible for accepting the results spend their day deciding which ones can be trusted.

The local productivity gains may be real. So may the growing queue downstream. An honest account has to include both.

I call the distance between producing an output and establishing that it is fit for use the acceptance gap. AI changes the cost of production quickly. Capturing that benefit requires changing how work reaches an acceptable finish.

The appropriate unit of productivity is a completed outcome at an agreed level of quality, with the cost of review and recovery included.

The queue moves downstream

Linear's September account of rebuilding its continuous integration system is a concrete example. AI-assisted coding had increased the pressure on the infrastructure that validates code. Its test suites had grown almost fourfold since the start of the year.

The company responded by reworking that infrastructure. It reported cutting pull-request wait time from more than six minutes to just over five, while roughly halving runner time per test.

This is a company engineering account, not an economy-wide productivity estimate. Its value is in the sequence: faster creation exposed a constraint, and the team invested in moving that constraint.

Verification capacity can improve. Treating it as permanently fixed would miss the most useful part of the example.

The same logic applies beyond code. A faster analyst can generate more scenarios than an investment committee has time to understand. A drafting assistant can expand the number of contracts reaching a small legal team. A support agent can close easy cases while concentrating difficult ones in the human queue.

Those outcomes need different responses. Sometimes the organization needs better validation tools. Sometimes it needs a different division of labor. Sometimes it needs to stop generating work that nobody values enough to accept.

Define completion before measuring speed

“Time saved” is meaningful only after deciding where the clock stops.

Suppose an assistant reduces the time needed to prepare a customer proposal. The preparation team measures a gain. If the proposal arrives with missing commercial assumptions, finance may spend the saved time reconstructing them.

This is an illustrative workflow, but the accounting problem is general. A cost transferred to another team has not disappeared.

For a proposal, completion could mean that the customer-facing commitment has passed the required checks and is ready to send. For a software change, it could mean deployed behavior that passes the agreed checks and remains stable through a defined observation period.

The definition depends on the task. It should be settled before the experiment, and it should include an owner who can say the work is acceptable.

I would track elapsed time from request to acceptance, direct human effort across the participating teams, and the rate at which accepted work must be reopened. Machine cost belongs in the account too. Where failures are consequential, their severity matters as much as their frequency.

This does not require a grand dashboard. Start with one recurring workflow and follow a representative sample from beginning to end. The purpose is to discover where the benefit lands and where the burden moves.

A historical result cannot stand in for today's workflow

The research on coding productivity illustrates why measurement needs care.

METR's early-2025 randomized study found that 16 experienced open-source developers took 19% longer with the available AI tools across 246 tasks. That was a result about particular developers, repositories, and tools at a particular time.

In its February 2026 update, METR said its later experiment provided an unreliable estimate of current effects. Developers' reluctance to work without AI and their selection of tasks introduced substantial bias; parallel agent work also complicated time measurement. The researchers thought greater speedups were likely, while cautioning against treating the raw estimate as reliable.

The responsible conclusion is methodological. Neither an old slowdown nor a developer's enthusiasm settles the productivity of a new workflow.

It also matters which work becomes possible. An agent may make a previously neglected maintenance task worth doing. Comparing only the duration of old tasks would omit that benefit. Counting every new artifact as valuable would make the opposite mistake.

Measure throughput and quality on comparable work, then separately examine worthwhile work the team could not previously afford. Keep the two claims distinct enough to learn from each.

Build evidence into the work

Our conversation with Baris Gultekin connected agent skills to the data and context that make them useful. He also advocated scoped agents whose skills and behavior can be tested.

That supplies a practical starting point. A narrowly defined task gives the organization something concrete to accept or reject. “Help with operations” is hard to evaluate. “Reconcile this class of invoice against these records and escalate these exceptions” has a clearer finish line.

My extension is to make the evidence needed for acceptance part of the output contract.

A reconciliation should identify the source records, the rule applied, unresolved differences, and the state actually written to the destination system. A code change should arrive with the relevant checks and a clear account of behavior changed. The reviewer should not need to recreate the entire task to understand what happened.

Stephen Wolfram's distinction between linguistic interaction and precise computational representation explains why this helps. A fluent explanation can guide a person toward a formal check; it cannot substitute for the check merely by sounding complete.

For arithmetic, calculate. For a database update, inspect the resulting state. For a customer commitment, establish who had authority to make it. Different claims call for different evidence.

Acceptance can be automated

The strongest objection to this argument is that AI will improve review as well as production. Why assume that people must remain at the end of every workflow?

We should not. Automated testing, constrained execution, model-assisted review, and sampling can expand acceptance capacity. Some categories of work should pass without an individual human decision.

The useful question is what justifies that level of autonomy. A class of reversible, low-impact changes with well-understood checks may qualify. A novel commitment with uncertain consequences may require a person with the relevant authority.

Even then, the person's attention should go to the consequential uncertainty. Asking them to read a long generic assurance report is an expensive way to simulate control.

Multiple agents can help, but agreement between them is not automatically independent evidence. If they share the same mistaken premise, a second confident explanation can reinforce the error. A measurement, a different source, or a test against the actual system often adds more than another vote.

The goal is to reduce the cost of establishing fitness for use while keeping the standard meaningful. If acceptance becomes faster because defects have become invisible, the productivity improvement is an accounting trick.

Give the receiving team a vote

There is a human consequence to all this measurement.

Organizations can reward the team that generates more work while leaving the receiving team to absorb the increased burden. The people closest to the failures then appear slow, resistant, or insufficiently enthusiastic about AI.

That arrangement encourages the wrong behavior. It makes rapid production visible and careful judgment look like friction.

The team accepting the work should help define success and participate in the productivity review. They should be able to identify repeated failure patterns and have those findings change the upstream system.

This is also a reason to invest in people's judgment as automation expands. If routine work disappears, the remaining work may be less frequent but harder. A smaller volume of human intervention does not imply that the intervention is less skilled.

Future To Build argued that valuable AI businesses would close unfinished transactions. The organizational corollary is that the person producing the artifact cannot be the only person who defines finished.

The work is cheaper only when the cost has fallen for the people who must live with the result.

AI can deliver that outcome. The companies that capture it will redesign acceptance alongside production, measure the whole transaction, and give the people carrying the consequences a say in the definition of progress.

Abundance in Practice · Essay 2 of 5. Previous: The Representation Gap · Next: The Software That Stays.

Abundant intelligence should reduce the burden of getting good work finished. We follow that practical promise in the Masters of Automation newsletter.

all signal, no spam.