The velocity curve is now measured, not anecdotal. For two years the claim that AI coding is accelerating rested mostly on vibes and vendor decks. Cursor’s data turns it into telemetry. And read as an operations document rather than a marketing one, that telemetry describes a structural shift: software delivery is getting harder to govern, not just faster to produce.
This is not a critique of Cursor. The report is strong validation. Cursor proves the velocity curve with numbers most of the industry only gestured at. The point of this essay is what sits on the other side of that curve.
What the Cursor Developer Habits Report Shows
The inaugural Cursor Developer Habits Report (Spring 2026 edition), published by Cursor (Anysphere, Inc.), draws on Cursor usage data rather than survey responses. It captures the transformation across five themes — developer acceleration, the economics of intelligence, the power user gap, the rise of context, and the shift to automation. The headline figures:
- 3.6K → 8.6K lines added per developer per week — the per-developer code volume rose from 3.6K (Jan 2025) to 8.6K (May 2026), with growth accelerating since the start of 2026.
- 125.86 → 345.02 lines per PR at p75 — lines added per pull request at the 75th percentile rose roughly 2.5x year over year (Jan 2025 to May 2026). Developers are taking on larger units of work in a single PR.
- 8% → 13.8% mega PRs — the share of PRs with at least 1,000 changed lines grew from 8% (Jan 2025) to 13.8% (May 2026).
- ~30% more tool calls per session in two months — coding agents are reading and editing files, searching code, running shell commands, and browsing the web more frequently as they take on more complex work.
- 7% → 36.3% changes committed without manual diff acceptance — since the start of 2026, more than 5x as many agent-generated changes are reaching commits without a separate manual diff acceptance step (7% on Jan 1, 2026; 36.3% on May 16, 2026).
- ~76% → ~81% AI-generated code survival — the share of AI-generated code that persists rose, so more agent-authored code is both landing and staying.
- 46x and 15x at the tail — p99 developers produce 46x more lines than the median active user and merge 15x more PRs than the median active PR author.
Agent changes reaching commits without a manual diff acceptance step
Pair two of those numbers and the framing changes. More agent-authored code is reaching commits with less manual diff review (7% to 36.3%), and a higher share of it survives in the codebase (~76% to ~81%). More unreviewed AI code is both landing and persisting. That is not just a productivity story. It is a story about where architectural decisions are now being made — increasingly inside an agent session, not inside a review thread.
Cursor states the destination plainly: AI software development is entering a new era, with AI becoming infrastructure for automating more of the software development lifecycle end to end. When something becomes infrastructure, the relevant question stops being “is it fast” and becomes “how is it governed.”
Velocity changed the unit of risk
When AI was autocomplete, governance could reasonably live in review. A human wrote most of the change, accepted small suggestions inline, and a reviewer read a human-sized diff before merge. The unit of risk was a line or a function, and review was a sufficient first governance surface.
The report describes a different unit of risk. PRs at p75 carry 2.5x the lines they did a year ago. Mega PRs — 1,000+ changed lines — are now 13.8% of merged work. Agent sessions touch more files and make ~30% more tool calls than they did two months prior. And changes increasingly reach commits without a separate manual diff acceptance step.
Review is not dead. But review can no longer be the first governance surface. By the time a 1,000-line agent-authored change lands in a PR, the architectural decisions inside it have already been made — which dependencies to import, which boundary to cross, which pattern to follow. A reviewer reading that diff is auditing decisions, not shaping them. The leverage point moved earlier, to the moment of generation.
The unit of risk scaled faster than the unit of review. When a single PR can carry 1,000+ agent-authored lines that committed without manual diff acceptance, the first place to assert architectural intent is before generation, not after merge.
This is why governance before generation stops being a slogan and becomes an operational requirement. The cheapest place to prevent an architectural violation is before the agent writes the code that contains it. Catching it in review still works, but at agent velocity, review becomes a backlog, not a gate. Verification contracts — architectural rules expressed as checks an agent’s output must satisfy — move the assertion to where the decisions are actually being made.
Context is not governance
The report’s “rise of context” theme is the one most likely to be misread as a solution. Models are reading far more before they write: input now accounts for more than 90% of input-output token volume, making context the dominant part of non-cache model usage. The intuition that follows is comforting — if the model can see the whole codebase, surely it will respect the codebase.
It will not, not reliably. More context helps an agent understand a codebase. It does not guarantee the agent complies with it. A model can read every file, ingest every convention, hold the entire architecture in its window, and still import a forbidden dependency, cross a layer boundary, violate a naming rule, or contradict a platform decision recorded in an ADR. Reading a constraint is not the same as being bound by it.
This is the difference between memory volume and enforceable intent. Context is probabilistic input to a generation step. Governance is a deterministic check on the output. The two are not substitutes, and scaling the first does not produce the second. A 90%-input token mix means agents are extraordinarily well-informed and still entirely unconstrained.
An agent that reads more is not an agent that complies more. Context tells a model what exists; it does not tell the system what must not ship. Architectural compliance is an enforcement property, not a retrieval property.
This is also the line between retrieval and governance. Feeding architecture into the prompt is retrieval; binding generation to it is governance. We have written about that distinction at length in RAG vs governance: retrieval surfaces relevant text, governance enforces a rule deterministically regardless of what the model chose to attend to.
Automation creates governance surfaces
The report’s “shift to automation” theme is where the governance gap becomes concrete. More AI changes are being accepted automatically: agent-generated changes reaching commits without a separate manual diff acceptance step grew more than 5x in 2026, from 7% on Jan 1 to 36.3% on May 16. Cursor also notes that adoption of its Automations is growing quickly, with security review emerging as a strong use case, and that SDK runs show early demand for turning agent infrastructure into a programmable platform customized to how each company builds software.
Every one of those is a new automated surface. And every automated surface is a place where architectural intent can be honored or quietly broken with no human in the loop. Automation does not remove the need for governance; it multiplies the number of points at which governance has to apply.
The implication is that governance can no longer be a single checkpoint. It has to propagate across the lifecycle:
- Before code generation — surface the relevant architectural constraints to the agent.
- Before tool execution — an agent running shell commands and editing files is acting on the system, not just proposing text.
- Before commit — the surface that 36.3% of agent changes now cross with no manual diff review.
- Before the PR — so a mega PR is born compliant rather than audited late.
- In CI — the deterministic backstop that fails the build on violation.
- Across generated artifacts — config, infrastructure, schemas, and migrations, not just application source.
Governance has to propagate across every automated surface, not sit at one checkpoint
A programmable agent platform with auto-accepting commit flows needs governance wired into each of those surfaces, not bolted onto one. That is the substance of governance propagation: the same architectural constraints, enforced consistently everywhere code is generated, evaluated, and committed. And it is why governance before generation is the anchor — the earlier in the chain a constraint is asserted, the fewer downstream surfaces have to catch the failure.
The power-user gap becomes a governance gap
The report’s “power user gap” theme is, on its face, a story about inequality of output: p99 developers produce 46x more lines than the median active user and merge 15x more PRs than the median active PR author. Activity is heavily concentrated at the tail.
Read as a governance document, this is the sharpest finding in the report. The most productive AI users are reshaping the architecture of a codebase 46x faster than the median developer — and far faster than review, documentation, onboarding, and informal team knowledge can keep up. A power user can refactor a subsystem, introduce a dependency, or establish a pattern in an afternoon that the rest of the team discovers weeks later.
Asymmetric implementation velocity is asymmetric architectural influence. When one developer with agents can out-produce a team, the architectural rules that hold the system together cannot live in that team’s collective memory or in a reviewer’s vigilance. They have to be machine-readable and machine-enforceable, so they apply at the power user’s velocity rather than the team’s. That is the core argument for architectural governance: encoding the rules of the system so they bind every contributor, human or agent, at any speed.
At 46x output, informal architecture stops scaling. Rules that depend on a human noticing in review cannot keep pace with a developer who reshapes the codebase faster than the team can read the diffs. Machine-enforceable intent is the only thing that scales with the tail.
The missing layer: architectural governance infrastructure
Put the five themes together and the report describes a single transition: AI is becoming infrastructure for execution. Cursor, Claude Code, Copilot, and Devin all increase execution capacity — they make it cheaper to generate, edit, and ship code. That capacity is real, measured, and accelerating.
What the velocity curve does not include is a layer that preserves architectural intent across all that execution. That is the layer Mneme occupies. It is not memory, not RAG, not PR review. It is a repo-native governance infrastructure layer that compiles architectural decisions — the ADRs and constraints a team has already agreed on — into machine-evaluable rules that agents can retrieve, respect, and be checked against.
The division of labor is clean. Execution tools own the velocity curve: more code, larger PRs, deeper sessions, more automatic commits. A governance layer owns the governance curve: the same architectural intent, enforced deterministically before generation and across every automated surface, regardless of which model or agent did the work. Because the enforcement is deterministic and model-agnostic, it does not erode as agents get faster or as the tool mix changes underneath it.
This is also where the layer meets the tools developers already use. Governance that runs at the hook level reaches the agent before generation; governance that runs in CI catches what slips through. Mneme is designed to sit at both — alongside execution in the Claude Code integration and as a deterministic gate in GitHub Actions — so the same constraints apply from the first prompt to the merge.
Cursor proves the velocity curve; the governance curve is the open problem. The report makes the case that AI is now SDLC infrastructure. The unanswered half is the infrastructure that keeps architectural intent intact while that execution scales — and that is the layer worth building toward.