Lakshmi Priya Gopalsamy

The AI Velocity Paradox

Oct 11. 2026 * Lakshmi Priya Gopalsamy, Independent Researcher & Technology Lead, Software Engineering, USA

 How GenAI exposes the delivery debt your DORA metrics have been hiding

The dashboard stayed green

Picture a quarterly review. The team rolled out AI coding assistants at the start of the quarter. Now the DORA dashboard is on the screen.

Deployment frequency is up. Lead time for changes is down. Change failure rate is flat. Every chart points the right way, and the room is happy.

Then someone from on-call asks a simple question: why are we getting paged more?

Nobody has a good answer. Nothing on that dashboard explains it.

I keep seeing this pattern in teams that adopted AI coding tools. Underneath the green charts, PRs were getting bigger. Reviews were faster but shallower. Small fixes went out right after releases, quietly, so they never counted as failures. And a few changes broke rules nobody had ever written down.

The dashboard was green. The system was carrying debt. That gap is what I call the AI velocity paradox.

DORA’s own data shows it

This isn’t just my read. DORA’s research has been tracking it for three years.

YearReportWhat it found
2024Accelerate State of DevOpsFor every 25% rise in AI adoption, delivery stability fell about 7.2% and throughput fell about 1.5%.
2025State of AI-assisted Software DevelopmentAbout 90% of professionals use AI at work. Throughput turned positive. Instability kept rising.
2026ROI of AI-Assisted Software DevelopmentExpect a J-curve: a dip before the gains. In DORA’s illustrative model, a change failure rate moving from 5% to 6% costs about $344K in downtime.

DORA’s 2025 summary is the one I keep coming back to: AI doesn’t fix a team; it amplifies what’s already there. The report adds that without strong control systems, such as automated testing, mature version control and fast feedback loops, more change volume leads to instability.

So the speed is real. The instability is real too. Both are true at the same time. That’s the paradox.

Why the dashboard didn’t warn us

Let me be fair to DORA. The metrics are good, and I still use them. But they measure the pipeline. They don’t measure how much change your system can safely absorb.

Deployment frequency counts deploys, not what’s inside them. When AI makes PRs bigger, every deploy carries more risk. The number looks the same, or better.

Lead time for changes measures commit to production. It doesn’t see the queue before the commit lands: the review wait, the back-and-forth, the approvals. That’s exactly where AI-generated code piles up.

Change failure rate counts the failures you call failures. A quick follow-up fix, a config tweak, a hotfix that never got an incident ticket. None of that shows up.

Recovery time tells you how fast you fixed something. It says nothing about the hidden assumptions you shipped that just haven’t broken yet.

Each metric is honest. But all four lag. They tell you about debt after it comes due, not while it’s building.

What delivery debt is

Delivery debt is the gap between how fast you can produce change and how fast your system can safely absorb it.

Every system has a change absorption capacity. A few things set it: how explicit your contracts are, how well your tests cover the real domain rules, how good your observability is, how coupled your services are, and how fast your team can make good decisions.

AI raises how fast you can produce change. On its own, it does nothing for absorption. When production speed outruns absorption capacity, the gap doesn’t disappear. It turns into debt. For a while, that debt is invisible on a DORA dashboard.

Where it comes from: the illusion of correctness

AI-generated code is clean. It compiles. It passes tests. In review, it looks like a solid engineer wrote it. The trouble is the assumptions underneath. Four kinds break production most often:

  • Boundary: “This field is always present.” Until a downstream service starts dropping it, and a real order hits that edge case at 2am.
  • Concurrency: “This call is safe to retry.” It isn’t. That’s how a customer gets charged twice on code that looked fine in review.
  • Domain: “These two order statuses mean the same thing.” Fulfillment and billing have always treated them differently. Nobody wrote it down, so the AI couldn’t know.
  • Security: “This request is internal, so it’s trusted.” Your internal network is not your security boundary.

None of these show up in code review. They show up in incidents. Until they do, every one of them is debt.

Where the debt hides

In my experience, it hides in five places.

  1. Contract debt. Boundaries that exist only as shared understanding, and a doc nobody updates.
  2. Verification debt. Tests that cover what the AI could infer from the code, not the rules that live in people’s heads and old postmortems. High coverage, wrong coverage.
  3. Observability debt. You know what the code says. You don’t know what it does.
  4. Coupling debt. Hidden dependencies that make every change ripple further than it should.
  5. Decision debt. The one we talk about least. When code arrives faster than people can review it, reviews get shallower or queues get longer. Reviewers carry more cognitive load, and decisions get rubber-stamped. DORA’s 2026 study has a name for this cost: the verification tax.

