Cursor's Agent Team in Practice: How to Break Through the 40% Productivity Ceiling

From Writing Code to Rethinking the Entire Development Lifecycle

As AI coding assistants swept through the software industry, Cursor's team noticed a counterintuitive pattern: customers would see exciting productivity gains early on after deploying these tools, but roughly a year in, that growth would plateau at around 40% — and stop climbing.

Behind that number lies an overlooked truth. Cursor points out that roughly 60–80% of a company's engineering budget goes toward engineers manually writing code. If AI could instantly take over that work, intuition suggests you'd see a three- to four-fold productivity leap. Yet in practice, most teams hit a ceiling at 40% throughput improvement.

The core argument from this talk is that this is the fundamental limit of "Phase 2" — treating AI as a coding assistant. You can make the assistant faster and faster, but until you move to the next phase, your throughput is destined to stall somewhere.

The data comparison is telling: from nearly zero AI-written code at the start of the year, to 15–20% in enterprise settings, to 75% at the frontier — and at companies like Cursor that have adopted AI aggressively, roughly 98% of merged commits are AI-generated. The coding phase has been fundamentally transformed. But the real bottleneck has simply moved elsewhere.

The Bottleneck Isn't Writing Code — It's the Entire SDLC

Why does the efficiency gain stall? Cursor's answer: AI only replaces a tiny slice of the software development lifecycle (SDLC).

A complete development process involves far more than writing code: planning, building, shipping and validating, and retrospectives. Engineering, product, and design teams do a lot more than just type code. Once AI accelerates the coding step, every other step becomes the new bottleneck.

Cursor offers a thought-provoking reframe — instead of asking "what can AI do?", ask the inverse: In this new world, which steps still require humans?

In the planning phase, agents may already be good at gathering user interview feedback, doing market research, or even exploring solution spaces. But before committing serious resources to building and marketing, you still need a human to review the plan and confirm it's worth the investment.

In the build phase, even when agents write virtually all the code, you still need documentation explaining architectural decisions and risky code segments. You don't need to read every section of a 20,000-line PR — but someone has to look at those critical hundred lines. And critically, before anything goes to production, nearly everyone agrees: you need a human who signs their name and says "this is good to ship."

The SDLC (Software Development Life Cycle) is a framework describing the full process of software from concept to retirement — typically covering requirements analysis, system design, implementation, testing, deployment, and maintenance. Different organizations slice it slightly differently, but the core idea is the same: software delivery is a pipeline of sequential steps, and any bottleneck limits overall throughput. This closely mirrors the manufacturing concept of the Theory of Constraints — a system's maximum output is determined by its slowest step. When AI tools multiply coding speed, the bottleneck naturally shifts to requirements review, architecture decisions, testing strategy, and release approval — steps that were previously obscured by the coding bottleneck. This explains why the gains from simply introducing an AI coding assistant tend to plateau within about a year: coding is no longer the limiting factor, so accelerating it yields near-zero marginal returns.

Filling the New Bottlenecks with an Agent Team

Cursor abstracts this system into three layers: at the top, humans who review artifacts and provide feedback; at the bottom, the "intelligence" — models and harnesses; and in the middle, the agent team that needs to be built.

The real challenge is: what should the system output to humans? Ideally, highly polished artifacts — clearly presenting what the agent did, which decisions require human input, and all relevant contextual details so that humans can accurately picture the agent's proposal. Alongside that, a high-quality feedback loop where human input can be directly consumed by agents to fix issues and keep moving.

Building on this, Cursor has deployed multiple concrete agents — many of which operate entirely outside the core coding step, creating leverage for PMs, security teams, growth teams, and more.

PM Agent and EM Agent: Starting From an Accidental Observation

The origin of the PM Agent and EM Agent is surprisingly organic. An engineer named Lauren noticed a problem while on call: when the team was internally testing a new agent window (codenamed Glass), 10–20 bug reports would come into the "Issues Glass" Slack channel every day. The habit was to spin up a cloud agent to fix them — the team's internal joke was "I sent someone to handle it" — but these agents kept getting stuck and failing to make real progress.

Lauren's insight: the problem was often that the bug reports themselves weren't detailed enough. So she built two skills — a "how skill" and a "why skill" — that taught the harness to examine the codebase more rigorously and generate deeper explanations. Combined with a system prompt, this automation would, upon receiving a Slack message, go research the codebase and come back to the reporter within minutes asking more pointed follow-up questions.

Interestingly, this "bug report agent" would sometimes feel like it was interrogating the reporter — and in many cases, the issue resolved itself once it had dug through the codebase. It answered the question like a support bot, and the problem disappeared.

