Enterprise Software Development Speed Statistics (2026)

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Enterprise software development speed statistics are easy to find and hard to trust. Most roundups mix market-size figures with vendor claims and rarely say how fast real teams move code from idea to production. This page collects only speed-related data — delivery benchmarks, cycle times, controlled AI experiments, project overruns and time-allocation studies — and names the source and year of every figure.

The audience is technology leaders who need a defensible baseline: a CTO preparing a board update, a VP of engineering setting targets for next year, or a procurement team comparing vendors that promise “2x faster delivery”. If you are planning a large build and want to see how these benchmarks translate into a delivery plan, our enterprise software development services page shows how we structure teams, pipelines and milestones around them.

Read the numbers with one caveat in mind: speed metrics only mean something together with stability. A team that deploys ten times a day and breaks production every week is not fast; it is noisy. That is why every section below pairs throughput figures with quality figures, the same way the KPIs for software development should be paired in your own dashboard.

What are the key enterprise software development speed statistics in 2026?

The key enterprise software development speed statistics in 2026 cover four areas: how often teams deploy, how long a change takes to reach production, how much AI changes that, and how often big programmes overrun. These twelve figures are the ones we see quoted most often in planning discussions, and each is explained in detail further down.

1. 19% of teams were elite performers in DORA’s 2024 State of DevOps research, deploying on demand with lead times under one day; 25% were low performers shipping between monthly and once every six months.
2. Under 25 hours is the elite cycle time (first commit to production) in LinearB’s 2026 benchmarks, based on 8.1 million pull requests from 4,813 teams.
3. Under 1 hour pickup time and under 3 hours review time mark elite pull-request flow in the same dataset.
4. 90% of technology professionals used AI at work in DORA’s 2025 report, and more than 80% said it raised their productivity.
5. 55.8% faster task completion was measured for developers using GitHub Copilot in a 2023 controlled experiment.
6. About 21% faster completion was measured for 96 Google engineers using AI in a 2024 randomised trial.
7. 19% slower: experienced open-source developers took longer on real tasks with AI tools in METR’s 2025 study, while believing they were 20% faster.
8. 91% longer review times and 98% more merged pull requests were recorded on high-AI teams by Faros AI in 2025.
9. 10–15% productivity gain from AI coding assistants alone, rising to 25–30% with end-to-end process redesign, according to Bain’s 2025 Technology Report.
10. 16% of developer time goes to writing code, per Atlassian’s State of Developer Experience 2025; half of developers lose 10 or more hours a week to organisational friction.
11. 45% over budget and 7% over schedule is the average for large IT projects, with 56% less value delivered than predicted (McKinsey and University of Oxford).
12. 80% of large software engineering organisations were forecast by Gartner to have platform engineering teams by 2026, up from 45% in 2022.

How fast do enterprise teams ship? DORA delivery benchmarks

Enterprise teams ship at very different speeds: in DORA’s 2024 research, the fastest fifth deploy on demand with lead times under a day, while the slowest quarter needs one to six months for a change to reach production. DORA (DevOps Research and Assessment, now part of Google Cloud) has run this survey for more than a decade, which makes it the most widely used public benchmark for software delivery performance.

DORA measures speed with two metrics — deployment frequency and lead time for changes — and stability with two more: change failure rate and time to recover from a failed deployment. The 2024 performance clusters look like this:

Source: DORA, Accelerate State of DevOps Report 2024. Percentages are shares of survey respondents, not of companies.

Two details matter for enterprise readers. First, speed and stability move together: elite teams have both the shortest lead times and the lowest failure rates, which contradicts the common belief that going faster means breaking more. Second, the medium cluster has a lower change failure rate (10%) than the high cluster (20%). DORA’s explanation is that some teams buy stability by shipping less often, a trade-off that tends to break down as systems grow.

What changed in the DORA 2025 report?

The DORA 2025 report, published in September 2025 as the State of AI-assisted Software Development, replaced the four classic clusters with seven team archetypes based on nearly 5,000 survey responses and more than 100 hours of interviews. The biggest shift was AI: for the first time, AI adoption was positively linked to delivery throughput, although it was still negatively linked to delivery stability.

For enterprises, the “constrained by process” and “legacy bottleneck” archetypes together cover 28% of respondents. Those are the two places where speed is lost to the organisation and the architecture rather than to engineers’ skills, and both are typical of large companies with long-lived core systems.

What did DORA find about AI and delivery speed in 2024?

