Your developers started using AI coding tools this year. They're writing more code than ever. Pull requests are flying. And yet the release date still slipped, and the last launch came with a week of bug fixes.
You're not imagining it. The 2025 DORA State of AI-assisted Software Development report found that AI adoption now goes hand in hand with higher delivery throughput, but also with more instability: more failed changes, more rework, longer time to fix issues.
Faster isn't the same as predictable. Predictable software delivery means you can say roughly when something will ship, and be right most of the time. Below, we unpack what the DORA research found, where work actually waits between backlog and release, and the practices that make delivery dates trustworthy again.
What the 2025 DORA report actually found
DORA, the long-running research program now hosted by Google Cloud, studies what separates high-performing software teams from the rest. Its 2025 edition focused on AI.
The headline finding is that AI acts as an amplifier. As InfoQ's coverage of the report puts it, AI magnifies a team's existing strengths and its existing weaknesses. A few numbers stand out:
- 90% of organisations now use AI in software development, up 14% from the year before.
- AI adoption now correlates positively with throughput, a reversal from 2024.
- AI adoption still correlates with higher delivery instability.
- Only 3% of developers report high trust in AI-generated output.
Does AI make software delivery faster?
It tends to increase throughput, meaning more changes get delivered. But DORA's research also links AI adoption to more instability, such as failed changes and rework. So AI can make teams faster without making them more predictable, unless the rest of the delivery process keeps up.
Why faster isn't the same as predictable
Predictability isn't about average speed. It's about how much delivery times vary. A team that always takes 4 to 6 days per item is more predictable than one that takes anywhere from 1 day to 3 weeks, even if the second team is faster on average.
Most unpredictability comes from work waiting, not work being done. Items sit in a queue for review, wait on a dependency, or bounce back for rework. Easy Agile's 2026 research found dependency delays alone cause 35.6% of sprint rollover.
AI shifts where the waiting happens. DX's analysis of the DORA findings, in their engineering enablement newsletter, points out that code review becomes the dominant bottleneck when AI speeds up coding. More code arrives, but review capacity stays the same.
Here's where work typically waits on its way from backlog to release.
Five practices that make delivery predictable
None of these are new. DORA's research has backed them for years. What's changed is that AI makes skipping them more costly.
1. Work in small batches
Break features into pieces that can be built, reviewed and shipped in a few days. DORA's 2025 report specifically highlights small batches as especially valuable for AI-assisted teams. Smaller changes are easier to review, easier to test and easier to roll back.
2. Limit work in progress
Starting more work doesn't finish more work. It spreads attention thin and leaves half-done items everywhere. Set a cap on how many items can be in progress at once, and finish before starting.
What are WIP limits and why do they help?
A WIP (work in progress) limit caps how many items a team or stage can work on at the same time. When the limit is reached, people help finish existing work before pulling in new work. It reduces context switching, shortens cycle time, and makes delivery times more consistent.
3. Treat code review as real work
If AI doubles the code coming in, review capacity has to keep up. Set a target, such as reviewing every pull request within one working day, keep changes small, and make reviewing a shared responsibility rather than one senior developer's job.
4. Automate testing and release
Manual testing at the end of a sprint is where predictability goes to die. Automated tests that run on every change catch problems early, when they're cheap to fix. Automated deployment makes releasing small changes routine instead of risky.
5. Track cycle time and rework
You can't make delivery predictable without measuring it. Two numbers matter most: how long items take from start to done, and how much work comes back as bugs or fixes after release.
What is cycle time in software development?
Cycle time is how long a work item takes from when work starts to when it's done, usually meaning released or ready to release. Tracking it over time shows how predictable your process is. A narrow, stable range of cycle times means reliable delivery.
Forecast with ranges, not promises
Ask a developer "when will this be done?" and you'll get a guess. Ask your delivery history and you'll get a forecast.
If you know how many items your team typically finishes per week, you can forecast a release as a range. Here's a simple illustration for a release with 30 items left.
Sharing "4 to 5 weeks" is more honest than "4 weeks," and far more likely to hold. Update the forecast every week as new data comes in. If scope grows, the range moves, and everyone can see why.
How do you forecast when a feature will be delivered?
Use your team's actual history. Count how many items they finished per week over the last 8 to 12 weeks, count the items left, and calculate a range from slower and faster weeks. Share the range, update it weekly, and make sure items are broken down to a similar small size.
Using AI without losing stability
AI tools aren't the problem. Using them without the right guardrails is. DORA's research points to the same foundations every time: clear expectations about how AI should be used, small batches, strong review, and good automated testing.
The trust numbers matter too. With only 3% of developers reporting high trust in AI-generated output, review isn't optional. AI-written code still needs the same checks as any other code, and probably more attention on edge cases.
How to build a more predictable development process
Here's the order we recommend.
- Measure where you are. Pull cycle time and weekly throughput for the last 8 to 12 weeks.
- Break work smaller. Aim for items that can be finished in a few days.
- Set WIP limits. Start with a limit close to the number of developers, then adjust.
- Set a review target. For example, every pull request reviewed within one working day.
- Automate tests and releases. Start with the riskiest areas of your product.
- Forecast in ranges and review weekly. Share ranges, not single dates, and update them as data comes in.
These practices work alongside good sprint habits. Our posts on sprint planning mistakes and handling sprint carryover cover what happens inside each sprint.
What this looks like in practice
Take a typical case. An eight-developer SaaS team in Bengaluru. They adopted AI coding tools early in the year and code output jumped. But releases kept slipping, and every release brought a wave of hotfixes. Two senior developers were spending most of their time reviewing large pull requests.
They make four changes. Features get broken into smaller items. A WIP limit of eight stops people from juggling several tasks each. Every pull request gets a one-day review target, shared across the team. And release dates are shared as ranges based on the last ten weeks of throughput.
The team doesn't write more code. But cycle times tighten, review queues shrink, and the founder starts getting release ranges that actually hold.
If you work with an outside development partner, including ours, ask for the same things: cycle time, throughput, rework and forecasts in ranges. At Nipralo, we build custom software, web and mobile apps for growing businesses, and we think clients should expect that level of visibility from any team they hire.
The bottom line on predictable software delivery
AI is making development teams faster. DORA's 2025 research shows it isn't automatically making them more predictable, and can add instability if the process around it doesn't keep up.
Predictable software delivery comes from the basics: small batches, WIP limits, fast reviews, automated testing, and forecasts built on real history. Get those right, and AI's speed turns into release dates you can trust.
Want release dates you can actually plan around? Book a free 20-min call and we'll look at how work flows through your development process and where it's getting stuck.
