More and more developers are using AI assistants to write code. With these tools, teams can move from an idea to implementation much faster than before. Logically, overall delivery should speed up as well — but often not as much as we would expect.
A team might reduce implementation time by 30% or even 50%, while the time it takes for a feature to actually reach production changes only slightly.
The reason is that other stages of the workflow — waiting for code review, QA, testing, approvals, and release — do not automatically speed up just because coding does.
That’s why it’s important to ask: if AI has significantly accelerated coding, why isn’t overall delivery time improving at the same pace?
Coding time is only one part of delivery time
Let’s imagine a typical workflow in a development team:
To Do → Development → Code Review → Awaiting QA
→ Testing → Ready for Release → Done
By breaking down the time in the status in more detail, you can see the following picture:
- 2 days in Development
- 2 days waiting for review
- 3 days waiting for QA
- 1 day in Testing
- 2 days waiting for release
Development time: 2 days. Total delivery time: 10 days.
With AI becoming part of the development process, it’s entirely possible to cut implementation time in half. In our example, that means cutting it from 2 days to 1.
That's a 50% improvement in Development.
But if everything else stays the same, the total delivery time drops from 10 days to 9, which is only a 10% improvement.
The team really did get faster at writing code — the improvement just happened in one part of a much larger delivery system.
Faster coding can expose the next constraint
Think of the workflow as a sequence of stages, each with its own capacity.
When Development becomes faster, more work can reach downstream stages sooner.
If Code Review, QA, Testing, or Release have enough capacity to absorb that work, delivery improves.
If they don't, some of the productivity gain turns into queue time.
The delay hasn't necessarily disappeared. Part of it has moved downstream.
That can show up in several places.
- Code Review. Developers open PRs faster, but reviewer availability stays the same. Development gets shorter while the review queue gets longer.
- QA. More work becomes ready for QA, but QA capacity, test environments, and test data haven't changed. Items begin to accumulate in Awaiting QA.
- Testing. More changes reaching Testing can increase regression scope, environment contention, or coordination work.
- Release. The feature is implemented and tested but still sits in Ready for Release, Approved, or Pending Deployment, waiting for a release window, approval, dependency, or another team.
This doesn't mean faster coding is useless.
It means the next opportunity for improvement may no longer be in Development.
Don't measure the stage you optimized in isolation
Suppose a team starts using AI coding tools and sees this:
Before
Development: 4.0 days
After
Development: 2.0 days
A 50% reduction looks impressive.
And it is.
But now look at the full path.
Before
Development 4.0 days
Code Review 1.0 day
Awaiting QA 1.5 days
Testing 1.5 days
Ready for Release 2.0 days
Total: 10 days
After
Development 2.0 days
Code Review 1.5 days
Awaiting QA 2.0 days
Testing 1.5 days
Ready for Release 2.0 days
Total: 9 days
Development improved by 50%.
Overall delivery improved by 10%.
That's still a real improvement. But it tells a very different story from looking at Development alone.
It also gives the team a much better question to investigate:
What is limiting the other 90% of the delivery path?
Overall cycle time isn't enough either
Looking only at Development can hide downstream delays.
But looking only at total cycle time has the opposite problem: it tells you that delivery is slow without telling you why.
Suppose your average cycle time is 11.5 days.
That gives you the end-to-end number.
But those 11.5 days might consist of very different things:
Active Development
Code Review
Waiting for QA
Testing
Blocked time
Approval delays
Waiting for deployment
Each one has a different cause and a different fix.
So if you want to understand why delivery isn't improving as quickly as coding productivity, you need to break the total down by workflow stage.
Break delivery time down by status
Here's an example for 50 recently completed Jira work items:
Workflow stage
Average time
Development
1.8 days
Code Review
1.2 days
Awaiting QA
3.4 days
Testing
1.5 days
Ready for Release
2.7 days
Development takes 1.8 days.
Awaiting QA and Ready for Release together take more than six.
At this point, reducing Development from 1.8 days to 1 day would certainly help.
But it would not transform delivery.
The bigger questions are:
Why does work spend 3.4 days waiting for QA?
and:Why does tested work spend another 2.7 days waiting for release?
That's where the difference between developer productivity and delivery performance becomes visible.
How to check this in Jira
Jira already stores the underlying history.
Every status transition is recorded in the issue changelog with a timestamp.
The challenge is aggregation. Looking at the history of one issue tells you what happened to that issue. It doesn't tell you whether the same pattern exists across a sprint, release, project, or team.
There are two basic approaches.
1. Build the calculation yourself.
For individual issues, Jira provides:
GET /rest/api/3/issue/{issueIdOrKey}/changelog
For multiple issues, you can use:
POST /rest/api/3/changelog/bulkfetch
From there, you can extract status transitions and calculate how long each item stayed in each status.
The basic calculation isn't especially complicated. The edge cases are.
You also need to decide how to handle:
- non-working hours
- weekends and holidays
- work items that enter the same status multiple times
- open items that haven't completed yet
- different work schedules
- outliers
2. Use a Time in Status report.
Another much simpler way is to use Time in Status app by SaaSJet.
It aggregates Jira status history across multiple work items and shows how much time they spend in different workflow stages without requiring you to calculate the changelog manually.
Whichever approach you use, the analysis itself matters more than the tool.
Start with a meaningful comparison
If you're trying to understand whether faster Development is translating into faster delivery, don't just compare one sprint with another randomly.
Use comparable periods or groups of work.
For example:
- several sprints before and after introducing AI tooling
- similar releases
- the same team over two comparable periods
- similar issue types or work categories
For cycle-time analysis, completed items give you a defined start and endpoint.
But don't ignore current WIP entirely.
If ten open tickets have already been sitting in Awaiting QA for two weeks, excluding them can make your completed-item numbers look healthier than the process really is.
Use completed work for consistent cycle-time comparisons, then inspect long-running open work separately.
Look at average and median together
Status-duration data is rarely perfectly distributed.
Imagine most work items spend one or two days waiting for QA, while three items wait for two weeks.
The average can move dramatically.
The median may barely move at all.
So don't rely on one aggregate.
If average and median are close, the pattern may be relatively consistent across the sample.
If they're far apart, investigate the underlying items. You may be seeing a small number of long-running cases, different types of work behaving differently, or a genuinely uneven process.
The aggregate tells you where to look.
It doesn't automatically tell you why.
Separate active time from waiting time
This distinction becomes especially useful as coding gets faster.
Compare:
Development: 2.5 days
Awaiting QA: 2.0 days
The numbers are similar.
Their meaning can be completely different.
Two and a half days in Development may represent active work.
If your workflow uses Awaiting QA as a true queue state, two days there represent time before QA begins.
Reducing active execution time through better tools, automation, or AI is useful.
But once waiting becomes a significant share of total cycle time, further optimizing execution produces diminishing returns unless the queues improve too.
That's why a useful metric to watch is the relationship between:
active time / total delivery time
and:
waiting time / total delivery time
If Development gets faster but waiting consumes a larger percentage of the cycle, you know where the next constraint is appearing.
Check whether the delay is systemic
Finding one status with a large number isn't enough.
Suppose Awaiting QA averages 3.4 days.
Before concluding that QA is the bottleneck, ask:
Is the wait high for most items?
Is the average being driven by a few extreme cases?
Does the pattern appear across several sprints?
Is one team responsible for most of it?
Is it concentrated in certain issue types?
Did the queue begin growing after Development throughput increased?
The answers matter.
A consistent three-day QA wait across most items suggests one kind of problem.
Five items waiting two weeks while everything else flows normally suggests another.
The longest status gives you a place to investigate.
It isn't automatically the bottleneck.
Compare the whole flow before and after
This is where you can see whether local productivity improvements are translating into system-level gains.
Imagine the following.
Before
Development 3.5 days
Code Review 1.0 day
Awaiting QA 1.2 days
After
Development 2.0 days ↓
Code Review 1.8 days ↑
Awaiting QA 2.6 days ↑
Development improved by 1.5 days.
Review and QA became 2.2 days slower.
In this example, total delivery time actually increased.
That doesn't prove AI caused the downstream slowdown. Workload, team composition, scope, release policies, or other factors may have changed too.
But it immediately tells you something important:
the gain in Development did not translate into a gain for the whole delivery system.
In another team, the result might look like this:
Development 3.5 → 2.0 days
Code Review 1.0 → 1.1 days
Awaiting QA 1.2 → 1.2 days
Now total delivery really did improve.
The point isn't that faster coding never improves delivery.
It does.
The point is to measure how much of that improvement survives the rest of the workflow.
What to investigate when the gain doesn't carry through
Once you know where the additional time sits, the investigation becomes much more concrete.
Code Review is growing
Look at:
- reviewer availability
- PR size
- code ownership
- how reviews are distributed
- review policies
- context switching
If developers produce changes faster than reviewers can absorb them, review becomes the new constraint.
Awaiting QA is growing
Look at:
- QA capacity
- handoff rules
- environment availability
- test data
- automation coverage
- work arriving in batches at the end of the sprint
Testing is growing
Look at:
- regression scope
- flaky tests
- environment setup
- unclear acceptance criteria
- dependencies between changes
Ready for Release is growing
Look at:
- deployment frequency
- release batching
- approval steps
- change windows
- cross-team dependencies
The goal isn't to move optimization away from Development permanently.
It's to improve the stage that currently limits the whole system.
Measure productivity where the customer feels it
AI coding tools can produce meaningful productivity gains.
But implementation speed is not the same thing as delivery speed.
If Development falls from four days to two, that's worth measuring.
Then ask what happened to the rest of the workflow.
Did total cycle time fall by two days?
One day?
Half a day?
Did the gain disappear into Review or QA queues?
Did throughput increase?
Did more work actually reach production?
Those questions show whether a local productivity improvement became a delivery improvement.
So instead of asking only:
Are developers coding faster?
Ask:
How much faster is work reaching the customer?
And if the answer is “not nearly as much as Development improved,” the next step isn't necessarily to make developers even faster.
It's to find where the rest of the time is going.
The takeaway
Faster coding should make delivery faster.
But the relationship isn't one-to-one.
If Development represents only part of your total cycle time, a 50% improvement in Development cannot automatically produce a 50% improvement in end-to-end delivery.
And as Development gets faster, Review, QA, Testing, and Release become a larger share of the remaining delivery time.
That's why the real productivity question isn't:
How much faster can we write the code?
It's:
How much faster can we move work through the entire system?
Because that's the improvement the customer actually experiences.
Top comments (0)