Budget the Verification Tax: The Line Item Missing From Every AI-Native Programme Plan

Every AI-native programme plan we have reviewed this year has a line for licences, a line for integration and a line for change management. Almost none has a line for the work of checking what the agents produced. The work exists anyway. Unbudgeted, it lands on the people who already had a full job, and the plan reads on track until the month it does not.

We call it the verification tax: the human time needed to check agent output to the standard the programme’s own controls require. It is the cost that turns a productivity gain into a delivery result, and it is the reason so many programmes report faster teams and no change in outcomes.

The evidence for the line item

DORA’s report on the return on AI-assisted software development is organised around the initial “productivity dip” of a new rollout, and around defending a budget through it. Its 2025 research supplies the reason the dip is uneven: AI’s primary role is that of an amplifier, magnifying the strengths of high-performing organisations and the dysfunctions of struggling ones. Change volume rises faster than the control systems around it, and the checking is where that lands.

The 2025 DORA survey put a number on the trust gap: roughly 30% of respondents reported little or no trust in AI-generated code, and shipped it anyway. McKinsey’s 2026 State of AI survey found eight in ten respondents reporting that AI improved their own productivity, while the share of organisations reporting any impact on earnings stayed flat at 37%. Our reading of the gap between those two numbers: the individual got faster, and the organisation absorbed the checking.

None of this argues against agents in delivery. It argues for putting the checking in the plan.

Where the tax lands

On a delivery programme the verification work has a recognisable shape:

• Drafted narratives checked against their sources. Status commentary, steering summaries, risk descriptions. Someone reads the draft and the tickets it came from.
• Agent-built estimates and plans walked through by a planner who can still explain the logic. We ask for this in every AI-native audit, and it is the check teams like least.
• Reconciled data sampled. RAID updates, dependency changes, resource allocations that an agent moved.
• Generated code, configuration and test assets reviewed and tested to the same standard as human-written ones, with change volume now higher.
• Rework when the check fails, and the re-check after the rework.

Three cost components sit underneath: review time, rework time, and the cost of keeping people able to review. That third one is the one plans miss twice. A team that stops doing the task by hand loses the ability to check it, and the sample rate quietly falls to zero because nobody can tell a good draft from a plausible one.

Why it is missing from the plan

The pilot measured generation speed. The business case counted verification as part of the time saved. And nobody owns it, because it spans the PMO, quality, and the domain experts who are the only people qualified to check.

There is also an accounting incentive. A plan with an explicit verification line shows a smaller net gain than one without. In a business case competing for funding, the line disappears.

Sizing it from the governance page

The one-page governance model already contains the input. For each agent, three columns: may do alone, may draft for human sign-off, may not touch. Column two is the verification workload. Column one is the sampling workload.

For each agent workflow:

1. Volume. How many outputs per month land in column two, and how many in column one.
2. Sample rate, set by consequence. Anything that moves money, commits the programme to a date, or goes to a regulator: every item checked. Executive narrative: a defined share. Internal drafts: a smaller share, never zero.
3. Minutes per check, measured for four weeks rather than estimated. The first measurement is usually higher than anyone predicted, because the checker has to reconstruct context the agent had and they do not.
4. Rework rate and rework minutes, also measured.
5. Skill maintenance. Hours per quarter in which a reviewer does the task by hand. Budget it as training, because that is what it is.

The arithmetic is volume, times sample rate, times minutes per check, plus rework rate times rework minutes, summed across workflows. As an illustration only, not a benchmark: an agent drafting 200 status items a month for sign-off, at fifteen measured minutes per check, is fifty hours a month before any rework. That is a quarter of a person, and it belongs to someone by name.

Re-baseline every quarter against the measured error rate. The sample rate on a workflow comes down when the error rate has been below the threshold for two consecutive cycles, and not before. It never reaches zero on column-one items that move money.

Funding it through the dip

Put the tax on the plan as a named line with an owner, front-loaded. Months one to six carry the highest sample rates and the slowest checks, which is exactly the productivity dip DORA describes. The line declines as measured error rates earn lower sampling, and the decline is a decision recorded against evidence rather than an assumption baked into the business case.

Two rules keep it honest. The verification line is never cut to make the business case close; if the case does not close with it, the case is wrong. And the owner is the person who signs the status report, because that is the person whose signature the checking protects.

What we check in an audit

Four questions expose an unbudgeted verification tax faster than any survey:

• Show us the sample rates per agent workflow, and who set them.
• Show us the measured minutes per check for the last month.
• Who did this task by hand in the last quarter, and could they do it today?
• What happened to the last agent output that failed a check, and how long did the rework take?

A programme that can answer all four has a verification tax on the plan and a control system that grew with its change volume. A programme that cannot has a faster pipeline into the same review bottleneck, and its next status report is the one the CFO should read most carefully.

Start Monday

Take the governance page, or write the three columns for the two agents doing the most work. Count last month’s column-two outputs. Time ten checks. That gives you the first number, and it is usually enough to change the plan. If you want the four questions asked by someone outside the programme, a delivery audit covers them in 7-14 days, or book a consultation and bring the count.

Sources: DORA, “ROI of AI-assisted Software Development” and the 2025 “State of AI-assisted Software Development” (dora.dev), verified against DORA’s publications page on 11 September 2026; McKinsey, “The State of AI: Global Survey 2026.” Figures are attributed to those publications and are not proprietary Zenous data. The sizing illustration is hypothetical and not a benchmark.