A 10× developer isn’t a 10× team

In July, Lauren Tan at Cursor shipped about a thousand pull requests. She said August would be double that, and it came in at 2,462. Cursor's own report on developer habits says its top developers merge around 15 times as many pull requests as a typical active developer.

Most teams don't see anything like that, even with the same AI tools. A thousand pull requests a month isn't a skill issue; it's a setup issue, and nobody sells you the setup. What many teams get instead is a bigger queue: more code waiting for someone to finish it.

A faster coder doesn't make a faster team

Speed up one stage of a pipeline and the work just waits at the next one. If agents write code ten times faster but review, checks and handoffs stay the same, the gain piles up as a queue. The fix is in the setup around the agents, and it pays to keep that setup simple: an elaborate multi-agent system that has to be rebuilt every time the model changes or someone new joins just adds work.

Six principles keep coming up in teams that make it work.

1. Make agents multiplayer

Think of the last annoying problem you solved with an agent: the things you tried, what didn't work, what finally did. If that lives in a private chat, the next person has to go through it all again.

Shopify built an agent, River, that works in public Slack channels, so conversations are visible and useful discoveries become shared instructions and skills that later sessions reuse. Over a 30-day period Shopify reported about 60,000 sessions across thousands of channels, and River co-authored about one in eight merged pull requests. The point isn't Slack; it's a shared setup: project instructions an agent can find, skills it can reuse, and work that doesn't vanish into someone's chat. If you lead a team, look after those shared resources and measure whether they get reused.

2. Keep the history separate from the session

You spend hours getting an agent to understand a project, then start a new chat or the conversation gets summarised, and half of it has to be explained again. Shopify's platform underneath River, Aquifer, keeps the saved history separate from the software running the agent and from the temporary workspace. The model and the workspace can be swapped; the history stays.

A simple test: what would you lose if your current chat disappeared? Whatever you can't afford to lose needs a home outside the chat.

3. People stay accountable for what ships

Addy Osmani describes this as owning the outer loop. The agent can investigate, write code, run tests and try again on its own. You decide what it's trying to achieve, what it may and may not touch, and what evidence would convince you the result is good, and you answer for what reaches customers.

You don't stay accountable by watching every step. You build checks into the work: tests that catch broken features, code rules that block known mistakes, permissions that keep the agent away from things it shouldn't change, even a second agent that reviews against an agreed bar. Anthropic describes the Claude Code team splitting work this way: Claude handles style checks, finding bugs and tests, while people focus on security, legal risk, what the product should do and whether the result is actually good.

Accountability is also how people learn. Someone early in their career should build a spreadsheet with AI, but be able to explain it cell by cell. Endless AI output that nobody else understands isn't productivity; it moves the work onto everyone who has to read it. Understanding the work is also what lets you contribute the next idea, not just approve this one.

4. Leave the work so someone else can pick it up

Saving every message isn't the same as leaving a usable handoff. Anthropic's approach for long-running agents keeps a list of features, a record of progress and a way to start the project, with the code left in a state the next agent or person can work with. A new session first checks where things stand, reads the notes and confirms the basics still run, then picks up the next task.

One detail matters a lot: an agent may mark a feature as passing when it works, but it isn't allowed to delete a test that says it doesn't. Otherwise you've built an efficient way to turn the checklist green while the product breaks. Design on the assumption that agents will try to pass the checks, and make sure the only way to pass them is honestly.

5. Let the agent check its own work

A familiar afternoon: the agent makes a change, asks you to look, you describe what's wrong, it tries again, and repeat. The agent is typing, but it needs you for every step. Visual and interaction work is the hardest case.

The better pattern is a small playground where the agent can try a change and check the result itself, with experiments saved as links others can reopen and checks that run without anyone clicking through the interface. The same applies elsewhere: can the agent find the docs, read the project's rules and run a check without asking you how? Lauren Tan turns recurring agent mistakes into reusable skills and automatic checks, which works far better than adding another paragraph to a giant instruction file. She says she barely reads code anymore, but only because those checks are in place first.

6. Drop the process that no longer helps

Offices used to pass memos around in brown inter-office envelopes. It's easy to rebuild that with agents: one writes a document, another reformats it, a third files tickets, and finally a person reads it. It's AI, but it's the same paperwork, and tokens aren't free. If a small team already agrees on what to build and how, generating a spec and tickets in five minutes isn't a win; the question is whether the step is needed at all.

Anthropic describes the Claude Code team being given explicit permission to drop processes that had become obsolete. Six-month roadmaps went stale, so they moved to building prototypes and getting internal feedback, while review and security got more attention. Most companies have more constraints than a lab, but anyone can ask whether a step still earns its place and start from what the work is actually for.

Some rituals have value an agent can't see. A stand-up is officially a status update, but it's also where people notice who's stuck and remember why they're doing the work. Be honest about what a ritual is for before replacing it, because with fast tools a team can travel a long way in the wrong direction before anyone notices.

Agents working with agents

Agents can investigate different parts of a problem, compare answers and check each other's work. The same ability can spread a mistake. That's an argument for limits on what agents can do, checks on what they're doing, and a way for an agent to stop and say it's stuck when a task can't be done, not for avoiding collaboration altogether.

Where to start

• Start small. Lauren Tan suggests three to five teammates, to learn how the pieces fit before a whole group adopts them.
• Find the bottleneck first. Is it reuse, guardrails, checks or handoffs? Fix the one that's holding work up.
• Don't slow your fastest people down. A better shared setup lifts everyone else while they keep going. Across a hundred developers, even 20 to 30 percent more finished work is a big deal.
• Measure what ships. Pull requests and lines of code aren't value. What counts is shipping things people care about, faster, and spending less time explaining the same things to agents.