What Is a Software Factory?
September 3, 2026
In 2025, lesson 1-2, What Is the Difference Between an AI Coding Assistant and an AI Coding Agent?, traced the evolution of AI development tools from autocomplete in 2021 to AI agents in 2025. As agents matured in 2026, we went on to cover best practices for working with them in our online course, AI Coding 201 — From Hands-on Practice to Best Practices.
By the second half of 2026, AI agents remained a central topic in the developer community. That conversation also gave rise to a new vocabulary, including harness engineering, loop engineering, and software factories.
This article explores the idea of the software factory: why a decades-old term has resurfaced this year, how an AI-era software factory differs from its predecessors, and what limitations teams face when building one today. We will also look at ways to push beyond those constraints.
What Is a Software Factory?
The software factory is not a new idea. It dates back to at least 1968. Early software factories focused on standardized development environments, tools, processes, and reusable components, all intended to make software production more efficient and scalable.
Their fundamental limitation was that traditional software methods could not handle every source of variation. Whenever requirements changed, existing modules and frameworks were often insufficient, leaving human engineers to resolve differences in requirements, make design judgments, and deal with edge cases. These systems could industrialize software production, but they could not autonomously generate software in the sense being discussed today.
In the AI era, agents are no longer limited to generating code from fixed templates. They can interpret requirements, explore an existing codebase, and produce code adapted to changing circumstances. Given a goal, specification, constraints, and acceptance criteria, an AI agent can potentially continue implementing, testing, and revising a solution with relatively little human intervention. When something goes wrong, it can debug its own work and keep going until the result passes validation.
In 2026, StrongDM unveiled the software factory it had built. Its process is fully automated: humans neither write nor review the code used to implement the software.
StrongDM calls this approach “non-interactive development.” In a conventional agent workflow, a human engineer remains in the loop, communicating with the AI and asking it to make adjustments. In a software factory, the AI instead carries out the entire task by itself, without interacting with a human along the way.
Some people in the community use the term “dark factory” to describe this process. In manufacturing, a dark factory is a facility operated entirely by machines, without people on the factory floor. With no people present, there is no need to turn on the lights—hence the name.
Loops at Scale
Once the concept is clear, the obvious question is: how do you actually automate a software factory?
That brings us to loop engineering, one of the most widely discussed ideas in the community today. Loop engineering is the practice of designing loops for AI agents. Many teams now work this way, with the Claude Code team among the best-known examples. During an Acquired Unplugged interview hosted by WorkOS, Claude Code lead Boris Cherny said, “I don’t prompt Claude anymore… My job is to write loops.”
At a high level, an AI agent can be modeled as a while loop that keeps running until it reaches a termination condition. If the ultimate goal is to complete a feature, the agent continues working until that feature is done.
Writing a loop means designing its conditions. “Stop when the feature is complete,” for example, is far too vague. The loop designer must define what “complete” actually means. The new tests might all need to pass, existing regression tests might also need to pass, and the code might need to match the conventions of the existing codebase. The more explicit and precise these conditions are, the more likely the loop's final output will match the developer's expectations.
StrongDM's approach is illustrated by the following core execution loop from its open-source attractor project:
FUNCTION run(graph, config):
context = new Context()
mirror_graph_attributes(graph, context)
checkpoint = new Checkpoint()
completed_nodes = []
node_outcomes = {}
current_node = find_start_node(graph)
-- Resolves by: (1) shape=Mdiamond, (2) id="start" or "Start"
-- Raises error if not found
WHILE true:
node = graph.nodes[current_node.id]
-- Step 1: Check for terminal node
IF is_terminal(node):
gate_ok, failed_gate = check_goal_gates(graph, node_outcomes)
IF NOT gate_ok AND failed_gate exists:
retry_target = get_retry_target(failed_gate, graph)
IF retry_target exists:
current_node = graph.nodes[retry_target]
CONTINUE
ELSE:
RETURN Outcome(
status=FAIL,
failure_reason="Goal gate unsatisfied and no retry target"
)
RETURN Outcome(status=SUCCESS, notes="Pipeline completed")
-- Step 2: Execute node handler with retry policy
retry_policy = build_retry_policy(node, graph)
outcome = execute_with_retry(node, context, graph, retry_policy)
-- Step 3: Record completion
completed_nodes.append(node.id)
node_outcomes[node.id] = outcome
-- Step 4: Apply context updates from outcome
FOR EACH (key, value) IN outcome.context_updates:
context.set(key, value)
context.set("outcome", outcome.status)
IF outcome.preferred_label is not empty:
context.set("preferred_label", outcome.preferred_label)
-- Step 5: Save checkpoint
checkpoint = create_checkpoint(context, current_node.id, completed_nodes)
save_checkpoint(checkpoint, logs_root)
-- Step 6: Select next edge
next_edge = select_edge(node, outcome, context, graph)
IF next_edge is NONE:
IF outcome.status == FAIL:
RETURN outcome
RETURN Outcome(status=SUCCESS, notes="Pipeline completed")
-- Step 7: Handle loop_restart
IF next_edge has loop_restart=true:
restart_run(graph, config, start_at=next_edge.target)
RETURN
-- Step 8: Advance to next node
current_node = graph.nodes[next_edge.to_node]
RETURN Outcome(status=SUCCESS, notes="Pipeline completed")
The simplified visual flow looks like this: while working on a task, the agent checks whether it has reached the end. If not, it determines whether anything needs to be retried and continues accordingly. When an error occurs—for example, when a test fails—the result is recorded so the agent can address it in the next iteration:
Recent frontier models have become much better at using tools and sustaining long-running agentic work. With the appropriate process defined in the system prompt, an AI agent can follow a loop like this to complete a task. In Expanding Our Long-Running Agents Research Preview, the Cursor team reported that modern frontier models can work continuously for more than 30 hours.
Are Software Factories Really as Good as They Sound?
After reading the description above, many readers will understandably be skeptical. Most people who use AI agents at work still need to intervene periodically to keep them from going off track. Is a dark factory genuinely practical? Some in the community also warn that while this approach might produce a usable product in the short term, a chaotic internal codebase could drive long-term maintenance costs sharply upward.
This model inevitably raises practical problems. For instance, if humans never touch anything, how can a team be sure that the code actually works? The obvious answer is software testing, but that leads to another question: if the AI agent writes both the implementation and the tests, how can it demonstrate that the software behaves as intended rather than merely producing an implementation that satisfies its own tests?
Dex, a prominent engineer in the community and the founder of HumanLayer, wrote at length about his team's experience in Why Software Factories Fail. His conclusion was that even today, the dark factory remains impractical. When the team eventually encountered a problem an agent could not solve and returned to inspect the code, they found an incomprehensible mess. The first time it happened, he spent nearly two weeks untangling AI-generated code. By roughly the third incident, the team decided that starting over would be easier, then spent another two weeks manually reorganizing the codebase.
Dex also noted that he could not find sufficiently complete follow-up data from StrongDM to evaluate long-term outcomes. That absence raises doubts about whether StrongDM's dark factory is genuinely sustainable from a maintenance perspective.
Beyond feasibility, some people question the cost-benefit ratio of software factories. StrongDM's announcement argued that if a software factory is not spending at least $1,000 in tokens per human engineer per day, it still has room for improvement. At $1,000 per engineer for each of 22 working days per month, the annual cost exceeds $250,000. In the context of an Asian company—Taiwan, for example—that is close to the combined annual salaries of four or five senior engineers. Costs at that level have led many people to conclude that a software factory is not necessarily the more economical option.
Despite these criticisms, and although we do not believe fully autonomous, 100% lights-out operation is currently realistic, we still think moving toward that goal is worthwhile. In the next section, we will discuss ways to reduce the need for human intervention when working with AI agents in practice.
Support ExplainThis
If you found this content valuable, please consider supporting our work with a one-time donation of whatever amount feels right to you through this Buy Me a Coffee page.
Creating in-depth technical content takes significant time. Your support helps us continue producing high-quality educational content accessible to everyone.