Sign in Subscribe

The Two-Person Team Is the New Ten-Person Team

The Two-Person Team Is the New Ten-Person Team

For most of my career, software organizations scaled in fairly predictable ways.

As products became more complex, teams grew alongside them. Frontend teams, backend teams, platform teams, DevOps, QA, infrastructure, security, product, design. More people meant more specialization, and more specialization was supposed to increase throughput.

Sometimes it did.

It also created coordination overhead, communication drag, process layers, ownership ambiguity, and organizational inertia. Anyone who has spent enough time inside growing engineering organizations has seen this happen. At a certain point, a meaningful amount of engineering energy starts getting consumed by the organization itself.

For a long time, that tradeoff felt unavoidable. I’m not sure it is anymore.

Over the last year, while building TattooSnap, I’ve repeatedly had moments where the amount of output coming from a very small engineering surface area felt almost absurd compared to what I would have expected even a few years ago. Not because AI replaces engineers. And definitely not because “vibe coding” suddenly works at scale. If anything, I’ve found the opposite to be true. The teams getting the most out of AI-assisted development are usually the teams with strong engineering fundamentals already in place. Good architecture. Clear boundaries. Testing discipline. Engineers who understand why the system works, not just how to make the code compile.

AI dramatically increases leverage, but it also accelerates instability when architecture, testing, and operational discipline are weak.

Generating code has never really been the difficult part of software engineering. The difficult part is maintaining coherent systems over time. Understanding tradeoffs. Recognizing ambiguity. Designing boundaries that survive iteration. Knowing when something is technically correct but operationally dangerous. That layer becomes more important as implementation speed increases.

While building TattooSnap, I intentionally kept the stack relatively small and operationally lightweight: React Native, TypeScript, Firebase, serverless infrastructure, CI validation, and aggressive iteration cycles. AI tooling became deeply integrated into the workflow very early on. The biggest shift was not simply writing code faster. It was collapsing the cost of experimentation. Ideas that previously might have required several days of implementation and validation could suddenly be explored in an afternoon. Boilerplate largely disappeared. Refactoring became less painful. Documentation improved. Repetitive implementation work shrank dramatically. The bottleneck moved upward.

The limiting factor stopped being raw implementation speed and became system design, product judgment, architecture, and decision-making clarity. I increasingly suspect a lot of organizations are still staffing for a world where implementation itself was the bottleneck.

Some of this honestly feels a little surreal after spending years inside organizations where spinning up a new service could somehow require three meetings, two approval chains, and a Jira epic before anyone actually started building anything. A lot of the current AI conversation focuses on replacing developers or reducing headcount. I suspect that framing misses the more important shift entirely.

I don’t think AI eliminates the need for experienced engineers. I think it amplifies the impact of experienced engineers.

When iteration speed increases, weak systems fail faster. Poor naming spreads faster. Ambiguous ownership compounds faster. Bad abstractions multiply faster. AI doesn’t remove technical debt. If anything, it increases the interest rate. I’ve watched organizations spend weeks or months coordinating work that a small aligned team can now prototype in a day.

That doesn’t mean large organizations suddenly become obsolete. Complexity, compliance, operational risk, and coordination across business domains are still very real problems. But organizational size itself is becoming a less reliable proxy for engineering capability. In some environments, it may even become a disadvantage. The organizations that thrive in this environment are probably not going to be the ones generating the most code. They’ll be the ones capable of maintaining clarity while moving quickly.

That means the fundamentals still matter:

  • clear architectural boundaries
  • testing discipline
  • observability
  • CI validation
  • operational maturity
  • fast feedback loops
  • strong technical judgment

None of that became less important because code generation improved. If anything, those things became more important.

I also think we’re going to see a growing advantage for smaller, highly capable engineering teams. A small, aligned team with strong systems thinking can now move at a pace that previously required significantly more organizational overhead.

That changes the economics of software development in ways I don’t think many companies have fully absorbed yet. As implementation becomes cheaper, clarity becomes more valuable. The future may not belong to the largest engineering organizations. It may belong to the smallest teams capable of building coherent systems without collapsing under their own velocity.