1000 PRs a Month: How a Cursor Engineer Manages 100+ Agents Simultaneously

Recently, an interview with a Cursor Principal Engineer on X sparked widespread discussion in the developer community. Despite having joined Cursor not long ago, this engineer has already achieved over 1,000 PRs per month. Even more astonishing, he simultaneously runs over 100 Agents in a fully autonomous mode to do his work—these Agents can even merge code directly into the main branch.

PR (Pull Request) is the core mechanism for code collaboration in modern software development. After completing a feature or fix, a developer creates a PR to request merging code into the main branch. Typically, a PR must pass code review and automated tests before it can be merged. Over 1,000 PRs per month means roughly 50 PRs per working day—nearly impossible under traditional development. A highly productive human engineer usually submits 20–40 PRs per month. What's even more notable is that these Agents can merge directly into the main branch, bypassing the traditional manual code review process, which places extremely high demands on code quality assurance.

This article is based on a deep analysis of this interview by a Bilibili creator, distilling the methodology that's truly valuable for AI Native development. It's worth noting upfront that Cursor's internal unlimited token usage is a prerequisite that most developers can't replicate. However, the evolution in thinking—from "managing 2–3 Agents simultaneously" to "orchestrating a fleet of 100+ Agents"—is the most valuable takeaway.

The Leap from 2 Agents to 100 Agents

Most developers trying to use AI Agents in parallel already feel overwhelmed when managing just 2–3. The reason is simple: Agents have a very low quality floor, and once you scale up, manual oversight becomes an insurmountable bottleneck.

It's important to understand what an AI Agent means in the software development context: it's not a simple code completion tool, but an AI system with autonomous decision-making capability and a complete work loop—receiving tasks, analyzing context, generating plans, executing code changes, and running verification. Cursor's Agent mode allows AI to execute terminal commands directly in the editor, modify multiple files, and run test suites, forming a workflow that closely resembles an autonomous developer. Running multiple Agents in parallel is essentially managing multiple independent development workflows, each requiring its own context space and compute resources.

This engineer's practice demonstrates that scaling Agent management isn't about throwing more compute at the problem—it's about a systematic methodology. The core approach can be summarized in three points: build trust, hard constraints beat soft constraints, and make your codebase Agent-friendly.

Building Trust in Agents: The First Step to Scaling

This is the most resonant point in the entire methodology. When you're managing dozens of Agents, trust becomes the biggest bottleneck.

Think of it like being a boss with an underperforming employee—you have no choice but to micro-manage them constantly. When those "employees" multiply to dozens, that level of scrutiny will crush the manager.

Teaching Agents to Self-Verify

The engineer's key advice: equip Agents with skills that allow them to self-verify quality. For example, teach an Agent how to capture CPU profiles and memory profiles, how to open the iOS simulator, and how to analyze performance data.

CPU profiling and memory profiling are two core techniques in software performance analysis. CPU profiling records how much CPU time each function consumes during a specific period, helping identify performance bottlenecks—for instance, a function unexpectedly consuming 80% of CPU time. Memory profiling tracks memory allocation and deallocation patterns to detect memory leaks or excessive allocation. Traditionally, these analyses require developers to manually launch profiling tools (such as Chrome DevTools, Instruments, pprof, etc.), collect data, and interpret it manually. Teaching Agents to perform these operations autonomously means they can automatically verify the performance impact of their code changes without human intervention in the collection and analysis steps—a critical capability for achieving fully autonomous development.

The core idea is giving Agents self-verification capability. Without this, you become the bottleneck in the entire process: constantly capturing profiles manually, taking screenshots repeatedly, copying and pasting console errors to the Agent. As long as this kind of manual back-and-forth copy-pasting is needed, you can never achieve true parallelism.

Put simply, an Agent's ability to self-verify determines how many Agents you can manage in parallel.

Hard Constraints Beat Soft Constraints: The Key to Agent Code Quality

The second highly insightful point: if you want Agents to consistently produce high-quality code, you must rely on hard constraints, not soft constraints.

The Difference Between Hard and Soft Constraints

• Hard constraints: Architecture design, linters, CI, compilers. These are rules enforced by machines that Agents cannot bypass.
• Soft constraints: The currently popular skills, memory, and various prompts. These are essentially "suggestions" that Agents may or may not follow.

A linter is a static code analysis tool that checks for syntax errors, style violations, and potential bugs before code runs. Common examples include ESLint (JavaScript/TypeScript) and Pylint (Python). CI (Continuous Integration) is an automation practice where every code commit triggers a series of automated checks—compilation, unit tests, integration tests, linter checks, and more. These are called "hard constraints" because they create unskippable gates in the code merge pipeline: if checks don't pass, the code can't be merged. By contrast, instructions written in prompts or rules files are "soft constraints"—large language models may ignore these instructions during complex tasks due to limitations in their attention mechanisms. Encoding rules as linter rules essentially transforms natural language "requests" into deterministic program logic.

