Your AI writes faster. Why is your team waiting longer?
The code is ready before lunch. By the next morning, it is still waiting for someone to review it. The developer saved time, but the person waiting for the feature has not received it any sooner.
That gap matters when a team introduces AI coding tools. A quicker first draft is useful. To understand the effect on delivery, follow the change through review, corrections and release as well.
Here is a practical way to separate hands-on effort from elapsed time, find the queue that needs attention and run a small improvement experiment without turning colleagues into a productivity leaderboard.
Two clocks, two different questions
Atlassian’s 2026 State of Developer Experience research reports that many developers experience faster individual work while friction remains across their workflow. It is survey evidence, rather than proof of what caused delays in your team. Use it as a reason to investigate your own process.
Hands-on effort is the time people actively spend doing the work. Add contributions from the author and reviewer. Elapsed delivery time is how long the change takes between agreed start and finish points, including waiting.
Define those points before collecting numbers. This exercise starts when implementation begins and ends when the change is available to users. It is broader than DORA’s change lead time measure, which starts when a change is committed to version control and ends at deployment. Label your measure accurately rather than calling every duration “lead time”.
A worked example: the faster draft that arrives later
A team makes a small improvement to a report download screen. The figures below describe two constructed versions of that task, one with AI assistance. They demonstrate the calculation, not observed results or a forecast.
Assume the stages happen in sequence within working time, with one person active at a time. Review includes checking the behaviour and tests. Corrections include another check of the revised change. No stages overlap in this simplified example.
| Stage | Without AI | With AI |
|---|---|---|
| Initial implementation | 90 | 35 |
| Waiting for review | 120 | 240 |
| Active review | 30 | 50 |
| Corrections and recheck | 30 | 45 |
| Waiting for release | 60 | 60 |
| Total elapsed time | 330 | 430 |
Hands-on effort falls from 150 to 130 minutes: 90 + 30 + 30 becomes 35 + 50 + 45. Across the people involved, that is a saving of 20 minutes. Waiting rises from 180 to 300 minutes.
The change reaches users after 7 hours 10 minutes instead of 5 hours 30 minutes. The net increase is 100 minutes. The arithmetic shows how both statements can be true: less labour, longer delivery.
| Measure | Without AI | With AI |
|---|---|---|
| Hands-on effort | 150 min | 130 min |
| Waiting | 180 min | 300 min |
| Elapsed total | 330 min | 430 min |
These numbers do not establish that AI caused the longer queue. Reviewer availability, change size or an urgent incident could explain it. They tell the team where to ask better questions.
Change the flow, then check the result
1. Make “ready for review” meaningful
Purpose: Help a reviewer start with the evidence they need.
A pull request is a proposed code change submitted for review. Before marking it ready, the author should explain the intended behaviour, the scope, what was checked and what remains uncertain. Keep unrelated tidying separate where possible.
A smaller diff, the visible set of changed lines, can still contain a difficult decision. Ask the likely reviewer whether the change is understandable and whether specialist knowledge is required. Do not use line count as a substitute for that conversation.
2. Agree a response when the queue grows
Purpose: Avoid creating more review demand than the team can handle.
Make review-ready work visible on the existing board. Agree a small work-in-progress limit, meaning the amount allowed in that stage at once. Choose it with the people reviewing, based on availability and risk. There is no universal correct number.
When the agreed limit is reached, help move an existing change forward before starting another non-urgent one. That might mean clarifying evidence, pairing on a correction or finding an available specialist. Keep an explicit route for genuinely urgent work.
3. Protect quality while testing the change
Purpose: Learn whether delivery improves without quietly transferring the cost.
Try one adjustment for ten working days, such as smaller reviewable changes or a shared review window. Compare similar work with an agreed baseline. Record author effort, review effort, corrections, waiting and release outcome. Keep exceptions visible.
Use team-level observations, not individual rankings. Check whether interruptions or after-hours review increased. Keep existing release checks, and note defects or reopened work after release. A shorter queue alongside more failures is not an uncomplicated improvement.
A small experiment you can take to the team
Copy this into your next delivery discussion. Agree who records the evidence and when the team will decide whether to keep, change or stop the experiment.
If you are new to the team, start by tracing one completed change with its author and reviewer. Ask where it waited and what would have helped the next person start. An estimate labelled as an estimate is more useful than a precise-looking number nobody can explain.
The next useful question after “How quickly was the code written?” is “What happened before a user could benefit from it?” Put both answers in the discussion.
Sources checked 29 October 2026. The tables, arithmetic and experiment are original teaching material.
You May Also Like
How to create a product backlog: a practical guide for Agile teams
How to ask for learning time at work, with a practical one-page plan
