Management
AI Productivity Gains: Set Realistic Software Deadlines
Cutting a two-day coding stage to one day does not halve an eight-day release plan. AI productivity gains have to be traced through the remaining work before they become a promise to a customer.
Find the part of the schedule that changed
Consider a hypothetical feature that previously required two days of implementation within an eight-day delivery path. AI reduces implementation to one day, while the dependent review, validation, and release work remains unchanged.
The simple illustration yields seven days, not four. It is not a general formula: some work overlaps, some bottlenecks shift, and AI may help other stages too. Its purpose is to expose the mistaken assumption that a 50% reduction in one stage halves the whole schedule.
Ask which stage currently constrains delivery. If the team is waiting for a product decision, generating another implementation is unlikely to remove that wait.
Interpret AI productivity gains at the right level
These claims answer different questions:
| Claim | What it may show | What it does not establish |
|---|---|---|
| A draft took less time | Faster initial implementation | Correctness or release readiness |
| More PRs were opened | Higher activity | More accepted customer value |
| Changes reached production sooner | Improved delivery flow | Stable operation or lasting benefit |
| A user outcome improved | Product value | Which part of the workflow caused it |
A manager needs the distinction when leadership asks whether a reported coding gain can fund a tighter roadmap.
DORA's 2025 research summary reports positive associations between AI adoption and throughput, alongside a negative association with delivery stability. These are population-level associations, not a prediction that AI will help or harm a particular release.
Should AI make every software deadline shorter?
No. Change the forecast when evidence shows that the relevant delivery path has improved. Some tasks benefit more than others, and downstream constraints may limit the effect.
Include verification and rework
Record the time spent understanding and correcting the result. A task that produces a draft in twenty minutes but needs several hours of investigation may still be valuable, but its gain differs from the initial speed claim.
Compare accepted work of similar difficulty. Track the tool and workflow used, because a result from one model, task type, or repository may not transfer to another.
My guide to reviewing AI-generated PHP code gives concrete technical checks. At the management level, make sure someone has capacity and responsibility to perform them.
Report gains with their conditions
A useful hypothetical update could read:
AI reduced drafting effort on the validation changes we sampled. Review effort was similar, and the release queue remains the main constraint. We will use the saved capacity for additional test coverage while gathering more delivery data. We are not yet changing the promised launch date.
If the evidence later supports a shorter forecast, update it. Avoid keeping a benefit invisible simply because the first result was uncertain.
Aligning roadmaps with team capacity still applies. AI changes the capacity conversation; it does not remove the need to make priorities and dependencies explicit.
How should a manager respond to a demand for twice the output?
Clarify which outcome is expected, identify the measured improvement, and show the remaining constraints. Offer a bounded evaluation and explicit tradeoffs rather than accepting an unsupported multiplier.
Avoid treating old experiments as permanent rules
AI tools and workflows change quickly. METR's February 2026 experiment update explains why its follow-up data could not reliably estimate the current productivity effect, including participant and task-selection issues.
The useful conclusion is not a universal multiplier in either direction. It is that measurement design, task selection, and the surrounding workflow affect what a result means.
A manager can acknowledge benefits without promising that every developer, repository, and feature will realize the same improvement.
Run a bounded local evaluation
Choose one repeatable class of work, such as adding validation with existing test patterns. Record a baseline from comparable work and evaluate a limited period with the proposed AI workflow.
Observe accepted outcomes, implementation effort, review effort, rework, and any operational problems. Note differences in task difficulty and staffing. With a small sample, describe the result as directional rather than statistically conclusive.
Do not reward tool use during the evaluation. The objective is to learn whether the workflow helps, including where the developer reasonably chooses not to use it.
Can self-reported time savings be useful?
Yes, as one signal. Pair them with accepted work, review effort, and delivery outcomes. Self-report alone cannot establish the counterfactual time or business value with confidence.
Decide how to use the gain
The business can choose shorter lead time, more useful scope, stronger quality, or capacity for neglected maintenance. Discuss that choice rather than automatically filling every saved hour with another commitment.
Verify the outcome after release. A faster project that creates recurring support work may transfer cost rather than eliminate it.
If you need to translate AI experimentation into a credible delivery plan, my AI and technical leadership consulting can help connect the evidence with the roadmap.