What Is an AI Software Factory? And How to Run One Without Code (2026)

In 1968, a General Electric engineer named R. W. Bemer proposed that software should be built the way cars are built: in a controlled environment, with standard tools, and with every step measured. Almost sixty years later, the idea is back under a new name. Vendors, consultancies and open-source builders now all write about the AI software factory, and Hacker News stories with "software factory" in the title went from 6 in 2025 to 77 in 2026 so far.

The new version keeps Bemer's line and replaces most of the workers with AI agents. A request goes in, agents write a spec, build, review and test, and a person approves what ships. This guide explains what an AI software factory is, where it came from, how the loop works, how to measure it and why a person still approves. The second half shows how a team that does not code can run the same loop and get a working app at the end of it, not a pull request.

TL;DR: An AI software factory is a controlled loop where AI agents spec, build, review and test each change, and people design the gates and approve what ships. It started with Bemer's 1968 proposal and Hitachi's 1969 Software Works. Teams without engineers can run the same loop in Taskade Genesis, free with 3 apps. Build your first app →

What Is an AI Software Factory?

An AI software factory is a controlled, measured loop that turns requests into shipped software, with AI agents doing most of the work at each stage. People design the loop, set the gates and approve what ships. The factory is the environment and the measurement around the agents, not any single agent.

That last point matters most. A coding agent such as Devin completes a task and stops at a diff or a pull request. A factory runs the whole system around many tasks: where the work comes from, which stage checks what, who approves, how the change reaches users, and how each run gets recorded so the team can measure and improve it. The agents are the workers. The factory is the line.

Three other meanings of "factory" share the word and cause confusion:

A useful one-line test: if you remove the agents and the loop still has stages, gates and a record of each step, you have a factory. If you remove the agents and nothing is left, you had an agent, not a factory.

The 2026 version also changes who does the work inside the line. AI agents now fill the gaps between the deterministic stages. Tests, linters and builds were already automatic. What stayed manual was the unstructured thinking between them: reading a vague request, writing the spec, reviewing a diff, deciding whether a change is safe. That is the work agents took over, and it is why the old factory idea came back.

Where Did the Software Factory Idea Come From?

The software factory idea is older than most of the software in use today. R. W. Bemer of General Electric proposed it in the late 1960s, Hitachi built the first one in 1969, and Japanese companies ran software factories at scale through the 1970s and 1980s. AI agents are the newest workers on a line that is almost sixty years old.

Bemer's Proposal (1965 to 1968)

R. W. "Bob" Bemer coined the term while he worked at General Electric. The usual date is 1968: an IFIP 68 position paper on the economics of program production, and a NATO working paper titled "Machine-controlled production environment". Bemer himself wrote that the idea first appeared in his 1965 IFIP paper. Historian Michael Mahoney quotes the factory as "a programming environment residing upon and controlled by a computer".

Bemer's goals read like a 2026 factory pitch: higher programmer effectiveness, less time and lower cost, all tracked with historical data. He also wrote that it must be impossible to produce programs outside the environment. That rule is the ancestor of every modern rule that says nothing merges without passing the pipeline.

Hitachi and the Japanese Software Factories (1969 to 1991)

Hitachi turned the proposal into a building. In his 1991 book Japan's Software Factories: A Challenge to U.S. Management, MIT professor Michael Cusumano writes that Hitachi in 1969 "first established a software facility labeled and managed as a factory". Chapters on SDC, Toshiba, NEC and Fujitsu follow. The Japanese factories treated software as a product with a set cost and a set quality, and they measured reuse, defects and output per person.

The lesson that carried forward: a factory is a management system before it is a tool. The same people, with the same skills, produced more and better software when the process was standard and measured.

Product Lines and CI/CD (2003 to the 2010s)

Jack Greenfield and Keith Short of Microsoft revived the term in 2004 with Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Their factory was a kit for one family of applications that share an architecture, which the field calls a software product line.

Then continuous integration and continuous delivery made the deterministic stages automatic. Every commit could build, test and deploy with no person in the middle. The factory line existed. What it lacked was a worker that could handle the parts between the checks.

The Agentic Wave (2025 to 2026)

Agents filled that gap. In 2025 and 2026, many teams published their own factory designs within a few months of each other.

Two building blocks made the do-it-yourself version possible. The first is harness engineering, the work of shaping the environment an agent runs in: docs in the repository, a git worktree per agent, linters and tests the agent can read. Our guide to the agent harness covers that layer. The second is Claude Code subagents and skills. A subagent is a Markdown file with its own instructions and its own model, and a skill is a packaged workflow that you call with a slash command. Put a skill in charge of a few subagents and you have a small factory. Our review of Claude Code skills shows how teams use them.

