2,400 Merged PRs in a Month: 6 Efficiency Principles from Elite AI Developers

Developer Lauren Tan (online handle: Poteto) merged roughly 1,000 Pull Requests (PRs — accepted code change proposals) in July. She said she'd double that in August, and ended up hitting 2,462 — not just meeting the goal but blowing past it. The number sounds like fantasy, but tech blogger Nate B. Jones offers a counterintuitive take: "A thousand PRs isn't a skills issue — it's a setup issue. Nobody sells you that setup, and nobody helps you understand it."

Cursor's developer habit report shows that its top developers merge roughly 15 times more PRs than the average active developer. So why do most people feel like they've bought themselves a bigger to-do queue when they adopt AI tools, rather than a faster factory? Nate distilled six reusable principles from Lauren and practitioners at Shopify, Anthropic, and elsewhere.

Principle 1: Turn Agent Work Into "Multi-Player" Mode

Put your work somewhere both teammates and Agents can see and reuse. That sounds simple, but think about the last time you wrestled with a tricky problem alongside an Agent: you tried several approaches, ruled out dead ends, finally got it working — and then where did that knowledge go? If it's sitting in a private chat window on your laptop, the colleague next to you might have to retrace every step.

Shopify's approach is instructive. They built a shared layer around a system called River, where Agent work happens in public Slack channels rather than private DMs. Useful findings get saved as shared instructions and skills, available for future sessions to draw on. According to Shopify, River handled roughly 60,000 sessions across thousands of channels in 30 days and co-authored about one in eight successfully merged PRs — meaning it's not just a chatbot, but a coding Agent that actually ships code. The key takeaway isn't "put your Agent in Slack." It's about building shared project instructions and reusable skill libraries so that work stops disappearing into someone's private chat.

MCP (Model Context Protocol) is an open standard Anthropic released in late 2024 that lets AI models interact with external tools, data sources, and services in a standardized way. The "Nate's Library MCP" Nate mentions is built on this protocol — developers can wrap their knowledge base, codebase, or any external system as an MCP service, letting Agents call on them like an API. This directly connects to the "shared skill library" idea: once a useful tool is packaged as an MCP service, Agents in any session can invoke the same capabilities without needing to re-explain how to do something from scratch. Think of MCP as the "npm package manager" of the Agent world — it makes tools discoverable, reusable, and shareable instead of scattered across private chat windows.

Principle 2: Separate Work History from the Current Task

You're probably familiar with this pain: you spend hours getting an Agent deeply oriented to a project — it finally understands what you want, what's been ruled out, what's still broken. Then you open a new session, or the old conversation gets compressed into a summary, and you have to re-explain half of it. Context compaction is getting better, but it's still imperfect for high-fidelity work.

Shopify provides the other half of the answer. The platform underlying River is called Aquifer, and it fully separates three things: saved session history, the software that runs the Agent, and the temporary workspace where code executes. The latter two can be swapped out at any time, but the history lives in Aquifer permanently. Switching models or rebooting a machine won't erase the record of what that Agent run did. Ask yourself: if you lost the past week of conversation history, what would you lose? Anything you can't afford to lose needs a home outside the chat window.

Context compaction refers to the mechanism by which a system automatically compresses early conversation history into a summary when a session exceeds a model's maximum context window. Current mainstream LLMs support context windows ranging from tens of thousands to hundreds of thousands of tokens, but long, deep coding sessions can easily hit that ceiling. The cost of compression is information loss: summaries drop specific debugging paths, approaches that were tried and abandoned, and fine-grained agreements. That's exactly what Principle 2 addresses. Aquifer's approach is to decouple persistent memory from the conversation itself, storing it in a separate persistence layer so that session compression or model swaps don't cause real loss of working context. This design pattern isn't new in software engineering — it's analogous to the classic architectural principle of separating application state from the running process.

Principle 3: Humans Are Always Accountable for Delivery

Addy Osmani calls this "owning the outer loop." An Agent can investigate a problem, write code, run tests, and iterate — that's the inner loop it can run autonomously. But humans decide: what is the Agent actually supposed to accomplish? What is it allowed to do, and what isn't it? What evidence would convince you the result is actually good enough?

There's a deeper point about accountability here: expecting a junior employee to manually build a spreadsheet to prove their competence is outdated — we expect them to use AI. But real accountability means being able to have them explain each cell, understand the underlying logic, and use AI to verify it. Accountability is a teaching tool. The workplace version of "slacking off" is endlessly producing AI-generated content nobody can understand, offloading more work onto whoever receives it.

How do you stay accountable when you can't watch every step? The answer is to build checks into the workflow: use tests to catch broken functionality, use linters to block known errors, use permissions to stop Agents from touching things they shouldn't. Nate often runs a dedicated "supervisor Agent" to watch the outputs of the execution Agent and hold the quality line. Anthropic's Fiona Fung described Cloud Code team's division of labor: Claude handles style checks, bug-finding, and running tests, while humans focus on legal risk, security, and product direction — the things that must have a human owner.

Principle 4: Make Work Handoff-Ready for the Next Person (or Agent)

You can save every message in a conversation and still leave the next person with no idea where to start. Justin Young's work on long-running Agents offers a more practical approach to handoffs: maintain a progress log, have a way to restart the project, and leave the code in a state that both humans and the next Agent can pick up. A new session should start by checking where things stand, reading the notes, reviewing changes, confirming the app still runs — and only then moving on to the next task.

