Software Factory

A human-built-and-operated automated software-delivery system in which codified, reusable agentic loops design, code, and verify changes into an existing system under human-set constraints — the developer builds and operates the factory rather than hand-coding the product.

Also known as: software factories, the backbone that builds the system, backbone that builds the system

Part of: Agentic Engineering

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (9)

• #ai #programming #softwareengineering | Addy Osmani | 11 comments Addy Osmani · 2026-10-08 source ↗ Reader 🖥️
  Software engineering has entered a third generation of AI coding tools — autonomous agents taking a spec and running for hours or days — where the engineer's job shifts from writing code to building and operating the 'factory' that orchestrates fleets of agents, and the decisive skill becomes specification clarity and verification rather than code generation.
• Cloudflare Introduces the Agent Development Lifecycle to Replace Traditional SDLC Olimpiu Pop · 2026-09-21 source ↗ Reader 🖥️
  Because AI models have made code generation fast, the bottleneck in software delivery has shifted downstream to testing, deployment, and maintenance, so Cloudflare argues the entire SDLC must be rebuilt as an event-driven 'Agent Development Lifecycle' — with Workflows as the orchestration primitive, OpenTelemetry-style observability into agent reasoning, and machine-speed security enforcement (short-lived scoped credentials plus a dynamically-narrowing 'Trust Ratchet') replacing human-paced review gates.
• Own the Outer Loop Addy Osmani · 2026-09-09 source ↗ Reader 🖥️
  Because agents supply capability but cannot inherit consequence, engineers must own the 'outer loop' of agentic systems — the boundary where Quality (checks/evidence), Verdict (the ship/block decision), and Answerability (the guarantee of being able to explain why) live — which means personal, attributable accountability, not code-writing skill, is what becomes scarce and valuable as harnesses, loops, fleets, and software factories absorb the inner work.
• Inside a Software Factory Paul Iusztin · 2026-09-04 Reader 🖥️
  A 'software factory' — a human-operated automated pipeline of eight SDLC stages over a shared context layer — is the right unit of analysis for disciplined AI-assisted development because it locates humans precisely at brainstorming, planning, and final review while agents execute everything between, and the engineering skill lies not in maximizing automation but in calibrating how much of the factory to build, buy, or leave manual as team scale and trust in the plan grow.
• Human judgment doesn't leave the software factory. It relocates. Addy Osmani · 2026-08-21 source ↗ Reader 🖥️
  As software development moves from hand-coding to operating repeatable, event-driven 'software factories' of coding agents, human judgment does not leave the loop -- it relocates upstream to intent, system design, and the quality bar, and downstream to verification design, risk, and ownership of what ships -- so the best factories are defined by how intelligently they place human attention, not by how completely they remove it.
• What the Hell Is a Loop, Anyway? Laurie Voss · 2026-07-29 source ↗ Reader 🖥️
  The word 'loop' in mid-2026 AI-engineering hype names at least four architecturally distinct systems — execution, task, product, and system loops, each defined by what it iterates on and what ends it — plus an unnamed fifth ring above them, the oversight loop, where a human sets goals, allocates budget, and culls work; so the real engineering question isn't whether to build loops or which camp in the autonomy debate is right, but what information is needed to set the autonomy dial correctly at each of those five levels.
• Software Factories, Light and Dark AddyOsmani.com · 2026-07-20 source ↗ Reader 🖥️
  Because verification, not generation, is the real bottleneck of an AI-driven 'software factory,' an engineer's central job is to decide loop by loop how much autonomy each part of the pipeline can earn — full automation ('dark') only where a check is cheap, fast, and hard to fake, human judgment ('lit') everywhere else — with the human's own role relocating from writing code to owning and verifying that outer decision.
• Looking back at the Future of Software Engineering unconference Bartosz Ocytko · 2026-07-07 source ↗ Reader 🖥️
  As agentic engineering matures into human-built-and-operated 'software factories,' the decisive questions of software engineering shift from raw automation to governance — where human judgment and sign-off sit in the automated loop, how platforms (rather than universal upskilling) safely absorb citizen developers, what would keep developer tooling relevant, and how organizations manage the widening gap between teams that codify their processes early and those that don't.
• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering Addy Osmani, Shubham Saboo, Sokratis Kartakis · 2026-06-15 Reader 🖥️
  As AI increasingly handles code generation itself, what separates production-grade 'agentic engineering' from risky 'vibe coding' is not which AI tool a team uses but how deliberately it designs and maintains the harness, verification (tests + evals), and context around the model — so the discipline a team already has is what AI amplifies, for better or worse.

Propositions touching this concept (19)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• explicitdevelopedA software factory is many harnessed agentic loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the whole system from above — an org chart made of loops, not a bigger single agent.
  Software Factories, Light and Dark · p1
• explicitestablishedBack pressure — you can only hand a loop as much autonomy as you can cheaply and reliably verify, 'and not one inch more' — makes verification, not generation, the actual constraint on how fast a software factory can run.
  Software Factories, Light and Dark · p10
• implicitThe review-gate bottleneck is a structural feature of any software factory, not an artifact of current tooling immaturity — it can be relocated (upstream to design, or distributed into cheap automated oracles) but never eliminated.
  Software Factories, Light and Dark · p22
• explicitdevelopedThe endpoint of agentic engineering is a largely self-evolving 'software factory' in which a feature request is built into the existing system, and which humans build and operate rather than hand-code.
  Looking back at the Future of Software Engineering unconference · p1
• explicitFor the foreseeable future the developer's role is to build and operate the backbone that builds the system and to set the constraints under which the system is allowed to evolve, rather than to write the application code.
  Looking back at the Future of Software Engineering unconference · p6
• explicitThe product loop ('software factory') iterates continuously on an entire codebase and its backlog, and its closing signals come from outside the codebase entirely — new issues, production logs, user feedback, review outcomes — unlike the task and execution loops, which have defined exit conditions.
  What the Hell Is a Loop, Anyway? · p4
• implicitThe industry's task-loop (Ralph loop) and product-loop (software factory) architectures are treated as points on one composable continuum — nestable inside each other — even though they operate on very different artifacts (a single spec vs. an entire codebase-and-backlog) and radically different timescales (minutes-to-hours vs. indefinitely ongoing).
  What the Hell Is a Loop, Anyway? · p14

2026-08

• explicitA software factory is a repeatable, event-driven loop around software work (triage, implement, test, review, ship), distinct from running a stock coding harness (Claude Code, Codex) across ad hoc sessions; a dedicated factory becomes worth building specifically when work needs to be repeatable and event-driven, triggered by an incoming queue (issues, Slack messages, a backlog).
  Human judgment doesn't leave the software factory. It relocates. · p1
• explicitestablishedHuman judgment does not leave the software factory as agent autonomy increases; it relocates -- upstream into intent, system design, and the quality bar, and downstream into evidence, risk, and ownership of what ships.
  Human judgment doesn't leave the software factory. It relocates. · p2
• explicitEvery approach to scaling a software factory still routes its output to one person's (the reviewer's) attention, so a factory should be evaluated by how much cheaper it makes the decisions that person still has to make, not by raw throughput.
  Human judgment doesn't leave the software factory. It relocates. · p8
• explicitSoftware factories should encode team/engineering culture and explicit ownership into the system itself (branch protection, scoped prompts, constraints on what an agent may touch) specifically to prevent mistakes an individual's attention could otherwise make -- such as pasting one project's prompt into another project's session -- rather than relying on an individual never lapsing.
  Human judgment doesn't leave the software factory. It relocates. · p9
• explicitBefore building a custom software factory, teams should consider buying one (Factory, Warp, HumanLayer) rather than assuming they need to build the orchestration, queueing, and handoff infrastructure themselves; many individual and team workloads run fine on a stock coding harness without a factory at all.
  Human judgment doesn't leave the software factory. It relocates. · p12

2026-09

• explicitA software factory is a human-operated pipeline of eight stages (triage/intake, brainstorming, planning, implementing, review, review-CI, release, monitor/incident-response), organized into three buckets (what to build, actual building and checking, self-improving) and run over a shared context layer.
  Inside a Software Factory · p1