In 2024, DORA found that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, even though the same adoption raised individual productivity by 2.1%, job satisfaction by 2.6% and documentation quality by 7.5%. The interpretation was that AI makes it easy to produce larger batches of change, and large batches are what DORA has always linked to slower, riskier delivery. By 2025 throughput had turned positive, but the stability penalty remained.

What is a good cycle time? Engineering benchmark statistics

A good cycle time for an enterprise team is under one working week, and elite teams achieve under 25 hours from first commit to production, according to LinearB’s 2026 Software Engineering Benchmarks. The dataset covers 8,109,244 pull requests from 4,813 teams and 163,820 contributors in 42 countries, which makes it one of the largest public sources of pull-request-level speed data.

Cycle time breaks down into stages, and each stage has its own benchmark. Looking at the stages separately is the fastest way to find where an enterprise team is losing days:

Source: LinearB, 2026 Software Engineering Benchmarks Report (P75 thresholds for the elite tier).

The table explains why small changes matter so much. Pickup and review times are where pull requests wait, and waiting time grows with size: a 100-line change is reviewed in minutes, a 1,000-line change waits until someone has a free afternoon. Teams that cut cycle time usually do it by shrinking pull requests and protecting review time, not by asking engineers to type faster. Our guide to CI/CD in software development covers the pipeline side of the same problem: the deploy stage.

How does AI-generated code change pull-request speed?

AI-generated code makes pull requests larger and slower to merge, according to LinearB’s 2026 data. AI-assisted pull requests were 408 lines at the 75th percentile against 157 lines for unassisted ones, and only 32.7% of AI-generated pull requests were merged within 30 days, compared with 84.4% of manual ones. At the same time, 88.3% of organisations used AI tools daily or several times a week, and 44.7% did not formally measure their impact.

Jellyfish saw the more optimistic side of the same trend in its 2025 review: as AI adoption in a team rose from 0% to 100%, median cycle time fell from 16.7 to 12.7 hours (24% faster) and pull requests per engineer rose from 1.36 to 2.9. Adoption of AI code-review agents grew from 14.8% to 51.4% of companies between January and October 2025. The two datasets are compatible: teams that adopt AI fully and adapt their review process get faster, while teams that only add AI-generated code to an unchanged process create a review queue.

Are enterprises slower than startups at shipping software?

Enterprises are measurably slower than startups at shipping software, but the gap is smaller than many expect and comes from organisational overhead rather than engineering skill. LinearB data analysed by DevPro Journal (3.6 million pull requests) put elite enterprise cycle time at under 29 hours, against under 27 hours for scale-ups and under 21 hours for startups.

Source: DevPro Journal, “A Quantitative (and Actionable) Analysis of Enterprise Software Delivery Speed”, January 2024, based on LinearB data.

The same analysis found that enterprise teams share only about 70% of their working hours, because they are spread across time zones. That alone stretches pickup and review times. Add change-approval boards, security reviews, shared release trains and dependencies between dozens of services, and the extra eight hours of elite cycle time are easy to explain.

DORA points to two further enterprise-specific brakes. Unstable organisational priorities were linked to a 40% higher risk of burnout in 2024, and teams that were forced to use an internal platform saw throughput fall by 8% and change stability by 14%. In other words, the structures enterprises add to go faster can slow them down when they are imposed rather than adopted.

Does AI make software development faster? What the studies show

AI makes isolated coding tasks faster in controlled experiments, typically by 20 to 55%, but its effect on end-to-end enterprise delivery is smaller, and for experienced developers on complex codebases it can even be negative. The answer depends on what is being measured: a single well-defined task, a developer’s week, or a team’s path from idea to production.

Why do task-level gains not turn into faster delivery?

Task-level AI gains do not translate one-to-one into faster delivery because writing code is only a small part of the delivery cycle. Bain estimates that writing and testing code accounts for only 25 to 35% of the time from idea to launch; the rest is discovery, design, review, integration, approvals and release. A 50% faster coding step inside a 30% slice of the timeline saves about 15% at best, and only if the downstream steps keep up.

Faros AI describes this as the “AI productivity paradox”: individual output rises sharply, but the company-level metrics barely move because the extra code piles up in review and testing. Faros found no significant correlation between AI adoption and company-level delivery improvements in its 2025 dataset. Bain’s survey points the same way: three out of four companies said the hardest part of AI adoption was changing how people work, not deploying the tools.

