The 3-Person AI Pod: How to Save the Junior Engineer

AI is taking over the work that once trained junior engineers. If companies stop hiring them, they'll eventually run out of senior engineers. Here's a team structure that keeps the pipeline open.

Freddie Page · October 13, 2026

Executive Summary: Early-career software developers are the group most exposed to AI so far. One Stanford study found that employment for developers aged 22 to 25 fell nearly 20% from its late-2022 peak [1]. The tempting response is to stop hiring juniors and let a smaller senior team direct the agents. That saves money this year and creates a shortage of senior engineers later, because every senior engineer starts as a junior one. Handing juniors AI tools isn't enough on its own, either: in a controlled study, developers who used AI help while learning a new library scored 17 percentage points lower on a comprehension test than those who coded by hand [2]. I'm proposing a small, deliberate team structure: a three-person pod with a Primary, a Backup, and an Apprentice, where the Apprentice learns by doing real work under close review rather than by watching.

The Two-Pizza Team, Revisited

Amazon's well-known rule is that no team should be bigger than two pizzas can feed. In practice that means fewer than 10 people, with each team owning a single service end to end [3]. Amazon itself says the rule is less about size than about pushing ownership down to the team. Small teams spend less time coordinating and more time shipping.

AI changes the work inside the team more than the principle behind it. When agents handle scaffolding, tests, and boilerplate, a team needs fewer people typing and more people deciding and reviewing. Matthew Skelton and Manuel Pais, the authors of Team Topologies, expect teams may get somewhat smaller, but they're clear that the real limit is still cognitive load: how much of the system a team can hold in its head [4]. AI doesn't raise that limit, and as Part 2 argued, someone still has to understand what the agents write.

The more useful question is what a small team needs to stay good, and to keep producing the engineers it will need five years from now.

The Pipeline Problem

Entry-level developers are where the change shows up first. Using payroll records from ADP, the largest payroll provider in the US, Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen found that early-career workers in the most AI-exposed jobs saw a 13% relative decline in employment, even after accounting for company-level changes. For software developers aged 22 to 25, employment fell nearly 20% between late 2022 and July 2025, while older workers in the same jobs held steady or grew [1]. The authors say plainly that AI probably isn't the whole explanation, since a lot else changed in the economy at the same time. But the decline is concentrated on exactly the people who would have become your senior engineers.

The short-term logic is easy to follow. If one senior engineer with good agents can do what once took a senior and two juniors, why hire the juniors? AWS CEO Matt Garman's answer in 2025 was blunt: he called replacing junior staff with AI "the dumbest thing I've ever heard." His reasoning was that juniors are among the least expensive people a company employs and often the most comfortable with AI tools, and that if you stop hiring them, in ten years nobody will have learned anything [5].

There's a second problem. Juniors have always built judgment through the mechanical work: writing tests, fixing small bugs, and finding out the hard way how the system behaves. AI now does much of that work, and giving juniors AI doesn't automatically replace the learning. In an Anthropic study of 52 mostly junior engineers learning an unfamiliar Python library, the group with AI help averaged 50% on a follow-up quiz, compared with 67% for the group that coded by hand. The biggest gap was on debugging, and the AI group wasn't meaningfully faster. The participants who scored well with AI used it to explain things, not just to write the code [2].

So the work that trained juniors is going away, and AI used carelessly doesn't teach the skill that matters most: understanding what the code actually does.

The Three-Person Pod

The structure I'd use for AI-heavy work is three people, each with a clear job.

• The Primary. A senior engineer who owns the design. They write the specs, break the work into pieces small enough to review, and direct the agents. They're accountable for what ships.
• The Backup. A mid-level or senior engineer who reviews what the agents and the Primary produce, keeps the pod's context and checks current, and can take over at any time. With two people who fully understand the system, the pod has no single point of failure.
• The Apprentice. An early-career engineer who does real work from the first week.

The Apprentice is what makes this different from a smaller senior team, and it's the easiest role to get wrong. An apprentice who mostly watches seniors work won't learn to read code the way Part 2 describes, because watching someone debug doesn't teach you to debug. So the Apprentice should:

• own small, well-defined specs end to end, using agents, with the Primary reviewing;
• do the first review of agent-generated changes before the Backup sees them, and explain what they found;
• write tests and fitness functions, which forces them to learn what the system is supposed to do;
• take the first pass at bugs and production issues, with a senior close by.

The Anthropic study also points to how the Apprentice should use AI: to explain as well as generate, and to work through errors themselves before asking for the answer [2]. The pod can teach that habit, and the Primary can look for it in review.

A pod also gives the Apprentice something larger teams often don't: two experienced people paying close attention to their work every day. On an eight-person team, a junior can stay on the edges for months without anyone noticing. In a pod of three, someone notices within a week.

This is a proposal rather than something I've measured, which is why I'm laying it out in public.

What the Pod Needs From the Platform

A three-person team can't also build its own agent environment, test sandboxes, and guardrails. Part 1 argued that platform teams should treat agents as customers, giving them governed access to models, shared context, and golden paths. DORA found that the quality of an organization's internal platform is directly linked to how much value it gets from AI [6].

For a pod, that means:

• A safe place for agents to run, with test data and mocked services, so an apprentice's mistakes can't reach production.
• Shared context, such as decision records, instruction files, and a catalog of existing services, maintained once rather than by every pod.
• The checks from Part 2: contract checks, architecture checks, and security scanning on every change.

Skelton and Pais also have a useful point about how to spread new practices. Rather than doing the work for product teams, an enabling team should help them see what's available and where their gaps are [4]. That's a good model for sharing AI practices across pods without turning one central team into a bottleneck.

If You Don't Have a Platform Team

Many growing companies have a handful of engineers and no platform team at all. The pod still works at that size; the platform just gets smaller. One pod may be most of the engineering team, and the Backup often doubles as the person who owns the tooling. A few adjustments help:

• Set up the checks first. Automated contract, architecture, and security checks do more for a small team than new job titles.
• Keep shared context in the repository, where both agents and people read it.
• Use what you can buy. Managed CI, hosted test environments, and off-the-shelf security scanning cover much of what a platform team would otherwise build.
• Hire the Apprentice anyway. It's tempting to skip when the team is small, but small teams feel it most when a senior engineer leaves and nobody else knows the system.

The engineers who will run your systems in ten years are early in their careers now. Whether they're ready depends on whether someone gives them real work and close review today.

This is Part 3 of a 3-part series on the operational realities of AI-native engineering. Part 1: The Verification Tax: Faster AI Code, Less Stable Delivery. Part 2: The Orchestrator's Fallacy: Why You Still Need to Understand the Code.

References

1. Brynjolfsson, Chandar & Chen, "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence," Stanford Digital Economy Lab (August 2025): ADP payroll data on employment by age and AI exposure.
2. Anthropic, "How AI assistance impacts the formation of coding skills" (January 2026): randomized study of 52 mostly junior engineers.
3. Amazon Web Services, "Amazon's Two Pizza Teams": Amazon's description of the team model.
4. Thoughtworks Technology Podcast, "Organizational design and Team Topologies after AI," with Matthew Skelton and Manuel Pais (September 2025): the Team Topologies authors on team size and cognitive load with AI.
5. The Register, "AWS CEO says using AI to replace junior staff is 'Dumbest thing I've ever heard'" (August 2025): coverage of Matt Garman's interview with Matthew Berman.
6. Google Cloud DORA, "State of AI-assisted Software Development" (2025): survey of nearly 5,000 technology professionals.