AI will make some teams smaller.

It will not make the work lighter.

There is a version of the future that has become fashionable in the software industry over the past year. Tiny teams. Powerful agents. AI-native development platforms. A product manager, a domain expert, a senior engineer, and a small group of coding agents producing software at a speed that previously required an entire delivery organisation.

It is not a silly idea.

Gartner has listed AI-native development platforms and multi-agent systems among its strategic technology trends for 2026, arguing these platforms may allow “tiny teams of people paired with AI” to produce more applications with the same developer capacity. Demos exist. Case studies exist. There are real companies shipping real software with structures that would have looked under-staffed three years ago.

So the tiny team story is real.

It is also misleading.

Because when people picture an AI-enabled tiny team, they picture the visible part: fewer humans, faster code generation, shorter feedback cycles, agents opening pull requests, tests running automatically, documentation appearing beside the change.

What they rarely picture is the weight around that team.

The platform. The controls. The context. The contracts. The evaluation harnesses. The deployment paths. The observability model. The review evidence. The operating model that decides what agents are allowed to do, what humans must judge, and what should be structurally impossible.

Tiny teams are possible only when the system around them is heavy enough to hold them.

The myth of the lightweight team

The lightweight team has always been part of technology mythology.

A few talented people in a room. No bureaucracy. No theatre. Clarity, taste, and the ability to decide without waiting for the organisation to catch up.

There is truth in the myth. Small teams do move faster. They have fewer handoffs and fewer people mistaking coordination for progress.

AI makes this story more attractive. If agents can draft code, inspect repositories, generate tests, explain unfamiliar systems, and open pull requests, then traditional staffing assumptions start to look heavy. Why hire when you can delegate?

The dangerous version of this thinking is when leaders confuse fewer people with less system.

A tiny team without a heavy system is not a high-performing unit. It is an overloaded group of humans surrounded by fast, plausible, semi-autonomous output that they cannot properly absorb.

The work does not disappear. It changes location.

Someone still has to define intent. Someone still has to decide what good looks like. Someone still has to understand the architecture, recognise which constraints matter, verify the output, and own the consequences when something goes wrong at 3am.

AI reduces the cost of producing change. It does not reduce the need to decide whether the change should exist.

This is the same point I made about agentic engineering from another angle: the engineer’s job is moving from production to judgment, and judgment is harder to fake.

AI compresses execution, not accountability

The most stubborn misunderstanding about AI in software delivery is that it mostly affects typing.

It does affect typing. It accelerates drafting, searching, explaining, refactoring, testing, and documenting. GitHub’s 2025 Octoverse describes AI and agents as some of the biggest shifts in software development in more than a decade.

But software engineering was never primarily typing.

It was a long chain of decisions disguised as artefacts.

A requirement is a decision about value. An architecture is a decision about trade-offs. A test is a decision about what must remain true. A deployment pipeline is a decision about risk. A runbook is a decision about what failure means and what should happen next.

AI helps produce all of these artefacts. The decisions remain.

This is why the phrase “tiny team” can mislead. It suggests the team itself becomes the unit of capability. In practice, the real unit of capability is the system the team operates inside.

A tiny team moves quickly when the engineering environment is already legible: clear ownership, clean repository structure, reliable CI, good tests, useful documentation, safe deployment paths, observable production systems, scoped permissions, paved roads.

Without those things, the team is not tiny. It is merely under-supported.

The agent does not remove the platform

There is a pattern in how technology gets adopted.

A new tool appears. It promises to make some older system unnecessary. For a while, everyone celebrates the bypass. Then the organisation discovers the old system existed for a reason.

Cloud did not remove infrastructure management. It changed its shape. DevOps did not remove operations. It redistributed operational responsibility. Platform engineering did not remove product teams’ work. It made the boundary between platform and product more explicit.

AI will follow the same pattern.

Agents will not remove the need for platforms. They will increase the need for platforms that agents can safely use.

A platform for human developers was already more than tooling. It was a curated path through complexity. A platform for human-and-agent teams has to do more. It needs to expose tools with clear contracts. It needs to provide context current enough to act on. It needs policies that are executable rather than aspirational. It needs sandboxed execution. It needs to produce evidence, not just output. It needs to know the difference between what can be automated, what can be proposed, and what requires human judgment.

The platform becomes the harness.

And the harness is the reason a tiny team can exist.

The small team becomes a control room

The AI-enabled team is often pictured as builders with superpowers.

A more accurate image is a control room.

The humans are not typing every instruction into every machine. They are watching flows, setting constraints, interpreting signals, intervening where judgment matters, and improving the system when the same failure appears twice.

The engineer becomes less of a person carrying bricks and more of a person designing the construction process. The product owner becomes less of a ticket writer and more of a translator of intent into executable contracts. The architect becomes less of a diagram producer and more of a keeper of system coherence.

This is not a smaller responsibility. It may be a harder one.

The team has to operate at a higher level of abstraction while still understanding enough detail to know when the machine is wrong. AI does not remove the need for engineering judgment. It makes weak judgment more dangerous, because weak judgment can now be amplified at speed.