Where does AI save the most time?

AI saves the most time on well-defined, low-complexity work such as documentation, boilerplate and test scaffolding, and the least on complex design and debugging in large, unfamiliar codebases. That pattern runs through every study above: the Copilot experiment used a small greenfield task, while METR used large mature repositories that the developers already knew well. For enterprise teams, this suggests targeting AI at documentation, migrations, test generation and repetitive integration code first. Our article on how teams actually build with AI goes into the workflows in detail.

AI adoption and trust statistics for software teams

AI is now part of almost every developer’s workflow, but trust in its output is low, which limits how much speed it delivers in practice. These adoption and trust figures explain why review and verification have become the new bottleneck:

• 84% of developers use or plan to use AI tools, up from 76% in 2024, and 51% of professional developers use them daily (Stack Overflow Developer Survey 2025).
• Only 3.1% of developers highly trust the accuracy of AI output, while 45.7% actively distrust it; favourable sentiment fell to 60% (Stack Overflow 2025).
• 66% say their biggest frustration is AI answers that are “almost right, but not quite”, and 45.2% say debugging AI-generated code takes more time (Stack Overflow 2025).
• 30% of respondents had little or no trust in AI-generated code in the DORA 2025 report, and the median user spent about 2 hours a day working with AI.
• 99% of developers say AI saves them time and 68% save more than 10 hours a week (Atlassian State of Developer Experience 2025).
• 90% of enterprise software engineers are forecast to use AI code assistants by 2028, up from less than 14% in early 2024 (Gartner).

The contrast between “99% save time” and “3.1% highly trust the output” is the core of the 2026 picture. Time saved while writing is partly spent again while checking, and the checking happens in code review, the stage that already limits cycle time.

How much time do enterprise developers actually spend coding?

Enterprise developers spend only 11 to 16% of their working time writing code, according to two of the most recent large studies, so the biggest speed gains usually come from removing friction around coding rather than from coding faster. Atlassian’s State of Developer Experience 2025, based on 3,500 developers and managers in six countries, put coding at 16% of developer time.

Source: Microsoft Research, “Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era”, ICSE SEIP 2025, survey of 484 Microsoft developers. Remaining time is spread across other activities.

Friction is the main reason the coding share is so low. In the Atlassian study, 50% of developers lost 10 or more hours a week to organisational inefficiencies and 90% lost at least 6 hours; the top causes were finding information, adapting to new technology and context switching. 63% said their leaders did not understand these pain points, up from 44% a year earlier.

Technical debt is the long-running version of the same problem. Stripe’s Developer Coefficient study found that of a 41.1-hour average week, developers spent 17.3 hours on maintenance, including 13.5 hours on technical debt, and 52% named legacy systems and technical debt as the main barrier to productivity. The figure dates from 2018, but it remains the most quoted measurement of how much capacity old code absorbs, and it matches the 11% of DORA 2025 respondents classed as a “legacy bottleneck”.

How often are enterprise software projects late or over budget?

Large enterprise software projects are late or over budget more often than not: a McKinsey and University of Oxford study of more than 5,400 IT projects worth over $15 million found an average 45% budget overrun, a 7% schedule overrun and 56% less value than predicted. About 17% of those projects went so badly that they threatened the existence of the company.

• 45% average budget overrun, 7% schedule overrun and 56% less value than planned for large IT projects (McKinsey and University of Oxford).
• Every additional year of project duration added roughly 15% to the cost overrun in the same study, so long projects are disproportionately risky.
• 31% of software projects were successful, 50% challenged and 19% failed in the Standish Group CHAOS 2020 data; success was 16.2% in 1994 and 37% in 2012.
• Small projects succeed about 90% of the time in CHAOS data, while very large ones succeed less than 10% of the time.
• 73.8% of projects met their business goals on average in PMI’s Pulse of the Profession 2024.
• Projects led by professionals with high business acumen met goals 83% of the time, stayed on schedule 63% and on budget 73% of the time in PMI’s 2025 survey of nearly 3,000 respondents.

The common thread is size. Overruns grow with duration and scope, and the best-performing projects are the ones broken into small, independently valuable releases. That is the same lesson the DORA and LinearB data teach at the level of a single change. Note also that the 7% schedule figure understates the delay users feel: projects often hit their dates by cutting scope, which is why the value shortfall (56%) is so much larger than the time overrun. For practical ways to size a project before it starts, see our software project estimation guide.

