The Software Factory Is Not the End of Agents. It Is What Comes After Them.

The advantage is not the smartest agent. It is the system that steers thousands of them.

The moat is not the agent. The moat is the steering system. Two companies can buy exactly the same frontier models. What they cannot buy is the years of encoded product knowledge, architecture, evaluation data, operational history, and feedback loops that one of them has built around those models. Same workers, very different factories.

That is the argument of this post, and it follows directly from the two before it. If Opportunity AI is about where enterprise value comes from, and the hybrid engineering stack is about which form of intelligence owns which decision, the software factory is the operating model that makes both real inside an engineering organization.

A useful definition, and only the beginning

“Software factory” is quickly becoming one of the defining terms of AI-native engineering. Envisioning defines it as a system in which triggers, rather than people, start coding-agent sessions. An issue arrives. CI fails. Monitoring raises an alert. Another agent finishes its work. Instead of a developer launching the next session by hand, the system does it.

That is a useful definition, and I think it describes only the first step.

The more interesting shift is not that we are automating the button that starts an agent. It is that we are building operating systems around populations of agents: systems that decide what work should happen, which agent performs it, what context it receives, what it is allowed to do, how its output is evaluated, when it should try again, when another agent should review it, and when a human needs to step in.

That is no longer an automated coding tool. It is a factory.

But factories are supposed to be deterministic

There is an apparent contradiction at the center of the idea. Factories mean repeatability: the same inputs through the same process produce essentially the same product. LLM agents are probabilistic. Give one the same task twice and it may take two different paths, make different implementation choices, and produce different results.

So how can anything built around nondeterministic agents deserve the name?

The answer is in the history of factories themselves. Factories never depended on every worker behaving deterministically; human workers certainly do not. Industrial systems created reliability by standardizing the environment around the worker: process, tooling, tolerances, inspection, quality control, and escalation. The goal was never to remove variability from the worker. It was to build a production system that could absorb variability and still produce predictable outcomes.

The original software-factory movement was built on the same instinct. Robert Bemer was writing about software factories in the late 1960s, Hitachi established its Software Works in 1969, and the movement emphasized standardized methods, reusable components, and quality controls in an effort to move software away from purely artisanal production.

AI brings that idea back with one important inversion. The worker can remain probabilistic because the production system around the worker can become increasingly deterministic.

Deterministic outside, probabilistic inside

Look at what is already forming around coding agents. The agent itself reasons, explores, and makes judgments; that part is intentionally nondeterministic. Around it we construct deterministic rails. A ticket defines the expected outcome. Architectural rules define boundaries. Sandboxes constrain the environment. Tests define acceptable behavior. Linters enforce standards. Security policies restrict actions. CI validates the result. Observability measures what happens after deployment.

Matt Pocock’s AI Coding Dictionary draws the line explicitly. Automated checks are deterministic: tests, type checks, builds, and lints produce a pass or a fail. Automated review is different: another agent forms a judgment, and that judgment remains probabilistic.

The emerging architecture is a loop:

Intent → context → agent execution → deterministic checks → probabilistic review → policy gates → deployment → telemetry → learning → new work

The agent is one component in that loop. The factory is the loop. Factory describes its own system the same way: signals such as customer feedback, incidents, and business requirements enter, become planned changes, are built, tested, reviewed, secured, shipped, and monitored, and the resulting telemetry feeds the next cycle. That is a control system, not an assembly line, and the distinction matters for everything that follows.

Agents were the worker. The factory is the management system.

The first generation of AI coding was assistance: autocomplete helped the developer write. Then agents arrived, and the developer could delegate a task: investigate this issue, implement this feature, refactor this service.

But the developer was still acting as the operating system. We started the agent. We supplied the context. We decided when it was finished. We started the next one, reviewed the work, resolved the conflicts, noticed the failures, and decided what happened next. The agent automated coding while the human kept orchestrating production.

Software factories automate that layer, and the evidence that this is an operating model rather than an experiment is now public.

Cursor calls it a third era of AI development: its engineers break work apart, launch multiple cloud agents, and review the artifacts rather than guiding a single agent turn by turn. Cursor reported in February that 35 percent of the pull requests it merged internally were created by autonomous agents running in cloud environments.

Uber went further. By August, Uber reported that more than 70% of its pull requests were attributed to local or cloud agents, with more than 3,600 agent skills and over 30,000 skill executions per day. More telling, a growing share of those sessions were started by managed automation rather than people: code review, self-healing CI, debugging, maintenance, and incident triage.

At that point we are no longer talking about an engineer using an assistant. We are talking about a production system allocating work to a digital workforce.

Why harness engineering is where the leverage lives

OpenAI’s account of building a product with no manually written code points the same direction. Its team found that the limiting factor was often not the model. The environment was underspecified: the agent lacked the tools, abstractions, context, and feedback it needed to operate reliably. The engineers’ work shifted toward designing environments, feedback loops, and control systems around agents.

Anthropic reached similar conclusions. Its experiments with long-running agents and teams of parallel Claude instances found substantial gains from planning, evaluation, decomposition, and carefully designed harnesses. Its C compiler experiment ran 16 parallel agents across nearly 2,000 sessions, and the research focused heavily on the infrastructure required to keep autonomous work progressing without continuous human supervision.

This is the shift in where engineering leverage sits, and it is the one I would ask every technology leader to internalize:

