ReadSigil

Writing · Essay · 4 November 2026

The verification queue

Why faster AI doesn't always produce faster businesses

By

AI has made it cheaper to produce work. It has not made the consequences of that work cheaper to own.

Imagine two teams building the same application. One uses coding agents and produces three times as many proposed changes. The other writes less code, but knows how to review it, test it, integrate it, and put it in front of customers. Which team creates more value?

We have spent an extraordinary amount of time measuring the first team's output. The more interesting question is what reaches the customer.

McKinsey's Technology Trends Outlook 2026 surveys 14 frontier technologies, with agentic software development among the two new categories it added this year. Its argument is broadly optimistic: AI is beginning to transform production, science, infrastructure and the physical world. But embedded in the discussion of software is a less comfortable idea. More production is not the same as more progress.

The numbers are not quite what the headline suggests

A study by Mert Demirer, Leon Musolff and Liyuan Yang follows the software-production chain from coding activity to final releases. McKinsey's September outlook refers to an earlier version of the study, reporting a 180% increase in coding activity against only about 30% more shipped releases.

A September 2026 revision of the authors' NBER paper reports a larger 240% cumulative increase in commits with advanced AI coding-tool adoption, compared with 30% more releases. These are estimates from an observational, matched event-study design, not a controlled experiment demonstrating that every organisation will see this result. Nor does a software release prove that customers found it useful.

The direction is the story: the gains shrink as work progresses from created to delivered.

There is corroborating but different evidence. In McKinsey's May 2026 survey, 30% of director-level and above respondents reported that team productivity had actually declined after adopting agentic development tools. This is survey evidence about organisations, not the same dataset or metric as the GitHub study. Mixing the two into one universal productivity estimate would be misleading.

Follow the work, not the model

A useful way to think about an enterprise is as a sequence of queues.

First, work is created. Then it is checked. Then it is integrated into a running process. Then somebody uses it. Sometimes a failed check sends it back for rework.

If AI doubles the first stage while every later stage stays fixed, the business may produce more unfinished work. The bottleneck has moved; the performance report has not.

Consider an explicitly illustrative bank workflow. A team once prepared 100 cases a week, and could validate and execute 80. AI raises preparation to 200 cases, but validation remains at 80. The cases may look better. The dashboard may show an impressive increase in productivity. Yet the maximum throughput of that unchanged validation step is still 80 cases per week, before accounting for rework or other constraints.

Now add real-world friction: incomplete evidence, integration failures, false positives, new policies and customers whose circumstances have changed. The question is not how many recommendations the AI produced. It is how many correct, timely and defensible actions followed.

Try the interactive verification queue. Change creation speed, verification capacity, release capacity and rework. Watch where the backlog accumulates. This is a teaching simulation, not an estimated bank process or an empirical replication of the research.

Five measures I would ask for before approving the next AI expansion

1. Finished work, not generated work. Count releases that actually reach users, cases correctly resolved, customer actions completed or exceptions closed. Drafts and model calls are inputs.

2. Time spent waiting for judgment. Measure the queue between AI output and human or system verification. A fast producer that creates a slow approval queue is not necessarily an improvement.

3. Rework and reversals. Ask how many AI outputs need correction, how many actions must be undone, and how often an ostensibly resolved case returns.

4. Cost per defensible outcome. Model spending alone is insufficient. Include validation time, infrastructure, integration, incident handling and ongoing oversight.

5. The harm boundary. Is a decision reversible? Can the evidence be reconstructed? Who has authority to stop it? Higher-risk decisions need a different speed limit from low-risk, easily reversible tasks.

This is not an argument for slowing AI down. It is an argument for investing in the stages that let speed matter. Improving test coverage, simplifying approval rules, clarifying data definitions and establishing accountable owners can create more real output than another increase in generation capacity.

The small-model lesson

There is a further implication for AI strategy. If an enterprise's constraint is an unreliable handoff or an expensive review process, upgrading to a larger model may not solve it. A narrowly scoped model, a deterministic rule or a carefully designed API may deliver more value if it reduces errors and moves work cleanly to completion.

This is particularly relevant in regulated environments. A credit decision, fraud alert or customer-service classification has to survive challenges that a plausible paragraph never faces. The work must be traceable to evidence, a policy, a responsible decision maker and a customer outcome.

The technology choice should come after that operating design, not before it.

A different board question

The conventional question is: How much productivity did AI create?

I would replace it with: Which constraint in the full journey did AI remove, and what changed for the customer?

We should still celebrate faster creation. It is a remarkable capability. But as generation becomes abundant, verification, integration and judgment become comparatively more valuable.

The next frontier of enterprise AI may not be another model benchmark. It may be a shorter queue between a machine's suggestion and a trustworthy result.

Evidence and method

Explore the interactive verification lab · More essays

ReadSigil is an independent publication. This is an editorial analysis, not investment, regulatory or bank-specific advice; it does not speak for an employer.