Beyond the two-pizza team rule

For many decades, the core aspects of software development had not really changed. Sure we added new languages and platforms, moved to the cloud and adopted agile. But the core idea, famously introduced by Amazon [1], of the two-pizza team had held for many, many years:

“The concept of Amazon’s two-pizza teams is straightforward: no team should be big enough that it would take more than two pizzas to feed them. Putting aside the number or the nature of toppings (we don’t have time and space to solve the “does pineapple belong on pizza?” debate here), ideally, this is a team of less than 10 people.”

But with the introduction of powerful agentic AI coding tools, small teams can now do even more than larger teams did in the past. AI impacts everything from how we work, what different people do, how we hire people, and how we structure our teams. Let’s see how agentic AI development challenges some of our core tenants of software development and how it changes software development organizational design. This is based on my research and what I’ve personally witnessed.

The SDLC is changing

AI is changing what the software development lifecycle looks like. Code generation is now cheap and abundant. Humans still have very important roles to play, however, but their responsibility has moved from “doing the thing” to “providing judgement and decision making”.

Roles are changing

In addition to the SDLC changing, so are team roles. Because code creation has become cheap, team members can now do more of their traditional responsibilities and take on new ones. The 8-10 person team can now be replaced with a 3-5 person team with dotted lines to managers, staff engineers, designers, DevEx engineers, etc. The small team can still own a stream of work end-to-end, including operations, and do so with fewer people with the help of AI. Within the team, what each person does is also changing because of the assistance of AI.

Core team

• Product Owners: fewer in number, broader in scope. They now own end-to-end outcomes and roadmaps
• Product Managers: shift to being more “builder PMs” that blur the line with engineers
• Junior devs: less than 20% of developers, they can still drive simple features and help senior developers with test design, observability, and verification. Ensure the culture emphasises deliberate training to help them grow.
• Mid-level devs: roughly 60% of developers, they guide the AI through small, incremental changes and ensure they understand what is changing
• Staff/principal devs: 20% of developers, they own the breadth of work instead of depth and ensure teams are aligned and making right decisions. They focus on keeping documentation (the AI “context layer”) up to date and they need to build the validation layer for non-functional and architectural decisions (e.g., have a test to enforce that services must not query each other’s database directly).
  • You need at least 1 staff/principal developer per 3 pods minimum, non-negotiable. Fewer than this, they get spread too thin and the architecture starts to crumble.

Dotted lines

• People leader: 1 PL can support 10-14 devs and is responsible for coaching, quality management, dependency management and conflict avoidance. They are no longer in charge of coordination - that responsibility moves to staff/principal engineers.
• QA/test engineer: The AI now does the test authoring. QA now owns deciding what is important to test, ensuring proper coverage, deciding when something is ready to ship. Supports multiple teams.
  • Note: Tests written by the same model that wrote the code inherit its blind spots, an all green test suite isn’t enough. QAs ensure tests exercise service boundaries, golden path end-to-end journeys, architectural fitness. QAs may do adversarial and exploratory testing, test reviews.
  • You need 1 QA/test engineer per 10 developers minimum once the team gets large, although in the early days it can be done by a senior engineer with a test mindset
• Designers: fewer in number, they now own overall look and feel and UX differentiators.
• DevEx/Platform engineers: their responsibility is to build paved roads, the agent runtime, the AI identity, evaluation framework, model routing, etc. Think CI/CD plus model access and routing, an MCP/tool gateway, context and retrieval services, agent identity and permissions, eval infrastructure, agent observability, and token/cost governance
• Security: Handles AppSec, AI supply chain, etc. You need 1 per 40 devs after the org gets large.
• Data engineer: owns AI accessible internal data, supports teams in making data accessible
• AM/ML engineer: defines product AI features, supports internal agent platforms. Can be handled by a dev before the data foundation is ready and the team has to support multiple product lines. They define our evaluation strategy to ensure we know AI features are correct.

Hiring is changing

Another area that is radically changing in the AI era is recruiting and hiring. It’s no longer as important to hire for very specific, deep expertise. Paired with AI, engineers are becoming more full-stack, not more specialized. Someone who was backend-only can now credibly work across frontend, database, and infra with AI filling the gaps.

So instead of hiring for very specific skills, it’s now important to hire for judgment, system design, and debugging under uncertainty. Syntax fluency and framework trivia have lost their value. We need to evaluate how well someone can add value in the new SDLC (see chart above).

So our interviews need to abandon Leet-code tests or whiteboard algorithms (to be fair, these were bad ways to interview even before AI). Interviews need to change to test judgement and decision making. For example, you could have a candidate work through a structured code review of a plausible-but-subtly-wrong AI-generated diff, or give the candidate the prompt and AI answer and have them spot problems or decide which AI-generated option is best.

We also need to talk about junior developers. In the mad panic of the early AI years, companies were stopping junior hiring. This is a mistake.

The structural problem, articulated well by Alasdair Allan at QCon London is that AI simultaneously stunts skill formation, transforms work into supervision, and slows hiring at the entry level. These trends are in conflict because supervising and guiding AIs require the exact judgment that the traditional junior-to-senior pipeline produced. Organizations racing to adopt agentic tooling and simultaneously stopping junior hiring are cutting off the pipeline that produces the people capable of supervising them. In 5 to 10 years, companies will find that they no longer have anyone capable of guiding the AIs with quality. On the other hand, organizations that invest in maintaining the hiring and training pipeline will still have senior engineers in a decade.

Org Design Scenarios

Taking all these changes together, what does this all mean for structuring software organizations? Let’s play out a few hypothetical situations.

