// blog
Nine People for Twelve Months, or Three for Three: An AI Team vs. a Traditional Team
On the same product rewrite, a traditional nine-person team is estimated at about twelve months; three senior engineers directing AI coding agents are on track for about three. That’s 108 person-months against 9. It works because the project fits: unfamiliar legacy code, a fresh architecture, and senior people who check every line. Without written specs, automated tests and security scans, the same speed just produces risk faster.
A case study in what changes when AI writes most of the code, and what doesn’t.
Picture a software company that needs to rebuild its flagship product. The code is years old, the business rules are buried in it, and thousands of customers depend on it every day. The engineering estimate comes back: a full team, about twelve months.
Now picture a second option. Three senior engineers, directing AI coding agents, tracking to finish the same scope in about three months.
That’s the choice facing Brightline Software, a fictional company I built this case study around. The schedule numbers, though, are modeled on a real rewrite in progress today. After thirty years in software, this is the biggest shift in how teams work that I have seen.
Open the full case study, with diagrams and charts →
Meet the two teams
Team Atlas is the team most of us have worked on: a product owner, a Scrum master, an architect, five developers and a QA engineer. Work moves through two-week sprints and a chain of hand-offs, from story to code to review to testing to release.
Team Forge looks nothing like that. Three senior engineers write detailed specs, run several AI agent sessions in parallel, and review every line the agents produce. Tests are written alongside the code, and an automated gate of tests and security scans blocks anything that fails. There’s no Scrum master, no separate QA role, and almost no coordination overhead.
The real difference is where human time goes. Atlas spends it writing code. Forge spends it specifying what to build and checking what got built. Agents draft; senior engineers edit.
Where the time and money go
On round-number assumptions, the gap is dramatic:
| Team Atlas | Team Forge | |
|---|---|---|
| People | 9 | 3 |
| Duration | ~12 months | ~3 months (projected) |
| Person-months | 108 | 9 |
| Total cost (USD) | ~$1,620,000 | ~$153,000, incl. ~$18,000 of AI tools |
The cost math assumes $15,000 per person-month fully loaded and about $2,000 per engineer per month in AI tools. Push those numbers around however you like; the ratio barely moves. Even if Forge’s schedule doubles to six months, it still uses under a fifth of Atlas’s person-months.
The savings aren’t even the biggest win. Shipping nine months earlier means earlier revenue, earlier customer feedback, and retiring the old system three quarters sooner.
The catch
If this sounds too good to be true for every team, that’s because it is. The research says AI is an amplifier, not a guarantee.
- Google’s 2025 DORA report surveyed nearly 5,000 technology professionals and found 90% now use AI. Adoption is linked to higher delivery throughput, but AI magnifies weak practices just as much as strong ones.
- Only 3% of developers report high trust in AI-generated output, in the 2025 Stack Overflow Developer Survey.
- In a randomized trial by METR, experienced developers working in code they knew well took 19% longer with early-2025 AI tools, while believing they were about 20% faster. METR’s February 2026 follow-up with late-2025 tools measured a speedup instead, which the authors themselves call weak evidence.
- Veracode tested more than 100 models and found security flaws in the code for 45% of tasks.
So why does Forge work? Because the project fits the favorable profile. It’s a rewrite of unfamiliar legacy code, onto a fresh architecture, by senior people who check instead of trust. Forge’s real risk isn’t speed. It’s plausible-looking code that hides a security hole or a wrong business rule, and three people reviewing a firehose of output. The guardrails a traditional team treats as good practice become mandatory.
When the traditional team still wins
I’d still pick a team like Atlas for:
- Regulated or safety-critical systems, where every line needs traceable human authorship.
- Large, tightly coupled codebases that three people can’t hold in their heads.
- Experts in code they know deeply, exactly where METR measured the slowdown.
- Change programs where people, not code, are the bottleneck.
- Growing new engineers. A seniors-only team builds no talent pipeline, and the industry still needs one.
What I’d tell any engineering leader
- Staff for judgment, not keystrokes. Your most senior people’s review is now the quality gate.
- Build the guardrails first. Tests, static analysis and security scanning must exist before agents produce code at volume.
- Treat the spec as the product. The quality of your written requirements sets the quality of the output.
- Measure; don’t trust the feeling. Track cycle time, escaped defects and rework. The METR study shows how wrong gut feel can be.
- Pilot on something bounded. A rewrite with clear scope is ideal; a sprawling legacy monolith is not.
- Keep a human accountable for every merge. AI drafts. A named engineer owns what ships.
The full case study, with the team diagrams, the delivery loops, the timeline and the risk table, is here: AI team vs. traditional team →. The way we plan every project, from the goal to an estimate split into AI time and Dev time, is free to copy.
Thinking about an AI-assisted rewrite of your own product? I help teams plan and run them. Get in touch.
Brightline Software, RosterPoint and everyone named in this case study are fictional. Cost figures are illustrative.