Why Your 3-Person Dev Team Can Now Outship a 15-Person One (And How to Set It Up).
AI agents have made raw code output nearly unlimited — but the bottleneck has moved from production to judgment. Here's why small, senior teams have the advantage.
Simon Willison — one of the most respected voices in software development, co-creator of Django — recently admitted something surprising. Running four AI coding agents in parallel exhausts him by 11am, despite having 25 years of engineering experience. Not because the tools are bad. Because his brain is the bottleneck.
That admission landed hard across the developer community because it captures a shift that every small engineering team is feeling right now: AI agents have made raw code output nearly unlimited, but the ability to direct, review, and integrate that output is still very human. And very finite.
This is a problem. But for small, senior teams, it's also an enormous opportunity.
The old math is broken.
For two decades, the equation was simple: more features required more engineers. A 15-person team outshipped a 3-person team because shipping was bottlenecked by typing — by the raw volume of code that needed to be written, tested, and deployed.
AI coding agents have changed that equation permanently. A single experienced engineer using Claude Code, Cursor, or similar tools can generate the code output that used to require three or four people. The bottleneck has moved from production to judgment.
This means something counterintuitive: a team of three senior engineers, properly set up, can now match or exceed the throughput of a team of fifteen — because the real constraint is no longer how fast you write code, but how well you evaluate it.
Why small teams have the advantage.
At first glance, it seems like larger teams should benefit more from AI agents. More people means more agents running in parallel, which means more output.
In practice, the opposite is happening.
Large teams hit coordination walls. When fifteen engineers are each running multiple agents, the volume of code entering the codebase explodes. Pull requests pile up. Review queues become unmanageable. Architectural consistency breaks down because no one person can hold the full system in their head while also reviewing AI-generated diffs. The management overhead that was already expensive becomes crippling.
Small teams stay coherent. Three engineers who know the entire codebase can run agents with far less coordination cost. They share context naturally. They catch architectural drift early because they're close enough to the whole system to notice it. The review loop — which is now the most important part of the process — stays tight.
This is the core insight: AI agents amplify whatever structure you already have. If your team is well-organised and technically strong, agents make you dramatically faster. If your team is bloated and poorly coordinated, agents make the chaos worse.
What "outshipping" actually looks like.
Let's make this concrete. Here's what a well-set-up 3-person team can realistically deliver in a week versus a traditional 15-person team:
| 3-person team with agents | 15-person team, traditional | |
|---|---|---|
| Features shipped per sprint | 8–12 | 6–10 |
| Code review turnaround | Hours | Days |
| Architectural consistency | High (shared context) | Degrades with team size |
| Communication overhead | Minimal | 3–5 hours/week in syncs |
| Cost per sprint (EU rates) | €12,000–€18,000 | €60,000–€90,000 |
| Decision speed | Same-day | Committee-driven |
The numbers aren't theoretical. This is the kind of output we see consistently at Nortis when working with lean founding teams. The cost difference is especially stark in the European market, where senior engineering salaries have increased significantly but headcount budgets have not.
The real risk: cognitive debt.
If the upside is obvious, why isn't every small team already doing this?
Because running multiple AI agents well is genuinely hard — and the failure mode is invisible until it's too late.
Willison calls it the need to develop "new personal skills for responsible agent use." The industry is starting to call it cognitive debt: the accumulated cost of context-switching between agent outputs, reviewing code you didn't write, holding multiple mental models simultaneously, and making high-stakes architectural decisions at a pace your brain wasn't designed for.
Cognitive debt looks like this in practice:
- You accept an agent's output because you're tired of reviewing, not because you've verified it
- You lose track of which agent is working on which task and start duplicating effort
- You merge code that works in isolation but breaks something three layers down because you lost the thread
- You ship faster but spend the next sprint fixing things that slipped through
The solution isn't to slow down. It's to build a workflow that manages your attention as carefully as it manages your code.
How to set it up: a practical framework.
Here's the workflow we use internally at Nortis and recommend to the teams we work with. It's designed for a team of two to five engineers, but the principles scale.
1. Assign agents to bounded contexts, not tasks.
Don't tell an agent "build the user settings page." Instead, assign agents to specific, well-defined domains: one agent handles the API layer, another handles the UI, another handles tests. This mirrors how you'd structure a team of junior developers — clear boundaries, limited autonomy, frequent check-ins.
The key is that each agent's output should be reviewable in isolation without needing to understand what every other agent is doing at the same time.
2. Batch reviews instead of streaming them.
The exhaustion Willison describes comes from constantly switching between agent outputs in real time. Instead, set up review windows: let agents work for 45–60 minutes, then review all outputs in a single batch. This lets your brain settle into one mode (evaluation) instead of constantly switching between generation and evaluation.
A practical cadence: run agents in the morning, review and merge before lunch, run another cycle in the afternoon, review before end of day. Two cycles, not eight.
3. Use test-driven development as your safety net.
Willison specifically highlights red/green TDD as the pattern that makes agentic coding responsible rather than reckless. Write the tests yourself — or have an agent write them and review them carefully — before letting agents generate implementation code. If the tests pass, you have a baseline of confidence. If they don't, you know exactly where to look.
This is non-negotiable. Without tests, reviewing AI-generated code is like proofreading a novel in a language you half-speak. With tests, it's like checking answers against an answer key.
4. Maintain a "source of truth" document.
Create a lightweight architecture document — we use a CLAUDE.md file in every project — that describes the system's structure, conventions, and constraints. Feed this to every agent at the start of every session. This is what prevents architectural drift: when every agent starts from the same shared understanding, their outputs stay consistent even without human coordination.
Update this document every time you make a significant decision. It takes five minutes and saves hours of debugging inconsistent agent output.
5. Rotate the "orchestrator" role.
On a three-person team, one person each day should be the orchestrator: the one who sets up agent tasks, batches reviews, and makes merge decisions. The other two focus on deep work — architecture, complex features, client communication. Rotate daily.
This prevents the burnout Willison describes. No single person is holding all the context all the time. And it forces knowledge sharing, because tomorrow's orchestrator needs to understand what today's orchestrator decided.
What this means for hiring and team structure.
If you're a CTO or founder building a team in 2026, this shift changes your hiring calculus:
Hire fewer, more senior engineers. A mid-level engineer running agents produces mediocre output at high volume — which is worse than no output, because someone senior has to review and fix it. A senior engineer running agents produces high-quality output at high volume. The seniority premium has never been higher.
Stop hiring for code output. Start hiring for judgment, systems thinking, and the ability to context-switch without losing quality. These are the skills that agents can't replace and that the new workflow demands.
Invest in process, not headcount. The teams that outperform aren't the ones with the most engineers or the most expensive AI tools. They're the ones with clear workflows, strong conventions, and the discipline to review before merging. Process is now a multiplier in a way it never was before.
The European advantage.
One thing we've noticed working with European startups specifically: the lean-team culture that's always been a feature of the EU startup ecosystem is now a genuine competitive advantage.
American startups scaled by hiring. European startups, constrained by smaller funding rounds and higher per-employee costs, learned to ship with fewer people. That muscle memory — building with three to five people what a US competitor builds with twenty — is exactly the skill set that agentic workflows reward.
If you've been running lean out of necessity, you're now running lean out of superiority. The infrastructure is finally here to make your small team the strategic advantage it always should have been.
Where this is heading.
The current moment is awkward. The tools are powerful but the workflows are immature. Most teams are in the "Willison at 11am" phase — getting enormous output but burning out from the cognitive load of managing it.
Within twelve to eighteen months, the orchestration layer will mature. Better review tools, smarter context management, more reliable agent output. The teams that figure out the human workflow now — while it's still hard and most teams are still fumbling — will have a compounding advantage that's difficult to catch.
The window to get this right is open. It won't stay open indefinitely.
Ready to build lean?
At Nortis, we build with the exact workflow described in this post — small senior teams, agentic tooling, tight review cycles, and the process discipline to ship fast without accumulating debt. If you're a founder or CTO thinking about how to structure your team for this new reality, we'd like to hear from you.