👋 Hey {{first_name|there}},
The stakes
The throughput chart in your board deck is real. The bill that follows is quieter, and it lands about a quarter later, in your on-call rotation, your incident count, the roadmap items that slipped while everyone was firefighting. AI didn't make that cost disappear. It moved it downstream, where the dashboards don't look.
📉 Where it's costing you
Last week, I covered how the delivery bottleneck moved downstream once AI sped up the typing. This is the part nobody puts on a slide: what that downstream pile-up actually costs you, release after release.
A head of engineering I talked to recently was proud of a clean number. Deploy frequency had roughly doubled in a year. Hard to argue with. Then, a little quieter, he mentioned that on-call had gotten brutal, two senior engineers were grumbling about leaving, and about a third of the quarter's roadmap had been eaten by stabilization work that never made it onto any executive summary. He hadn't connected the two facts. The speed and the pain were living in different spreadsheets.
That's the instability tax. You ship faster, you ship more, and a system that was never built to absorb that volume starts charging you for it downstream. The research backs this up more bluntly than the vendor decks admit. DORA's 2025 report, across roughly 5,000 professionals, keeps landing on the same finding: AI lifts throughput and, at the same time, hurts delivery stability. Their own word for it is amplifier, not solution. It magnifies whatever shape your delivery system was already in.
Faros AI's 2026 telemetry, drawn from around 22,000 developers, puts numbers on the damage. Incidents per change are up more than 240 percent. Read that slowly: every code change you merge is now more than three times as likely to cause a production incident as it was before. Median time sitting in review climbed past four times what it was. Bugs per developer up by half. The throughput went up, and so did almost everything you don't want.
And here's the cruel part. The people you'd lean on to pay this tax down, the senior engineers doing careful review and hardening, are exactly the headcount that gets trimmed to fund the tooling. You cut the people who turn fast output into something customers can rely on, then act surprised when the value never lands.
🧭 The shift
From: "Velocity went up, so delivery improved."
To: "Velocity went up on credit. The instability tax is the interest, and it comes due every release."
Speed you can't sustain is a loan, and most teams took it out in 2025 without setting up the payments. The trap is an easy one to fall into: you measure the part that got cheaper, which is writing code, and you wave through the part that got more expensive, which is everything after the merge. A throughput chart on its own isn't a measurement. It's a press release.
A couple of defaults that change the conversation:
Put change failure rate and incidents-per-change on the same slide as your deploy frequency. If you only show the speed number, you're reporting half a sentence.
Count the firefighting, rework, rollbacks, the review backlog, and the roadmap work displaced by stabilization. That is the real price of the velocity, and it belongs on the same slide as the wins.