Let’s talk about productivity and velocity. AI is already the biggest change to how we work. We can write code and implement features at speeds that would have been unthinkable before. But those changes still then need to be reviewed, tested, and accepted. Without the people and attention it needs, that work simply shifts the queue from writing code to reviewing and accepting it.
Implementation is only part of getting a feature into someone’s hands.
Even for a small team, our overall process is similar to many other software development practices. Design checks whether the implementation delivers the intended UI and UX, while business acceptance establishes whether it meets the need and applicable requirements. Each brings a different perspective, and each takes time and attention. Faster implementation improves delivery only as far as the rest of that work can support it.
Consider a team that previously produced three changes a week and could properly review three. If it starts producing six while review capacity stays at three, unfinished work accumulates. AI can add to that pressure where the code may be verbose, or substantial tests have been included that also need scrutiny. We can end up with more changes to review and more code in each change. Where does that work wait after the engineer considers it ready?
Waiting work also needs attention.
By the time feedback arrives, the engineer may have moved on to another issue. A reviewer may need an explanation of a decision made days earlier. Related changes can develop while the first one remains open. Keeping more work in progress creates coordination work of its own, even when each implementation was quick to produce.
All of this should be considered when deciding what faster engineering means. The point at which an agent finishes its task is useful to observe, but so is the time until someone can use the accepted result. Looking at the whole journey helps us distinguish time spent building, time spent examining the work, time spent revising it, and time spent waiting for someone to make a decision.
We can start another feature, or we can help existing work reach acceptance.
The response should depend on what is holding the work up. If reviewers spend their time reconstructing the requirement, clearer product context may help. If changes arrive with basic problems still unresolved, more preparation before review may help. If business acceptance is waiting on a person who was never told when they would be needed, the team has a coordination problem. Asking everyone to review faster would leave those causes intact.
AI can contribute to this supporting work as well. In our workflow, agents help with testing and explain what they changed, and why, before engineers inspect the draft pull request. That can give the engineer more material to work from. We still have to assess whether the tests establish anything useful and whether the explanation matches the actual changes. Generating more review material is valuable only when it helps someone reach a sound decision.
We should make that choice deliberately. Some of the capacity AI gives us should go towards helping existing work reach acceptance: investigating a review finding, clarifying expected behaviour, or preparing a better way to demonstrate the result. That is productive work, and we should treat it that way instead of measuring productivity by how quickly we start the next feature.
Faster implementation is a worthwhile improvement. To turn it into faster delivery, we need to give the work that follows the attention it requires. When an AI-assisted change is ready, what still has to happen before the user benefits?