DORA’s 2025 State of AI-Assisted Software Development reaches the same point from another angle: AI does not fix a team, it amplifies what is already there. If the system is clear, it amplifies clarity. If the system is confused, it industrialises confusion.

Verification becomes the scarce resource

The more AI produces, the more verification matters.

Stack Overflow’s 2025 Developer Survey found that more developers actively distrust the accuracy of AI tools than trust them. Only a small fraction reported high trust in the output.

That distrust is not backwardness. It is professional instinct.

A senior engineer knows that a clean diff can be architecturally wrong. A security engineer knows that a working implementation can still create exposure. An operator knows that a passing test suite can miss the failure mode that appears at 3am on a Sunday. Plausible is not the same as correct.

An agent making the same mistake at machine speed is not the same risk as a junior making it once. This is also why “human in the loop” is not a strategy on its own: a person at the end of a pipeline cannot meaningfully review what the pipeline produces faster than they can read it.

In a tiny AI-enabled team, verification stops being an afterthought. It becomes the operating model.

Every delegated task needs a way to prove it is done. Every agent action needs a boundary. Every generated change needs review evidence. Every repeated mistake needs to become a rule, test, template, or tool improvement. Every increase in autonomy needs a stronger feedback loop.

The future of software delivery may be less glamorous than the demos suggest. More tests. More contracts. More policy-as-code. More architecture decision records. More observability. More boring discipline.

The boring things become leverage.

The hidden organisation behind the tiny team

When a tiny team succeeds, it is easy to praise the team.

It is harder, and more useful, to look at the system that made the team possible.

A platform team already solved environment provisioning. A security team embedded controls in the pipeline. Someone maintained the repository instructions, test suites, and tool contracts that the agents rely on. Someone wrote down the architecture principles that prevent every choice from being a debate. An operations team built the observability and incident response that turns failure into information instead of catastrophe.

The tiny team is visible. The heavy system is mostly not.

This matters because leaders may try to copy the visible structure without funding the invisible one. They see three people and an AI tool. They do not see the platform investment, the quality model, the governance architecture, or the operational maturity that allows delegation to be safe.

Then they ask their own organisation to become “leaner” by removing people, adding AI, and leaving the underlying mess intact.

That is not transformation. That is compression. And compressed complexity has a way of reappearing as a 2am incident.

The new role of platform engineering

This is why platform engineering becomes more important, not less. I argued in March that the value of a platform is usually measured in the wrong place. AI makes that mistake more expensive.

The platform is no longer only a paved road for human developers. It is the operating substrate for mixed human-and-agent delivery. It has to answer questions that did not exist as concrete artefacts before:

  • What context does an agent need to perform this task safely?
  • Which tools can it call, and which environments can it touch?
  • What evidence must it produce alongside the change?
  • Which policies are enforced automatically and which require human approval?
  • Where does the agent escalate uncertainty rather than guess?
  • How are agent mistakes captured and turned into system improvements?

These are organisational design questions expressed through technology.

Signs your system is too light for the team you want

Before shrinking a team around AI, it is worth checking whether the surrounding system can hold it. A few signals that it cannot, yet:

  • New engineers cannot reach a working environment on their own in a day.
  • Architecture decisions live in people’s heads rather than in the repository.
  • The same kind of incident recurs and produces a fix, not a system change.
  • CI catches lint and unit failures but not policy, contract, or security breaches.
  • Ownership of a given service is ambiguous when something breaks.
  • Release rollback is a human decision made under pressure rather than a default path.
  • Documentation exists, but nobody trusts it enough to act on it without asking a person.
  • Agent output is reviewed by reading the diff, not by reading evidence the agent produced.

Each of these is a place where a tiny team would silently absorb risk that the wider organisation used to absorb for them. None of them are solved by adopting a coding agent.

What good looks like

A good tiny team does not feel heroic. It feels calm.

The work is clear before it is delegated. The agents operate inside known boundaries. The repository is navigable. The tests mean something. The deployment path is boring. The architecture has names. The policies are executable. The humans review evidence rather than hunting for context. The platform absorbs repetition. The system learns when agents fail.

There is still creativity and ambiguity. But the ambiguity is brought to the surface, where humans can decide what to do with it, instead of being smuggled into production through plausible-looking code.

That is the real promise of tiny teams. Not fewer people doing the same work under more pressure. Smaller groups operating inside better systems, with machines handling more execution and humans spending more time on intent, coherence, and learning.

The trade

Some organisations will use AI to justify smaller teams. Some will even succeed.

The ones that benefit most will not be the ones that reduce headcount, buy agent tools, and celebrate velocity. They will be the ones that understand the trade.

You can make the team smaller only if you make the system heavier.

Heavier with context. Heavier with contracts. Heavier with verification. Heavier with platform capability. Heavier with security boundaries. Heavier with operational feedback. Heavier with explicit judgment about what humans still own.

This is the part the productivity narrative misses.

AI may reduce the number of hands needed to produce software. It does not reduce the need for the organisation to know what it is doing.

The future of software delivery may belong to tiny teams. But only if they stand on heavy systems.