Anatomy of a Software Factory: Why 10x Engineers Gave the Org 1.5x

TL;DR: This is the written version of a talk I have been giving this year. It answers one question: if every engineer is 10x, why did the company only get 1.5x, and what kind of machine closes that gap.

Software engineering in 2026

In teams that have adopted Claude Code, Codex or something like them, most new code is generated. The engineer describes the change, the agent writes it, the engineer reads the result. For a growing number of repositories the figure is 100%, and nobody has typed a function body in months.

So what did that do to output? Measured per engineer, the curve is the one everybody expected:

Measured for the organisation, the curve is a different shape:

Ten times the code. One and a half times the shipped product. Both curves begin at the same point and split in the quarter the agents showed up. Individual productivity is not organisational velocity, and the space between those two curves is the subject here.

The bottleneck moved

Software delivery is a line. Plan, code, review, test, deploy. For the whole history of the field, the slow stage was code. Work piled up in front of the engineers and everything downstream had slack, because review, test and deploy only ever received what the engineers could write.

Agents removed that constraint. They did not remove the line. Code now arrives at review faster than reviewers can read it, so the pile moves to review. Give review more capacity and the pile moves to test. Fix test and it lands on deploy. The squeeze hops to wherever capacity is lowest, and work piles up wherever it lands:

This is the whole explanation for the 10x versus 1.5x gap. A line runs at the speed of its slowest stage. Agents made one stage fast and left four alone. Goldratt wrote this down in 1984 for physical factories and it has not stopped being true for software ones.

Two ways to scale, both of which fail

If the line is the problem, the instinct is to add capacity to the line. There are two ways to do that, and engineering leaders have tried both this year.

More people

The first answer is the one the industry has used for fifty years. Add a team. Specialists in columns: PM, design, dev, QA, each handing work down to the next. Six teams of four is twenty-four people, and on paper it is six times the throughput.

In practice three things happen, and Brooks described all of them in 1975.

• Bottlenecks. Every column still has its own slowest stage, and every column still feeds the same deploy pipeline and the same reviewers of record. You added six piles, not six lines.
• Coordination. Twenty-four people have 276 pairwise channels. The meetings and the hand-offs between columns eat the capacity the columns were supposed to add.
• Cost. Headcount is the most expensive input in software, it takes a quarter to hire and a quarter to onboard, and it does not scale back down when the backlog empties.

More people was the right answer when code was the constraint, because people wrote code. It is the wrong answer when the constraint is everything after code, because people do not scale those stages either.

More tokens

The second answer is newer. If one agent made the engineer 10x, run many agents and automate the line. Plan, code, review, test, deploy, all handled by agents, every item moving cleanly from one end to the other.

Anyone who has run a fleet of unsupervised agents against a real repository knows what the line looks like after a week:

The failure here is different from the headcount failure, and it is worth being exact about it, because the fix is different too.

• Signal. Twelve agents open forty pull requests overnight. Which three matter? Which one quietly weakened a test to make it pass? The volume of output drowns the information in it.
• Feedback. An agent that is told its PR was wrong does not get better next time unless something writes that lesson down somewhere the next run will read. Without that loop every run starts from zero and makes the same mistake with the same confidence.
• Control. The fleet works on whatever it was pointed at. Nobody re-ranks its backlog when revenue goals change, nobody stops it when a compliance deadline moves up, and nobody can say on Monday what it will have shipped by Friday.

More tokens solves the one problem that was already solved, writing code, and creates three new ones. Which leads to the only question that matters.

Who runs the line

The line needs an operator. Not a person watching dashboards, and not a cron job that retries failed agents. Something that owns the whole loop from an idea to a running product, and that holds the agents to standards the way a plant manager holds a line to tolerances.

That is what a software factory is. Here is the idea in one picture:

An idea enters. It is triaged, specified, implemented, verified, shipped and monitored, and monitoring feeds the next idea. People sit at three points on the loop: they approve the spec, they review the code, and they judge the product. Everything between those points is the factory’s job.

Now the same idea with the machinery drawn in:

Read it left to right.

Triggers. On the left, four kinds of people feed the factory: a CXO with a goal, a PM with a feature, a user with a complaint, an engineer with a prompt. In production the list is longer: a GitHub issue, a public forum post, a Slack thread, a production alert, a schedule. Anything that can start work is a trigger, and a prompt is one of them.

The mission board. Triggers land on one board inside the factory: To Do, In Progress, Done, with typed tickets. FEAT 41, BUG 52, CHORE 47. A mission is a goal split into issues. Each issue is its own conversation on its own git worktree and branch, and issues run in parallel inside that factory. The board is the executive view of that factory’s progress: what is running, what is in review, what is blocked.