This wave is what people mean by agentic software factory: the same line Bemer drew, now staffed by agents. The broader practice behind it is agentic engineering, where engineers design the system that the agents work in instead of writing every line.

How Does an AI Software Factory Work?

An AI software factory works as an eight-stage loop: intake, spec, build, review, approve, deploy, monitor and improve. Agents do most of the work inside each stage, automatic checks run between stages, and a person sits at the approval gate. Every run is stored, so the team can measure the loop and make it better.

The diagram shows one pass. In a real factory, stage 8 feeds stage 1: a production error becomes a new request, and a repeated review failure becomes a change to the factory itself.

Three design rules show up in almost every serious factory:

1. Spec before code. An agent that starts from a written spec builds the right thing more often, and a person can check the spec in a minute instead of a diff in an hour.
2. Agents in the gaps, machines at the checks. Deterministic steps such as tests, lint and builds stay deterministic. Agents handle only the parts that need judgment.
3. Store every run. A factory that does not record its runs cannot measure itself, and a factory that cannot measure itself is a set of scripts.

The position of the person in this loop has a name: human in the loop. The rest of this article returns to that position, because it is where factories differ most.

Two Ways to Build a Software Factory

Two factory talks from October 2026 show the two main ways to build one. ZazenCodes builds a small factory inside one repository with Claude Code skills, subagents and Markdown files. Zach Lloyd of Warp describes the factory as infrastructure: defined in code, measured, scored and improved by agents. The first fits one developer. The second fits a company.

The Do-It-Yourself Factory in Claude Code

In Build Your Own AI Software Factory with Claude Code (ZazenCodes, October 7, 2026, sponsored by Anthropic), the host builds a factory inside his own website repository with one long prompt. The result is one skill, a set of subagents, a backlog file and a dashboard.

The loop is easy to copy:

1. A spec writer turns the request into a spec file.
2. A builder checks out a factory branch, builds the feature and writes a build file.
3. Four reviewers (security, UX, UI design and code) run in parallel and send findings back.
4. The review loop stops after two rounds, so a stuck job cannot burn money forever.
5. An approver merges a safe change and escalates anything risky. In his case, billing and course access always go to a person.

His first job shows why the approver matters. The approver escalated the change, he read the reason in the dashboard, and he approved it by hand. He then asked Claude Code to add git worktree support so that several jobs could run at once, and he noted that the factory itself was able to build that change. His advice is the best line in the talk: build a small factory and understand it, instead of copying a large one you cannot read. If you want to compare this style of tool, see our list of Claude Code alternatives.

The Factory as Infrastructure

In the Warp talk below, Zach Lloyd defines a cloud software factory as "a measurable, improvable system": ideas come in, agents triage and spec, agents implement and review, agents verify, the change ships through CI/CD, and the factory monitors the result. A person can join at each stage.

Lloyd gives four properties for a factory platform: it is infrastructure that plugs into your tools, it is open to any model and any harness, it is defined in code and versioned, and it keeps your data on your own systems. He then splits engineering into two jobs. Product engineering builds value for customers, now through the factory. Factory engineering tunes the factory itself: which skills, which model mix, which workflow.

The measurement layer is what makes this view different. Every agent run is stored. An LLM-as-judge scores a sample of runs on criteria such as redundant tests. Agents read the failed scores, find repeat problems and open pull requests against the factory definition. Benchmark suites replay real tasks across model and harness settings and plot correctness against cost. For a wider view of the platforms in this space, see our guide to agentic engineering platforms.

Warp's launch post dates the product to August 18, 2026. Its later rollout post of October 15, 2026 reports cost per pull request down from $80 to $20 over six weeks, with a lower revert rate and 40% higher PR throughput. The talk quotes different dollar figures, so cite the post, not the talk.

Light Factory vs Dark Factory: Why a Person Still Approves

A dark factory is a software factory where no person writes or reviews the code, and only machines verify it. A light factory keeps a person at the approval gate, at least for changes where a wrong call is costly. In 2026 most teams that publish their factory designs run a light factory, and the reasons are about trust, not about what agents can type.

The term comes from manufacturing. A "lights-out" plant runs with no people inside, so nobody needs the lights on. Dan Shapiro made it the top level of AI coding in his January 23, 2026 post on the five levels of AI coding, which borrows the levels of driving automation.

What a Dark Factory Looks Like

StrongDM published the best-known example on February 6, 2026. A three-person team set two rules: humans do not write code, and humans do not review code. Scenario tests that the agents cannot see, and a simulated copy of the outside services, replace review. Two days later, a Stanford CodeX post asked the obvious question in its title: built by agents, tested by agents, trusted by whom?

