This is a production story, not a benchmark. On July 30, Cursor published how they set up their cloud agent environment, and the number near the top is the one that matters: in December 2025, cloud agents authored roughly one in ten pull requests merged to the Cursor monorepo. Today, they write more than half.
That shift happened in about eight months, on a real engineering codebase, under production pressure. It is worth asking what actually changed.
The post describes three categories of work, none of which involves the underlying model.
Environment alignment. Cursor’s developers use Macs. Their cloud agent VMs run Ubuntu. The mismatch was subtle enough to cause failures that weren’t immediately obvious—tools that worked locally would fail in the cloud in ways agents couldn’t easily diagnose or recover from. The fix was a Cursor-defined Dockerfile that brought the cloud environment into alignment with local development. This is table stakes for human developers onboarding onto a new machine; it turned out to be equally important for agents.
Interface simplification. Build systems accumulate incidental complexity. Commands have flags that matter in some contexts and not others; services need to be started in particular orders; long-running processes need supervision. Cursor built anydev, a CLI that abstracts this complexity into something an agent can call predictably. Critically, anydev includes a supervisor process that monitors and restarts long-running build commands—removing that state management responsibility from the model entirely. The principle here is that every decision you can take away from the agent is a failure mode you’ve eliminated.
Self-healing infrastructure. The most interesting piece is Cloud Doctor, an automation that monitors the agent environment, detects failures, performs root-cause analysis, and opens pull requests to fix the environment itself. Agents can break their own environments—through incomplete setup, unexpected state, or failed commands—and the response wasn’t to build a more careful agent but to make the environment repair itself. The CI/CD instinct applied to agent infrastructure.
The pattern across all three is the same: treat the agent environment as a production system with its own reliability requirements, not as a static backdrop. Teams that deploy AI agents often think about model selection and prompt engineering, then hit plateaus they can’t explain. The Cursor story suggests many of those plateaus are environmental: the agent is capable enough, but the surface it’s operating on isn’t maintained well enough to let it show it.
The headline number—over half of merged PRs—tends to provoke two reactions. One is skepticism about whether agent-authored PRs are equivalent in scope or quality to human-authored ones. The post doesn’t address this directly, and it’s a fair question. The other reaction is to try to calculate what this implies about engineering velocity: if you can multiply your PR throughput by some factor without a proportional headcount increase, what does that do to product development timelines?
Cursor’s incentive to report this number favorably is obvious, since they sell a product that competes partly on agent capability. But the infrastructure details in the post are credible and boring in the right way—Dockerfiles, CLI wrappers, restart supervisors. Nobody engineers that level of operational plumbing for a demo.
The real takeaway isn’t the percentage. It’s that Cursor invested engineering time treating their agent environment as a first-class production concern, and the productivity followed. That sequence—environment first, results second—is probably the right order of operations for any team that has hit a ceiling on what its agents can accomplish.