Decision debt isn’t a tooling problem. It’s a decision architecture problem.

Why faster becomes slower

Keep pushing speed on a system carrying this debt, and a familiar shape appears.

At first, velocity goes up. It looks great. Then the debt starts coming due: debugging, rollbacks, rework. The time you saved generating code gets spent two or three times over cleaning up.

So velocity doesn’t compound. It oscillates. Fast for a quarter, then slow while the team pays it back. Then someone asks why the AI investment stopped paying off.

DORA sees the same shape. Its 2026 study traces the dip to three causes: the learning curve, the verification tax, and downstream processes like testing and change approval that haven’t caught up. DORA calls it the tuition cost of transformation, and warns that leaders who read the dip as failure pull the funding and lose the gains.

The dip is real. But you don’t have to wait it out blind.

Read DORA in pairs

Keep DORA. Just stop reading its metrics alone. Give every speed metric a safety partner, and read them together.

Speed metricIts safety partnerWhat the pair tells you
Deployment frequencyRework rateBoth rising: you’re busier, not faster
Lead time for changesDecision latency: review queue time, review loops, escalationsLead time down, queue up: your debt is in your decisions
Change failure rateRework rate plus contract drift alertsFailure rate flat, rework up: failures are hiding
ThroughputChange cost: PR size, files touched, incidents per changeCost per change rising: coupling debt

Rework rate is the one DORA itself added as a fifth metric. It counts the unplanned deployments you push because something wasn’t right the first time. It often moves before change failure rate does.

Decision latency comes from my own research. It’s the time your organization takes to make a quality decision: notice the problem, coordinate, approve, act. You can track it with simple proxies like approval queue time, review loops, escalation frequency and rework churn.

Change cost answers one question: is it getting cheaper or more expensive to change this part of the system over time? That’s the real health signal for a codebase.

Contract drift alerts fire when a schema or a field’s meaning changes without a version bump. You catch the problem at a 0.3% error rate, not from a customer ticket three days later.

Paying it down: CATS

Once you can see the debt, you can pay it down. The framework I use with my teams is CATS.

  • Contracts. Make boundaries explicit: API specs, event schemas, field meanings, owners. Every time someone says “I thought that field was always there,” that’s a contract waiting to be written. AI generates far better code against an explicit contract than an implied one.
  • Automated Verification. Tests that enforce domain rules, not just happy paths. Schema checks and security checks in CI. Your job is to name the invariants. AI’s job is to cover them.
  • Telemetry. Code review tells you what the code says. Telemetry tells you what it does. Add drift alerts, feature flags and canaries, plus a rollback checklist your team can run at 11pm without a four-person call.
  • Simplification. Remove hidden coupling as a habit, bundled into feature work. Touch it, improve it. Measure it by change cost, not by how clean the code looks.

Contracts and verification raise your absorption capacity. Telemetry tells you when you’re over it. Simplification keeps it growing.

Keep humans where decisions are made

CATS alone won’t fix decision debt. You also have to be explicit about where AI helps and where humans still own the call.

AI can draft, generate, summarize and suggest at almost every stage. Humans still own problem framing, architecture boundaries, approval of risky changes, the go or no-go decision, and incident tradeoffs. Treat AI output as a draft, not a decision.

And use AI where it’s strongest: as a design-time partner, not a runtime engine. Have it write the check, the validator or the rule once. A human reviews it. Then deterministic code runs it every time. That turns a recurring judgment cost into a one-time cost, and frees your reviewers for the decisions that actually need them.

Two weeks to start

You don’t need a roadmap conversation for this, and you don’t need to pause feature work.

Week 1: see the debt.

  1. Put rework rate and review queue time next to your DORA metrics.
  2. Baseline them.
  3. Find your two or three most brittle boundaries.
  4. Write their contracts, and gate CI on schema validation.

Week 2: start paying it down.

  1. Write one invariant test suite for the domain rule that would hurt most if it broke.
  2. Add drift alerts on those boundaries.
  3. Remove one high-risk coupling point.
  4. Add a feature flag template and a rollback checklist.

Then check again in four weeks. Is rework going down? Is change cost going down? That’s your answer.

DORA isn’t wrong. It’s incomplete.

DORA tells you how fast change moves through your pipeline. It doesn’t tell you how much change your system can safely take. AI made the first number much bigger. It didn’t touch the second.

The teams that win won’t be the ones that generate the most code. They’ll be the ones that can absorb it safely.

So on Monday, put one safety metric next to every speed metric. Find one brittle boundary. Write its contract.

I’m presenting this as a talk at Raptors Conference 2026 (online, 21 October 2026).

References