That question is the whole debate. A dark factory can be fast and correct on a narrow, well-specified problem. It can also build the wrong thing at scale, because no person reads what it ships. When the code touches money, personal data or a customer promise, someone has to answer for it, and "the tests passed" is not an answer a customer accepts.

Why Most Factories Stay Light

Addy Osmani's essay Software Factories, Light and Dark (July 20, 2026) frames the choice well. In his words, a lit factory is "the same pipeline with the lights left on where judgment lives." He does not argue for all dark or all light. He argues that people move to the outer loop, where they choose the approach, check the work and approve changes, and that "the hard, skilled job is deciding where to put each switch."

The public factory designs agree with him:

• Vercel's AI SDK factory states that a human stays in control "including merging every change".
• GitHub's Copilot coding agent does not let the person who asked for a pull request approve it.
• The ZazenCodes factory has an approver that escalates risky changes to a person.
• Warp's stack puts human gates in its orchestration layer.

For a business that builds its own tools, the answer is simple: keep the lights on. The person who runs the work is also the best reviewer of the tool that runs it. We made a similar argument in software that runs itself: the software can run on its own, but a person still decides what "right" means.

How Do You Measure a Software Factory?

You measure a software factory per change, not per agent. The five numbers that matter are human touches per change, time to ship, cost per change, revert rate and eval pass rate. Together they show how automated, how fast, how cheap and how safe the line is, and whether the agents still do the job well.

Cost per change replaced total token spend as the headline number in 2026. A team that spends more on tokens but ships twice as many good changes is doing better, not worse. Our guide to AI cost per task explains how to compute that number for your own work.

The eval number needs the most care. Public benchmarks measure general skill. A factory needs evals on its own tasks, because a model that wins a public leaderboard can still fail the job you give it. Taskade applies the same idea to app work in TSK-Bench: a model passes only when it builds a working app, and it is tested again after one follow-up change.

A team without engineers can track the same five numbers in a project. One row per request, with the date it arrived, the date the change went live, how many times a person stepped in and whether the change was rolled back, is enough to see the trend after a month.

Can a Business Without Engineers Run a Software Factory?

Yes, if the factory makes working apps instead of pull requests. A software factory changes a codebase for developers, and its output is a merged pull request. An app factory makes running business apps with their data, for the people who run the work, and its output is a live app that customers and staff use. The loop is the same one layer up.

Every factory in the history above assumes a repository, a CI pipeline and an engineer who tunes the line. Most businesses have none of those. They have a backlog of tool requests that nobody builds: a better client intake, a dashboard the team checks each morning, a tracker that replaces a shared spreadsheet. We wrote about that list in the end of the software backlog, and about the build-or-buy choice it creates in build vs buy software.

The factory levels in the search results stop at the developer. A business needs one more rung:

Here is the difference in one picture. The first flow is how most businesses get a tool change today. The second is the same request through an app factory.

BEFORE: a feature request in a backlog
────────────────────────────────────────────────────────────
 Staff member   "We need a field for the client's budget"
      │
      ▼
 Email or ticket to the vendor or an internal developer
      │
      ▼
 Backlog  (waits days to months, competes with other requests)
      │
      ▼
 Workaround in the meantime: a spreadsheet, a copy-paste step
      │
      ▼
 Change ships, maybe. The workaround often stays.
AFTER: a request to a working app in one loop
────────────────────────────────────────────────────────────
Staff member submits the request form
│
▼
Requests project records it   (memory)
│
▼
AI agent triages it: what, why, which app   (intelligence)
│
▼
Automation assigns the owner and notifies them   (execution)
│
▼
Owner asks Taskade EVE for the change, tests it, publishes
│
▼
Working app with the new field. The request row closes.

The second flow is not a dark factory. A person still approves the change. What disappears is the wait between the request and the person who can make the change, because the person closest to the work can now make it. Our census of what people build with AI shows which tools businesses build first, and our guide to internal tools dashboards shows the most common one.

How to Run an App Factory in Taskade Without Code

You can run an app factory in Taskade with five steps: set up an intake, build the app from one prompt in Taskade Genesis, add AI agents and automations to run it, approve each change in chat with Taskade EVE, then publish and measure. The output is a live app with its database. The Free plan includes 3 apps, so you can start without a card.

Taskade frames the loop as Workspace DNA: projects are memory, agents are intelligence, and automations are execution. Each run writes back into the same workspace, so the next change starts with more context than the last one.

Step 1: Set Up the Intake

Give every request one way in. The intake is a form that adds a row to a Requests project, with fields for who asked, what they need, why, and which app it touches. In Taskade, an AI form can collect the request and start an automation the moment someone submits it.