The engineer's assessment is razor-sharp: If you rely solely on soft constraints, your code degrading is just a matter of time.

Replace Repeated Reminders with Linter Rules

For example, if you don't want Agents to write comments, the best approach isn't to repeatedly remind them in the prompt—it's to write a linter rule that bans all comments outright.

There's also a highly practical rule of thumb here: When you find yourself repeatedly giving the same suggestion to an Agent, consider whether you can codify that suggestion as a linter rule or CI check. This upgrades a soft constraint that depends on "reminders" into a hard constraint enforced by machines.

This approach essentially crystallizes human experience into the toolchain—moving from "having to say it every time" to "set it once, enforce forever." For scenarios involving 100 Agents, the importance of this cannot be overstated—you can't accurately write the same rule in the prompts of 100 Agents, but a single linter rule can permanently cover all Agent output.

Building an Agent-Friendly Codebase

The third point focuses on how the codebase itself is organized. The engineer recommends proactively restructuring your codebase to be more agent-friendly.

Feature Map: A Navigation Map for Agents

His specific approach is to maintain a dedicated feature map in Cursor's codebase. This map serves as navigation, telling Agents where a specific UI element is, what features it has, and what its keyboard shortcuts are.

In large projects, code is typically organized by technical layers (e.g., model, view, controller) or business domains (e.g., auth, payment, notification), but the mapping between UI-level features and code files isn't always intuitive. Traditional teams usually rely on architecture documents, README files, or team members' tacit knowledge to solve the "where is the code for this feature" problem. The innovation of a feature map lies in being designed specifically for AI Agent consumption—describing the correspondence between UI elements and code locations, keyboard shortcut bindings, feature boundaries, and other information in a structured way. This aligns with the rising "docs-as-code" philosophy, but expands the target audience from human developers to AI Agents.

With this map, Agents can locate code much faster. Otherwise, when a user submits feedback with a screenshot, an Agent might have to consume a huge portion of its context window searching for the corresponding code—extremely inefficient.

Context window is a core technical parameter of large language models, referring to the maximum number of tokens the model can process in a single interaction. Although current mainstream models have expanded context windows to 128K or even 200K tokens, in real codebase scenarios, a medium-sized project can easily exceed millions of tokens. When an Agent needs to understand a bug report and locate the corresponding code, it must load relevant files, dependencies, type definitions, and other information within its limited window. Every irrelevant file loaded squeezes out space needed for reasoning and generation, adding "noise." Therefore, the less noise in the context window, the higher the model's output quality.

In the Agent era, the context window is a scarce resource. Reducing an Agent's "pathfinding cost" directly improves its output efficiency and quality.

The Management Philosophy Behind the Methodology

You might not have noticed, but this engineer set up a large number of principles for his Agents—and many of these principles are the very same requirements he previously imposed on human employees as a manager.

This reveals a fascinating insight: managing an Agent fleet and managing a team share highly similar underlying logic. Whether it's building trust, setting clear rules, or reducing collaboration friction, the wisdom of human team management applies equally to AI Agent orchestration. This is no coincidence—large language models are trained on massive amounts of human text, and their understanding of "instructions," "rules," and "principles" mirrors, to some extent, how humans understand these concepts. In management terms, hard constraints correspond to "institutional management," soft constraints correspond to "cultural management," and feature maps correspond to "knowledge management." The most effective team management has never been about choosing one of the three—it's about making all three work in synergy.

He also open-sourced some of his skills. Interested developers can search for pstack on GitHub, which includes practical skills like no-comments and a series of principles.

Conclusion: The Role Shift from Executor to Agent Architect

While most developers can't replicate the extreme setup of "unlimited tokens + 100 Agents," the core of this methodology—let Agents self-verify, use hard constraints as guardrails, and make your codebase easier for Agents to understand—is extremely valuable for any team moving toward AI Native development.

Going from "hand-holding one Agent" to "orchestrating an Agent fleet" is fundamentally a role shift from "executor" to "architect." The real leverage isn't in how much code you can write, but in how well you can design a system that lets Agents write reliable code for you. This transformation echoes multiple paradigm shifts in software engineering history: from hand-written assembly to high-level languages, from monolithic applications to microservices, from manual deployment to CI/CD. The essence of each shift has been encoding human knowledge and experience into systems, replacing repetitive low-level operations with higher-level abstractions. Managing an Agent fleet is very likely the next milestone on this evolutionary path.