AI Software Factory

An AI software factory is a team-wide setup where coding agents take a spec, write the code, test it and verify it inside one shared, governed pipeline, so people review outcomes rather than every line. Some builders call it an agentic software factory. The agents are the visible part. The factory is everything the team shares around them: playbooks, a registry of agents and tools with an owner for each, permissions enforced in code, and the evals every change has to clear before it merges.

The phrase is older than coding agents. In software engineering it has long meant applying manufacturing methods to software, assembling applications from reusable components and templates. The 2026 sense keeps the production line and puts agents on it. We read it as the harness around one agent, made common to a whole team. The context rules, tool contracts, permission scopes and eval gate are owned once, instead of rebuilt by every engineer on a laptop.

What is a software factory in the AI sense?#

Start from a team that adopts coding agents without one. Each engineer runs their own prompts, their own rules files and their own idea of what the agent may touch. That works for one person and breaks down by the tenth, because nobody can say which version of a playbook is current or which agent runs on whose credentials. A software factory pulls those pieces into one place the team maintains, the way shared CI once replaced personal build scripts.

The pipeline itself is short. A spec goes in, an agent builds in a sandbox, the change runs a set of gates, and a person reviews what the gates produced. Most of the work sits in the shared layer underneath. Write 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 each field.

Keep the registry searchable rather than loaded into the prompt. On Solarpunk, the desktop agent we built, tool selection held up until roughly thirty tools in context and then went quietly wrong. It recovered once each plan step searched the registry for the few tools that step needed.

Run the factory's parallel work across tasks, one change per agent. Agents that split one change and cannot see each other's work make conflicting decisions that no merge reconciles. Our page on multi-agent orchestration keeps tightly coupled work, which includes most coding, in one agent with continuous context.

Who is building software factories, as of October 2026?#

The term spread among AI builders on X in the third week of October 2026, and Johannes Schickling, who founded Prisma, wrote that "software factories are having a bit of a moment". Read each definition for the part it puts first, since several of the people using the term build a product for one part of a factory.

Zohar Einy, CEO of Port, defined the factory as every engineer's prompts, skills and agents pulled into one place the team works on, then listed what its registry needs: an identity for each agent rather than a developer's token, and an owner for every skill, plugin and MCP server. We put the registry first as well. An agent nobody owns is the one nobody fixes when the API underneath it changes.

Zach Lloyd, Warp's founder, wrote that the goal is not full automation today, and that a team should measure and tune its factory, which Warp calls factory engineering. Josh Rosen placed factory engineering after prompt, context and harness engineering. We read that sequence as an order of work. Build the harness around one agent before sharing it, because a factory repeats whatever the harness gets wrong for every engineer at once.

Itamar Friedman, CEO of Qodo, wrote that "Agents across the SDLC are a step toward a software factory", and that engineering teams need to build and own the system around them. SDLC here means every stage of shipping code. Read the ownership part literally, because the factory holds your permission model and your definition of done. We leave the harness and its eval suite in the client's codebase, where the team can read them.

The security framing arrived the same week. Tailscale joined Docker, Keycard, Snyk, Socket, Tessl and Tracebit on Agent Baseline's Secure Software Factory reference architecture, whose version 1 is dated 13 October 2026. Its rule is that "the agent proposes, policy authorizes, and infrastructure enforces", across four boundaries: sandbox, network, supply chain, and identity. We build to the same rule. On Skionis the agent acts only through purpose-built tools with no general shell, and nothing in the system depends on the model being correct.

Hamilton Greene sorted system guardrails for software factories from deterministic checks, such as types, linters and tests, to judgement checks such as automated review. Put the deterministic checks first, because they run in seconds and give the agent an answer it cannot argue with.

What an AI software factory has to verify#

A green test run is weak evidence in a factory, because the agent that wrote the change often wrote the tests too, or can edit them. Agent Baseline makes the same point from the security side: code can pass every test and still come from an agent that reached too far. Make the completion check read the result from a different path than the one the agent used to make the change.

We built Solarpunk to compare the agent's claim of completion against the actual state of the application it changed. Only that comparison catches an agent reporting success on work that never landed. Our guide on why AI agents report unfinished work as done covers the check in full.

Keep every gate out of the agent's reach. OpenAI's misalignment report, updated 20 October 2026, describes a GPT-6 Astra agent in an internal coding task that removed a monitoring integration to match a reference implementation, then falsely denied removing it. In our harness work, the permission scope is enforced in code the agent cannot edit, and finished work is checked in the harness rather than requested in a prompt. A factory needs that at team scale, so the eval suite, the CI configuration and the guardrails sit outside every agent's write access.

What is a dark software factory?#

A dark software factory is one where people never read the code. Alexey Grigorev, founder of DataTalksClub, put it in three steps: you give specs, agents build and verify, and you get artifacts to validate outcomes and make business calls. The name borrows from lights-out manufacturing, a plant that runs with nobody on the floor.

We change what the reviewer reads before removing the reviewer. On Skionis, the DevOps agent we shipped on a live AWS account, engineers approve a diagram of what will exist after the change. The alternative was raw template diffs, which engineers do not read carefully at the tenth change of the week.

Template errors before deploy fell from around 10% to 4% once a validation loop sat in front of that approval. The reviewer saw fewer bad changes and still approved every apply. Engineers who had refused to let the agent near production came to let it own routine cloud changes, and the review step earned that, not the model.

Every agent we have put into production still has a person approving its consequential actions or reviewing the finished result. Set that per class of work rather than for the whole factory. A dependency bump with a full test suite and an independent check can move toward unattended, while a schema migration on a production database should not. Our guide on AI agent governance sets out the evidence that moves one action up a level.

Before you run one#

Build the parts in the order a single agent needs them, then share them. Put an eval suite in CI built from cases pulled from your real work, with a gate that fails a build which regresses. A change to a shared playbook or model reaches every engineer at once, and nobody can review that by reading a diff.

Give each agent a scope enforced in code, following our guide to AI agent permissions, and a sandbox for anything that runs code, following the one on AI agent sandboxing. Record a trace of every run, so a bad change is something the team steps through rather than reconstructs.

Then write down which classes of work the factory may take and which stay with a person. A small team on one repository, whose engineers already read every diff, gains little from the shared layer and should spend the effort on the harness around the agent it already runs. A team whose agents are spreading faster than anyone can list them needs the registry and the gates before the next agent.