Cursor's Data: Code Output 2x, But the Gains Went to the Top 1%

The flat-hierarchy story , that AI coding tools would compress the gap between strong and weak developers , was wrong. Cursor's Spring 2026 Developer Habits Report, drawn from 18 months of product telemetry, shows the opposite: output doubled on average, but the distribution tightened sharply at the top. The productivity gap inside engineering teams is wider now than it was in January 2025.

The headline numbers#

Average weekly code output per developer climbed from roughly 3,600 lines in January 2025 to 8,600 lines by May 2026 , a 2.4x increase. Lines added per pull request at the 75th percentile rose 2.5x over the same period. The share of PRs carrying at least 1,000 changed lines grew from 8% to 13.8%. AI agent tool calls per session increased roughly 30% over just the last two months of the measured period.

These are real gains. The retention metric makes that harder to dismiss: AI-generated code still present 60 minutes after generation rose from 76% to 81%, meaning more of what agents write is surviving review rather than being reverted.

Where the gains actually went#

Cursor's report measures concentration with Gini coefficients: 0.77 for AI-generated code, 0.75 for AI spending, 0.72 for token consumption. A coefficient of 1.0 means one person holds everything; 0.77 is closer to extreme inequality than to a bell curve.

The output numbers at the tail are striking. The top 1% of developers produce 46 times as many lines as the median active user and merge 15 times as many commits. The 90th percentile leads the median by a far smaller margin , which means the gains are not just concentrated at the top decile but at the very tip of the distribution.

The report's explanation matches common sense: developers who understand architecture, decompose tasks well, and can judge model output quality capture compounding returns. Developers who treat AI as a question-and-answer box see limited gains. The dividing line is judgment, not tool access. Every developer on a given team has the same Cursor subscription; the productivity spread still widens.

The review surface problem#

One number in the report deserves more attention than it has received. On January 1, 2026, 7% of agent-generated changes reached commits without a separate manual diff acceptance step. By May 16, 2026, that figure was 36.3% , more than a fivefold increase in four and a half months.

Pair that with the PR size data and the shape of the problem becomes concrete. A 1,000-line agent-authored change committed without manual diff review is not a PR review problem. By the time the PR exists, the architectural decisions are already made: which dependencies to import, which boundaries to cross, which patterns to follow. A reviewer auditing a 1,000-line diff is auditing decisions that were finalized inside an agent session.

Review is not dead. But review alone is no longer sufficient governance. The unit of risk scaled faster than the unit of review.

What this means for engineering managers#

Three practical implications follow from the data, none of which require accepting the most optimistic or pessimistic read on AI coding.

First, the productivity gap inside a 20-to-2,000-person engineering team is almost certainly widening. Tool access is not the constraint. Architecture skill , the ability to decompose a problem and evaluate the output , is what compounds. Identifying which developers have it, and structuring code ownership to match, matters more than it did 18 months ago.

Second, mega PRs are becoming normal. 13.8% of merged PRs now carry at least 1,000 changed lines. A review process designed for 150-line diffs does not scale to that surface area without structural changes to how review is staffed and tooled.

Third, the 36.3% auto-commit figure is not slowing down. As agents handle more of the commit flow, the assumption that a human saw every diff before merge stops holding. Teams that have not adapted their review and verification posture to this reality are accumulating decisions they did not consciously make.

The governance gap Hyrax fills#

The review problem the Cursor data describes , more surface area, less human inspection, faster commit velocity , is exactly what Hyrax is built to address. Hyrax reads the entire codebase across six agent domains (security, code quality, reliability, API and data, ops, UX), runs 13 verification steps on any proposed fix, and submits a PR. The human merges; Hyrax never auto-merges.

The point is not to replace the human reviewer but to match the review capability to the actual surface area. At 8,600 lines per developer per week, with 13.8% of PRs exceeding 1,000 lines and 36.3% of agent changes bypassing manual diff review, the math does not work with human review alone. The surface area is too large. Autonomous code governance , systematic, repeatable, scoped to verifiable fixes , is the matching capability.

Cursor's report covered in the dev.to governance analysis frames the conclusion plainly: AI is now software-delivery infrastructure. The question that follows is not whether the velocity is real. It is whether the governance infrastructure exists to keep architectural intent intact while that velocity scales. For most teams right now, it does not.

Hyrax is live at hyrax.dev.