Case study

Nine people for twelve months, or three for three

On the same product rewrite, a traditional nine-person Scrum team is estimated at about twelve months and 108 person-months. Three senior engineers directing AI coding agents are on track for about three months and 9 person-months. The gain holds only with guardrails: written specs, automated tests and security scans, and a human review of every line. The company in this case study is fictional.

Last updated

Team Atlas: 9 people, 12 monthsTeam Forge: 3 people + agents, ~3 months

Brightline Software needs to rebuild RosterPoint, its workforce-scheduling product, and fold four products into one platform. CTO Rachel Moreno compares two ways to staff it: a traditional Scrum team, and a small senior team directing AI coding agents.

4×faster to ship (12 → about 3 months)
12×fewer person-months (108 → 9)
~$153kagainst ~$1.62M total cost (USD, illustrative)
9 moearlier to market
Fictional company

Brightline Software, RosterPoint, Brightline One and every person named here are fictional. The schedule figures are modeled on a real rewrite in progress; Team Forge's three months is a projection, not a shipped result. Cost figures are round-number assumptions.

The two teams

Atlas spreads the work across specialists. Forge puts the judgment in three seniors.

Team Atlas, led by engineering manager Daniel Ortiz, is a conventional cross-functional Scrum team. Team Forge, led by principal architect Maya Chen, is three senior engineers who write specs, run several agent sessions in parallel, and review every line the agents produce.

Team Atlas has nine people in specialist roles; Team Forge has three senior engineers directing AI coding agentsTeam Atlas · 9 peopleProduct ownerScrum masterArchitect / tech leadBackendBackendBackendFrontendFrontendhand-offQA engineerPeople write the code; work moves by hand-offs.Team Forge · 3 people + agentsMaya Chen · architect and orchestratorwrites specs, owns the architecture and the test strategySenior engineerbackend reviewSenior engineerfrontend reviewAI CODING AGENTS · PARALLEL SESSIONSAPI and servicesData migrationUI screensTest suitesLegacy analysisDocs and specsAgents draft. People specify, review and merge.No Scrum master, no separate QA role, no hand-offs.
Who does the work. Atlas's headcount is a typical team for this scope.

How the work flows

Atlas spends people's time writing code. Forge spends it specifying and checking.

Team Atlas runs a sprint pipeline with hand-offs; Team Forge runs a short loop of spec, agents, an automated gate and human reviewTeam AtlasONE CYCLE ≈ A TWO-WEEK SPRINTUser storybacklog groomingHand-write codedevelopersPeer reviewpull requestsQA testingafter developmentSprint releasedemo, retrobugs found late go back to the developers, often in the next sprintTeam ForgeONE CYCLE ≈ HOURSWritten specacceptance criteriaAgents generatecode and tests togetherAutomated gatetests, static and security scansHuman reviewevery lineMergegate fails → an agent fixes it in minutesreviewer rejects → re-spec
The delivery loop for one feature. Forge's bottleneck moves from writing code to reviewing it.
StageTeam AtlasTeam Forge
Understanding the legacy systemWeeks of reading code and interviewing expertsAgents read the whole codebase and pull out the business rules in days; people check them
RequirementsUser stories groomed in backlog sessionsDetailed written specs become the main input
BuildHand-written code in two-week sprintsSeveral agent sessions run in parallel
TestingQA writes and runs tests after developmentTests written alongside the code gate every change
CoordinationStandups, planning, retros, hand-offsThree people share context directly

Timeline and cost

Forge ships about nine months earlier, for roughly a tenth of the cost.

