The End of the Large Software Team

The short answer

AI coding tools have not eliminated software teams, but they have shrunk what a team needs to be. A single skilled developer with AI copilots and agents can now build, ship, and maintain internal tools that once required three to eight engineers. That shift is quietly rewriting the calculus between building software in-house and renting it as SaaS.

This is not hype. It shows up in real numbers, real case studies, and real change in how companies staff projects. But the picture is messier than the loudest claims suggest, and the mess matters if you are the one deciding whether to build or buy.

What the data actually shows

Start with the controlled evidence, because anecdotes cut both ways.

Microsoft Research's randomized trial with GitHub Copilot found developers completed a coding task 55.8% faster than a control group, with the largest gains going to less experienced developers.¹ A separate analysis of 187,000 GitHub developers found that after Copilot access, developers shifted the mix of their time: core coding activity rose 12.4%, while time spent on project management tasks fell 24.9%. Peer collaboration dropped by nearly 80%.² In plain terms: less time coordinating with other people, more time just building.

That second finding is the real story behind "the end of the large team." Large teams exist partly to split up coding work and partly to manage the coordination overhead that comes from splitting up coding work. If a tool lets one person write, test, and ship without needing three reviewers and a project manager to keep everyone in sync, the coordination tax shrinks along with the headcount.

But not every study agrees, and the disagreement is instructive. METR ran a randomized trial with 16 experienced open-source developers working in codebases they knew well, and found that when they were allowed to use 2025-era AI tools, they took 19% longer to finish issues, not less. The developers themselves believed AI had sped them up by 20%. It hadn't.³

Both results can be true at once. AI tools tend to help most on greenfield work, unfamiliar codebases, boilerplate, and less experienced developers. They help least on complex, high-standard codebases where an expert already has deep context and where a wrong suggestion costs more to unwind than it saves. Internal tools, dashboards, and workflow apps sit much closer to the first category. Legacy financial infrastructure sits closer to the second.

Why this changes the build-versus-buy decision

For years, the default answer to "should we build this internal tool ourselves" was no, because building meant hiring, and hiring meant months of ramp-up plus ongoing maintenance headcount. That math is what made SaaS subscriptions the safe default for almost anything short of a core product.

AI-assisted development attacks the expensive part of that equation directly. If a single developer, working with a coding agent, can stand up an internal approvals tool, a reporting dashboard, or a lightweight CRM in weeks instead of a quarter with a team, the fixed cost of building drops below the multi-year cost of a SaaS subscription for many mid-complexity tools. The build option stops looking like a staffing project and starts looking like a weekend sprint with a maintenance tail.

This does not mean every SaaS tool becomes worth replacing. Complex, compliance-heavy, or deeply integrated systems still favor buying, because the risk of a lone builder missing an edge case is higher than the savings. But for the long tail of internal tools that companies rent mostly out of habit, the calculation has genuinely flipped for a meaningful slice of them.

The other side: shadow building and governance

There is a governance cost to this shift that gets less attention than the productivity headlines. As it becomes easier for one person to build real software, more of that software gets built outside official channels. A Cybernews survey of more than 1,000 US employees found 59% use AI tools that have not been formally approved by their employer, and among executives and senior managers that figure rises to 93%.⁴ Separately, IBM found that data breaches involving unsanctioned AI cost companies an average of $670,000 more than breaches involving approved AI tools.⁴

That is the shadow IT problem, but faster and with higher stakes. A spreadsheet macro built by a finance analyst is annoying if it breaks. An AI-built internal tool that touches customer data, runs on someone's personal API key, and has no owner once that employee leaves is a different category of risk. The tools that make one developer as capable as a team also make it easier for that developer to build something nobody else in the company knows exists.

The fix is not banning the practice. It is doing the boring governance work early: knowing what internal tools exist, who owns them, where the data lives, and what happens when the builder moves teams. Companies serious about owning their internal software rather than accumulating a pile of unmanaged one-off tools are starting to treat this as its own discipline, which is part of the thinking behind platforms like Remy that help teams keep AI-built internal software accountable rather than invisible.

What this means for team structure

The realistic version of "the end of the large software team" is not zero engineers. It is smaller core teams doing more, supported by fewer specialists, with AI absorbing the coordination and boilerplate work that used to require extra headcount. The MIT Sloan analysis of the Copilot data makes the case explicitly against cutting junior engineers to save money, since junior developers showed the largest productivity gains from AI assistance and lose the most from having it withheld.² The efficient team of 2026 is not team-of-one everywhere. It is smaller teams with AI doing the coordination work, plus a governance layer to keep track of what gets built.