The workers. The grid in the middle is the fleet. Each cell is an agent working one issue. Some are lit and some are dim, because the fleet is sized to the backlog, not to a headcount plan.

The gates. Nothing moves from a worker to production without passing review, quality, security and deploy. These gates are code: the repository’s own tests and linters run by exec, an adversarial review agent that was not the author, policy that decides what may auto-merge and what must wait for a person. A change that fails a gate goes back to the worker for rework, not to a human for a decision.

Monitor. After deploy, the factory watches production. An incident is a red packet that travels back along the bottom wire into the board as a new ticket, with the root-cause analysis attached. The line is closed.

Self-improve. The cyan loop around the outside is the part that makes this a factory and not a pipeline. Every run leaves something behind: a skill (a procedure written to the repo that later runs search and load), a memory about the codebase or a past incident, a tuned automation threshold, a tighter gate, a sharper report. Insights are collected at the bottom and fed back into every station. The factory you have in month four is not the one you set up in month one.

That picture is the definition. A software factory is a long-running environment that takes in work from any trigger, runs it through agents in parallel, holds every change to checks that are code, and improves its own machinery as it goes.

The six tenets

A definition says what a factory is. The tenets say what it must be good at, and each one answers one of the six failures above. Three for the failures of more people, three for the failures of more tokens.

1. Works autonomously

The distinction is in the loop against on the loop. In the loop, a person is a station: nothing passes until they act. On the loop, the person is an observer with a stop button. Work flows through gates that are code, and the person is pulled in only when a gate asks for them: a spec to approve, a high-risk diff to read, a product to judge.

Autonomy is a dial, not a switch. You can start with every PR waiting for a human and move, one class of change at a time, towards letting the factory merge docs, dependency bumps and isolated fixes on its own. What matters is that the dial exists.

2. Highly scalable

A surge lands, say forty issues from a security audit on a Tuesday afternoon. The fleet grows to drain it and shrinks back once the backlog is clear. Nobody is recruited, nobody is onboarded, and nothing is scheduled, because agents coordinate through the board and the repository.

What limits this is partitioning. Parallelism helps only when a goal can be split into issues that do not overwrite one another, which is why the mission planner is among the hardest pieces of a factory to get right.

3. Cost effective

The honest comparison is not agents against nothing. It is agents against what companies already do when they need more delivery than they can staff: outsourcing. A factory running on tokens, with gates that reject bad work before a person sees it, ships more per dollar than a contracted vendor, and it does so with the repository’s own standards rather than the vendor’s.

Tokens are not free, and a factory that re-runs a failing issue a dozen rounds over is burning money. That is why the next three tenets exist.

4. Measurable

Every shipped change records four numbers: the value it was tagged with, the cycle time from trigger to production, the defects found afterwards, and what it consumed in tokens and compute. Forty PRs overnight stop being noise when each carries a price and a duration and the board can sort by both.

This is also what makes the 10x against 1.5x argument settleable inside one business. If you cannot measure org-level delivery you cannot know whether the factory moved it.

5. Self-improving

The factory treats its own machinery as an experiment. A new skill, a changed prompt, a different gate threshold, a re-ordered automation: each is a run that gets a score. If the score beats the best so far, the change is kept and the bar moves up. If not, it is dropped. The chart is a staircase that only goes up.

This is deliberately not just “the agent writes skills”. Skills are one artefact among several. Memories of the codebase and past incidents, tuned automations, sharper reports, tighter checks and better prompts all climb the same hill. A factory in which only the skills improve is a factory with one of six loops closed.

6. Business driven

The fleet should not work on whatever it was last pointed at. Goals, revenue this period, retention, a compliance deadline, re-rank the backlog, and the factory takes the next ticket from the top. When the goal changes, the ranking changes, and what ships by Friday changes with it. That is the control a crowd of unsupervised agents cannot offer and a CXO will not run a factory without.

Six answers to six failures

Scaling by	Breaks on	Tenet
Headcount	Hand-offs	Works autonomously
Headcount	Communication overhead	Highly scalable
Headcount	Budget	Cost effective
Raw agents	Signal	Measurable
Raw agents	Feedback	Self-improving
Raw agents	Control	Business driven

With all six in place:

Nothing queues, because no station depends on a person being awake, and the fleet sizes itself to the backlog while the gates size themselves to the risk. That is the whole anatomy.

The next essay follows one production bug through a coding harness and through a factory, and explains why the tool on your laptop, however good, is one station on this line and not its operator.