An engineer produces a patch in an afternoon. It waits several days for someone who understands the service to review it. A second patch arrives before the first has feedback. Faster drafting helped one step; the release is still waiting on the same person.
Measure work and waiting time
Use a recent, ordinary change as the starting point. Record when its requirements became clear, when implementation began, when review was requested, when feedback arrived and when the result reached users. The purpose is to locate delays, not to rank individual developers.
Now consider where an AI coding tool changes that path. It might shorten implementation, help explain unfamiliar code or prepare test cases. It can also generate more material for a limited review pool. Which effect matters depends on the constraint in this particular team.
Put productivity claims in context
DORA’s 2025 research frames AI as an amplifier of organizational strengths and weaknesses. Its practical implication is to examine the conditions around adoption, including the delivery system receiving the generated work. Tool usage alone is a weak description of that system.
For the illustrative team, adding review capacity or clarifying acceptance examples may matter as much as drafting speed. That is a hypothesis to test locally. It is not a claim that AI always increases queues or that every team should reorganize around the same metric.
Improve one step in the workflow
Choose a bounded experiment. For example, ask every proposed patch to include a small acceptance example, the expected behavior and a clear account of what changed. AI assistance may help prepare those materials, but the author remains responsible for checking them.
Observe whether reviewers can make decisions with fewer clarification rounds. Also inspect defects, abandoned patches and rework. A faster first review that produces a fragile release is a different outcome from faster useful feedback.
- How long does work wait for a decision?
- Which questions repeatedly send it back to the author?
- How large is the change the reviewer must understand?
- Does the deployed behavior satisfy the agreed example?
Focus on the main bottleneck
If implementation is the slow step, better assistance there may be valuable. If release coordination consumes the time, another code-generation feature will not remove that coordination by itself. If requirements keep changing, generating larger patches earlier can increase the amount discarded.
Follow a change end to end, make one improvement and observe what moves. That gives the team a reason for its next investment that is more useful than counting accepted suggestions.