AI does not simply shrink software teams. It moves the work up the skill curve. The winning shape is smaller, more senior pods that direct capable agents, keep quality built in, and sit on top of a platform strong enough to absorb the extra change.
First, what is a "two-pizza team"?
The phrase comes from Amazon. The rule of thumb: a team should be small enough that two pizzas can feed it, which in practice means a single-digit team size, commonly six to nine people. The logic is that small teams move faster, coordinate with less friction, and own their work end to end. Most engineering leaders already organize around some version of this idea, even if they have never used the name.
The one-pizza team is what happens when AI agents absorb a large and growing share of the execution. The output that used to require a two-pizza team now comes from a pod you could feed with a single pizza, about three to five people plus their agents. Same throughput, smaller team size, and a different role mix.
It is a useful frame because it is not a new concept. It is an evolution of one engineering leaders already trust. The hard part is not shrinking the team. It is choosing which seats stay, which change, and what the agents are actually allowed to do.
Illustrative composition. Team size flexes by workload, but the pattern holds: smaller, weighted senior, with shared product, design, and platform feeding the pod. Quality keeps its place in the role mix even as the team gets smaller, and the role levels up, from manual testing to senior quality engineering.
What changes first
The first move is not a new tool rollout. It is a new operating shape.
The pod needs a Forward Deployed Specialist who owns the line from discovery to shipped. It needs Forward Deployed Engineers who embed with the team and turn ambiguous business intent into production code. It needs an AI-native quality specialist who designs validation from the start. And it needs internal platform support: guardrails, CI/CD, test infrastructure, agent rules, and review paths that make higher change volume safe.
That is the one-pizza team in practice. Senior people direct. Agents execute. The platform absorbs volume. Quality moves earlier. The role mix changes before the org chart does.
Why the old org chart breaks
AI does not remove work. It relocates it.
The instinct is to read AI as a productivity dividend you can bank as team-size reduction. The data does not support that read. What AI reliably increases is the volume of change moving through the pipeline. In one study of more than 10,000 developers, pull requests merged nearly doubled.1 But more pull requests is not the same as more value. A controlled METR trial found experienced engineers using early-2025 tools were about 19% slower in mature codebases, while a 2026 follow-up found the effect much smaller and noisy.2 The payoff is real, but uneven. It depends on the system around the tool.
The honest claim is narrower and stronger: more change enters the system, and that change has to be reviewed, tested, and integrated before it ships. In Faros AI's 2026 telemetry study, median pull-request review time rose roughly fivefold as AI adoption climbed, bugs per developer rose 54%, and the rate of changes merged with no human review jumped about 31%.3 Google's DORA research found that higher AI adoption can improve individual productivity while reducing delivery stability when the underlying system is weak.4
Where the new load lands:
This is where the instinct to bank AI as team-size savings gets dangerous. The new load lands on the highest-judgment work in the cycle: reviewing, integrating, and validating a much larger volume of change. Cut those roles and you remove capacity exactly where the bottleneck is forming. The work did not disappear. It moved up the skill curve, which is the whole reason the team's shape has to change.
The new pod: who is on it and what they do
If the team gets smaller and the work moves up the skill curve, the composition has to change with it. The shape we build toward for a standard product pod is small, senior, and organized around a clear set of roles, with agents doing routine work beneath them and two shared functions feeding every pod. The point is not the team size. It is the mix.
Four ideas drive that shape.
Smaller, and deliberately senior
Shrink the two-pizza team toward three to five people plus agents, and weight the mix toward senior engineers. Not because AI only handles junior work. By 2026, capable agents can complete multi-file features, refactors, and test scaffolding,9 and METR's time-horizon work shows frontier models taking on longer software tasks over time.10 What agents still do not own is the judgment around that execution: framing an ambiguous problem, weighing system-level tradeoffs, and standing behind what ships. That judgment is the scarce input, which is why the pod skews senior.
One caution matters: do not strip the junior pipeline entirely, or you starve your future seniors. Protect a path in, on purpose.
Forward deployed, and AI-native by default
The pod is led by a Forward Deployed Specialist who owns the line from discovery to shipped and turns business intent into work the team and the agents can execute. The Specialist is paired with Forward Deployed Engineers who embed with the team and ship production code, rather than advising from the outside. The model started at Palantir and is now spreading across AI labs and cloud providers, including AWS's 2026 Forward Deployed Engineering investment.12 That is a signal: AI deployment is becoming an embedded engineering motion, not a tool handoff.
Every seat is AI-native, and we mean something specific by that. AI-native is not "has used an AI tool." It is an engineer who directs agents to amplify their own judgment, works fluently with the latest agentic coding tools, and reviews and owns every line that ships. The opposite, the engineer who outsources their thinking to a model and ships unreviewed output, is exactly who a serious screen filters out. We pressure-test for three things before anyone joins an engagement: real consulting delivery, production AI building, and current AI fluency. No unreviewed code. No AI slop.
Quality and product, built in rather than bolted on
Two functions have to move earlier. Embed a senior quality engineer from sprint planning forward so validation is designed in as output rises, not caught at the end. The quality-to-engineering ratio holds at roughly one to three even as the pod gets smaller, and the role levels up: manual testing gives way to eval design, validation, and AI-code review. World Quality Report 2025-26 names GenAI as the top skill for quality engineers, which is another way of saying the quality role is getting more technical, not less important.6
Product and design move up too. AI helps engineers more than it helps discovery, which quietly makes well-formed requirements the thing the whole pod waits on.
The platform underneath
The single highest-impact investment is a strong internal platform: the guardrails, CI/CD, test infrastructure, agent instructions, and review paths that absorb higher change volume safely. DORA's research is blunt about this: AI amplifies a good system and magnifies the dysfunction of a bad one.4 Most organizations now run internal platforms; the quality of yours is what decides whether AI helps or hurts.5
How each role changes
Read this as the direction of travel, not a layoff list. Most roles are being redefined and moved up the skill curve, a few are squeezed, and several clearly grow.
| Role | How it changes with AI | Direction |
|---|---|---|
| Junior developer | The work AI does best today; the entry pipeline tightens, yet it is still how you grow seniors. | Squeezed |
| Mid-level developer | Much of the hands-on coding is now automatable; the job shifts toward directing agents, reviewing output, and owning the result. | Redefined |
| Senior engineer / lead | Highest impact: directs agents, owns architecture, gatekeeps quality at review. | Growing |
| Product manager | More central: AI speeds the artifact work (specs, research synthesis, prototypes), which raises the premium on deciding what to build. Value shifts toward problem definition and prioritization. | Growing |
| Designer | Prototyping accelerates; the value moves to framing the problem and the handoff into build. | Redefined |
| DevOps / platform | Central to AI ROI; owns the guardrails and pipelines that must absorb higher volume safely. | Growing |
| Quality engineer | Levels up to senior: moves from manual testing to eval design, validation, and AI-code review. One role among several that grows, not the headline. | Growing |
| Forward Deployed Engineer | AI-native builder embedded in the team: directs agents, owns architecture, ships production code, and reviews every line. Now an industry-wide role, and Elios Certified across delivery, production AI, and current fluency. | Growing fast |
| Forward Deployed Specialist | Embedded lead who turns intent into delivery and operationalizes AI inside the team rather than advising from outside. | Emerging |
Why this takes a quarter, not a sprint
AI is an amplifier. It magnifies whatever your organization already is.
Mature teams with strong platforms, solid tests, and small batch sizes convert AI into compounding gains. Teams without those foundations watch AI magnify their dysfunction instead. That is why a serious adoption is a quarter of foundational work, not a one-month tool drop.
The gains are real, but they are uneven by task. McKinsey's early generative AI research showed large speedups on bounded development work, while METR's later field trial found experienced engineers slower with early-2025 tools in mature repositories.72 Expect months, not weeks, and expect the curve to bend only after the platform and guardrails are in place.
The staging is also how you de-risk the commercial commitment. Gate it. Prove gains in a pod or two, confirm quality held, then expand. You scale on evidence, not on faith in a tool.
The caveats that matter
A paper that only cites the upside is marketing, not analysis. Three caveats matter.
First, many productivity numbers come from vendors with a stake in the result, so treat them as directional. Second, quality signals are mixed: GitClear reports more duplication and churn as AI-generated code scales.8 Third, regulated industries still require independent validation, which puts a hard floor under how far QA can be reduced regardless of tooling.11
None of this argues against adopting AI. It argues for adopting it with instrumentation, guardrails, and a team shaped to catch what AI gets wrong.
