Will Booth
Will Booth
Home

Will Booth

Senior Product Manager

All articles
AI & Tech·March 2026·6 min

The Post-Code Era: How AI is Dismantling the Traditional Software Team

When the mechanical act of writing code is no longer the bottleneck, the decades-old ratios that defined software development stop making sense. We are moving from a world of code scarcity to one of architectural abundance.

AI Summary✦ Powered by Claude

A Seismic Shift in Software Development

For decades, the shape of a software team was a given. You needed engineers — lots of them — because writing code was hard, slow, and expensive. PMs existed to manage the queue. Designers existed to stop engineers from making things ugly. The ratio was baked into every org chart, every hiring plan, every Series A pitch deck.

That world is ending. Not gradually — the way people predict paradigm shifts at conferences — but right now, in real teams, in real companies. AI coding tools have crossed a threshold where a single technically-literate person can do what once required a team of five. The implications for how we structure product organisations are not minor. They are total.

The Collapse of the Old Ratio

The traditional squad model — one PM, one designer, five to eight engineers — was never a principled decision. It was a response to scarcity. Code was the bottleneck, so you hired heavily toward it. The ratio made sense when the constraint was engineering capacity.

The Old Way: a cross-platform app takes a full team months of sprints. The New Way: a solo builder ships a production-ready MVP in three weeks for $350.

Remove that constraint and the entire justification for the ratio collapses. Teams that built around the assumption of engineering scarcity are now overloaded with capacity and underloaded with direction. The bottleneck has moved, but the org chart hasn't caught up.

The uncomfortable truth is that many engineering roles as currently defined are not long for this world — not because engineers are becoming less valuable, but because the definition of what an engineer does is changing faster than most organisations can respond to.

Everyone is a Builder Now

The most significant consequence of AI coding tools isn't that engineers become more productive. It's that the threshold for who counts as a builder has dropped dramatically. A PM who can articulate a problem clearly and iterate on a prompt is now able to ship working software. A designer with a grasp of component libraries can write production-ready UI. A data analyst can build their own tooling without filing a ticket.

This isn't theoretical. The 'vibe coding' movement — building software through natural language prompts, often without writing a single line manually — has produced working applications with real users. Cursor, Claude, and GitHub Copilot have fundamentally decoupled 'having an idea' from 'being able to build it'.

The consequence is not that professional software engineers disappear. The consequence is that the gap between having a product idea and shipping a version of it has collapsed from months to days. Every function in a company now has the potential to become a builder function.

What Elevates vs. What Compresses

Not everything in the software team is equally affected. Some roles are elevated by this shift. Others are compressed.

What gets elevated: architectural judgment, systems thinking, product taste, strategic clarity, and the ability to say no. These are the things AI cannot do. Deciding which problem is worth solving, which tradeoff to accept, which customer segment to disappoint in service of focus — these require human judgment grounded in context that exists nowhere in the model's training data.

What gets compressed: boilerplate code, CRUD operations, basic API integrations, documentation, unit tests, and any implementation task that can be described precisely in natural language. These aren't all the things engineers do — but they're a significant portion of what junior and mid-level engineers spend their time on.

  • Elevated: system architecture, technical judgment, product strategy, design taste
  • Elevated: stakeholder reasoning, ethical judgment, novel problem framing
  • Compressed: routine implementation, boilerplate, documentation, basic testing
  • Compressed: large coordination layers built to manage code scarcity

The New Gold Standard: The Three-Person Team

If the old gold standard was the two-pizza team, the new one is smaller and more deliberate. The optimal AI-era product team is three people: a Visionary PM, a High-Taste Designer, and a Technical Architect.

The Visionary PM owns the problem space. They know the user, the market, and the metrics. They're ruthless about what not to build, and they can articulate the strategy clearly enough that AI tools can execute against it. The High-Taste Designer holds the bar for the experience. In a world where UI can be generated in minutes, taste is the differentiator — someone who can tell the difference between something that works and something that's right. The Technical Architect understands the system deeply enough to make durable decisions about how the AI-generated code is structured, scaled, and maintained.

This trio can out-ship a traditional team of ten because they have zero coordination tax and total trust.

This isn't a team that works without AI tools. It's a team that's designed around them. The AI is the fourth member — always available, endlessly productive, and completely without judgment. The three humans provide everything the AI cannot.

Maintenance: The Hidden Challenge

There is a trap in the post-code era that optimistic accounts of AI development tend to skip over: what happens six months after you ship? AI-generated code can be difficult to reason about, inconsistent in its patterns, and hard to hand off. If the person who prompted it into existence moves on, what remains can be a working system that nobody fully understands.

This is not a reason to avoid AI tools. It's a reason to be more deliberate about the Technical Architect role. Someone needs to own the long-term coherence of the codebase — setting conventions, reviewing AI output critically, and ensuring that velocity today doesn't create a maintenance crisis tomorrow.

The organisations that win in this era won't be the ones who move fastest. They'll be the ones who move fast without accumulating technical debt that eventually makes moving fast impossible.

Strategy is the New Bottleneck

When code was the bottleneck, strategy felt like a luxury. You could get away with vague direction because there was always a sprint backlog to hide behind. In a world where implementation is cheap and fast, vague strategy is immediately and visibly costly. The gap between a clear strategic direction and a fuzzy one shows up in days, not quarters.

This is the deepest shift the post-code era brings. The ability to say 'no' with conviction, to hold a line under stakeholder pressure, to make a clear bet and not flinch — this was always what separated good PMs from great ones. Now it's what separates teams that ship meaningful things from teams that ship a lot of things that don't matter.

The scarcest resource in software is no longer the engineer who can write the code. It's the person who can decide what code is worth writing — and who has the clarity and the standing to make that call stick.

Thanks for reading.
—Will