Public accounts of software factories emphasize three different design layers: a bounded production line for repeatable work, one outer controller improving a product through a tight loop, and an organization of agents coordinating a graph of work. They can coexist in one system. Each layer adds a different kind of control, along with its own coordination cost and human responsibility.
Consider a checkout bug. A bounded line defines the path from request to reviewed change. An outer loop can drive the uncertain middle by repeatedly selecting, changing, and checking the next small step. If the work expands into dependent diagnosis, implementation, review, and release jobs, a work graph can coordinate several loops and their handoffs. The practical question is where a team should start and which additional layer has earned its cost. SWFT recommends starting with the bounded line.
What are the three visions of the AI software factory?
| Vision | Primary layer | How work moves | Best first use | Main risk |
|---|---|---|---|---|
| Bounded production line | One repeatable job | A known sequence of agent steps, ordinary software, checks, and human decisions | A migration, integration, narrow bug class, or security repair | Generating work faster than the team can verify and absorb it |
| Embedded agent loop | One repository, evolving goal, and outer controller | One outer controller repeatedly reads the current state, chooses a small next step, acts, checks, and starts again; it may delegate bounded subtasks internally | Greenfield systems or continuous repair with strong executable feedback | A plausible local change can move the whole product in the wrong direction |
| Agent organization | A graph of related jobs | An orchestrator assigns dependent tasks to several persistent or replaceable workers | Large backlogs with genuinely separable work and mature delivery controls | Coordination, merge conflict, cost, and failure multiply with the worker count |
These visions are neither mutually exclusive choices nor maturity levels. A team can put a Ralph-like outer loop inside a bounded production line, then route several such lines through a work graph. A small loop can still be the deliberate final design, and adding agents can add coordination without adding useful capability. Each layer should solve an operating problem the simpler system actually has.
Vision one: the bounded production line
The clearest company evidence cited here starts with one class of work and a controlled path through it. A person or system supplies a clear request. The factory prepares the workspace and context, lets an agent handle the uncertain middle, runs known checks in ordinary software, and returns a result for acceptance.
Ramp and Stripe provide concrete company examples. In Ramp's January 12, 2026 account, Inspect runs in an isolated development environment with the application, browser, databases, monitoring, source control, and approved internal tools needed for the job. Ramp later described dedicated lines for security repair and software integrations built on the same environment.
In Stripe's February 9, 2026 account, Minions turns a delegation into a branch for human inspection and review. Its workflow alternates flexible agent steps with deterministic steps for context preparation, code checks, source control, and continuous integration. “One-shot” describes one unattended delegation. A run can contain many model calls, and production delivery still requires people.
The transferable idea is the production line. It has a defined intake, a prepared agent harness, a limited set of allowed actions, a quality bar, and a known output. The agent does not own every decision. Product policy, security boundaries, and final acceptance remain attached to named people or deterministic rules.
This vision is attractive to a product manager because its value can be measured against today's process. Measure time to users, review effort, rework, defects, incidents, and whether the line reduces a real backlog. Pull-request count alone measures activity.
The limit is equally practical. Ramp and Stripe publish first-party operating accounts, not independent comparative studies. Their systems sit on top of mature developer infrastructure and review practices. A team cannot copy the agent interface and assume it has copied the factory.
Vision two: Huntley's embedded Ralph loop
Geoffrey Huntley's Ralph vision reduces the operating model to one outer loop, one repository, and a repeated instruction. In his July 14, 2025 account, the pure form is a shell loop that sends a prompt file to a coding agent again and again. Specifications and a plan are loaded each time. The controller chooses one important item, changes the repository, checks the result, and leaves the new state for the next iteration.
Huntley calls the outer design monolithic: one operating-system process performs one task per loop. An iteration may still fan out internally to many subagents for search or writing, while validation stays serialized to avoid conflicting feedback. His argument is against starting with independent top-level workers that must coordinate their own durable work and handoffs. His operating advice is to keep one item in each iteration, observe how the loop fails, and improve the specifications, feedback, or constraints so that failure is less likely to recur.
This turns context engineering into product infrastructure. Context engineering means curating what the model sees for its next decision. The repository, specifications, plan, current errors, and tool results carry useful state between iterations. Excess context can add cost and reduce effectiveness. Birgitta Böckeler's February 5, 2026 primer also explains that letting an agent decide what to load introduces uncertainty.
Huntley's January 17, 2026 follow-up extends Ralph from completing a build to “evolutionary software”: loops that observe a running product, find a fault or opportunity, change the system, deploy, verify, and repeat. He presents autonomous product and revenue optimization as his direction of travel. That is a dated operator forecast, not evidence that a general self-evolving product factory was reliable across organizations in January 2026.
The loop becomes safer when progress has backpressure. In this setting, backpressure is feedback that resists forward motion until the current result earns another step. A failing test, type error, security rule, budget, human decision, or production signal can all tell the agent “not yet” and explain why. Moss Banay's January 17, 2026 account describes automated quality and correctness feedback as a way to keep longer agent tasks aligned. Huntley highlighted that framing for Ralph loops the same day.
The embedded loop fits work where the desired behavior can be tested, the repository holds enough product knowledge, mistakes are recoverable, and the team can inspect the run. It is a poor fit when the next step requires an unsettled pricing, legal, safety, or customer-experience decision.
Vision three: Yegge's work graph and agent organization
Steve Yegge begins with a different constraint: one person can no longer keep track of many coding-agent sessions. His answer is to make work, identity, state, and handoffs durable outside any one model session.
In Yegge's January 1, 2026 launch account, Gas Town represents jobs as persistent records called Beads. Related jobs form dependency graphs and reusable workflows. Named agent roles pick up ready work, communicate, wait for gates, prepare changes, and pass them toward review and merge. Sessions may disappear; the work record, worker identity, history, and current state remain.
SWFT uses the plain term work graph for that operating idea: a durable map of jobs, dependencies, owners, states, and evidence. The graph tells the system which tasks can run in parallel, which must wait, what was attempted, and what completion unlocks next.
Orchestration is the control work around that graph. It admits a job, assigns a suitable worker and workspace, watches budgets and dependencies, handles interruption, routes review feedback, resolves or escalates conflicts, and records the result. Its value is organizational: keeping several imperfect loops from losing work or blocking one another.
Yegge reported sustained use of 20 to 30 coding agents and designed Gas Town around several worker roles. He also wrote that the code was less than three weeks old, fully generated through prompting, complicated, and probably unsuitable for most readers at launch. Both points belong together. The scale claim is a first-person operator report. The warning is part of the same primary source.
The design kept moving. In a January 5 forecast, Yegge argued that coding agents would become workers inside coordinated colonies while acknowledging that Gas Town still needed frequent manual steering. By April 24, he backed Gas City as the new direction: an SDK built by Julian Knutsen and Chris Sells that replaced one fixed team shape with composable agent “packs” and a supervisor plane.
In his August account, Yegge said Gas Town had broken under a later model's behavior and that he had given up on reusable harnesses. He rebuilt the ideas as Wheelhouse, a private system bound to his game, with people and agents producing work, separate agents implementing it, another model reviewing it, a merge system, and standing production roles. The work graph survived another harness reversal. The chronology matters. “The Yegge model” is a changing design program, not a stable product specification.
This vision earns its complexity when there is a real graph of separable work and an organization already knows how to manage queues, ownership, integration, and release. It is premature when one well-instrumented worker cannot yet complete one bounded job reliably.
What is the difference between an agent loop and multi-agent coordination?
An agent loop is the cycle inside one worker:
read the goal and current context → choose an action → use a tool → inspect the result → continue, stop, or ask for help
An orchestrator manages work around one or more loops:
admit jobs → resolve dependencies → assign workers → preserve state → collect proof → integrate results → release capacity
The distinction matters because these layers fail differently. A loop can misunderstand the task, choose a poor tool, exhaust its context, or accept a weak result. Coordination can duplicate work, create conflicting changes, strand a dependency, overload review, lose ownership, or spend more on communication than execution.
More workers help only when the work can be separated and their results can be integrated. If five agents all need the same files, the same product decision, and the same reviewer, parallelism moves the queue rather than removing it.
Which AI engineering terms matter across all three visions?
| Term | Plain-English meaning | The product decision it exposes |
|---|---|---|
| Agent loop | One model repeatedly chooses actions and learns from tool results until it stops or needs help | What tells the worker to continue, stop, or escalate? |
| Agent harness | The instructions, tools, context, permissions, workspace, state, and feedback around the model | What can this worker see and do, and where can a mistake land? |
| Context engineering | Choosing and updating the information available for the next decision | Which product facts are required, current, sensitive, or distracting? |
| Backpressure | Feedback or a gate that blocks forward progress until the current work is proven | Which failure should stop the line before it reaches a reviewer or user? |
| Work graph | Durable jobs plus their dependencies, owners, states, and evidence | What can run now, what must wait, and who owns the result? |
| Orchestration | Routing work, workers, workspaces, budgets, handoffs, and integration across loops | Does coordination remove a real bottleneck or create another system to operate? |
| Observability | A usable record of what the agent saw, did, changed, spent, and failed | Can the team explain a result and diagnose a bad run? |
| Eval | A realistic scenario with an explicit scoring rule, repeated across versions | What evidence would justify wider use or more autonomy? |
| Agentic engineering | Designing and improving the complete system around agents, not only selecting a model | Who owns the briefs, context, tools, controls, proof, and learning loop? |
An eval is broader than a conventional software test when the result needs judgment. Anthropic's January 9, 2026 evaluation guide describes task suites, graders, and run transcripts. For a product team, that means keeping realistic examples, defining what good looks like, and checking both the final result and the path taken to reach it.
Observability makes those paths available. It is the flight recorder for a run, including context retrieved, tools called, decisions made, checks passed, time spent, cost, and reasons for stopping. Useful observability helps an owner diagnose the system quickly; raw logs without a reader do not.
What do the strongest counterweights add?
The factory metaphor makes output easy to imagine. Four writers sharpen what the metaphor leaves out.
Skilled operators still supply judgment
Simon Willison's June 18, 2025 account describes a coding agent as a tool-using loop directed by someone who understands both the domain and the agent's capabilities. The operator specifies the task, reviews the result, finds gaps, and steers again. This is a useful correction to headcount forecasts: autonomy on a task does not transfer product accountability to a model.
Context is a designed boundary
Böckeler separates reusable instructions, general guidance, tools, skills, codebase structure, and conversation history. Her framing makes context a set of product choices rather than a document dump. A PM should ask who owns each source, how current it is, whether the agent should load it automatically, and what happens when important context is absent.
Generated code still has an owner
Armin Ronacher's September 29, 2025 report describes an infrastructure project of roughly 40,000 lines in which he estimated that AI wrote more than 90 percent of the code. He also says he retained the system design, reviewed the work, constrained what the agent could decide, and remained responsible for production behavior. High code-generation share and high human ownership can coexist.
Software carries a theory of the product
Peter Naur's 1985 paper “Programming as theory building” predates coding agents. It locates the primary result of programming in human understanding of how a program maps to the real-world problem. As agents generate more of the artifact, the team still needs a maintained and tested theory of the customer, the rules, and the intended behavior.
Specifications, examples, evals, traces, and architecture can make parts of that theory inspectable. They do not eliminate the need for people who understand why the system should behave one way rather than another.
Where should a product team start, and how should the layers combine?
Treat the visions as layers that can combine, then start with the bounded production line. Choose one recurring job, define the user outcome and stop rules, prepare one safe agent harness, add one fast proof loop, and measure accepted delivery rather than generated activity.
Use an embedded loop when the product or repository needs iterative discovery and each step leaves strong, recoverable evidence. Keep the goal stable, the next action small, and the backpressure close to the change.
Add a work graph and multi-agent orchestration only after three conditions are true:
- There is enough independent work to benefit from parallel execution.
- Work state, dependencies, ownership, and evidence survive any one agent session.
- Review, integration, release, and incident response can absorb the added output.
No cited public evidence compares these three design emphases in a controlled study. Ramp and Stripe report bounded systems inside their companies. Huntley and Yegge report and forecast from systems they built. The counterweights are practitioner accounts and one earlier theory of programming. A product team should treat each as a source of design hypotheses, then use its own evals, delivery measures, and incidents to decide which additional layer earns a wider role.