• explicitThe clear line between vibe coding and disciplined, maintainable use of coding agents is defined by whether a software factory — process and gates — sits around the agent.
  Inside a Software Factory · p2
• explicitA software factory should expose two interfaces — granular single-step commands for human-directed control, and one chained end-to-end command for full autonomy — with planning kept as its own separate, always human-driven command regardless of which mode is used.
  Inside a Software Factory · p11
• explicitcontestedA software factory is fundamentally about process, not tools; a factory that doesn't fit how a team already works adds friction, never gets adopted, and ends up useless.
  Inside a Software Factory · p16
• explicitA claim that someone has 'cracked' the software factory problem should be read skeptically: it usually indicates either insufficient testing of the idea or an attempt to sell it.
  Inside a Software Factory · p18
• explicitEngineers must own the outer loop — the accountability for agentic systems (harnesses, loops, fleets, software factories) — and this becomes more true, not less, as more powerful models become available.
  Own the Outer Loop · p1
• explicitBrownfield systems are the hardest frontier for scaling software factories, because their legacy — production behavior, migration histories, unspoken assumptions, edge cases, and accumulated scars — must be converted into explicit constraints tied to objective evidence before agents can be trusted with them.
  Own the Outer Loop · p21

Tensions

Open gaps (11)

• incompleteThe 'lit factory' safety net (types, seams, legible layout, bounded components, dependency injection) is presented as something teams 'have always talked about,' but the article never addresses teams that don't already have it — there's no stated path from a weak-architecture brownfield codebase to the lit-factory's prerequisites, leaving exactly the population most at risk of comprehension debt without a remediation route. This echoes an already-flagged gap elsewhere in the corpus about the same unstated-prerequisite problem for 'software factory' claims generally.
  Software Factories, Light and Dark — read next: Read on legacy modernization and evolutionary architecture for how under-resourced teams retrofit the architectural prerequisites (types, seams, boundaries) the lit-factory model assumes.
• illogicalThe piece argues both that free-running loops are dangerously unstructured (motivating the pivot to explicit graphs) and that short, low-stakes loops (the nightly lint-fix cron) legitimately earn full autonomy without any explicit graph structure — it never reconciles when a loop needs graph-discipline versus when it's fine to run as a pure loop; length and stakes are offered as the answer for automation-worthiness, but that criterion is never explicitly connected back to the separate loop-vs-graph argument.
  Software Factories, Light and Dark — read next: Read for a unified framework connecting loop-length/stakes-based autonomy criteria with graph/state-machine architecture choices, rather than treating them as two independent recommendations.
• incompleteThe rule of thumb that 'an agent holds up for three to ten steps, then starts losing the thread past twenty' is stated (attributed to Dex Horthy) without any grounding for why that specific numeric range holds, what model or context window it was measured against, or whether it's expected to shift as context windows and context-management techniques improve — it's treated as a durable constant rather than a fast-moving, model-dependent empirical measurement.
  Software Factories, Light and Dark — read next: Look for benchmark data on agent step-count reliability across model generations and context-management techniques, to see whether this threshold is already stale.
• incompleteThe Squid v1 failure ('something went off-script... I couldn't debug it, couldn't halt it mid-run') is never described concretely — what broke, how it manifested, how long it ran undetected — so it functions as an origin myth justifying the granular-vs-autonomous design rule without evidence that granular commands would actually have prevented the same failure on a different task.
  Inside a Software Factory — read next: Compare against extract-addy-osmani-software-factories-light-dark#p9, which reports a similar personal failure (a fully automated pipeline running about four months before a serious bug was found) in far more concrete terms — useful for testing whether Iusztin's vaguer account describes the same underlying failure mode.
