This isn’t a cost-cutting story. It’s a clarity story.
Every CTO I talk to is asking some version of the same question.
Not out loud. Not in the all-hands. But in the quieter conversations — the ones that happen after the demo, after the board meeting, after the third consecutive sprint that somehow finished early and still left everyone feeling vaguely uneasy.
The question is: how many people do I actually need on this team?
It’s an uncomfortable question because it sounds like a cost-cutting question. Like you’re looking for an excuse to reduce headcount and use AI as cover.
But that’s not what’s driving it. What’s driving it is something more honest: the realization that the team structure we’ve been using for twenty years was designed for a set of constraints that no longer exist. And that rebuilding it for the constraints that do exist isn’t about doing more with less.
It’s about doing better with different.
The Classic Team and Why It Made Sense
The canonical Agile software team looked something like this:
- Product Manager — owns the roadmap, manages stakeholders, defines priorities
- Business Analyst — translates business needs into requirements, bridges PM and dev
- Scrum Master — facilitates process, runs ceremonies, removes blockers
- 4 Developers — build the thing
- QA Engineer — validates that what was built works as specified
Eight people. The exact composition varied, but the logic was consistent.
And the logic was sound — for its time.
Each role existed because a specific coordination cost was high. The BA existed because the gap between business language and technical language was wide and expensive to bridge informally. The Scrum Master existed because the overhead of running a disciplined Agile process was real. QA existed at the end because validation was a distinct skill that required dedicated focus. The four developers existed because writing code was slow, and the only way to produce more was to have more people writing it.
Every role was a solution to a genuine problem. The team of eight was a well-engineered response to the constraints of 2001.
The Agile Manifesto was written before the iPhone existed. Before cloud computing was mainstream. Before APIs were everywhere. Before AI could write production code.
The constraints changed. The team structure didn’t.
What AI Actually Changed
There’s a tempting but wrong way to think about what AI coding tools did to software development.
The wrong way: AI makes developers faster, so you need fewer of them.
The right way: AI eliminated the bottleneck of code generation, which means the bottleneck is now somewhere else entirely.
This distinction matters enormously for how you structure the team.
When code generation was the bottleneck, the answer was more developers. Four developers producing 200 lines per day gave you 800. Eight gave you 1,600. The math was linear.
With AI tools, code generation is effectively free. A single developer directing AI can produce what four developers produced manually. The bottleneck is no longer how much code gets written — it’s the quality of the judgment behind the code.
Who defines the right problem to solve? Who evaluates whether the generated solution is actually correct? Who maintains the coherent mental model of the system as it evolves? Who catches the edge case that the model generated confidently but incorrectly?
Those questions are answered by people, not models. And critically, they’re not answered by more people — they’re answered by better people, operating with more clarity.
This is why the restructured team is smaller but not cheaper in the way that word usually implies. You’re not replacing skilled people with a tool. You’re redesigning the team around where the skill actually matters now.
The Team of Three
PM/PO: One Person, Two Jobs
In the classic team, the PM and BA were separate roles because translating business requirements into technical specifications was a full-time job. It required constant back-and-forth, extensive documentation, and weeks of refinement before a developer could confidently start building.
AI collapsed that translation cost dramatically.
A PM/PO who can articulate what needs to be built in clear, specific terms can now use AI to generate user stories, acceptance criteria, and technical specifications in minutes rather than days. The output isn’t perfect — it never is — but it’s a 70% draft that can be refined in a fraction of the original time.
One person doing what used to require two, because the most time-consuming part of the BA role — the mechanical translation work — is now handled by AI.
But here’s the critical implication: that PM/PO needs to be better, not just faster. The BA used to absorb ambiguity over weeks of iteration. Now that ambiguity has to be resolved at the beginning, because AI will execute on unclear requirements at machine speed in the wrong direction.
Clarity is no longer a nice-to-have. It’s the single most important input to the entire system.
Senior Developer 1: The Tech Lead
This person writes less code. They make more decisions.
Their primary function is architectural judgment — maintaining the coherent mental model of the system, making the calls about structure and patterns that AI can suggest but not decide, and evaluating AI output against the reality of the specific codebase.
They’re also the quality gate. Not in the QA sense — we’ll get to that — but in the sense that their experienced eye is the last check before something goes to production. They understand not just whether the code works, but whether it fits, whether it’s maintainable, whether it’s creating a problem that will surface in six months.
This is the role that Amazon’s March 2026 outage made viscerally clear. When AI-generated code was deployed without adequate senior review, a six-hour outage on their main ecommerce site followed. The fix was to require senior sign-off on all AI-assisted deployments — an acknowledgment that senior judgment is not a bottleneck to be optimized away, but the critical quality layer that makes the whole system safe.
Senior Developer 2: The Builder
The second developer is the engine of the team — doing the bulk of construction work with AI as an active copilot.
What makes this role different from a traditional mid-level developer is the level of autonomy it requires. With no BA on the team, this person needs to read the PM’s requirements and convert them directly into implementation decisions without a translation layer. With QA restructured, they need to generate and implement tests as part of their workflow, not as a separate phase.
This is not a junior role. The leverage AI provides only materializes when the person directing it has enough experience to recognize when the output is wrong, when the approach is architecturally problematic, and when the model is confidently solving the wrong problem.
A junior developer with AI produces junior work faster. A senior developer with AI produces senior work at a fundamentally different scale.
What Happened to QA
The QA engineer’s disappearance from this team structure requires more explanation, because it’s the most counterintuitive.
Removing QA doesn’t mean removing quality. It means moving quality to where it actually belongs: the beginning of the process, not the end.
The classic QA model had a structural flaw that practitioners knew about but couldn’t easily fix: by the time a bug reached QA, the cost of fixing it was already high. The developer had moved on. The context was cold. More fundamentally, QA was testing against specifications that had been defined separately, by people who may have had different mental models of what “correct” meant.
The restructured model addresses this at the root.
Before development starts: The PM/PO defines test cases in functional, non-technical language. Not ticket descriptions. Scenarios with specific inputs and expected outputs. “When a user submits the form with an invalid email, they see this error message.” These cases are the definition of done, made explicit and unambiguous at the moment when changing them is cheap.
During development: The senior developer implements those test cases as automated tests using AI. The model generates 80% of the testing code; the developer reviews and adjusts. The feature and its validation are built together, not in sequence.
On delivery: The PM/PO does a functional walkthrough against the cases they wrote. Not a technical review — a business review. Does it do what I said it should do? If yes, it’s done. If no, the gap is clear and specific, because the criteria were clear and specific from the start.
No dedicated QA role. No bottleneck at the end. No blame game between dev and QA about whose interpretation was correct.
Quality isn’t removed from the process. It’s distributed through it — where it’s cheaper, faster, and more effective.
What the Numbers Actually Mean
A reasonable person might think: this team is 62% smaller. That sounds like a cost-cutting exercise with extra steps.
Let me be direct about what changes and what doesn’t.
What gets smaller: Headcount. Coordination overhead. The number of handoffs between roles. The time lost to miscommunication between BA and dev, between dev and QA, between Scrum Master and everyone.
What doesn’t get smaller: The quality of the people. The investment in those three individuals. The expectation of their output.
The senior developers in this model are not doing 33% of what four developers used to do. They’re doing more — significantly more — because AI has expanded what a skilled developer can execute on. The PM/PO is operating at a higher level of clarity and accountability than the PM + BA of the old model combined.
This team costs less in headcount. It costs more in individual quality. The trade is worthwhile because the leverage AI provides scales with the judgment of the person directing it — not with the number of people in the room.
A mediocre senior developer with AI is still mediocre. They’ll generate more mediocre code, faster, and approve it with confidence.
A great senior developer with AI is a force multiplier.
The New Bottlenecks You Need to Know About
I’d be doing you a disservice if I presented this as a clean upgrade with no tradeoffs. There are new failure modes worth understanding before you restructure.
The senior developer becomes the single point of failure. In the classic team, review responsibility was distributed. In this model, it concentrates. When your tech lead is depleted — and they will be, because operating as a judgment layer over AI-speed generation is cognitively intense — the quality gate weakens.
Clarity failures are catastrophic. In the classic model, ambiguous requirements were caught over weeks of BA iteration. In this model, they’re amplified. AI will execute on an ambiguous requirement at machine speed, in the wrong direction, before anyone realizes the spec was unclear.
System context lives in fewer heads. With a smaller team, architectural knowledge, historical decisions, the reasons certain patterns were avoided — all of it is concentrated in one or two people. When they leave, more leaves with them. Documentation isn’t optional in this model. It’s insurance.
Why This Is a Clarity Story, Not a Cost Story
The teams that implement this model as a cost-cutting exercise — reducing headcount without changing how the remaining people work, what they’re accountable for, or how requirements are defined — will fail. They’ll produce more code, faster, with more technical debt and more production incidents than the team they replaced.
The teams that implement it as a clarity exercise — asking hard questions about where judgment actually lives, restructuring roles around the new bottlenecks, investing deeply in the quality of the people who remain — will build something genuinely better.
Smaller teams have fewer alignment problems. Fewer handoffs mean fewer opportunities for requirements to get distorted in translation. A PM/PO who writes test cases before development starts produces clearer requirements than one who hands them off to a BA for interpretation. A developer who builds tests alongside features catches problems earlier and cheaper than one who ships to QA at the end of the sprint.
The classic team of eight was optimized for a world where execution was the bottleneck. The team of three is optimized for a world where judgment is.
AI didn’t just make teams smaller. It made clarity more valuable than it has ever been.
Diego Fiorentin is the founder of NextTo.ai, an AI consulting firm that helps companies implement AI operationally — business-first, not tool-first. If you’re thinking through what the right team structure looks like for your organization in an AI-assisted context, book a conversation →
