AI-native tiny teams: is it viable or just pure hype?

Marat Kee — Mon, 24 Aug 2026 19:06:56 +0000

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.

How AI is Shrinking the SDLC: in greenfield, brownfield, regulated industries

Marat Kee — Wed, 01 Apr 2026 11:07:50 +0000

How AI is Shrinking the SDLC

I work with experimental AI-first teams, exploring how agentic engineering impacts Lead Time. Here's what I'm seeing.

And unlike some people say, I think that SDLC is not killed by agents. I think it compresses into something more lightweight.

One person with AI can generate what used to require a team. The bottleneck shifts from writing code to validating it.

But this isn't uniform across all contexts. Greenfield, brownfield, and regulated environments each compress differently.

Scenario 1: Greenfield / MVP / Internal Tools

Context: New project, no users, low error cost, speed is critical.

What changes:

Tiered Code Review: security-critical code (auth, crypto) — 100% human review; everything else — automated checks + spot-check
Observability as primary safety net (canary releases, auto-rollback)
Iterations are now significantly faster, to the point where customer gets updates during the demo

Important: even in greenfield, AI code contains 1.7x more issues. Skipping review entirely is risky.

How to ensure we didn't make it worse:

Lead Time ≤ 1 day
Deployment Frequency > 1/day
Change Failure Rate within DORA "Good" threshold (0-15%)

Scenario 2: Brownfield / Existing Product

Context: Real users, established reputation, existing technical debt. Errors cost money.

What changes:

We need a tiered approach by risk:

Code Type	Human Review	Examples
Security-critical	100% senior review	Auth, payments, PII, crypto
Business logic	30-40% peer review	Features, API, data flows
Utility	Spot-check + automated	Tests, docs, configs

Found interesting stats: Per LinearB 2026 Benchmarks, AI PRs merge at 32.7% vs 84.5% for human code — most require rework. Per my experience, we accept only 18% of 100% ai written PRs.

How to ensure we didn't make it worse:

Code Review Time doesn't grow (despite more PRs)
Defect Rate stable or declining
SLA/SLO maintained

Scenario 3: Regulated Industries (Fintech, Healthcare, Insurance)

Context: Compliance requires human accountability. Audit trail is mandatory.

What changes:

100% audit trail for all AI-generated code: who requested, what was generated, who approved
AI accelerates stages, but humans make decisions — this is a regulatory requirement (FDA, PCI-DSS, HIPAA)
Stages can merge, but the artefacts are still reqiured for audit

How to ensure we didn't make it worse:

Change Failure Rate doesn't increase
Compliance review time gradually decreases
Audit trail complete and verifiable

The Bottom Line

There's no universal "new SDLC" with only agents and zero humans. Reality is a spectrum depending on project context.

Besides the context, team and its culture dramatically influence whether AI makes it better or worse. It accelerates good practices and bad practices equally. Get your quality gate together and embrace the result.

DEV Community: Marat Kee

AI-native tiny teams: is it viable or just pure hype?

AI does accelerate the team locally. No evidence of e2e acceleration and prevalence of tiny teams though

Four conditions decide whether a tiny team can work

1. The system is easy to change

2. Critical knowledge is shared

3. Failures are reversible

4. The supporting platform is strong

Use two stress tests before shrinking a team

A better decision than “three people or ten?”

How AI is Shrinking the SDLC: in greenfield, brownfield, regulated industries

How AI is Shrinking the SDLC

Scenario 1: Greenfield / MVP / Internal Tools

Scenario 2: Brownfield / Existing Product

Scenario 3: Regulated Industries (Fintech, Healthcare, Insurance)

The Bottom Line