Summary
- The 2026 benchmarks draw on 8,109,244 pull requests from 4,813 teams and 163,820 active contributors across 42 countries, aggregated at the 75th percentile.
- Elite cycle time is under 25 hours, elite pull request size is under 100 lines, and elite change failure rate is under 1%.
- Manual pull requests merge within 30 days at 84.4% versus 32.7% for AI pull requests, which also run 2.6x larger at the 75th percentile.
- 88.3% of surveyed organizations use AI-assisted tools daily or a few times a week, while 44.7% do not formally measure AI's impact.
Engineering benchmarks and research
Engineering benchmarks show where a team's delivery numbers sit relative to a community of comparable teams, which turns a metric into a decision. LinearB's 2026 Software Engineering Benchmarks Report is the fifth annual edition, built from 8,109,244 pull requests across 4,813 development teams and 163,820 active contributors in 42 countries, with all data anonymized and normalized. This page carries the headline bands for delivery, predictability, project management, and AI contribution, along with the methodology needed to cite them correctly.
Methodology matters as much as the numbers, because a band quoted at the wrong percentile or against the wrong organization size invites the wrong conclusion. For the tier-by-tier discussion of what separates top performers, see engineering metrics benchmarks.
An engineering benchmark is a published band showing where a metric value sits relative to a community of teams, expressed in tiers. A benchmark answers whether a number is good, which a metric alone cannot do.
Methodology, and how to cite these figures
The 2026 data set covers 8,109,244 pull requests from 4,813 development teams and 163,820 active contributors across 42 countries, with a qualitative layer added this year from the 2026 AI in Engineering Leadership Survey of engineering executives, platform leaders, and DevEx professionals. Aggregation uses the 75th percentile, chosen because it is less sensitive to outliers and therefore more reliable than an average.
Four rules keep a citation accurate. Default to the 75th percentile and label any average as an average. Reproduce band strings exactly, since time metrics mix minutes and hours within a row. Treat rate and ratio metrics as single-band, because merge frequency, deploy frequency, PR maturity, change failure rate, refactor rate, rework rate, capacity accuracy, planning accuracy, and the four project management metrics publish one band across every percentile. And keep the three AI contribution types separate, since their profiles differ.
| Tier | Definition |
|---|---|
| Elite | Top 10% of the LinearB community |
| Good | Top 30% of the LinearB community |
| Fair | Top 60% of the LinearB community |
| Needs improvement | Bottom 40% of the LinearB community |
Organization size bands split the delivery and predictability metrics three ways: enterprise at 1,000 or more employees, scale-up at 200 to 1,000, and start-up at 0 to 200. The four project management metrics publish at organization level only. Comparing an enterprise team against the aggregate understates its performance, since elite enterprise cycle time is under 27 hours against under 25 hours for the full data set.
What to do next: Write the percentile and the size band next to every benchmark figure you circulate internally. An unlabeled number gets compared against the wrong tier.
Delivery benchmarks, 75th percentile
Delivery metrics measure how work moves from commit to release. Time values are in hours unless minutes are shown.
| Metric | Elite | Good | Fair | Needs improvement |
|---|---|---|---|---|
| Coding Time (hours) | < 54 mins | 54 mins - 4 hours | 5 - 23 | > 23 |
| Pickup Time (hours) | < 1 | 1 - 4 | 5 - 16 | > 16 |
| Approve Time (hours) | < 10 | 10 - 22 | 23 - 42 | > 42 |
| Merge Time (hours) | < 1 | 1 - 3 | 4 - 16 | > 16 |
| Review Time (hours) | < 3 | 3 - 14 | 15 - 24 | > 24 |
| Deploy Time (hours) | < 16 | 16 - 106 | 107 - 277 | > 277 |
| Cycle Time (hours) | < 25 | 25 - 72 | 73 - 161 | > 161 |
| Merge Frequency (per dev/week) | > 2.0 | 2 - 1.2 | 1.2 - 0.66 | < 0.66 |
| Deploy Frequency (per service) | > 1.2 | 1.2 - 0.5 | 0.5 - 0.2 | < 0.2 |
| PR Size (lines) | < 100 | 100 - 155 | 156 - 228 | > 228 |
| PR Maturity (%) | > 89% | 89 - 83% | 82 - 77% | < 77% |
Deploy time carries the widest spread in the table, running from under 16 hours at elite to beyond 277 hours in the lowest tier, which makes it the phase where automation returns the largest gain. Cycle time is the sum of the phases above it, so it should be read as a result rather than as a target. For the phase-level diagnosis, see cycle time.
What to do next: Place each of your delivery phases in a band and rank the gaps. The largest gap is the constraint, and the total tells you nothing about which one it is.
Predictability and project management benchmarks
Predictability metrics measure whether commitments hold, and project management metrics measure whether work is traceable enough to attribute. Every band below applies across all percentiles, since these are rate and ratio metrics.
| Metric | Elite | Good | Fair | Needs improvement |
|---|---|---|---|---|
| Change Failure Rate (%) | < 1% | 1 - 4% | 5 - 17% | > 17% |
| Refactor Rate (%) | < 11% | 11 - 16% | 17 - 22% | > 22% |
| Rework Rate (%) | < 3% | 3 - 5% | 6 - 8% | > 8% |
| Capacity Accuracy (%) | 85 - 115% | 75 - 85% or 115 - 125% | 70 - 75% or 125 - 130% | < 70% or > 130% |
| Planning Accuracy (%) | > 82% | 82% - 64% | 63% - 47% | < 47% |
| Issues Linked to Parents (%) | > 90% | 90 - 67% | 66 - 56% | < 56% |
| Branches Linked to Issues (%) | > 77% | 77 - 62% | 61 - 41% | < 41% |
| In Progress Issues with Estimation (%) | > 55% | 55 - 26% | 25 - 14% | < 14% |
| In Progress Issues with Assignees (%) | > 96% | 96 - 84% | 83 - 76% | < 76% |
The iteration planning distribution adds context to the two accuracy metrics: 73.1% of teams under-commit their plans, 14.7% land in the range where commitments align with delivery, and 12.2% sit in the potential over- or under-commit zones. Under-committing reads as reliable delivery on a single-metric report, which is why the two accuracy metrics need to be read together.
What to do next: Check branches linked to issues before you set any delivery target. Below 62%, the attribution underneath every other metric on this page is unreliable.
AI contribution benchmarks
The 2026 edition added AI insights covering three distinct pull request types, and their profiles differ enough that merging them produces a figure describing none of them. Every relationship here is correlational and aligns with LinearB's qualitative research over the past year.
| Pull request type | Median size (lines) | P75 size (lines) | Pickup Time P75 (hours) | Refactor Rate P75 |
|---|---|---|---|---|
| Agentic AI | 89 | 293 | 17.6 | 0.17 |
| AI-Assisted | 96 | 408 | 8.3 | 0.22 |
| Unassisted | 26 | 157 | 3.4 | 0.37 |
Acceptance rate is the new headline benchmark, measuring the share of pull requests merged within 30 days. Manual pull requests merge at 84.4% against 32.7% for AI pull requests, and the elite threshold differs by type, sitting above 95% for manual work and just above 71% for AI work. Exceeding 60% acceptance for AI pull requests is difficult across the data set. Review time inverts the pickup order, with AI-assisted pull requests clearing in 3.2 hours against 4.2 hours for unassisted work, so the largest changes receive the least review time. For the analysis, see how to measure generative AI code.
What to do next: Segment your own acceptance rate by contribution type before setting a target. One threshold across both types either flatters manual work or penalizes AI work.
Survey findings on AI adoption and readiness
The qualitative layer covers adoption, confidence, measurement practice, and readiness. Adoption reached 88.3% of surveyed organizations using AI-assisted tools daily or a few times a week, against a 71.6% baseline in early 2024, with 64.9% using them every day and 23.4% a few times a week. Confidence in AI-generated code quality runs lower, with 39.4% somewhat confident, 33% neither confident nor unconfident, 19.1% somewhat unconfident, and 6.4% extremely confident.
Measurement practice is the gap with the clearest business consequence: 76.1% of engineering leaders report measurable productivity improvements while 44.7% do not formally measure AI's impact at all. Of those who do measure, 27.7% combine quantitative and qualitative methods, 13.8% use qualitative methods only, and 13.8% use quantitative methods only. Readiness shows practice maturity ahead of infrastructure, with 72.6% reporting maturity in user-focused development, 67.4% in iterative delivery habits, and 56.2% in version control maturity, while 64.5% indicate their internal data is not ready for AI workflows and 15.6% strongly disagree that their data is high-quality and accessible.
What to do next: Compare your own measurement practice against the 44.7% figure. If AI impact has no owner and no metric, your reported gains rest on the same anecdotal basis the market relies on.
How to use a benchmark in four steps
A band is only useful once it produces a target, and APEX supplies the structure for turning one into the other with a single north star per pillar. The full model is in the APEX framework.
- Pick the percentile and stay with it. The 75th percentile is the default here, and mixing percentiles inside one comparison invalidates it.
- Match the organization size band, since enterprise, scale-up, and start-up bands differ on every delivery and predictability metric.
- Compare at phase level rather than on totals, because a cycle time gap cannot tell you which handoff to change.
- Set one target per quarter, choosing the phase with the largest gap, and re-measure after a full sprint before adding a second.
External research is worth reading alongside these bands rather than instead of them. The 2025 DORA State of AI-assisted Software Development report covers the organizational conditions that decide whether AI helps, and the SPACE paper in Communications of the ACM remains the reference for keeping measurement multi-dimensional.
What to do next: Choose your one target for the quarter today, from the phase with the largest band gap, and write down the number you expect to reach.
Frequently asked questions
What data are the 2026 engineering benchmarks based on?
The 2026 Software Engineering Benchmarks Report draws on 8,109,244 pull requests from 4,813 development teams and 163,820 active contributors across 42 countries, with all data anonymized and normalized. It is the fifth annual edition and adds a qualitative layer from the 2026 AI in Engineering Leadership Survey.
What is a good cycle time?
Elite cycle time is under 25 hours and good is 25 to 72 hours at the 75th percentile. Enterprise organizations above 1,000 employees reach elite under 27 hours, so compare against your size band rather than the aggregate.
Why do these benchmarks use the 75th percentile?
The 75th percentile is less sensitive to extreme values and outliers than an average, which makes it a more reliable basis for comparing performance across organizations. Only time metrics and pull request size change with percentile, since rate and ratio metrics publish a single band.
How do AI pull requests compare with manual ones?
AI-assisted pull requests reach 408 lines at the 75th percentile against 157 for unassisted work, agentic pull requests wait 17.6 hours before pickup against 3.4 hours, and AI pull requests merge within 30 days 32.7% of the time against 84.4%. The three contribution types should be kept separate, since their profiles differ.
Can I cite these benchmarks in my own reporting?
Yes. Attribute to LinearB's 2026 Software Engineering Benchmarks Report, state the percentile, name the organization size band if you use one, and reproduce band strings as published. Frame every AI finding as correlation rather than causation.
Get the full report
The bands on this page are the headline set. The 2026 Software Engineering Benchmarks Report carries the complete tables by percentile and organization size, the appendix percentiles, and the full AI insights section, and engineering metrics in LinearB puts the same bands next to your own pipeline.