Throughout 2026, I have been hearing a familiar claim: AI-native tiny teams are the only way forward—the logical next step in how software gets built.
Management presentations often reinforce it with the same argument: throughput is up. So we can supposedly deliver the same amount of work with fewer people. That must mean optimisation (he-he).
Not so fast guys. I work with around 50 cross-functional teams in a large fintech environment, including teams responsible for critical core services. I have also tried to work with tiny teams—or at least to find a credible path for existing teams to become smaller without merely moving their workload, risk, and dependencies somewhere else.
Here is what I have found.
Disclaimer: This is not a universal model or a controlled study. It is a practitioner’s view, shaped by work in regulated, operationally demanding systems. I draw heavily on Team Topologies and Value Stream Mapping: make cognitive load visible, reduce unnecessary handoffs, and look at the full flow of value rather than the productivity of one local team.
Most importantly, a team only counts as “smaller and more effective” if the systems it owns remain operable: observable, supportable, secure, recoverable, and safe to change.
AI does accelerate the team locally. No evidence of e2e acceleration and prevalence of tiny teams though
A 2026 Management Science study found productivity gains from generative AI among developers. CircleCI’s State of Software Delivery 2026 reported 59% average year-over-year growth in daily CI/CD pipeline runs.
But no studies whatsoever refer to increases being attributed to smaller team sizes.
Moreover, productivity gains in feature branches != gains in master branches! In fact those declined 4%.
More AI-assisted output does not prove that a smaller team is more effective.
There's not enough evidence to treat tiny teams as the default target for every product area.
Four conditions decide whether a tiny team can work
1. The system is easy to change
AI performs best where context is current and discoverable: a greenfield product, a well-isolated service, clear interfaces, and automated checks. Mature systems carry historical decisions, undocumented constraints, integrations, and old incidents. Agents can inspect what the code does today. People still need to understand why it works that way.
2. Critical knowledge is shared
A three-person team becomes fragile when one person alone understands a critical integration, a regulatory rule, or the architecture. This is the bus-factor problem. Documentation and RAG help retrieve recorded knowledge; they cannot recover decisions that were never captured.
3. Failures are reversible
A small team can experiment quickly when a mistake is cheap to detect and easy to roll back. In finance, healthcare, or critical infrastructure, changes may require independent security, risk, legal, or compliance review. If these people must join every week, they belong to the practical delivery system even when they are outside the team on the org chart.
4. The supporting platform is strong
“Three people built a product” often means: three people built a product on top of a platform created by dozens or hundreds before them. CI/CD, test environments, observability, access controls, developer tooling, and specialist support reduce the coordination load that each product team would otherwise carry.
Use two stress tests before shrinking a team
One person disappears for a month.
- What decisions stop completely? The answer exposes the real bus factor.
AI doubles the flow of changes tomorrow.
- Where does the next queue form: review, testing, security, release, or user validation?
The second test matters because AI changes where the constraint sits. Code may be written faster, then review becomes the bottleneck. Improve review, and the queue can move to QA, security review, a release window, or product validation.
DORA calls this the verification tax: some of the time saved during generation shifts into verifying the AI-generated result. If the full path from idea to confirmed outcome barely changes, AI has accelerated one stage rather than delivery as a whole.
A better decision than “three people or ten?”
Do not set a team-size target first. Score the four conditions above from 0 to 2:
- 0 — barely constrains a tiny team;
- 1 — a noticeable risk;
- 2 — a serious constraint.
Run the conversation for ten minutes with the team during the retro. Then invest where the score reveals the constraint: documentation and shared ownership, test automation, platform capabilities, or faster access to specialised review.
AI expands the range of viable team configurations. It makes the ingredients of team size more visible: domain complexity, risk, the perspectives required to make safe decisions, and the quality of the system around people.
The question is what complexity people used to handle—and what has actually taken it over.
This is a practical adaptation of the full article: Tiny Teams With AI: What the Evidence Shows—and What It Still Doesn’t.
Top comments (0)