Why more AI usage can still leave shipping slow
A team can write code faster this month and still ship at the same tired pace as last month. That’s the part people keep missing when they look at AI adoption charts and assume they’ve found proof of faster delivery. If more engineers are using copilots, chat assistants, or code generators, it does tell you something. It tells you the tools are being used. It does not tell you that customers are seeing features sooner.
That confusion shows up everywhere. A manager sees a higher AI usage rate, a couple of PRs land faster, and the slide deck starts to look optimistic. Then the release train hits review queues, QA waits, product sign-off, or a flaky deploy, and the whole thing slows right back down. The code may arrive earlier in the pipeline, but the work still has to pass through the rest of the pipeline before it creates value.
More AI activity in the editor says a lot about typing speed. It says very little about when the work reaches production.
This is where the distinction between local speed and system speed matters. Local speed is what happens inside one engineer’s editor: drafting a function, sketching a test, refactoring a gnarly block of code. System speed covers the whole path from “this work exists” to “users can use it.” If the first part gets faster while the rest stays congested, the overall result barely changes. You can even make the queues longer. Faster coding can produce more pull requests, and more pull requests can create more waiting if the review process wasn’t built for that volume.
That’s why raw AI usage counts are such a tempting distraction. They’re easy to measure and easy to celebrate. A chart that says “72% of developers used AI this week” feels tidy. It also says nothing about lead time, which is the number that actually answers the shipping question. How long does work sit before it merges? How long does it wait in review? How long does it get stuck behind another team’s dependency or an approval step nobody can see from the editor? Those are the questions that expose where delivery gets jammed up.
So yes, track adoption if you want to know whether people are trying the tool. Just don’t confuse that with shipping speed. A team can use AI heavily and still release slowly if the workflow around it stays brittle. The real story lives in software delivery metrics that measure flow, delay, and rework, not in a headcount of autocomplete sessions.
Once you start looking at the full path, the pattern gets clearer fast. The next question isn’t “Are people using AI?” It’s “Where does the work stop moving?”
Faster typing is only one part of the pipeline
A developer who can turn out a feature twice as fast at the keyboard is still stuck inside a bigger machine. The code has to get reviewed. It has to pass QA, if your team still uses it. Someone from product may need to sign off. Then the deployment has to behave itself, which is asking a lot from modern software on some Tuesdays.
That’s the part people miss when they celebrate adoption of AI coding tools as if they were a shipping metric. Local speed goes up. The editor feels snappier. Pull requests appear sooner. Your team may even feel a bump in developer productivity, at least on the surface. But if the rest of the path is clogged, the business gets only a slice of that gain.
A faster draft is useful only if the rest of the workflow can keep up.
That sounds obvious until you look at the actual queue. A feature can spend twenty minutes being generated and then sit for two days waiting on review. It can move through QA quickly and then stall because product wants a wording change on one modal. It can pass every check in staging and still get trapped by a flaky deployment or a release window nobody wants to touch before lunch. The code itself was never the slowest part.
This is why charts can look cheerful in one tab and disappointing in another. AI adoption can climb while delivery time barely moves. A team may report that more engineers use AI every week, more files get touched by copilots, and more code starts life as generated text. Nice. But if merge time stays flat, if review queues are still long, and if deployment failures keep bouncing work back into the queue, the release date does not care how fast the first draft was written.
The same pattern shows up in teams that adopt automation elsewhere. You can speed up test generation and still wait on a brittle suite. You can make code review comments shorter and still have too few reviewers. You can draft product docs in minutes and still lose a day to a release approval step. Every downstream stage acts like a sink. It absorbs time. It absorbs energy. It eats whatever gains the upstream step produced.
If you want a more honest picture, look at how long work waits between stages. DORA metrics are a decent starting point here, because they push teams toward delivery flow instead of raw activity counts. The DORA metrics guide lays out the basics, and Google’s Four Keys approach to measuring DevOps performance is a practical way to think about the same problem. Neither one asks, “How much AI did you use this week?” They ask, in different ways, “How fast did work move, and where did it stall?”
That distinction matters because optimization at one step can be swallowed by queues later in the chain. If generation gets faster but review stays manual and overloaded, the bottleneck just moves. If QA still depends on a human clicking through the same brittle path, the queue sits there like an unpaid tab. If deployments are unstable, your team gets to enjoy rework, which is a charming way to spend a Friday evening.
So yes, speed at the keyboard helps. No argument there. But system speed is what decides whether a customer sees the change, whether revenue lands sooner, and whether your team spends less time staring at waiting states. Faster typing can reduce one slice of the work. It cannot rescue the whole pipeline by itself.
Measure end-to-end flow, not activity
If faster typing is the input, lead time is the output that actually matters. The number to watch is simple enough: how long does work take from the moment it enters the system until a user can actually feel it? That might mean from ticket creation to production, or from the first commit on a change to the deployed release, depending on how your team draws the boundary. What matters is that the clock starts when the work becomes real and stops when it is delivered.
DORA has tracked this idea for years under lead time for changes, and that framing is useful because it pulls attention away from noisy activity metrics. A team can write more code, open more pull requests, or spend more hours in the editor and still leave shipping speed unchanged. If the work spends most of its life waiting, the extra typing just produces a larger pile of waiting things.
The useful question is not “how much did we touch?” It’s “how fast did work move through the system?”
That shift sounds small, but it changes what you look for. Instead of counting commits or AI-assisted edits, trace the path of a change through every handoff. Who picks it up first? Where does it sit next? How long does it wait there? How many times does someone send it back for changes? Once you look at the whole route, the hidden delays usually stop hiding.
A lot of teams confuse active work time with queue time. Active work time is when someone is actually changing code, writing tests, or fixing a failing build. Queue time is everything else. A pull request waits for review. A review waits for a reviewer. A deployment waits for a release window. A bug fix waits for another bug fix to clear the runway. None of that shows up if you only ask, “How productive were the developers this week?”
That distinction matters because queue time often dwarfs the time spent typing. A change might take an engineer 45 minutes to implement and then sit for 36 hours before review starts. Another might get merged quickly, then bounce through QA because a test kept failing in the same place. On paper, the team looked busy. In practice, the work barely moved.
This is where cycle time and lead time get mixed up in casual conversation. People use both terms to talk about speed, but the useful habit is to separate motion from waiting. If you can see how much of the path is active work and how much is queue, you can tell whether the team is blocked by code, coordination, or process. Without that split, you end up praising the fastest typist in a room full of stalled tickets.
Treat the delivery path as a chain of handoffs, because that is what it is. One person starts the work. Another reviews it. A third signs off. Then the system itself gets a vote, which is rude but unavoidable. If your deployment path runs through CI, containers, and Kubernetes, even the infrastructure layers become part of the flow. Google’s modern CI/CD guide for GKE is a decent reminder that releases are usually a sequence, not a single event. Each handoff can add delay, and each delay shows up in lead time.
Once you start measuring the full path, the picture gets clearer. You stop asking who wrote the most code and start asking where the work sat still. That is the useful question if you care about shipping faster, because speed lives in movement, not motion.
The metrics that reveal real bottlenecks
A useful dashboard for delivery speed doesn’t need a hundred charts. It needs a few measurements that show where work stalls after the code is written. That’s the part a lot of teams skip. They can tell you how many prompts were used, how many lines were generated, maybe even how many PRs touched AI-assisted code. Fine. But if you want to know whether shipping got faster, you need to see what happened after the editor closed.
The first number I’d track is time to merge. This tells you how long a pull request sits between “opened” and “landed.” A short time to merge usually means the team can get work reviewed and accepted without much drag. A long one means the code is waiting somewhere, even if the author finished in a flash. That wait might come from reviewer load, oversized PRs, or a habit of letting changes age in the queue until somebody has a quiet afternoon. The useful part here is that time to merge separates coding speed from delivery speed. A developer can finish a task in an hour, and the work can still spend two days in limbo.
From there, split out time in review. This is where a lot of teams discover a quiet code review bottleneck. If PRs sit untouched for hours or days, the issue usually isn’t that the author typed too slowly. It’s that review capacity doesn’t match incoming work, or that reviewers are waiting for someone else to go first. Sometimes the queue gets worse because reviews are too large and too fuzzy. Nobody wants to open a 900-line diff after lunch. Smaller PRs usually move faster, but the point isn’t moral purity. It’s reducing the time work spends parked between “ready” and “approved.”
If code only moves quickly before it reaches other people, the dashboard is lying by omission.
After review, measure time blocked by dependencies. This includes cross-team waits, external approvals, security sign-off, API access, legal review, product decisions, and any other condition that sits outside the engineer’s direct control. These delays can hide behind a healthy-looking commit stream. A developer may finish their piece, then spend a day waiting for another team to expose an endpoint, or a vendor to approve a change, or a manager to decide whether the scope is still real. If that wait isn’t tracked separately, it gets lumped into vague “delivery time,” which makes it hard to fix. Put a timer on the block itself. That gives you a clean answer when someone asks where the schedule went.
The next slice is QA delay. If testing happens in a batch at the end, it often becomes a queue of its own. Work can sit after merge while tests run, bugs get logged, repro steps are clarified, or someone manually checks edge cases that should probably have been covered earlier. QA time matters most when it is not just “testing time” but “waiting for testing.” Those are different problems. One is the work itself. The other is line-standing. If your team sees a lot of time here, you may need better test automation, smaller releases, or a tighter feedback loop between development and validation. The exact fix depends on the shape of the delay.
Then there’s deployment instability and rework. A deploy that fails, rolls back, or triggers a hotfix adds time that doesn’t show up in a simple coding metric. So does a feature that ships and then needs another pass because requirements were half-baked, the edge cases were missed, or the first implementation was rushed. Google’s State of DevOps research has long treated lead time and deployment performance as operational metrics for a reason: shipping speed is not just about writing faster code. It’s about how quickly changes move through the whole system, including the part where things break and need another round.
If you want a dashboard that tells the truth, keep these slices separate. Track time to merge. Track time in review. Track time blocked by dependencies. Track QA delay. Track failed deployments and rework. Once those numbers are visible side by side, the picture gets a lot less fuzzy. You can tell whether AI is actually helping or whether it just made the typing stage faster while the rest of the pipeline kept its old habits. And that’s the distinction that matters before you start changing the process.
How to use the data to ship faster
Once you have the numbers, resist the very human urge to declare victory because one chart moved up and to the right. A team can report more AI-assisted commits, more generated scaffolding, or more code written per day and still ship at the same pace. The baseline should be delivery time, not tool activity. Start with your current lead time, then break it into pieces you can actually act on: time to merge, time in review, time blocked on dependencies, QA delay, deployment failures, rework. That gives you a before picture that isn’t based on vibes or whoever wrote the loudest Slack message that week.
Faster shipping usually comes from removing waits, not from celebrating more typing.
From there, pick the single worst waiting point. Not the one that feels most annoying in a retro. The one that consumes the most calendar time. If pull requests sit for two days because reviewers are overloaded, speeding up code generation won’t move much. If QA queues are long because every change needs manual checks, a smarter editor won’t clear that pile either. If deployments fail often, the problem is probably release reliability, not developer speed. In other words, look for the constraint that turns finished work into parked work.
That’s where AI can help, but only when it matches the bottleneck. If the slowest part is drafting repetitive code, tests, or migration scripts, using AI there might cut the delay in a real way. If the slowest part is review, use AI to improve the shape of the PR before it lands. Summaries, smaller diffs, tighter test coverage, clearer intent in the description. Those are practical uses. If the real drag is dependency wait time, AI won’t magically make another team answer faster. It can help write better specs or reduce back-and-forth, but it won’t replace the missing approval.
This is also where DORA metrics earn their keep. They give you a way to check whether a change actually improved the engineering workflow or just made people feel busier. Review the data on a regular cadence, not once a quarter when everyone has forgotten what happened. Weekly works well for many teams. Look for two things: did waiting time drop, and did rework stay flat or improve? If lead time shrinks but rework spikes, you may have simply pushed lower-quality work downstream faster. That’s not progress, that’s faster chaos.
The nice part is that you don’t need a grand transformation plan. Fix one bottleneck, measure again, repeat. If the queue moved, keep going. If it didn’t, stop pretending the first guess was right and try the next constraint. Faster shipping comes from better flow through the system. AI is one tool in that system, useful in some places and irrelevant in others. The teams that ship faster usually know the difference.