• incompleteThe build→buy→build-again curve across organizational scale rests on exactly two data points at the extremes — the author's own solo practice at the small end, and OpenAI's self-reported internal Codex pipeline at the largest end — with no examples, metrics, or switching-cost discussion from the broad middle range (roughly 10-100 engineers) where most organizations actually operate.
  Inside a Software Factory — read next: Look for practitioner reports from mid-size engineering orgs that have adopted or abandoned Factory.ai or Warp's Oz, to test whether the two-endpoint curve generalizes or whether the middle regime behaves differently than either anchor suggests.
• illogicalThe article opens by criticizing '___ engineering' neologisms (loop engineering, graph engineering) as marketing talk that overtheorizes intuitive, already-established practice, then spends its own middle section formalizing 'software factory' into an eight-stage taxonomy with its own new vocabulary (context layer, ADR-plus-glossary as planning output, grill-the-plan) — the piece never explains why 'software factory' escapes the exact critique it levels at sibling terms.
  Inside a Software Factory — read next: Read against extract-osmani-loop-engineering, which shows the identical pattern (a piece critiquing terminology churn while itself coining new terminology) — useful for testing whether this is a recurring rhetorical feature of the 'next ___ engineering' genre rather than something specific to this author.
• incompleteThe mining study measures public open-source adoption only. The paper itself notes that 'high-volume internal deployments... leave no public trace,' but the headline anecdotes it discusses (Stripe's Minions, 1,300 PRs/week) are exactly such internal deployments. The 0.59% figure is therefore a floor on publicly-visible evidence, not a measure of practice overall, and the paper cannot adjudicate whether loop engineering is genuinely rare or merely rare in public repositories.
  Loop Engineering: Building Blocks, Adoption, and Impact — read next: An internal-tooling survey or structured practitioner-interview study of enterprise/internal loop adoption (the kind this corpus's Stripe and 'software factory' pieces gesture toward) to estimate private adoption rates that public GitHub mining cannot reach.
• incompleteThe claim that traditional SWE skills 'shift up the stack' into spec-writing and verification is asserted without any worked example of what a verification-bound, back-pressure-style allocation rule (deciding which parts of the factory can safely run unverified) actually looks like in practice.
  #ai #programming #softwareengineering | Addy Osmani | 11 comments — read next: extract-addy-osmani-software-factories-light-dark, the author's own later, fuller treatment, which supplies the concrete 'back pressure' rule and the lit/dark factory distinction this post only gestures at.
• incompleteThe essay proposes an 'accountability contract' (checklist understood, evidence, who's accountable, system status) but never specifies how any of these fields get populated from an actual hour-scale agentic run whose intermediate decisions are, by the essay's own admission, not fully recorded and cannot all be traced back to input tokens — leaving the central operational question (how do you produce the evidence you're claiming to own) unanswered.
  Own the Outer Loop — read next: Read Osmani's own 'Quality in the Harness' and 'Software Factories, Light and Dark' for the concrete evidence artifacts (tests, static analysis, review gates) he specifies elsewhere, and read agent-governance / decision-provenance literature for concrete audit-trail mechanisms.
• incompleteThe essay treats the boundary between 'inside the system' (agent capability) and 'outside the system' (human agency: decide/verify/approve/own) as stable scaffolding for the whole Quality/Verdict/Answerability framework, without engaging the possibility — raised in the author's own prior essay — that this boundary must be continuously re-earned as models improve, rather than being a fixed line (design = human, lint-fix = machine).
  Own the Outer Loop — read next: Reread the open gaps on extract-addy-osmani-software-factories-light-dark, especially its critique that the human/machine ownership mapping should be continuously re-earned, and the corpus's agentic-fitness-functions concept (an AI judge already encroaching on the judgment side of the boundary).
• incompleteThe five-ring loop stack (execution/task/product/system/oversight) is asserted and illustrated with separate single-company examples for each tier (Ralph loop, Warp/Oz, Karpathy, Meta, Anthropic), but no single organization is shown running all five tiers simultaneously with visible hand-offs between them — the stack diagram is composed, not demonstrated end-to-end on one real product.
  What the Hell Is a Loop, Anyway? — read next: A case study of one company operating execution-through-oversight loops concurrently on the same codebase, with the actual interfaces (data, triggers, escalation paths) between tiers made explicit.