Built on top of this are two higher-level agents: one that categorizes and triages all issues into P0, P1, P2 priority levels; and a more experimental EM Agent that proactively messages the relevant engineer saying something like "two new remote SSH bugs came in — can you take a look?" The latter is still imperfect, because the team lacks a precise map of who owns which code — which is exactly what they're currently teaching the agent.

The "harness" mentioned in this context is a key engineering concept in AI agent systems — it refers to the execution framework and orchestration layer built around the underlying model. It manages the agent's tool calls (e.g., reading/writing files, executing commands, querying APIs), assembles and trims the context window, handles multi-step task state management, and implements error retry logic. Think of the model as the "brain" and the harness as the "body and nervous system" — it determines what information the brain can perceive, what tools it can operate, and how to chain multiple actions into a complete workflow. A "skill" is a reusable sub-capability module within the harness — for example, "read the codebase and generate an explanation" or "send a message to a Slack channel." Multiple skills combined form a complete agent. This layered design allows different agents to share underlying skills, reducing duplicated effort.

Agents Across Security, Code Review, and Growth

The value of agents extends well beyond the planning phase. Cursor has run similar experiments across multiple business functions.

Security Bot: Fixing 200+ Vulnerabilities

Travis on the security team built an automation that triggers on PR publication. In an ideal world, you'd have an application security engineer review every PR and spend hours hunting for issues at every severity level. In reality, no one has that many security engineers. This agent runs a series of prompts to surface the kinds of issues an AppSec engineer would typically find — and to date, it has fixed over 200 vulnerabilities, the vast majority automatically. The result: the security team doesn't need to grow at the usual pace, yet every PR gets a more thorough review than before.

Smart Detection of Low-Risk Commits

Cursor once tightened its code review policy, which caused a flood of PRs to trigger as many as eight reviewers — even for a trivial string change. Engineers were frustrated. So the team built an agent to assess PR risk.

They watched it run for a week first, confirmed the assessments looked reasonable, and then allowed "extremely low risk" PRs to merge without human review. An unexpected bonus: when a PR is assessed as medium-to-high risk, the agent — drawing on its deep understanding of the codebase — can identify who knows that code best, routing to more appropriate reviewers than a traditional code owners file would. The system both unblocks low-risk changes and ensures that code genuinely needing review gets more rigorous scrutiny.

Full-Cycle Automation for Growth Experiments

The growth team has only about two engineers, yet runs 20–30 experiments per month. Their process: plan, launch, run, decide, ship, clean up code. The team built four agents: one audits experiment setup (to avoid metrics being incorrectly wired), one syncs documentation across Notion, Linear, Statsig, and the codebase, one monitors running experiments (to catch metric logging errors before you're six days in and forced to restart from scratch), and one reads Statsig data and recommends winning variants.

The final decision still belongs to a human — but once you've picked a variant, the agent automatically submits a PR to clean up the Statsig code and remove the stale feature flags, so dead branches don't accumulate in production. The result: dramatically higher experiment throughput, with the team able to focus their energy on what actually matters — which bets to make and how to design the experiments.

Statsig (referenced as "StatsSig" in the original) is an experimentation and feature management platform for product teams, offering A/B testing, Feature Flag management, and metrics analysis. Feature Flags allow teams to dynamically enable or disable functionality without redeploying code — a core piece of modern continuous delivery infrastructure. In growth experimentation, each experiment typically maps to a Feature Flag: enabled when the experiment starts, and requiring the corresponding branch logic to be deleted from the codebase when it ends. Otherwise, dead code accumulates over time, increasing maintenance burden and cognitive overhead. This is exactly the "clean up code" step described above — tedious, easy to forget, but necessary — making it an ideal target for agent automation.

Organizational and Cultural Ripple Effects

When you start building this "meta-system" and agent team, priorities shift accordingly.

Cursor is evolving its team culture. They have a dev X channel — a place where engineers complain about developer experience issues. Someone raised an interesting question: why do humans have this channel, but cloud-running agents have nowhere to "complain"? So the team built an agent X channel. Now it streams a feed of messages from agents expressing "frustration" about things they can't accomplish — and the team is experimenting with whether those issues can be auto-fixed.

Once people start talking about "the factory," the culture compounds: everyone sets goals around building reusable skills for others, and looks for early "champion" advocates. Lauren, the new hire who built the PM and EM agents, has become a key figure in helping the team think in a more meta way about how to build the factory.

Team composition is also changing. That growth team is two software engineers, one data scientist, one designer, and one PM — a very different ratio than before. But it turns out that when agents can carry a significant share of the workload, this new composition is actually the more effective configuration.

For engineering leaders thinking about how to evolve their organizations, these front-line practice notes may be exactly the starting point for breaking through that 40% ceiling.