Platform engineering, low-code and other speed levers: statistics

Platform engineering is the speed lever enterprises have adopted most widely, with Gartner forecasting that 80% of large software engineering organisations will have platform teams by 2026, up from 45% in 2022. DORA’s data shows the payoff is real but conditional on how the platform is introduced.

The pattern is consistent: tools speed delivery when they remove waiting and manual steps, and slow it down when they add mandatory process. A golden-path platform that makes the right way the easy way helps; a platform that every team must use regardless of fit hurts. The same applies to cloud automation, which is why we treat cloud and DevOps engineering as part of delivery speed rather than as separate infrastructure work.

How do you benchmark your own enterprise delivery speed?

You benchmark enterprise delivery speed by measuring the four DORA metrics and the stages of cycle time on your own data for at least one quarter, then comparing the medians with the public benchmarks above. Industry averages are only useful once you know your own baseline. A practical sequence looks like this:

1. Pick a scope. Start with three to five teams that own deployable services, not the whole organisation; mixed portfolios hide bottlenecks.
2. Collect the four DORA metrics. Pull deployment frequency and lead time from your CI/CD system, and change failure rate and recovery time from incident records.
3. Split cycle time into stages. Measure coding, pickup, review and deploy time separately from your version-control data; the slowest stage is your first target.
4. Track pull-request size. Median and 75th-percentile lines changed per pull request predict review delays better than any other single number.
5. Add an AI lens. Tag AI-assisted pull requests and compare their size, review time and merge rate with unassisted ones, as LinearB does.
6. Survey friction. Ask developers how many hours a week they lose to waiting, searching and context switching; Atlassian’s figures give you a comparison point.
7. Review quarterly and change one thing at a time. Treat each improvement as an experiment, and watch stability metrics as closely as speed metrics.

Avoid turning these numbers into individual performance targets. DORA and the SPACE framework both warn that delivery metrics describe systems, not people; once engineers are judged on pull-request counts, the counts go up and the delivery speed does not. Our DevOps in software development guide covers the practices that move these metrics in a sustainable way.

What do these statistics mean for enterprise software buyers in 2026?

For companies buying or commissioning enterprise software in 2026, the statistics point to one conclusion: delivery speed is decided by batch size, review flow and organisational friction far more than by headcount or tooling. When you evaluate an in-house plan or an external partner, these are the questions the data says you should ask:

• What is the planned release cadence? A plan with one big release at the end carries the 45% overrun risk of large projects; monthly or more frequent releases cut it.
• How will lead time and change failure rate be reported? A vendor that cannot show DORA metrics for its current projects is asking you to trust a promise.
• How is AI-generated code reviewed? Larger AI-assisted pull requests and longer reviews are well documented; a credible team has a policy for both.
• How much of the timeline is waiting? Approvals, environments and access requests often consume more calendar time than development.
• How is work split into releases? CHAOS data shows small projects succeed about nine times as often as very large ones, so ask how the scope will be cut into independently valuable increments.
• What does the team measure before the first release? A baseline taken in the first sprint makes later claims about speed verifiable, and it exposes slow environments and approval steps early.
• How is legacy integration handled? Legacy bottlenecks affect about one in nine teams in DORA 2025, and integration is where enterprise schedules most often slip.

These criteria apply whether the work is a new platform, a modernisation programme or an integration-heavy build. They also explain why the custom software development market keeps shifting towards partners who can show delivery data instead of only hourly rates, and why the software development trends for 2026 are dominated by platform engineering and AI governance rather than new languages.

FAQ

Published 25 October 2026. Sources: DORA, Accelerate State of DevOps Report 2024; DORA, State of AI-assisted Software Development 2025; LinearB, 2026 Software Engineering Benchmarks; DevPro Journal, enterprise delivery speed analysis (2024); Faros AI, The AI Productivity Paradox (2025); Jellyfish, 2025 AI metrics in review; Peng et al., The Impact of AI on Developer Productivity (2023); Google, How much does AI impact development speed? (2024); METR (2025) and METR update (2026); Stack Overflow Developer Survey 2025; Bain Technology Report 2025; Atlassian State of Developer Experience 2025; Microsoft, Time Warp (2025); Stripe, The Developer Coefficient (2018); McKinsey and University of Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012); Standish Group CHAOS 2020; PMI Pulse of the Profession 2024 and 2025; Gartner forecasts on AI code assistants, platform engineering and low-code. Forecasts are predictions, not measurements.