AI Shrinks the Team, Not the Problem

Every boardroom conversation about artificial intelligence in software engineering eventually arrives at the same number. Fewer people. The pitch is seductive: if AI makes each engineer three times more productive, a team of 30 can become a team of 10. The headcount drops, the salary line drops with it, and the quarterly results look fantastic.

This is a dangerous half-truth.

The Capability Trap

What AI genuinely replaces is capability. The ability to write code, generate test suites, scaffold services, produce documentation. These are real gains. A senior engineer with a competent AI copilot can produce working code at a pace that would have seemed absurd five years ago. McKinsey estimates a 20-40% acceleration in development tasks. GitHub's own data puts it higher for certain categories of work.

But capability was never the bottleneck. Not really.

The bottleneck in every engineering organisation of meaningful size is coordination. Who decides what to build. Who owns the outcome when it breaks. Who holds the context of why a system was designed this way, what constraints were navigated, what trade-offs were accepted. Who resolves the conflict when two teams need the same resource, or when the product roadmap contradicts the technical reality.

None of this is capability. All of it is human.

More Output, More Surface Area

Consider a team of 30 engineers reduced to 10 through AI-augmented productivity. Each of those 10 is now producing roughly what three engineers used to. The volume of code entering the system has not changed. The number of integration points has not changed. The surface area for bugs, conflicts, architectural drift, and unintended interactions remains the same, or grows.

But the number of people available to review that output, hold context about it, and coordinate its integration has dropped by two-thirds.

This is not a theoretical concern. It is an arithmetic one. The coordination burden per person has tripled.

The Interface Problem

Every AI agent introduced into a workflow creates a new interface. A boundary between human judgment and machine output. Someone has to validate what the AI produced. Someone has to decide whether the generated code fits the system's architecture or merely compiles. Someone has to catch the cases where the AI confidently produces something that is syntactically correct and semantically wrong.

These are new coordination costs. They did not exist before. They exist now precisely because the AI is good enough to be trusted most of the time, which makes the times it cannot be trusted harder to spot.

Interfaces are where systems break. This has been true since the first two software modules were connected. It was true when organisations adopted microservices. It is true now that the interface is between a human engineer and an AI agent. The technology on either side of the boundary changes. The fragility of the boundary itself does not.

Decisions Become the Bottleneck

When execution is cheap, decisions become expensive. This is not intuitive to most technology leaders because the industry has spent two decades optimising for execution speed. Agile, CI/CD, DevOps, platform engineering. All of it focused on reducing the cost and time of turning a decision into running software.

AI completes that project. Execution is now, for practical purposes, approaching commodity. The scarce resource shifts to the thing upstream of execution: deciding what to build, and in what order, and why.

This is a coordination problem. It requires understanding the business, the users, the technical constraints, the competitive landscape, and the second-order consequences of choosing path A over path B. No AI system does this reliably today. More importantly, no AI system is accountable for getting it wrong.

Accountability Does Not Distribute

A recurring fantasy in technology leadership is that responsibility can be spread thin enough to disappear. Shared ownership. Collective accountability. Blameless culture. These are well-intentioned ideas, but they collide with a structural reality: when something goes wrong, someone has to fix it. Someone has to make the call at 3am. Someone has to walk into the room and explain what happened and what changes.

AI does not do this. AI does not own outcomes. The engineer whose name is on the pull request owns the outcome, regardless of how much of the code an AI wrote.

Reducing the team does not reduce the number of things that can go wrong. It reduces the number of people available to own them.

The Real Cost Equation

Engineering Economics argued that every technical decision carries hidden costs. AI introduces a new variant of this principle. The visible cost, headcount, drops. The hidden cost, coordination per person, rises. For organisations that track only the first number, the savings will appear real until the system begins to degrade in ways that are difficult to attribute to any single cause.

The degradation is predictable. Architectural coherence erodes because fewer people hold the full picture. Response times to incidents increase because the on-call rotation is thinner. Knowledge silos deepen because there are fewer people to distribute context across. Technical debt accumulates faster because the AI generates code quickly but does not maintain it.

These costs do not appear on the headcount line. They appear later, in slower delivery, in production incidents, in the quiet departure of the remaining engineers who are now doing the coordination work of three people without the title or compensation to match.

What Does Not Change

The technology changes. The tools change. The speed of execution changes.

The coordination problem does not change. The need for someone to own the outcome does not change. The fragility of interfaces does not change. The cost of getting decisions wrong does not change.

Organisations that understand this will use AI to make their teams more effective without assuming they can make them smaller in proportion. They will recognise that a 10-person team producing the output of 30 needs better coordination structures, not fewer coordinators.

Those that do not understand this will cut headcount, celebrate the savings, and spend the next three years wondering why everything is slower than it used to be.

I'm Lloyd. I help Series A-C companies fix what's broken and ship what's stuck.

lloyd@codegood.co