---
schema: "swft.publication/v1"
id: "three-visions-software-factory"
title: "Three visions of the AI software factory"
description: "Compare three composable AI software factory layers: bounded production lines, Ralph agent loops, and multi-agent work graphs, with clear terms and limits."
summary: "An AI software factory can combine a repeatable production line, one outer controller working through a tight repository loop, and an organization of agents coordinating a graph of work. Most product teams should begin with one bounded line, then add longer loops or multiple workers only when proof and coordination can keep up."
canonical: "https://swft.io/ideas/three-visions-of-the-ai-software-factory"
author: "SWFT Editorial"
author_type: "Organization"
published: "2026-09-01"
modified: "2026-09-02"
kind: "analysis"
section: "Ideas"
tags: ["AI software factory", "Ralph loop", "Gas Town", "agent orchestration", "multi-agent systems", "agentic engineering"]
evidence_labels: ["INFERENCE", "OBS", "SELF-REPORT"]
source_ids: ["ai-engineer-worlds-fair-2026", "anthropic-agent-evals", "armin-ronacher-90-percent", "birgitta-context-engineering", "geoffrey-huntley-backpressure", "geoffrey-huntley-loop", "geoffrey-huntley-ralph", "moss-banay-backpressure", "peter-naur-theory-building", "ramp-inspect-background-agent", "ramp-inspect-integrations", "ramp-security-fixes", "simon-willison-skilled-operators", "steve-yegge-future-coding-agents", "steve-yegge-gas-city", "steve-yegge-gas-town", "steve-yegge-shape-things-to-come", "stripe-minions-part-one", "stripe-minions-part-two"]
authorship_disclosure: "AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections."
---

# Three visions of the AI software factory

A practical guide to combining bounded production lines, Huntley's embedded Ralph loop, and Yegge's multi-agent work graph.