Keep the intake to one place. A factory with three intakes (email, chat and a form) spends its first hour each day on sorting. If requests already arrive by email or in another tool, an automation can copy them into the same project, because Taskade automations connect to 100+ integrations: triggers pull events in, and actions push data out.

The Requests project is the factory's memory. It holds the history of every change: what was asked, what was built and how long it took. That history is what you measure in Step 5.

Step 2: Build the App From One Prompt in Taskade Genesis

Describe the app in plain words, and Taskade Genesis builds a live app with its database from that one prompt. A good factory prompt names the job, the people who use the app, the records it keeps and the steps it runs. For example:

Build a request tracker for a 12-person operations team.
Staff submit requests with a title, the app it affects,
a priority and a due date. Show a board with To Do,
In Progress, Review and Done columns, plus counts per column
and a list of requests that wait more than 3 days.

You can also start from a kit. The Neon Task Management Dashboard below is a real Taskade Genesis app kit, not a mockup. It tracks tasks, owners and progress on one board, which is the shape of a factory work queue. Click around in it.

▲ ■ ●  This app is live. The board, the counts and the records all come from the workspace behind it.

The kit includes automations, so cloning it needs a paid plan. On Free, describe the app in Taskade Genesis instead and build the automations yourself. More kits for common jobs are in the Taskade app gallery. To learn how the builder works, read the Taskade Genesis guide.

Step 3: Add the Workers: AI Agents and Automations

A factory needs workers at the stations. In Taskade, AI agents are the workers that think, and automations are the workers that act.

Give the triage agent knowledge it can use: a short document that lists your apps, who owns each one and which requests are urgent. AI agents in Taskade work with knowledge and tools, and they can read the web for research. They do not drive a browser or click through other sites.

A multi-stage approval, such as manager then finance, is the same pattern with more stations. Our approval workflow tutorial builds one with built-in steps.

Step 4: Review and Approve in Chat With Taskade EVE

The review gate is where a person decides. Before you ask for a change to a live app, set the app to publish manually. With automatic publishing, a saved change reaches visitors right away. The owner opens the app and asks Taskade EVE for the change in chat, for example "add a Budget field to the request form and show it on the board". Taskade EVE builds and edits the app in the same chat, and with manual publishing on, the owner sees the preview before anyone else does.

Then the owner verifies the outcome, not the code:

1. Submit a real request through the form.
2. Check the new row and the new field in the Requests project.
3. Confirm that the automation ran and that the agent used the new field.
4. Open the app as a second account, to see what other people see.

If the app has client sign-in, remember what it does. Client sign-in works on every Taskade plan, Free included, and it confirms who the visitor is. It does not hide other people's records on its own. You match records to the login and test that with the second account.

Taskade Genesis keeps saved app revisions that you can preview and restore, and a Live badge shows which revision visitors use. Set the app to publish manually if you want every change to wait for this approval. That one setting is what keeps your factory light.

Step 5: Publish, Measure and Repeat

Publish the approved revision, then close the request row with the date. That row is your factory's record. After a few weeks, the Requests project answers the factory questions from the metrics section:

Ask an AI agent to read the project each Friday and summarize the trend: which apps get the most requests, which requests wait longest, and which changes needed a restore. That summary is your improvement stage. Fix the slowest station first, then take the next request.

For a longer walkthrough of a first build, see our guide on how to build an internal tool without code. Plans and limits are on the pricing page.

Factory Primitives: Code Factory vs Taskade App Factory

Every factory primitive in the two talks has an app-factory version, but not every one has a Taskade feature today. The table maps each primitive to what Taskade ships, so you can see where the app factory is complete and where a person or a workaround fills the gap.

What Taskade Does Not Do

Taskade is an app factory, not a code factory, and some code-factory features have no Taskade version. Know these limits before you choose, because they decide which kind of factory fits your work.

When to Choose a Code Factory Instead

Choose a code factory when your product is a codebase. A SaaS product, a mobile app, a public API or a large repository with tests and a release process all fit tools such as Claude Code, Factory, Warp Factories or the GitHub Copilot coding agent. Those tools speak Git, run your tests and open pull requests your engineers review.

Choose an app factory when the output is a business tool and the person who asks is the person who runs the work. A client portal, a CRM view, an intake form, a tracker or an operations dashboard does not need a repository. It needs a live app, its data, and agents and automations that keep it working. Our guide to agentic engineering without code covers the same choice from the agent side.

Many teams use both. Engineers run a code factory on the product, and the operations, sales and support teams run an app factory on the tools around it.

Related Reading

• Best software factory tools in 2026: code factories for engineers and app factories for teams who do not code
• Free AI app builders: where to start an app factory on a free plan

Frequently Asked Questions