Writing
The One-Year Law: Why AI Broke DORA's Ten-Year Invariant
For ten years, software delivery operated under a proven invariant: throughput and stability move together. Generative AI broke it in a single year.
EngineeringFor ten full years, the main rule in software engineering was simple: speed and stability move together.
From 2014 to 2023, the DevOps Research and Assessment team surveyed tens of thousands of engineers. They found the same pattern each year. Elite teams shipped code more often. They pushed changes faster. They recovered from outages quicker. They had far fewer bad deploys.
In their 2018 book Accelerate, Nicole Forsgren, Jez Humble, and Gene Kim stated the rule:
Astonishingly, these results demonstrate that there is no tradeoff between improving performance and achieving higher levels of stability: they move together.
The logic was clean. Speed came from discipline. Small batch sizes cut risk. Daily trunk habits stopped merge pain. Automated test suites caught bugs before code reached users.
Then 2024 arrived, and the rule broke.
The break
The split showed up in the 2024 Accelerate State of DevOps Report.
For the first time in ten years, teams adopting AI tools saw delivery speed break away from operational stability. The survey covered nearly 3,000 engineers. It showed that for every 25% jump in AI use, delivery throughput fell by 1.5%, while delivery stability dropped by 7.2%.
By the 2025 report, throughput bounced back as developers learned to use their tools. But delivery stability stayed low. As the DORA team noted, AI acted as an amplifier. It helped strong teams with automated test suites, and it sped up pain everywhere else.
When a ten-year rule dies in twelve months, people seek easy targets. The common tale blames model mistakes or junior developers who paste code they cannot read.
That sets up a neat fix. If bad code is the problem, the cure is better prompts, cleaner context, and stricter linters. I know that idea is tempting. I spent months believing it.
It does not survive contact with a real pipeline.
Where the pipe bursts
The breakdown happens in the review queue.
Consider the ideas behind trunk-based development. In the 2016 DORA report, keeping active branches under three and branch lives under one day predicted high delivery speed. That workflow rested on a quiet fact: humans wrote code at the same pace other humans could review it.
When an engineer wrote code by hand, drafting a 300-line change took hours of thought. Reviewing it took thirty minutes. New pull requests rarely choked the review queue. Small changes moved like water through an open pipe.
AI erased the writing bottleneck, but it left the review bottleneck alone.
An engineer with coding agents can build three big feature branches before lunch. Across a team of twenty engineers, the flow of new pull requests jumps. Basic queue math shows what happens next. When work arrives faster than reviewers can read it, queue wait times explode.
When pull requests sit in queues for days, two bad things happen.
First, merge friction grows. Long-lived branches drift from the main trunk. They create semantic conflicts that pass automated merges but break real systems.
Second, reviewer fatigue sets in. Senior engineers drown in synthetic pull requests. They stop reading every line. They start rubber-stamping diffs. Code that merely looks fine gets merged straight into production.
The speed-stability rule did not fail because AI wrote bad code. It failed because our pull-request queues were built for human typing speed.
Checks at the boundary
You cannot fix this queue by hiring more human reviewers. The math fails. The real fix requires moving checks out of the pull request and into a local execution harness.
The old workflow used human pull-request reviews as the main quality gate. In an agentic world, that design breaks. Humans are poor at spotting tiny bugs across thousands of lines of machine code. Humans are good at setting intent, picking system boundaries, and judging risk.
Teams that fix this speed-stability split make an architectural shift. They treat generated code as unverified work until proven right by automated test suites.
They do not ask senior engineers to read raw code text in GitHub. They require the author, human or agent, to supply automated proof of correctness inside an execution harness. That means running fast unit tests, checking strict type contracts, and testing live behavior before a human opens the diff.
The pull request stops being a manual bug hunt. It becomes a checkpoint where humans verify that the automated gates ran clean.
The ten-year DORA rule was a measure of balance between human writing and human review. AI broke that balance for good.
Speed and stability can still move together, but only for teams that build test harnesses fast enough to match their code generators.