> **Authorship:** AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections.

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](https://builders.ramp.com/post/why-we-built-our-background-agent), 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](https://builders.ramp.com/post/100-vulnerabilities-patched-with-0-humans) and [software integrations](https://builders.ramp.com/post/integrations-that-write-themselves) built on the same environment.

In [Stripe's February 9, 2026 account](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents), 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](https://ghuntley.com/ralph/), 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](https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html) also explains that letting an agent decide what to load introduces uncertainty.

Huntley's [January 17, 2026 follow-up](https://ghuntley.com/loop/) 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](https://banay.me/dont-waste-your-backpressure/) describes automated quality and correctness feedback as a way to keep longer agent tasks aligned. [Huntley highlighted that framing](https://ghuntley.com/pressure/) 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](https://yegge.ai/essays/welcome-to-gas-town/), 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](https://yegge.ai/essays/the-future-of-coding-agents/), Yegge argued that coding agents would become workers inside coordinated colonies while acknowledging that Gas Town still needed frequent manual steering. By [April 24](https://yegge.ai/essays/welcome-to-gas-city/), 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](https://yegge.ai/essays/the-shape-of-things-to-come/), 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](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) 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](https://simonwillison.net/2025/Jun/18/coding-agents/) 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](https://lucumr.pocoo.org/2025/9/29/90-percent/) 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”](https://www.sciencedirect.com/science/article/pii/0165607485900328) 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:

1. There is enough independent work to benefit from parallel execution.
2. Work state, dependencies, ownership, and evidence survive any one agent session.
3. 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.

## How we know

- **First-party report (SELF-REPORT)** Ramp and Stripe describe bounded background-agent systems with prepared environments, scoped context, deterministic checks, and human acceptance paths. Sources: [Why We Built Our Own Background Agent](https://builders.ramp.com/post/why-we-built-our-background-agent); [Minions: Stripe's one-shot, end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents); [Minions: Stripe's one-shot, end-to-end coding agents, Part 2](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2).
- **First-party report (SELF-REPORT)** Huntley describes Ralph as a monolithic, single-repository outer loop that may use internal subagents and is tuned through specifications, limited context, observation, and backpressure; his broader evolutionary-software claims remain operator forecasts. Sources: [Ralph Wiggum as a "software engineer"](https://ghuntley.com/ralph/); [everything is a ralph loop](https://ghuntley.com/loop/); [Don't waste your back pressure](https://banay.me/dont-waste-your-backpressure/); [don’t waste your back pressure](https://ghuntley.com/pressure/).
- **First-party report (SELF-REPORT)** Yegge describes Gas Town as an experimental multi-agent orchestrator with persistent work records, dependency graphs, roles, workflows, handoffs, and merge coordination, while warning about its launch-stage complexity. Sources: [Welcome to Gas Town](https://yegge.ai/essays/welcome-to-gas-town/); [The Future of Coding Agents](https://yegge.ai/essays/the-future-of-coding-agents/); [Welcome to Gas City](https://yegge.ai/essays/welcome-to-gas-city/); [The Shape of Things to Come](https://yegge.ai/essays/the-shape-of-things-to-come/).
- **First-party report (SELF-REPORT)** Willison, Böckeler, and Ronacher describe the continuing roles of skilled operation, deliberate context design, architecture, review, and production responsibility in agentic software work. Sources: [Coding agents require skilled operators](https://simonwillison.net/2025/Jun/18/coding-agents/); [Context Engineering for Coding Agents](https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html); [90%](https://lucumr.pocoo.org/2025/9/29/90-percent/).
- **Observed artifact (OBS)** Naur's 1985 paper supplies a pre-agent conceptual counterweight: programming builds a theory of how a system solves a real-world problem, not only program text. Sources: [Programming as theory building](https://www.sciencedirect.com/science/article/pii/0165607485900328).
- **Analysis (INFERENCE)** The three-layer framing, work-graph term, decision sequence, and shared vocabulary are SWFT's synthesis. No cited controlled study ranks these design emphases. Sources: [Why We Built Our Own Background Agent](https://builders.ramp.com/post/why-we-built-our-background-agent); [Minions: Stripe's one-shot, end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents); [everything is a ralph loop](https://ghuntley.com/loop/); [Welcome to Gas Town](https://yegge.ai/essays/welcome-to-gas-town/); [Welcome to Gas City](https://yegge.ai/essays/welcome-to-gas-city/); [The Shape of Things to Come](https://yegge.ai/essays/the-shape-of-things-to-come/); [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents); [AI Engineer World's Fair 2026](https://ai.engineer/worldsfair/2026).

## Sources

- **Observed artifact (OBS)** [AI Engineer World's Fair 2026](https://ai.engineer/worldsfair/2026) — AI Engineer; accessed 2026-09-01. The official 2026 program groups software factories, harness engineering, context engineering, evals, sandboxes, memory, and agentic engineering into dedicated tracks.
- **First-party report (SELF-REPORT)** [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) — Anthropic; published 2026-01-09; accessed 2026-08-31. Practitioner guidance on task suites, graders, transcripts, and evaluation lifecycle for agents.
- **First-party report (SELF-REPORT)** [90%](https://lucumr.pocoo.org/2025/9/29/90-percent/) — Armin Ronacher; published 2025-09-29; accessed 2026-09-01. Ronacher's first-person report of a roughly 40,000-line infrastructure project with more than 90 percent AI-written code, alongside his retained ownership of architecture, review, runtime behavior, and production responsibility.
- **First-party report (SELF-REPORT)** [Context Engineering for Coding Agents](https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html) — Birgitta Böckeler / Martin Fowler; published 2026-02-05; accessed 2026-09-01. Böckeler's practitioner primer on instructions, guidance, tools, skills, codebase context, context-loading decisions, and the cost and reliability limits of supplying too much context.
- **First-party report (SELF-REPORT)** [don’t waste your back pressure](https://ghuntley.com/pressure/) — Geoffrey Huntley; published 2026-01-17; accessed 2026-09-01. Huntley's response to Banay's backpressure essay, explicitly applying its automated-feedback framing to Ralph loops and other agent systems.
- **First-party report (SELF-REPORT)** [everything is a ralph loop](https://ghuntley.com/loop/) — Geoffrey Huntley; published 2026-01-17; accessed 2026-09-01. Huntley's dated operator account and forecast for evolutionary software, including a deliberate preference for a monolithic loop over multi-agent coordination at this stage.
- **First-party report (SELF-REPORT)** [Ralph Wiggum as a "software engineer"](https://ghuntley.com/ralph/) — Geoffrey Huntley; published 2025-07-14; accessed 2026-09-01. Huntley's first-person account of the Ralph technique: a monolithic, single-repository loop that reloads specifications and a plan, performs one item per iteration, and is tuned from observed failures. Its outsourcing and cost claims are not independently verified.
- **First-party report (SELF-REPORT)** [Don't waste your back pressure](https://banay.me/dont-waste-your-backpressure/) — Moss Banay; published 2026-01-17; accessed 2026-09-01. Banay's practitioner account of backpressure as automated quality and correctness feedback that helps an agent detect errors before moving forward. Huntley highlighted and applied this framing to Ralph loops the same day.
- **Observed artifact (OBS)** [Programming as theory building](https://www.sciencedirect.com/science/article/pii/0165607485900328) — Microprocessing and Microprogramming / Elsevier; published 1985-05-01; accessed 2026-09-01. The canonical journal record for Naur's argument that programming primarily builds a human theory of how a program solves a problem, rather than merely producing program text. It predates coding agents and is used here as a conceptual counterweight.
- **First-party report (SELF-REPORT)** [Why We Built Our Own Background Agent](https://builders.ramp.com/post/why-we-built-our-background-agent) — Ramp Builders; published 2026-01-12; accessed 2026-09-01. Ramp's technical account of Inspect's isolated development environments, company context, entry points, attribution, and early adoption.
- **First-party report (SELF-REPORT)** [Integrations That Write Themselves](https://builders.ramp.com/post/integrations-that-write-themselves) — Ramp Builders; published 2026-08-14; accessed 2026-09-01. Ramp's account of a specialized Inspect line that researches APIs, writes deterministic provider modules, tests them, and opens evidence-rich PRs.
- **First-party report (SELF-REPORT)** [We proactively fixed ~100 security issues in 6 days with 0 humans](https://builders.ramp.com/post/100-vulnerabilities-patched-with-0-humans) — Ramp Builders; published 2026-02-20; accessed 2026-09-01. Ramp's account of a detector, adversarial judge, failing-test, and repair pipeline. The zero-human claim ends before human PR review and landing.
- **First-party report (SELF-REPORT)** [Coding agents require skilled operators](https://simonwillison.net/2025/Jun/18/coding-agents/) — Simon Willison; published 2025-06-18; accessed 2026-09-01. Willison's practitioner account of the coding-agent loop and the domain knowledge, tool knowledge, steering, and review supplied by a skilled operator.
- **First-party report (SELF-REPORT)** [The Future of Coding Agents](https://yegge.ai/essays/the-future-of-coding-agents/) — Steve Yegge; published 2026-01-05; accessed 2026-09-01. Yegge's dated forecast that coding agents would become workers inside coordinated colonies, alongside his admission that Gas Town still needed substantial manual steering and course correction.
- **First-party report (SELF-REPORT)** [Welcome to Gas City](https://yegge.ai/essays/welcome-to-gas-city/) — Steve Yegge; published 2026-04-24; accessed 2026-09-01. Yegge's first-party account of Gas City, built by Julian Knutsen and Chris Sells, replacing Gas Town's fixed topology with composable agent packs, a supervisor plane, durable work data, observability, and external sandbox integrations.
- **First-party report (SELF-REPORT)** [Welcome to Gas Town](https://yegge.ai/essays/welcome-to-gas-town/) — Steve Yegge; published 2026-01-01; accessed 2026-09-01. Yegge's launch account for an experimental multi-agent orchestrator built around persistent work records, dependency graphs, named worker roles, durable workflows, merge handling, and human oversight. The post explicitly warns that the system was new, complicated, and not ready for most users.
- **First-party report (SELF-REPORT)** [The Shape of Things to Come](https://yegge.ai/essays/the-shape-of-things-to-come/) — Steve Yegge; accessed 2026-09-01. Yegge's August account says Gas Town failed under a later model, rejects reusable harnesses, and describes Wheelhouse as a bespoke successor with producer, consumer, review, merge, and standing production-agent roles. The operating claims and forecasts remain first-party reports.
- **First-party report (SELF-REPORT)** [Minions: Stripe's one-shot, end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents) — Stripe Dev Blog; published 2026-02-09; accessed 2026-09-01. Stripe's account of Minions' intake surfaces, prewarmed devboxes, Blueprints, scoped context, internal tools, checks, human review, and early scale.
- **First-party report (SELF-REPORT)** [Minions: Stripe's one-shot, end-to-end coding agents, Part 2](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2) — Stripe Dev Blog; published 2026-02-19; accessed 2026-09-01. Stripe's follow-up on directory rules, deterministic retrieval, curated tool access, local checks, selective CI, repair limits, and reviewed output.

## Read next

- [Ramp Inspect: how a background coding agent became factory infrastructure](/companies/ramp-inspect)
- [OpenAI's Codex factory: harness engineering and Symphony orchestration](/companies/openai-codex-symphony)
- [How an AI software factory works](/software-factory-architecture)