Short answer
Can a product team of nine run with one engineer when AI agents write and review the code? In my model, yes, for a mature product with testable tickets, automated evidence and reversible deploys. The other eight move to new products. Without those conditions, cutting the team only moves the bottleneck.
You have a product with nine engineers on it. Everyone uses an AI assistant, the pull request count went up, and somehow the roadmap moves at the same speed. Leadership asks the obvious question: if agents write the code, why do we still need nine people here?
I think the honest answer is that you might not, but only after you change what those nine people spend their days on. This article is a model, not a case study. It shows how a team of nine on one product can become one engineer on that product, with the other eight building new products, and it lists the conditions that have to hold for that to work.
Why nine people with AI assistants still ship like nine people
Most teams added AI to the typing step and left everything else alone. Faros AI’s 2025 report, based on about 10,000 developers, found that teams with heavy AI use completed 21% more tasks and merged 98% more pull requests, while review time per pull request went up 91%. DORA’s 2025 report describes AI as an amplifier: throughput rises, and so does instability.
That is what you would expect. If the code arrives faster and every change still waits for a person to read it, the queue moves from the editor to the review tab. Nine people with assistants become nine reviewers with a growing backlog of diffs. I wrote about the arithmetic in Amdahl’s law for software teams: speeding up one step barely moves delivery when the other steps are waiting on people.
So the move from nine to one does not come from faster code generation. It comes from taking people out of the steps where they mostly wait: reading diffs, rerunning tests, checking that a ticket was done the way it says.
The model: six quarters, one product, nine engineers
Here is the scenario I use when I talk this through with a team. It is illustrative. The quarters are a planning unit, not a promise.
- A mature product: real users, a working release process, a backlog of features, fixes and upkeep.
- Nine engineers on it today. The organisation has more product ideas than people to build them.
- The backlog does not shrink. The same volume of work keeps flowing in.
- Each quarter, people move off the product only when the work they did is covered by agents plus automated checks, and the incident rate has not risen.
One product team over six quarters
Engineers on the product vs engineers moved to new products
- On this product
- Moved to new products
Data as a table
| On this product | Moved to new products | |
|---|---|---|
| Q1 | 9 | 0 |
| Q2 | 8 | 1 |
| Q3 | 6 | 3 |
| Q4 | 4 | 5 |
| Q5 | 2 | 7 |
| Q6 | 1 | 8 |
The first quarter changes nothing in headcount. It is spent making the product legible to agents: every ticket gets acceptance criteria that a machine can check, the test suite gets the gaps closed, and deploys become reversible. One person moves at the end of it, usually the one who built the evidence pipeline and is now best placed to set one up on a new product.
The middle quarters are where review stops being a human step. A second model, not the one that wrote the code, reads the diff against the criteria and the evidence. People read the findings and the exceptions, not every diff. Each quarter two engineers move to new products, and the ones who stay spend less time reading code and more time writing intent.
By the last quarter one engineer owns the product. That person is not a lone coder. They own the backlog, the acceptance criteria, the pipeline that turns tickets into merged and deployed changes, and the decisions agents are not allowed to make.
What the one engineer does all week
The role that remains looks more like a product owner who can read a stack trace than like a developer. Here is how I would expect the week to split once the pipeline is running. These are modelled hours, not measured ones.
The remaining engineer's 40-hour week
How the time splits once agents write and review the code
- Writing intent and criteria
- Exceptions and decisions
- Improving the pipeline
- Users and incidents
Data as a table
| Writing intent and criteria | Exceptions and decisions | Improving the pipeline | Users and incidents | |
|---|---|---|---|---|
| Typical week | 14 h | 10 h | 8 h | 8 h |
Writing intent is the biggest block, because it is the one thing the pipeline cannot do for itself. A vague ticket produces confident, wrong code. A ticket with checkable criteria produces code a reviewer model can accept or reject on evidence.
Exceptions come next: the run that parked because it needed a credential, the product question the agent refused to guess, the change that touched payments and needs a human signature. Improving the pipeline means adding a check every time something slipped through, so the same class of mistake cannot happen twice. Users and incidents stay with a person, because someone has to talk to the customer.
The pipeline that replaces eight people
The shape is the same in every serious setup I have seen described publicly. A person writes the intent. Agents plan, write, test and review. Only exceptions come back to a person.
How a ticket moves with one engineer on the product
- Person
- Agent
- Automated check
Steps as text
| Step | What happens |
|---|---|
| 1. Ticket with criteria | Person — written by the engineer |
| 2. Writer agent | Agent — plans, codes, registers checks |
| 3. Evidence | Automated check — build, tests, scenarios |
| 4. Reviewer agent | Agent — different model reads diff |
| 5. Deploy behind flag | Automated check — rollback is one command |
| 6. Exceptions only | Person — back to the engineer |
| Loop | findings go back: back from step 4 to step 2 |
The reviewer has to be independent. A model reviewing its own work tends to agree with itself, which is why I use a different model as the reviewer (why the writer can’t be the reviewer). The reviewer also has to judge evidence that the pipeline collected itself, not the writer’s claim that tests pass.
There is at least one public example of a team running this way. StrongDM describes a “software factory” started on 14 July 2025 with two rules: code must not be written by humans, and code must not be reviewed by humans. Simon Willison, who wrote about it in February 2026, describes it as a three-person team. In place of human review they validate against end-to-end scenarios kept outside the codebase, and they build behavioural clones of services such as Okta, Jira and Slack to test against. I take it as evidence that the approach is being tried in production by serious people, not as proof that it fits your product.
What has to be true before anyone moves
This is the part teams skip. The headcount number is the output of these conditions, never the input.
| Condition | How to check it | What happens if it’s missing |
|---|---|---|
| Tickets have machine-checkable acceptance criteria | Pick ten recent tickets. Could a script tell you whether each was done? | Agents finish the wrong thing confidently |
| Evidence is collected by the pipeline, not reported by the agent | Every merge has build, test and scenario output attached | Review turns back into reading code |
| The reviewer is a different model with the power to reject | Count rejected runs. Zero rejections means it is decorative | Self-review approves its own mistakes |
| Deploys are reversible | Time a rollback. It should be minutes and one command | Every merge needs a nervous human |
| Risky areas are fenced | Payments, auth, migrations and data deletion need a human signature | One bad merge costs more than the team saved |
| There is somewhere for people to go | A list of products or bets that are waiting for engineers | The plan becomes a layoff, and the people who know the system leave |
The last row matters most to me. The model in this article is about moving people to new products, because that is where the value is. A company that uses agents only to cut the payroll on one product keeps the same revenue and loses the people who know how to build the next thing.
Where the model breaks
I would not run this plan on every product. It breaks in predictable places.
- Discovery-heavy products are a poor fit. If the hard part is figuring out what to build, not building it, one engineer cannot run enough experiments or talk to enough users. Agents speed up delivery, not product sense.
- Legacy code without tests is slow to start. Agents can write tests, but without a trusted baseline the reviewer has nothing solid to check against. Budget a long first quarter.
- In regulated domains, where a named person must approve each change, you can automate everything up to the signature, not past it.
- On-call load matters. If the product pages someone three nights a week, one engineer is a burnout plan. Fix reliability first.
- Token spend is real. StrongDM’s guidance is that a factory spending less than $1,000 a day on tokens per human engineer has room to improve. Willison points out that this is roughly $20,000 a month per engineer and turns the approach into a business question. Your numbers will differ, but measure them.
- One owner is a bus factor of one. The fix is that the pipeline itself becomes the documentation: criteria, checks and run history are written down because agents need them. A second engineer should be able to pick it up in a week. If they can’t, you are not at one yet.
A bad approach is to set the headcount target first and then ask the team to make it work. You get pressure to approve runs that should have been rejected, and the incident rate climbs until someone reverses the whole thing. A good approach moves people one at a time, each move earned by a condition you can check, and is willing to stop at three or four if the product needs it.
What the other eight do
They build. Each one who moves takes the same playbook to a new product: tickets with criteria, an evidence pipeline, an independent reviewer, reversible deploys. Some start greenfield products where the factory setup is easier because there is no legacy. Some become the owners of internal tools nobody had time for. One or two may end up improving the pipeline across products, because a shared set of checks is worth more than nine local ones.
In my view, this is the real argument for the model. A company with nine engineers does not get one product with fewer people. It gets up to nine products, each with an owner, if the pipeline holds. Whether it holds is a question you answer with evidence quarter by quarter, and the levels of autonomy are a decent way to track where each product stands.
Questions
Can one engineer really maintain a product with AI agents?
For a mature product with testable tickets, automated evidence, an independent reviewer and reversible deploys, I think yes. For a product still looking for its market, or one with a heavy on-call load, no.
What is the ideal engineering team size with AI?
There is no single number. Size the team by the work that still needs a person: writing intent, handling exceptions, talking to users. Code writing and routine review no longer set the size.
Does shrinking a team with AI mean layoffs?
It doesn’t have to, and in this model it doesn’t. People move to new products as their old work gets covered, which only works if the company has more to build than it has people.
How long does it take to go from nine engineers to one?
In the model, about six quarters, with the first spent on criteria, tests and rollbacks. A product with poor test coverage or unclear ownership will take longer, and some should stop at three or four.
Is it safe to remove humans from code review?
It is safe only where the reviewer is a different model, it judges evidence the pipeline collected, and risky areas such as payments or migrations still need a person’s signature. The staged path is in can you take people out of code review.