A better model helps one worker. A better harness improves every task that worker performs. A better factory improves every agent operating inside it.

That is a very different compounding curve.

The model may become the least differentiated part of the stack

Today organizations spend enormous energy debating which model is best. Claude or Codex. This frontier release or that one. Which benchmark moved this week. Those questions matter, and they will matter less over time.

Uber already treats model selection as an optimization problem, benchmarking models against real workloads and routing each task toward the best combination of cost, quality, and reliability. Factory makes the argument explicit: a software factory should be model independent because different tasks need different mixes of cost, speed, and capability.

The model layer is becoming interchangeable compute. The durable advantage sits higher: your architecture, your product knowledge, your acceptance criteria, your skills, your historical decisions, your evaluation datasets, your incident history, your security rules, your customer feedback, your definition of quality, and above all the feedback loops that turn failures and human corrections into better instructions, tests, policies, and context.

Why the fully dark factory is probably the wrong target

The industry is understandably fascinated by the “dark factory,” where humans no longer inspect what agents produce. StrongDM has demonstrated one version: humans specify intent, constraints, and scenarios, while agents generate code and validate it against scenario-based tests until the behavior converges. StrongDM describes this as validation replacing code review.

It is a compelling model with a hard limit. Not everything we care about has a reliable oracle.

Does the test pass? Automatable. Does the API still conform to its contract? Probably. Did latency exceed 500 milliseconds? Certainly. Is this architecture becoming unnecessarily coupled? Will this abstraction make the next twelve changes harder? Did we technically deliver the feature while misunderstanding the product problem? Those are harder, and they are the ones that cost the most.

Dex Horthy of HumanLayer offered the important counterexample after running a lights-out factory: agents can optimize for observable outcomes like passing tests without preserving long-term maintainability, because the cost of bad architecture may not surface for months. Even OpenAI, after demonstrating very high autonomy, says plainly that humans continue to prioritize work, translate feedback into acceptance criteria, and validate outcomes, with agents escalating when judgment is required.

That is the likely enterprise destination. Not zero humans. Human attention allocated where it has the highest marginal value. The factory’s job is not to eliminate people. It is to keep reducing the human attention required for work that can be specified, constrained, and verified mechanically.

The real progression is not Copilot → Agent → No Humans

A more useful maturity model is:

Assistant → Agent → Agent Team → Software Factory

The move from assistant to agent gave AI agency. Agent to agent team gave it parallelism. Agent team to factory gives it institutional structure: persistent context, triggers, orchestration, permissions, evaluation, observability, memory, cost controls, learning loops, and escalation.

Cloudflare is already questioning whether today’s developer infrastructure fits this world, arguing that Git platforms themselves may need to evolve for environments where hundreds or thousands of agents work concurrently and repositories become programmable infrastructure for agent workflows.

A collection of workers is not a factory. The factory is what coordinates them.

The executive question changes

For technology leaders, the interesting metric is no longer what percentage of our code is written by AI. That number is becoming meaningless. The better questions are about verified business output.

Uber measures managed agents on cost per merged pull request, cost per review, cost per alert, and cost per cleanup, alongside revert rates and mean time to recovery. That is the operating model executives should care about, and it translates into questions a board can ask:

How much verified work can the organization produce?
How much human attention does each outcome consume?
What share of work can safely execute without supervision?
How quickly does the system detect and recover from failure?
How often is human judgment converted into a reusable rule, skill, evaluation, or control?

Those are factory metrics, and they connect AI investment directly to business value.

The real opportunity is the learning factory

A traditional factory improves through process improvement. An AI software factory can do something stronger: it can learn from every execution.

A production incident becomes a new evaluation. A security finding becomes a policy. A rejected architecture becomes a constraint. A review comment becomes a lint rule or an agent skill. A recurring support issue becomes a trigger. A successful implementation becomes reusable context. A failure becomes training data for the steering system. OpenAI describes capturing human taste and converting it into documentation and mechanical enforcement; Factory describes feeding sessions, reviews, and incidents back into the system.

This is where the compounding advantage appears, and it is why I opened where I did. Two companies with the same foundation models do not have equivalent AI capability once one of them has spent years encoding its knowledge into the factory.

What this means

Three implications for anyone who runs a company rather than an engineering organization.

You are building an asset, not buying a tool. Model subscriptions are operating expense that every competitor can match. The factory, the encoded knowledge, evaluations, policies, and loops, is a durable asset that belongs to the company that built it. Fund it and account for it that way.

The headcount question is the wrong question. The right one is how much verified output the organization produces per unit of human attention, and how that ratio is trending. Ask your technology leader for that number.

Judgment becomes the scarce input. As agents absorb specification-ready work, the people who remain are the ones defining intent, setting constraints, deciding what quality means, and teaching the factory when reality proves it wrong. Hiring, development, and incentives should follow that shift.

The next era of AI engineering is not primarily about replacing developers with autonomous agents. It is about turning agents into a manageable, governable, continuously improving digital workforce. The workers stay probabilistic. The factory becomes increasingly deterministic around them. And humans move to where judgment creates the most leverage.

Software factories are not what comes after agents. They are what agents become when we finally learn how to operate them at scale. The companies that figure this out will not simply write software faster. They will build systems that continuously turn organizational knowledge into software, and unlike the next generation of models, that capability belongs to them.