👋 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.
🔬The lens: The Instability Tax Ledger
Pull five numbers, each for the 90 days before your AI rollout and the 90 days after. You're after direction here, not precision: which way did each one move. Most leaders have never set these side by side.
Change failure rate - Of the changes you shipped, what share needed a rollback, hotfix, or follow-up incident? Moving up is the clearest signal you're paying the tax.
Incidents per change - Total incidents divided by deploys. If deployments doubled and incidents more than doubled, your speed is net negative.
Rework rate - What share of merged PRs got touched again within two weeks? High churn means you're shipping drafts and paying to finish them in production.
Review backlog age - Median time a PR waits before it's reviewed. A growing queue here is the downstream bottleneck forming in real time.
Unplanned work as a share of capacity - How much of the last two sprints went to firefighting and stabilization versus the planned roadmap? This is the tax expressed in lost product time.
How to read it: If three or more of these moved the wrong way since you switched AI on, you're paying the instability tax, and it compounds; one rough release seeds the incidents in the next. Nobody's arguing you should ship slower. The point is to see the bill coming before Q3 hands it to you.
🪞 In practice
Scenario: A B2B SaaS company, a mid-size engineering org, rolled out AI coding tools across the board in early 2025. Adoption was fast, and morale was high.
What the dashboard showed: Deploy frequency up sharply. Lines of code merged way up. The leadership update wrote itself.
What the ledger showed when they finally pulled it: Change failure rate had crept from roughly one in twelve deploys to nearly one in five. On-call pages had close to doubled. Two of the three biggest features promised for the half were sliding, not because they were hard, but because the team kept getting pulled into stabilizing last week's shipments.
The move: They stopped chasing deploy frequency as the headline metric and started reviewing failure rate next to it every two weeks. They reinstated mandatory review on anything touching billing and auth, even when the AI wrote it confidently.
The tradeoff they accepted: Throughput dipped for about six weeks, and that was uncomfortable to explain upward. I'll be honest, I've been on the other side of this. I once helped a team celebrate a doubled deploy number for a full quarter before anyone asked what the failure rate was doing. We were optimizing the easy half.
Result: Failure rate came back down, not all the way, but close. On-call calmed enough that the two engineers stayed. The roadmap stopped getting eaten alive, though they'd already lost most of a quarter to cleanup before anyone looked. The deploy number settled below its peak, and as far as I know, nobody outside engineering ever noticed.
🎯 This week's move
Pull the five Instability Tax Ledger numbers for your own org, before and after AI rollout. An afternoon, not a project.
Add change failure rate and incidents-per-change to whatever throughput slide goes to leadership next. Stop reporting half the picture.
Look at where your senior review capacity is actually going. If it's been cut to fund tooling, you've removed the thing that pays the tax down.
By the end of this week, aim to know your change failure rate before and after AI, as one number you can say out loud in a meeting.
👋 Wrapping up
The speed is genuine. The thing most teams skipped is funding the cost of keeping it.
This tax stays invisible through the demo. You meet it a quarter later, on a brutal on-call week, staring at a roadmap that slipped while no one was watching.
Before you pay for more speed, find out what the last batch is still costing you.
Small ask: Hit reply and tell me one number: has your change failure rate moved since you rolled out AI coding tools? Up, down, or you don't measure it yet?
Thanks for reading.
See you next week,
Bogdan Colța
Tech Architect Insights