60% of product PRscontain fixes.

Repairs consumed over half the estimated effort.

Security flawshide for months.

The PHP2Shell flaw remained in the code for 21 months.

Monthly product pull requests across four open-source projects, February-September 2026. Repairs account for 7,293 of 12,038 eligible pull requests (60.6%). The remaining eligible pull requests include unresolved repair classifications.

Share of 2,508 repair-containing pull requests in August-September 2026. Behavior and logic 842 (33.6%), integration and compatibility 355 (14.2%), reliability and error handling 326 (13.0%), API / schema contracts 214 (8.5%), performance and resources 224 (8.9%), security and privacy 101 (4.0%), remaining categories 446 (17.8%). The first four categories account for 69.3%.

Repair Pull Requests by category

Different bugs. The same repair burden.

Most repairs involve behavior, integrations, error handling or API contracts. Finding these bugs means checking how the system works together, not just reviewing individual changes.

Regressions can occur in any category.

The effort behind the fixes

56% of estimated engineering effort goes to repairs.

Estimated in story points. Repair work took more estimated effort than feature work. Engineers are not just finding bugs. They are investigating, fixing, testing and reviewing them.

Across four open-source projects in August-September 2026, repairs account for 7,408.5 of 13,215 estimated story points (56.1%). August: 3,462.5 of 5,654 (61.2%). September: 3,946 of 7,561 (52.2%). Relative model estimates, not measured hours.

Find. Fix. Know.

Early finds bugs, creates Fix PRs with tests for eligible findings after authorized initiation, and shows what was verified. Your team reviews and controls the merge. Spend less engineering effort driving bug fixes and more on building value.

[See Release Guard]

What Early adds after code review

The Engineering Cost of Software Repair

See where engineering effort goes across four open-source projects.

First page of Early's software repair research white paper.

Loading form...

The bigger picture

Beyond Code Review: What Makes a Release Ready?

Over 50% of estimated implementation effort went to repairs. What does that mean for release confidence?

Engineering Got Faster. How Does QA Keep Up?

More changes arrive. The release date stays. QA needs more than a bug count to decide what deserves attention and whether the release is ready.

The Code Is Ready. The Team Is Still Figuring It Out.

Coding agents can finish the implementation before the team has answered the questions that determine whether it is ready to release.

Put more engineering capacity into building value.

Evaluate findings, accepted fixes, and review effort in your team's workflow.

[Explore a pilot]