A software factory is the shared system a team runs coding agents through, so the gates, the registry and the permission model are owned once. Bigcircle already builds those pieces around a single agent, and making them common to a team is how a software factory starts.
Key facts
Definition
A software factory is a team-owned workflow in which coding agents take specs through shared gates, and the gates, the registry and the permission model live in code the agents cannot edit.
How Bigcircle does it
- On Skionis, Bigcircle measured template errors before deploy falling from around 10% to 4%, and an engineer still approved a diagram of every apply.
- On Solarpunk, Bigcircle has each step search the registry after tool selection went wrong past roughly 30 tools held in context.
- In Bigcircle's harness work, a change to the prompt, the model, the tools or the harness clears an eval suite in CI built from real traffic before a shared change merges.
Comparison
CI/CD runs steps people wrote against code people wrote, while a software factory has agents write the change, so a green test run the agent can edit is one gate and the proof is a check the agent cannot edit.
Key number
Victor Savkin's 6 August 2026 post treats a product that writes 100% of the code as something that will not work.
The permission scope sits in code the agent cannot edit, an eval suite in CI has to clear before a shared change merges, and the completion check reads the system the agent changed.
On Skionis, the DevOps agent we shipped on a live AWS account, that check is a validation loop against the account, and an engineer approves a diagram before anything applies. On Solarpunk, the desktop agent we built for executive operations, each step searches a registry instead of holding the whole tool list in the prompt. Each of those is the harness around one agent. The software factory is the decision to maintain that harness once for the team.
The older meaning is a pipeline that people operate. This guide is the agent meaning. It covers which sense a vendor is selling, what a green CI run still proves once an agent can edit the tests, what the team has to own in code, which work can ship with nobody reading the diff, and when the shared layer is the wrong spend.
For the short definition, and for the accounts that used the term in October 2026, see the AI software factory glossary entry. This guide assumes that definition and goes into the build.
What is a software factory?
Treat a software factory as the harness around one AI agent, maintained once for the team that runs many of them. The agents write the changes. The team owns the gates, the registry and the permission model, in code the agents cannot edit. By the tenth engineer, a copy that lives on each laptop has already drifted, and nobody can say which version of a rule is current.
The figure splits one run from the layer every run shares. A spec for one change reaches an agent in a sandbox, the gates run outside that agent's write access, and a person reviews the evidence before merge. A failed gate returns to the agent with a bound.
Put the gates outside the agent's write access before you share anything else. A gate the agent can rewrite is only a preference, and a shared copy of a preference applies to every engineer at once. In our harness engineering, the permission scope is enforced in code the agent cannot edit, and the harness and its eval suite in CI live in your codebase, where your team can read them.
Build that harness for one agent, and share it only after the one agent survives real work. On Solarpunk, tool selection held until roughly 30 tools sat in context, and then the model picked plausible tools from the wrong system with no sign in its output.
It recovered once each plan step searched the registry for the few tools that step needed. A shared registry that is still pasted whole into every prompt repeats that failure for the whole team.
Keep each recurring task as a playbook with an owner, a version, typed inputs, stop conditions and a check of its own. Our guide to agent playbooks sets out those fields, and skills vs MCP separates a playbook the host loads into context from the access that stays on an MCP server. The procedure belongs in what a plan step searches for. The credential and the side effect stay on the tool.
Run the parallel work across tasks, one change per agent. Agents that split one change, and that cannot see each other's edits, make conflicting decisions that no merge reconciles. Multi-agent orchestration keeps tightly coupled work, which includes most coding, in one agent with continuous context.
What is a factory in coding?
Coding teams have used factory for three different builds, and a vendor page rarely names which one it means. Name the row before you compare products. A template library and a shared harness solve different problems, and the page that blurs them will sell you the wrong one.
| Sense | What it produces | Who operates it |
|---|---|---|
| Component factory | Applications assembled from templates and reusable parts | People, following a schema |
| DevOps factory | Software delivered to one community of users | People, with automation in place of manual work |
| Agent factory | Changes written by coding agents and checked by shared gates | The team owns the gates. The agents write the change |
The component sense is the oldest one in software engineering: a schema, templates and parts, assembled into applications. A lot of older writing still means that, and a model has no part in it. Keep the name in mind when a page talks about reusable code and a factory schema, so you do not brief an agent project against a component catalog.
The DevOps sense is the one public-sector and platform pages still use. The Office of the DoD CIO, in its March 2025 State of DevSecOps, calls a software factory a collection of people, tools and processes that lets teams continuously deliver software to one community of users, using automation in place of manual work. CI, the repository and the issue tracker stay in that picture. An agent factory keeps them and adds the shared harness on top.
Ask which row a vendor is selling, and ask to see the permission scope, the eval gate and the stop. A product whose demo is that it writes the code for you still has to answer those three. The next section is where that answer has to come from.
Software factory vs CI/CD: what does the pipeline still prove?
Keep the pipeline you already trust, and keep a green run in its place once an agent can rewrite the tests. CI/CD runs steps people wrote against code people wrote. In a software factory the agents write the change, so a green test run they can edit is one gate, and the proof is a check they cannot edit.
Order the checks so the ones code can decide run first: the build, the tests, the schema, then a read of the target system. Use a model judge only for a question code cannot decide, which is the line our guide on how to build LLM evals draws. A judge that reads the transcript the agent just wrote is scoring the same story the agent told.
On Skionis we measured template errors before deploy falling from around 10% to 4% once a validation loop read the live account. A template can pass its schema and still be invalid for that account, because limits, quotas, regions and resources already in the account are what the loop reads.
Most of those errors die before AWS is asked to start anything. The reviewer sees an architecture diagram, because raw template diffs are not read carefully at the tenth change of the week, and an engineer still approved every apply.
Victor Savkin's post of 6 August 2026, on the Nx blog, treats a software factory as a workflow, and treats a product that writes 100% of the code as something that will not work. The script in that post tells the agent to open pull requests and make sure CI is green.
Run CI in the harness, from files the agent cannot write, and do not take the agent's word that the run passed. The green result has to come from the pipeline, which the agent cannot edit.
When a check fails, send the work back with a bound. On Skionis, a template that will not come clean after bounded revision goes to a person as a request the agent cannot safely fulfil. Loop engineering is where the cap, the budget and the stop reason live. Share a loop only when that bound is already in the harness. A shared loop with no bound is a run that does not end, copied to every engineer.
What does an AI software factory have to share?
Share the harness only after one agent already runs it on real work. The shared layer is a registry searched at each step, a permission scope enforced in code, an eval gate in CI and a trace of every run in one format. A prompt file on a laptop is a personal copy of one instruction. It is not the layer the team maintains.
In our harness work, the eval suite runs in CI against cases pulled from real traffic. A change to the prompt, the model, the tools or the harness has to clear that suite before it merges. The gate matters more once the change is shared. A playbook or a model change reaches every engineer at once, and reading the diff does not show what each of them will get.
Give each agent a scope enforced in code, following AI agent permissions, and a sandbox for anything that runs code, following AI agent sandboxing. On Skionis the agent is untrusted. It acts only through purpose-built tools, with no general shell and no path from a plan step to an arbitrary API call, and nothing in the system depends on the model being correct. The per-call checks and the approval points are the work of our guardrails service.
Record a trace of every run in one format, so a bad change is something the team can step through. That record is the observability the factory owes you: one shape for every run, whoever started it.
On Solarpunk the trace separates a planning defect from an outage, an expired session, stale state or an unsupported action. The completion check compares what the agent claims with the state of the application, which is also where tool calling has to stay typed, so the claim names a call that actually ran.
Paul Iusztin, writing on O'Reilly Radar on 4 September 2026, built a first version so overbuilt that he stopped using it. He could not halt a run or redirect it without throwing the run away. A stop has to be a state the harness reads, on a flag the agent cannot clear. If you cannot halt the shared run, fix that on the single agent before you copy anything.
Keep one change on one agent when the edits depend on each other. Parallelize across tasks, where each agent can finish its own change without reading the others. A factory that fans one pull request out to several agents will spend the review on conflicts the agents could not see.
What is a dark software factory?
A dark software factory ships code that no person has read, and machines are the only check. Addy Osmani's essay of 20 July 2026, Software Factories, Light and Dark, takes the name from lights-out manufacturing, where the floor runs with nobody on it, and treats the diff as that floor.
The essay attributes a working range of 3 to 10 steps, and a loss of the thread past 20, to Dex Horthy, along with about 4 months of a factory in which nobody read the code.
Our cap is the bound in the harness, set for the class of work, and 3 to 10 steps is not that cap. The point we take from the essay is narrower. A loop earns time with nobody watching only when the check is hard to fake, runs often, and answers immediately, as a type check or a test does. A green suite the agent can edit does not earn that time.
We change what the reviewer reads before we take the reviewer off the change. On Skionis the approval is a diagram of what will exist afterwards.
Engineers who had refused to let the agent near production came to let it own routine cloud changes, and the review step earned that. Every agent we have put into production still has a person approving its consequential actions or reviewing the finished result. AI agent governance is where that rule is set per class of work.
| Class of work | What has to be true first | Where the person stays |
|---|---|---|
| Dependency bump | The tests sit outside the agent's write access, and an independent check reads the result | Can move toward unattended |
| Routine cloud change | A validation loop reads the live account, and the reviewer sees a diagram | An engineer approves every apply |
| Schema migration on a production database | The change is hard to undo | A person stays on it |
| Shared playbook or model change | The eval suite in CI, built from real traffic, has to clear | It reaches every engineer, so the diff is not the review |
Write the class down before the factory takes the work. A dependency bump and a schema migration on a production database are different decisions, and one policy for both will put unread code on the database. Move a class toward unattended only after the check for that class has been in place on the attended runs.
When should you skip a software factory?
Skip the shared layer when the team is small, the repository is one, and engineers already read every diff. Spend that effort on the harness around the agent you already run. The factory starts to pay once agents are spreading faster than anyone can list them, because that is when you can no longer say which playbook is current or which agent runs on whose credentials.
Fix the single agent before you share it, whenever its gates still live in the prompt, whenever you cannot halt a run, or whenever the checks read the transcript. The shared copy will have the same gaps, and it will have them for every engineer. A registry, an eval gate and a stop are the pieces worth copying. A prompt is not.
Leave a product that promises to write all of the code. Savkin's post already treats that promise as something that will not work, and the line we use is the same one we ship: the agent writes the change inside a sandbox, and the team owns the gates.
Warp's page of 17 September 2026 labels a walk-phase factory, on Warp's own account, at roughly 75% of changes to the warp.dev marketing site and 20% to 30% of pull requests, and it labels those figures as Warp's rather than an industry benchmark.
If a vendor cannot show you the permission scope, the eval gate and the stop, you are looking at a demo of generation. Ask for the three, and walk away when the answer is a roadmap.
Common questions
What is a software factory?#
A software factory, in the sense this guide uses, is a team-owned workflow in which coding agents take a spec through shared gates. The gates, the registry and the permission model live in code the agents cannot edit.
The older DevOps sense is a pipeline of people, tools and processes that delivers software to one community of users. Keep the two senses apart when you read a vendor page, because they describe different systems and the buying decision is not the same.
What is an AI software factory?#
An AI software factory is that shared workflow with coding agents doing the writing. The agents are the visible part. The factory is the registry, the permissions, the eval gate and the trace that the team maintains once, in place of one copy on each laptop. Build it by taking the harness that already works around one agent and making that harness the team's, with the same gates for every engineer.
What is a dark software factory?#
A dark software factory is one where people never read the code and machines are the only check. We change what the reviewer reads first, a diagram of the change in place of a raw diff, and we keep a person on consequential actions. Unattended time is for a class of work whose checks sit outside the agent's write access and have already held on the attended runs.
What is a factory in coding?#
In coding, factory has meant three things. One is assembling applications from reusable parts and templates. One is a DevOps pipeline that delivers software to one community of users. One is a shared harness that coding agents run through. Ask which of the three a page means before you compare it with another, or you will score a template library against a permission model.
How does a software factory compare with CI/CD?#
CI/CD still runs the build, the tests and the deploy, and a software factory keeps that pipeline. The new part is that agents write the change, so a green test run is weaker evidence when those agents can edit the tests. Keep CI, run it from files the agent cannot write, and add a read of the system the agent changed before anyone treats the run as done.
When should a team skip a software factory?#
Skip it when a small team on one repository already reads every diff. Build the harness around the one agent first: the permission scope, the eval gate, the completion check and a stop you can actually use. Share that harness when you can no longer say which playbook is current or which agent runs on whose credentials.
Further reading
- Addy Osmani, Software Factories, Light and Dark, 20 July 2026, and the same essay on O'Reilly Radar, republished 18 September 2026. A dark factory as code no person has read, the diff as the floor, and the 3 to 10 step range, the loss of the thread past 20, and the run of about 4 months, which the essay attributes to Dex Horthy.
- Paul Iusztin, Inside a Software Factory, O'Reilly Radar, 4 September 2026. The first version could not be halted or redirected without throwing the run away.
- Victor Savkin, A Software Factory Is a Workflow, Not a Product, Nx, 6 August 2026. A workflow in place of a product, and a script whose prompt tells the agent to make CI green.
- Warp, What is a software factory?, 17 September 2026. Warp labels these as its own figures and not an industry benchmark: a walk-phase factory automates roughly 75% of changes to the warp.dev marketing site and 20% to 30% of pull requests overall.
- Office of the DoD CIO, State of DevSecOps, March 2025. People, tools and processes that deliver software to one community of users.
- VMware, What is a Software Factory?, read 2 November 2026. The DevOps sense: a repeatable path, templates and reusable code. The page shows no date.
- Wikipedia, Software factory, read 2 November 2026. The component-assembly sense, including templates, reusable parts and a factory schema.
- Neely Dunlap, What is a software factory?, Faros, 1 September 2026. Agents, tools, context, workflows, verification and human judgment on the way from an issue until software ships. The statistics on that page are not used here.
- The AI software factory glossary entry, for the October 2026 accounts and the short definition.
- Loop engineering, AI agent governance, why AI agents report unfinished work as done, AI agent permissions, AI agent sandboxing and agent playbooks.
- The Skionis build and the Solarpunk build.
- Agent harness engineering and AI guardrails.