Your teams are shipping more. The status report is greener than it was two years ago. Velocity is up, cycle time is down, and the AI line item in the budget looks like it is paying for itself.
Now ask the second question: is the portfolio safer than it was?
For most organisations the honest answer is no. The reason is not that AI failed. It is that the PMO instrument was built to measure delivery, and AI moved the risk somewhere the instrument does not point.
1. The evidence, and what I am deliberately not citing
There is a great deal of vendor benchmarking in circulation right now, most of it with no published methodology and a product at the end of it. I am going to lean on one source, because it publishes both its method and its sample: DORA’s 2025 research on AI-assisted software development, drawn from nearly 5,000 technology professionals plus over 100 hours of qualitative work.
The findings that matter for governance:
- 90% report using AI at work. This is no longer a pilot population.
- More than 80% believe it has increased their productivity. Perceived productivity is close to universal.
- 30% report little or no trust in the code AI generates. They are using it anyway. Hold on to that number; it is the interesting one.
- AI adoption correlates positively with throughput and product performance, a reversal of the previous year’s finding.
- AI adoption continues to have a negative relationship with software delivery stability.
And the framing sentence, which I would put on a slide in front of any steering committee: AI doesn’t fix a team; it amplifies what’s already there.
Note the shape of that fifth point. It is not “AI causes outages.” It is that change volume rose faster than the control systems around it: testing, review, version control discipline, feedback loops. Push more through an unchanged pipe and the pressure shows up at the narrowest point, which is usually downstream of anything a PM watches.
2. Why the dashboard went green anyway
Look at what a standard portfolio report actually contains. Milestone status. Percentage complete. Budget variance. Resource utilisation. Open risks and issues, self-assessed. A RAG rating owned by the person being rated.
Every one of those is a throughput or conformance measure. Not one of them is a stability measure.
So when throughput improves and stability degrades, the report has a vocabulary for exactly half of what happened. It goes green, correctly, according to its own definitions, at the precise moment the other variable starts moving.
That is worse than no signal. A dashboard that is silent tells you to go and look. A dashboard that is confidently green tells you not to.
There is a second-order effect worth naming. If milestone burn-up is what gets reported, and AI makes burn-up cheap, then the report becomes easier to satisfy without the underlying position improving at all. Any measure that stops being hard to move stops being informative. A lot of PMO metrics quietly crossed that line in the last two years and nobody re-baselined them.
3. The amplifier thesis is a governance finding
“AI amplifies what’s already there” reads like a slogan. It is not. It is a prediction, and it is testable on your own portfolio.
If it holds, then two programmes adopting the same tooling will diverge rather than converge. The one with real automated testing, trunk discipline, fast feedback and clear ownership gets faster and stays stable. The one with manual regression, a quarterly release train and diffuse ownership gets faster and breaks more, because the speed arrives before the safety net does.
That has a direct consequence for how a portfolio is governed. AI adoption should not be assessed as a programme. It should be assessed as a multiplier on an existing capability baseline.
Which means the useful governance question is not “are we adopting AI?” That has already been answered by 90% of your engineers without a business case. It is:
Which of our delivery units have the control systems to survive being made faster, and which are we about to accelerate into a wall?
That is a portfolio question, it is answerable, and almost nobody is asking it.
4. What to put on the report
Five measures. They are not new inventions. The change is that stability is represented at all, and that two of them describe the control system rather than the output.
1. Change failure rate, and time to restore. The two stability halves of the DORA four. If your report carries throughput measures without these, it is structurally incapable of showing the trade you are currently making. This is the highest-value single addition, and it is usually available from tooling you already own.
2. Rework rate. Code changed or reverted shortly after being merged. It separates work that shipped from work that was finished. In an AI-assisted codebase throughput and rework can rise together, and only one of them is value.
3. Review and test coverage of AI-generated change. Not “do we use AI” but “what proportion of merged change was machine-authored, and did it pass the same gates as everything else?” You cannot govern a category you do not label. Recall the 30% who do not trust the output and ship it regardless. That gap is a control gap, and it is measurable.
4. Control-system capability, per delivery unit. A short, honest, periodically refreshed assessment: automated test depth, deployment reversibility, feedback latency, ownership clarity. This is the baseline the multiplier acts on. It changes slowly, so it does not need to be monthly.
5. Decision latency. How long a decision sits between being needed and being made. It is the one measure on this list that AI has done nothing to improve, and as build time collapses it becomes a larger share of elapsed time. A team that ships in two days and waits eleven for an approval has an eleven-day problem.
Deliberately not on the list: lines of code, AI-assisted commits as a headline number, seat licences activated, and any “AI productivity uplift” percentage. The first three measure adoption rather than outcome. The fourth is unfalsifiable without a control group you do not have.
5. Two objections, and what each one gets right
From the PMO side: “Change failure rate is an engineering metric. It does not belong in a portfolio report.”
It belongs there for the same reason safety incidents belong in a construction portfolio report. It is a leading indicator of a cost the portfolio will pay, denominated in unplanned work, and it is the only counterweight to a throughput number that has become cheap. The objection is really about ownership, because PMOs avoid metrics they cannot influence. That is fair, but the answer is to name an owner, not to omit the measure.
From the R&D side: “You are going to turn stability into a target and we will game it.”
Also fair, and historically well earned. Any of these five, made into an individual or team target, will be optimised rather than improved. Change failure rate is the obvious one, since it is trivially suppressed by shipping less. The mitigation is structural: report stability and throughput as a pair, never separately, at delivery-unit level rather than per team, and treat movement in one without the other as the thing that needs explaining. A pair is much harder to game than a number.
The standards are converging on the same point from both directions, which is usually a sign that it is real. PMBOK’s eighth edition, published in November 2025, raised Embed Quality to a core principle alongside value and accountability. Scaled Agile’s AI-Native release in June 2026 went further and created a named role, the AI Value Architect, carrying cost, risk, ethics and legal exposure for AI-assisted delivery. Whether or not you adopt either framework, note what both are doing: putting an accountable human name against a class of risk that tooling introduced and tooling does not own.
6. The ownership problem, which is the actual problem
Here is the situation most organisations are now in, stated plainly.
Agents can be assigned work in the delivery tool. In Jira they can be given items and mentioned in comments like a teammate. Microsoft’s Planner Agent builds plans and schedules from a prompt or a meeting transcript. Most major platforms now ship something equivalent. Work is being created, moved, drafted and closed by something that cannot be held accountable.
Meanwhile the RACI is unchanged.
The failure mode is not dramatic. Nothing announces itself. A risk is drafted by an agent, reviewed by nobody in particular, and appears in the pack. A status is generated from ticket state that an agent also updated. The report becomes self-referential, summarising the tool’s view of itself, and the human who would have noticed the discrepancy has been removed from the loop as an efficiency.
Two rules I would put in place before adding another agent:
- Every agent action has a named human accountable for its output. Not a team, a person. The agent is a tool being wielded, exactly like a spreadsheet macro, and accountability sits with whoever wields it.
- Nothing an agent produces enters the governance record without human attestation. Draft freely. Assert with a name on it.
Neither rule slows down anything that should be fast. Both close the specific gap where a plausible artefact reaches a decision-maker with nobody behind it.
7. The one-page change
If you do nothing else this quarter:
- Add change failure rate and time to restore to the portfolio report, next to the throughput measures, on the same page.
- Report them as a pair. A green throughput number beside a degrading stability number is the finding, not a formatting problem to be resolved.
- Name one accountable owner for stability at portfolio level, and one human attestation point for anything agent-generated that reaches the board pack.
The productivity gain from AI is real. The reporting has simply not caught up to where the risk went, and until it does, every green status is an assertion about half the system.
Faster was never the goal. Faster and still true was.