Key Takeaways
- →Ungoverned AI speed behaves like a loan. The gain shows up at once on a velocity dashboard; the repayment shows up later in delivery stability, rework and duplicated code.
- →In METR’s 2025 trial, experienced open-source developers were 19% slower with AI tools on real issues in their own repositories, after forecasting a 24% speed-up.
- →DORA’s 2024 report links a 25% rise in AI adoption to a 7.2% fall in delivery stability, even as documentation quality, code quality and review speed improve.
- →Hold AI-assisted development to the standard of your financial controls and, in my experience, you keep more of the gain. Four lightweight pillars do the work; what they keep is the Governance Dividend.
- →Startups racing to product-market fit, closing competitive windows and small high-trust teams can reasonably run lighter. The risk is making that trade without noticing.
Once AI coding assistants reach every team, a question follows within a quarter. Velocity metrics look strong, so when do the efficiency gains show up as fewer people needed? I hear some version of it from technology leaders often, and I used to answer it with the same dashboards they were reading: faster pull requests, more commits, shorter time to completion.
Those dashboards measure the wrong thing. My claim in this piece is that ungoverned AI speed behaves like a loan. The gain arrives at once and shows up on every chart; the repayment arrives later, in delivery stability, rework and duplicated code, and the people closest to the work are often the last to notice it.
Call that deferred cost the hidden tax on AI speed. The Governance Dividend is what a team keeps when it governs AI-assisted development with the same rigor it applies to financial controls. The rest of this article sets out the evidence for the tax, what I have seen of the Dividend, and where the argument stops holding.
The Productivity Numbers Are Real
Start with the upside, because it is real. AI coding tools deliver genuine productivity gains in specific contexts. Dismissing them would be lazy, and the evidence is too strong.
A controlled experiment by Microsoft Research and GitHub, with a co-author from MIT Sloan, asked developers to write an HTTP server in JavaScript. Those given GitHub Copilot finished 55.8% faster than those working without it. McKinsey’s research found developers could complete some coding tasks up to twice as fast with generative AI.
Note who ran the first study: the company that sells the tool. It was still a randomized experiment, and McKinsey’s lab work points the same way. On a clear, bounded task, the gain holds up.
That is where my confidence started to crack.
The Number That Changed My Mind
In July 2025, METR published a study that I still think about most weeks. It recruited 16 experienced developers from large open-source projects they had contributed to for years, and had them work through 246 real issues in their own repositories. Each issue was randomly assigned to allow AI tools or to forbid them.
With AI allowed, the developers took 19% longer.
Before they started, they had forecast that AI would cut their time by 24%. After they finished, they estimated it had cut their time by 20%. They still believed it had helped.
Between what they forecast and what METR measured lies a gap of 43 percentage points. I have spent fifteen years in AI and technology, and that number remains one of the most unsettling I have come across. It shows how poorly we understand when AI tools help and when they don’t, however good the tools themselves are.
The METR study has limits worth stating: sixteen developers is a small sample, and METR itself warns against reading it as true of all developers or all software work. But a 43-point gap between forecast and result should give every technology leader pause.
Studies with the big gains used isolated, well-defined tasks: green-field work with a clear specification. METR used complex work in large codebases that the developers already knew intimately. Different task types produced different outcomes.
Which raises an uncomfortable question for any CTO staring at their AI adoption metrics: are you measuring the tasks that look good on a dashboard, or the tasks that actually drive your product forward?
What Speed Actually Costs
None of this is hypothetical. The tax shows up in aggregate data that most engineering leaders aren’t tracking against their AI adoption curves.
Google’s 2024 DORA report estimated that a 25% increase in AI adoption goes with a 7.2% decrease in delivery stability and a 1.5% decrease in delivery throughput. Read that again. More AI adoption, less stable delivery. The same report found the local signals moving the other way: documentation quality up 7.5%, code quality up 3.4% and code review speed up 3.1%.
That is the shape of the tax. The team feels faster and its code reads better, while what reaches customers gets less stable. GitClear’s analysis of 211 million changed lines found duplicated code blocks rose eightfold during 2024. And MIT Sloan Management Review offers a financial analogy I now borrow often: implementing AI-generated code is often like borrowing at a much higher interest rate, debt that compounds the longer it goes unaddressed.
According to CISQ, poor software quality cost the U.S. economy at least $2.41 trillion in 2022, and accumulated technical debt principal stood at about $1.52 trillion. Those numbers predate the spread of AI coding tools. My expectation is that they get worse before they get better, unless organizations treat governance as infrastructure, not overhead.
The Developer Experience Gap
In engineering teams, one pattern comes up again and again. With AI, a junior engineer writes as fast as a senior one, but without the senior engineer’s map of what problems the code creates.
That’s the gap. In the Copilot experiment, less experienced developers gained more from the tool than experienced ones. My read is that they also carry the most hidden debt. The AI doesn’t know your system’s edge cases, your team’s conventions, the reason that seemingly redundant validation layer exists. It generates plausible code at industrial volume. Plausible isn’t the same as correct. And at scale, the difference compounds.
Keep the tools in junior developers’ hands, and restructure how senior engineers spend their time. Less writing code, more reviewing it. Less building, more coaching. The role shift is real, and organizations that ignore it pay the tax silently: in production incidents, in customer-facing bugs, in the slow erosion of system reliability that doesn’t show up on any velocity dashboard.
Teams that get this right, in my experience, treat their senior engineers as AI coaches, not only as individual contributors. The job is to make sure the code that gets written, by humans or machines, holds up under production conditions.
The Governance Dividend
I started calling it the Governance Dividend after a pattern kept showing up in my advisory work. The companies that had invested in AI development governance (lightweight structural discipline, with no heavy process and no bureaucratic review boards) were keeping more of the value from AI tools than the ones that had simply turned everything on and hoped for the best.
It shouldn’t have surprised me. It’s the same pattern I see in Minimum Viable Governance deployments across every domain. Governance is what turns speed into something durable.
Research beyond engineering points the same way. In a 2025 survey of 915 executives, IBM’s Institute for Business Value found that organizations in the top quartile of AI ethics spending, as a share of AI spend, averaged 30% higher operating profit attributable to AI over two years than those in the lowest quartile. An earlier IBM study, cited in a California Management Review article, reports a related but distinct signal: companies that implement generative AI with the right guardrails may be 27% more likely to achieve higher revenue performance than peers that do not. Different metric, same direction. The AI ROI measurement framework I published earlier covers how to capture these gains in a format boards trust.
These are correlations, and the firms that spend on governance may differ from the rest in other ways. I read them as consistent with the Dividend rather than proof of it. What the Dividend asks is concrete: govern AI development with the same rigor you apply to financial controls. Not more rigor. The same rigor.
A Framework for Governed AI Development
What does governed AI speed actually look like in practice? Working through this with engineering organizations, I’ve landed on four pillars. (The Governance Playbook covers the broader organizational governance architecture. What follows here is specific to AI-assisted development.)
Four Pillars of Governed AI Development
Lightweight structure that turns velocity into lasting value
A distinction I use with engineering teams: vibe coding versus production coding. Vibe coding is AI-assisted exploration, prototyping, spiking and learning. It should be encouraged, even celebrated. It should never reach production without being reworked. The boundary between exploration and production needs to be explicit, enforced and understood by every developer on the team. Treat it as a transition that makes sure what ships is what you intended, rather than a gate that slows people down.
Technical debt from AI-generated code needs the same visibility as revenue metrics. Track it. Dashboard it. Assign ownership. Senior engineers should evolve from individual contributors into AI coaches who review AI-assisted output with the same critical eye they’d apply to a junior developer’s pull request, because that’s functionally what it is. If your team doesn’t have a debt-tracking practice, the 5-Pillar AI Readiness Assessment can surface how exposed you are.
The 2023 DORA report found that quality documentation amplifies the impact of other engineering practices on organizational performance: continuous integration by 2.4x, continuous delivery by 2.7x and reliability practices by 1.4x. Morgan Stanley’s DevGen.AI reviewed nine million lines of legacy code between its January rollout and June 2025, by the bank’s account, using AI to pay down old code rather than pile up new code. That’s the right use of AI in a governed development pipeline: point the machine at the debt, not at the velocity dashboard.
Commits per day, lines of code, pull request throughput: these measure activity. Delivery stability, defect escape rate, mean time to recovery, customer-facing incident frequency: these measure value. If your AI adoption metrics only track the first category, you’re measuring the speedometer while ignoring the engine temperature. The AI ROI measurement framework provides a structured approach to building metrics boards actually trust.
None of these four pillars require heavy process, though they do cost senior engineers’ time. No review boards. No 47-page policy documents. They require structural clarity about what AI-assisted development is for, what quality means in your organization, and who owns the gap between the two.
What the UAE Is Getting Right
I spent four years working on AI strategy in Abu Dhabi, and the UAE’s approach deserves attention. It is running an experiment worth watching.
It is building speed and governance at the same time, at two levels. Abu Dhabi’s Law No. 3 of 2024 established the Artificial Intelligence and Advanced Technology Council (AIATC), an emirate-level body. At the federal level, the UAE Charter for the Development and Use of AI (2024) sets out twelve principles, non-binding by most legal readings, that give the federal approach room to firm up over time. Governance usually arrives after problems emerge. The UAE is building the scaffolding, emirate and federal, while the technology is still being deployed. That’s the Governance Dividend applied at the level of a national technology strategy.
The lesson for everyone else: governance and speed can run side by side. The organizations and governments that treat them as parallel workstreams, instead of treating governance as a brake on speed, are the ones positioned to keep compounding returns.
Where This Framework Falls Short
I’d be dishonest if I didn’t flag the limits.
Startups building MVPs may reasonably prioritize raw speed over governed speed. When you’re racing to validate product-market fit, the technical debt tax is a problem for future-you. That’s a legitimate trade-off, as long as you’re making it consciously, not accidentally. The Responsible AI Playbook covers governed speed at startup scale.
Competitive windows sometimes close faster than governance processes can open. If your market is being disrupted by an AI-native competitor, waiting for perfect structure is its own risk. The question isn’t whether to move fast. It’s whether you’re tracking the tax you’re accumulating while you do.
And small teams with high trust may already have the implicit governance that formal structure provides. If your four senior engineers all review each other’s AI-assisted code by habit, you don’t need a policy. You need to notice when the team grows past the point where implicit governance stops working. In my experience, that transition catches more organizations than any of the technical risks I’ve described.
The Choice in Front of Engineering Leaders
In the right contexts, the productivity gains from AI coding tools are substantial and well-documented, and speed is often essential.
My argument is narrower: ungoverned speed creates costs that compound silently. And by the time those costs become visible (in production incidents, in system fragility, in the slow erosion of your engineering team’s confidence in the codebase they’re shipping), the interest has been accruing for months.
The organizations that do well here won’t be the fastest movers or the slowest. They’ll be the most deliberate: fast where speed creates value, governed where speed creates risk, and honest about which is which.
That’s the Governance Dividend. The window to capture it is still open. But the tax on ignoring it is compounding every quarter.
The question for your next leadership meeting: are your AI velocity metrics measuring speed, or value? If you can’t answer that with confidence, the 5-Pillar Readiness Assessment is the diagnostic I’d start with.
Related Frameworks
The pattern I call the Governance Dividend draws on the same thinking as a few other frameworks I write about. The Minimum Viable Governance framework provides the organizational governance foundation. The Governance Playbook turns principles into practice across the enterprise, not just engineering. And the 2026 AI Forecast covers the broader trends shaping the speed-versus-governance reckoning this year.
For regulated contexts, where compliance costs reshape the speed equation, the GDPR compliance guide and the The HIPAA Review Passed. The Model Remembered Patient Details cover the governance questions boards are starting to ask.
Sources and Changes
- Peng, Kalliamvakou, Cihon and Demirer, "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot", arXiv, 13 February 2023.
- McKinsey, "Unleashing developer productivity with generative AI", 27 June 2023.
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 10 July 2025, and the paper.
- Google Cloud and DORA, Accelerate State of DevOps Report 2024, October 2024, and the 2023 report.
- GitClear, "AI Copilot Code Quality: 2025 Data", February 2025.
- Anderson, Parker and Tan, "The Hidden Costs of Coding With Generative AI", MIT Sloan Management Review, 18 August 2025.
- CISQ, "The Cost of Poor Software Quality in the US: A 2022 Report", November 2022.
- IBM Institute for Business Value, "The AI ethics trust engine", October 2025.
- Domin, Rossi, Goehring and others, "On the ROI of AI Ethics and Governance Investments", California Management Review, 29 July 2024.
- Entrepreneur, "Morgan Stanley Builds AI Tool That Fixes Major Coding Issue", 3 June 2025, reporting the Wall Street Journal the same day.
- Latham & Watkins, "AI in the UAE: Understanding the Regulatory Landscape and Key Authorities", 30 October 2025, and the UAE Charter for the Development and Use of AI.
All sources checked on 6 October 2026.
Changes on 6 October 2026. New dek, summary, takeaways and art. I re-checked every fact. METR randomized each issue, not each developer, and the gap between forecast and result is 43 points, while the gap after the study is 39. The Copilot study was run by Microsoft Research and GitHub, so I no longer call it independent of the vendor. The 30% operating-profit figure now cites the IBM report that contains it, and the 27% revenue figure is credited to IBM's earlier study, which California Management Review cites. Morgan Stanley's nine million lines covered January to June 2025. I dropped a client scene, an unattributed quote, a count of advisory engagements, a course description I could not support and a claim about the AIATC's independence. Two charts whose bars misstated their figures are replaced with charts of METR's and DORA's own numbers.
Get The Brief
Original thinking on AI strategy and governance. Every other Tuesday.
Senior AI strategist helping leaders make AI real across four continents. Forbes Technology Council member, IEEE Senior Member.
Ajay's views, from 15 years in the field. Not legal or compliance advice. See full disclaimers →
Published by AI Exponent LLC