Team Atlas runs 12 months; Team Forge is projected to finish in about 3 months036912months from kickoffTeam Atlas9 peopleDiscoveryBuild · about 14 sprintsQALaunchTeam Forge3 peopleBuildShips about month 3 (projected)analysis · build · hardeningabout 9 months earlier to market
Forge is done before Atlas finishes its first build phase. Atlas: the company's 12-month estimate. Forge: a projection from a rewrite in progress.
Atlas uses 108 person-months and about 1.62 million dollars; Forge uses 9 person-months and about 153 thousand dollarsPERSON-MONTHSAtlas108Forge9TOTAL COST, USDAtlas~$1,620,000Forge~$153,000, incl. ~$18,000 of AI tools
Forge uses 9 person-months to Atlas's 108. Assumes $15,000 fully loaded cost per person-month and about $2,000 of AI tools per engineer per month. Even if Forge takes six months, it uses under a fifth of Atlas's person-months.

Quality, security and risk

Forge's main risk is unchecked output, not speed.

Code that compiles and passes a demo can still hide a security hole or a wrong business rule. None of these risks is new; AI shortens the time in which they can pile up, so what a traditional team treats as good practice becomes mandatory for Forge.

RiskAtlasForgeHow Forge handles it
Security vulnerabilitiesModerateHigherStatic analysis, dependency scanning and a security review on every merge
Lost business rulesModerateModerateCharacterization tests against the legacy system; replay of real customer data
Review overloadLowHighSmall, focused changes; tests as the first gate
Key-person dependencySpreadConcentratedAgent-written docs, recorded specs, pairing
MaintainabilityFamiliarUnfamiliarEnforced standards, architecture rules, refactoring passes
Vendor and toolingNonePresentKeep the code tool-agnostic; avoid pipeline lock-in

What the research says

AI amplifies whatever discipline a team already has.

90%

of nearly 5,000 technology professionals in Google's 2025 DORA report use AI, and adoption is now linked to higher delivery throughput. The report calls AI a mirror and a multiplier: it lifts cohesive teams and exposes weak ones.

3%

of developers report high trust in AI-generated output, in the 2025 Stack Overflow Developer Survey, as reported by InfoQ.

45%

of coding tasks produced code with security flaws, across more than 100 models tested by Veracode. For Java, the failure rate was over 70%.

In METR's trial, developers expected to be 24% faster, believed afterward they were 20% faster, and measured 19% slower20% slowerno change20% fasterExpected+24%Believed afterward+20%Measured−19%
Experts in code they knew felt faster but measured 19% slower. 16 experienced open-source developers, 246 real tasks in repositories they knew well, early-2025 tools. METR's February 2026 follow-up with late-2025 tools measured a speedup instead, which the authors call weak evidence.

The rewrite fits the favorable profile: unfamiliar legacy code, a fresh architecture, and senior people who check instead of trust. The METR trial is the warning: Forge should track measured cycle time and defect rates, not how fast the work feels.

Limits

Where a team like Atlas still wins

  • Regulated or safety-critical systems such as medical, avionics and payment cores, where every line needs traceable human authorship.
  • Large, tightly coupled codebases that three people cannot hold in their heads, and where AI tools do worst.
  • Experts in code they know deeply, the setting where METR measured a slowdown.
  • Stakeholder-heavy change programs, where people, not code, are the constraint.
  • Growing new engineers. A seniors-only team builds no talent pipeline.

Lessons for leaders

What Rachel Moreno would tell another CTO

  1. Staff for judgment, not keystrokes. Put the most senior architects on the AI-native team; their review is the quality gate.

  2. Build the guardrails first. Tests, static analysis and security scanning must exist before agents produce code at volume.

  3. Treat the spec as the product. The quality of the written requirements now sets the quality of the output.

  4. Measure instead of trusting the feeling. Track cycle time, escaped defects, rework and security findings against the traditional baseline.

  5. Pilot on a bounded, high-value project. A rewrite with clear scope is a good start; a sprawling coupled system is not.

  6. Plan the people transition. Move people toward review, domain expertise and customer work rather than simply cutting.

  7. Keep a human accountable for every merge. AI drafts; a named engineer owns what ships.

Planning an AI-assisted rewrite?

I help teams plan and run them: the specs, the guardrails, the review and the estimate. Every engagement starts with a free 30-minute call. The way we plan every project, from the goal to an estimate in AI time and Dev time, is free to copy.

Sources