Yield Engineering for Fleets of Autonomous Coding Agents

I spent the first half of 2026 in rooms with teams running fleets of coding agents in production. The pattern repeated enough that it stopped surprising me. An engineer kicks off a batch of agents, each isolated in its own container or microVM, and closes the laptop. The agents keep working. Overnight the team ships thousands of change requests a week, and a large share of those merge straight to production with no human in the path. The engineer wakes up, reviews what shipped, and steers the next batch.

This is real, it is shipping today, and it works. The interesting part is what people choose to measure once it does.

The ground floor is already poured #

The techniques that make this possible have a shape now, and that shape has a name: loop engineering. You give an agent a clear task and the means to stay on it for hours instead of a single turn. You wrap it in deterministic checks it runs against its own output, tests and type checks and linters and builds that either pass or fail. You isolate it in a container or microVM so it can act unattended without putting your machine or your main branch at risk. Loop engineering is the floor everything else stands on, and most of the teams I sat with have it working.

Once the loop runs, the first number everyone reaches for is velocity. Change requests per week. Share auto-merged. Time from prompt to production. These climb fast, and they make a satisfying screenshot in a leadership update.

Velocity is the easy number. A loop that produces more output per hour is doing exactly what a loop is built to do. Output volume tells you almost nothing about whether the output is good, and whether it is good decides whether any of this survives contact with a customer.

The factory we already named #

We reach for factory language without thinking about it: software factory, dark factory, lights-out delivery. The metaphor is comfortable enough that we use it before we have earned it, the way the first web pages were called documents because that was the nearest familiar thing.

Lean into the metaphor and you inherit its discipline. A real factory is graded on yield rather than on how many units came off the line: what you produced, minus the defects, minus the downtime the line ate while producing. A semiconductor fab can run wafers all day, and if a third of the dies come back dead, the fab is failing no matter how busy it looked.

What makes the fab’s yield hard to fake is that the defect is physical. A die passes electrical test or it does not, and no wording on a dashboard changes that. Software has no such guarantee, and that is the trap waiting at the end of the analogy. The obvious first metric, one-shot acceptance rate, the share of agent pull requests that merge with no human edits, is a vanity metric the moment you read it alone. You control what counts as merged. Lower the bar, ship smaller and safer changes, stop counting the rollbacks, and the number climbs while the work gets worse. So the move is to ask what the yield of a software factory is, and how to measure it so it cannot be talked up.

The objection, put fairly #

The strongest argument against me is a good one, and it deserves to be stated at full strength before anyone waves it off.

A wafer is the same design stamped out millions of times. The fab etches one pattern and repeats it across identical dies, so defect rate has clean meaning: you measure deviation from a fixed reference, the same reference every time. Software has no such reference. Every pull request is a different artifact. New code, new intent, a different shape each time it lands. There is no master pattern to compare against. At the level of a single unit, the comparison falls apart. You are producing one novel part after another rather than stamping the same part, and calling that a production line is a stretch.

If yield were a per-unit property, that objection would end the discussion.

Yield was never per-unit #

Zoom out from the single artifact and a pull request is a pull request. With guardrails around it, it has a known and checkable shape. It passes its unit tests or it does not. It survives static and dynamic analysis or it does not. The end-to-end suite goes green. Property-based tests hold across the input space. The functional and non-functional requirements are met or they are not. Then it merges, it ships, and it has an outcome. Sometimes the outcome is immediate: a feature moves the top line, reaches a customer who was not reachable before. Sometimes it trails by weeks: a defect surfaces in the feature itself, or in something adjacent that the change quietly disturbed.

The fab analogy fixes the thing I had backwards when I started. Yield was never a property of the individual unit. A fab does not quote yield because its dies are identical. It quotes yield across dies that are physically not identical at all: process drift, particle defects, and edge-of-wafer effects mean no two come off exactly the same. Yield is a rate measured over a batch of non-identical things. That is the entire point of the number.

The population of merged pull requests is exactly that kind of batch. Non-identical units, each shipping into production, each with a measurable outcome. Across that population there is a defect rate. You can measure it, attribute it, and drive it down, in precisely the way fabs ran a yield function over wafers where no two looked alike, across the Moore’s Law decades when yield learning was the discipline that turned a lab process into an industry.

Where this does not apply #

This is a Pareto claim, and I would be selling you something if I called it a law of nature. Greenfield prototyping does not fit the mold. The genuinely novel build, the first cut of a thing nobody has made, the exploratory spike where the point is to learn what the product even is, that work is closer to designing a new chip than to running an existing process. Holding it to a yield number would measure the wrong thing and punish the right behavior.

The genuinely novel build is the minority of what most organizations ship. The majority of production change is variation on understood problems: a new endpoint shaped like the last forty endpoints, a bug fix, a migration, a feature that resembles features you have shipped before. That majority is the line, and that majority has a yield.

The function underneath #

Accept that merged pull requests form a population with a measurable defect rate, and software delivery stops being something you describe with adjectives. It becomes something with a yield function: a definable relationship between what the line produces and what survives contact with production. A number you can take across the population of what your factory ships, and steer over time.

That practice, measuring the yield of an autonomous software factory and tuning the line to raise it, is what I have started calling yield engineering. It borrows the fab’s vocabulary on purpose. A fab asks how many wafers shipped good, and it runs a whole discipline, yield engineering, around moving that fraction up. The software version is the same discipline pointed at pull requests instead of dies. The terms are collected in the yield engineering glossary.

Part 2 works out what goes into that function, and how to keep one-shot acceptance from quietly becoming the vanity number that flatters everyone. The specific readings you take off the line, and the one rule that keeps them reliable once an agent is fast enough to flood you with output. The rule matters more than the readings, and it is the part most teams will get wrong first.

For now I will leave it as a question, because I am still pressure-testing this in the field. If you are running agent fleets in production, what does your line measure today? Is velocity quietly standing in for a quality number you have not figured out how to take yet? Tell me where this breaks. I would rather be corrected here than be confidently wrong in Part 2.