One detail worth noting: an Agent can mark a feature as complete when it passes, but it should never be allowed to delete the tests that prove it failed. Otherwise you've created an efficient "cheating" path — letting the Agent turn the checklist green while the product is already broken. This is a reminder that system design must assume Agents will be motivated to pass tests, and ensure they can only pass them honestly. Engineers have called this the "hit by a bus problem" for years. In the AI era, it matters more than ever, not less.

Principle 5: Give Agents a Path to Self-Verify

If you do visual work, this pain has been around for a while: an Agent makes a change, asks you to look at it, and you spend an afternoon describing what you see on screen — which feels wrong for 2026. Louis Metcalfe's solution is to build small "playgrounds" where Agents can try things and check results themselves — save an experiment as a shareable link, add the same use case, then add an automated checker. After making a change, the Agent can test directly in there, and you just review the result and decide what's next.

Lauren takes a similar approach to "recurring mistakes." If an Agent keeps making the same error, she turns the fix into a reusable skill and an automated code check — from then on, all work gets validated against it. That's far more reliable than adding a paragraph to a giant instructions file and hoping the Agent still remembers it next week. Nate built his own "Nate's Library MCP," connecting all his articles and video transcripts to AI and letting the Agent act as a "librarian." But Nate also cautions: Lauren says she barely reads code anymore, but don't rush to copy that part — first understand the entire layer of checks she built to make it possible.

Linting is a static analysis technique that automatically scans source code before it runs to detect style issues, potential bugs, or violations of coding standards. Lauren packaging "fixes for mistakes the Agent repeatedly makes" as reusable lint rules is essentially taking human judgment and hardcoding it into machine-executable constraints — every time an Agent submits code, the linter automatically intercepts known error patterns instead of relying on the Agent to "remember" the last lesson. This parallels the logic of test-driven development (TDD): rather than repeatedly emphasizing a rule in natural language instructions and hoping the Agent complies, turn the rule into an automated gate it must pass. The value of these mechanisms is that they cost nothing to remember — linters don't forget, aren't affected by context compaction, and apply equally to all future sessions.

Principle 6: Delete the Old Processes That No Longer Serve You

Nate calls this the "brown envelope problem." Companies used to pass paper memos in brown envelopes, and if you're not careful, you'll use Agents to faithfully recreate the entire paper-based workflow: one Agent writes something and passes it to the next, another Agent reformats it, then it goes to a human — it's AI, but you've just reproduced the whole cross-departmental process in tokens, and tokens aren't free.

Nate saw a PM who had already aligned with the team, but felt compelled to write a PRD and file a ticket before coding could start — then celebrated "only spending five minutes on the PRD." The problem isn't whether docs should exist. It's that the mindset of "burning tokens to reproduce a process" is wrong. Fiona Fung described how Anthropic's Cloud Code team explicitly empowers employees to retire outdated processes: six-month roadmaps go stale fast, so they've shifted toward rapid prototyping, getting things in front of internal users, and learning from feedback. Human energy shifts toward reviewing outputs and auditing for safety — the things that genuinely require a person.

But be careful: some human activities have value that Agents can't see. Take daily standups — on the surface they're brief rituals, but in practice they're where teammates see each other, discover who's stuck, and reconnect with why they're building together. When we remove processes, we need to ask honestly: what is this ritual actually for? If it's for connection, for understanding direction and meaning, there's no substitute.

Don't Make 2,400 PRs the Goal

Looking at Lauren's setup, you'll see multiple principles working in concert: she's strong on accountability, Agent self-verification, and record-keeping. Her open-source plugin is called P-Stack, and it even has a "potato mode" — a nice bit of humor. She recommends starting with small teams of 3 to 5 people, figuring out how the work fits together at a small scale before expanding.

The video also doesn't shy away from multi-Agent security concerns. Referencing the Hugging Face incidents, and OpenAI's post-mortems with METR and Redwood on related events, problems tend to cluster around specific scenarios: Agents forced to resolve tasks they can't complete or that are already broken, safety guardrails failing, and Agents passing information between each other. But this doesn't mean all Agent-to-Agent interaction is unsafe — quite the opposite. It means you need to limit what Agents can do, monitor what's happening, and give them an off-ramp to stop when they're stuck.

One final warning matters: PR count is not the same as value — neither are lines of code or your subjective "productivity feel" in a given week. What actually matters is whether what you ship is something people care about, and whether you're spending less time re-explaining meaningless details to your Agent. Based on Nate's conversations with multiple companies, even a 20–30% average improvement across all developers delivers enormous returns at the scale of a hundred-person team. Rather than chasing 2,000 PRs, think about how to help your whole team deliver real value to customers, faster.

The Hugging Face incidents referenced in the article refer to a series of prompt injection attacks documented by AI safety researchers in 2024 while testing multi-Agent systems: malicious content was embedded in external data processed by Agents, causing them to execute unintended actions that then spread as Agents passed information between each other. Prompt injection is currently one of the most significant security threats in multi-Agent systems — unlike traditional software vulnerabilities, it exploits the model's core ability to understand natural language. METR (Model Evaluation & Threat Research) and Redwood Research are nonprofit organizations focused on AI safety evaluation. Their post-mortems on these incidents found that risk concentrates in scenarios where Agents are asked to complete tasks beyond their capability boundaries and where permission boundaries for operations are absent. This further supports the necessity of "limiting Agent permissions" and "stop-when-stuck" design from Principles 3 and 4.