Five people (early stage startup)

Shape: One pod. No managers. No layers. No specialization by function.

Key aspects:

• Seniority: Heavily senior. Every person must be able to verify agent output in at least two domains. There is no room for someone who can only produce.
• What AI does here: Nearly all first-draft implementation, scaffolding, test generation, migrations, documentation, and infrastructure-as-code. Effective capacity is 5 humans plus a large number of concurrent agent sessions. This is the size where the productivity gains are largest because the work is greenfield, small codebase, no legacy. This is also where the temptation to over-build is correspondingly greatest, so manage scope closely.
• What humans do: Talk to customers. Decide what to build. Verify everything that ships. Hold the architecture in their heads while it is still small enough to fit.
• Explicitly do not hire: a QA engineer, a DevOps engineer, an engineering manager, or a data scientist. At this scale, senior devs perform all roles. Ensure documentation is kept up to date (“context as infrastructure”) so all architecture decisions, conventions, design changes, etc are documented. Tests are critical as the final verification layer
• Beware: the vibe-coded foundation nobody fully understands. This will lead to a “we can’t move fast anymore” situation within a year. Make sure teams know what the AI is building.
• When to grow: when the founder/lead is spending more than half his week doing reviews

Ten people (small established startup)

Shape: Two stream-aligned pods of 3-4 with dotted line to PM and Designer. Still no engineering managers; the group is led by a working Head of Engineering plus tech leads.

Key aspects:

• PM: Implementation is no longer the constraint; intent is. A pod that ships the wrong thing twice as fast is worse off than before.
• Designer: as the product evolves, design becomes a critical factor in success. A designer ensures overall UX consistency, mentors teams, and does UX research with customers supporting the PM.
• Platform owner responsibility: At this scale we don’t need dedicated capacity. Instead, we need a senior engineer who takes ownership of CI/CD, the golden path, and quality gates as roughly a third of their job.
• Written specs become mandatory: Two pods cannot hold the same mental model ADRs start. The agent context layer becomes a maintained artifact with a named owner.
• Ownership boundaries become explicit: Two pods running agents into one codebase will produce duplicated abstractions within weeks unless module ownership is written down.
• On-call starts: A real rotation with a runbook. This establishes the practice and culture before you probably need it.
• New meetings: weekly architecture sync (30 minutes, both pods) and a standing “duplication and refactor” meeting to keep the codebase clean.
• Beware: review bottlenecks lead to merging with less scrutiny. Look for ways to add automation without removing the human-in-the-loop from critical reviews.

Twenty-five people (mid-level organization)

This is where an AI-augmented organization acquires the coordination profile of a 50-person org from a few years ago. The organization needs to make structural investments or they will have an expensive mess in a year or so.

Shape: 3-4 stream-aligned pods of 3–5, one enabling function, one to two managers. Each team should own its own specific services/modules including their operation. Without this, agents will happily produce cross-cutting changes at a rate no human can integrate.

Key aspects:

• Platform team: Agents need consistent environments, reliable pipelines, deterministic builds, and governed access to tools and data. They need them before the org is large, because agent output volume arrives before headcount does. The platform function here owns CI/CD and environments, the paved road, and the agent harness (sandboxes, MCP servers and tool access, credential brokering, model routing, spend visibility).
• Agent governance basics: Introduce the concept of agent identities distinct from human credentials. Ensure AI identifies have scoped permissions and audit trails. Do frequent inventories and audits. You do not need a security hire yet; teams own their security. Schedule a real external penetration test annually.
• Quality engineering: one senior person, not a manual tester. This person owns the risk model, the coverage strategy, the contract-test discipline at service boundaries, and increasingly reviewing the tests the machines wrote.
• A deliberate early-career junior cohort. 2–3 people, hired as a cohort rather than individually, with a structured training on fundamentals. Think of it like a medical residency: they do basic tasks (aka simple features)and manual work which, while inefficient, forces learning. Measure the growth of their understanding, not their velocity (which will be low). This costs real money but pays off over time.
• Beware: over specialization. There is still no need for a QA team, AI team, or thick management layer yet.

Fifty people (growing org or sub-org of a larger development group)

This is product development at scale and we need to have all the roles filled out to ensure sustainability.

Shape: ~2 domain groups, each with 3–4 pods, plus centralized enabling functions. Two management layers.

Key aspects:

• Two platform tracks: split the platform team into two areas of responsibility. Track one is the internal developer platform now itself built with AI assistance. Track two is the platform for the AI: agent runtime and lifecycle, identity and credential brokering, evaluation harnesses, model routing and fallback, spend attribution and controls, and the audit surface.
• Management bifurcation: split the EM role explicitly: EMs own people, growth, and flow. Staff/Principal engineers own technical direction and standards.
• Assign Architecture ownership: Empower a small staff-level group to own ADRs, the service catalog, overall standards, and fitness functions (executable architectural constraints that run in CI). This is not a review board that blocks work. This team supports the product engineers.
• Dedicated security owner: With the enormous commit velocity and corresponding risk of security findings, the “everyone owns security” model stops working. The first hire should be an application security engineer who also owns agent permissions and AI supply chain.
• Beware: spreading managers too thin. Above the 1:14 ratio, they won’t be able to coach developers, developer growth will stall, and bad habits will creep in.

What comes next?

As AI models improve, it’s possible we will see more SDLC evolution, more role compaction, and even smaller, more cross-functional teams. Truthfully I think we’re reaching a plateau where future improvements will be gradual not revolutionary. But it’s definitely been exciting to watch and I can’t wait to see how things continue to evolve.