Does a human have to review every change an AI agent produces? Or should no human read code at all anymore? In the discussion about AI software factories, this question is often answered like a dogma: always or never. This article presents both positions and proposes a third way, in which the risk of each individual change decides.
What Is an AI Software Factory?#
The term software factory is by no means new. As early as 1968, Bob Bemer explored the idea of turning software development from an individual craft into a systematic, repeatable production process.
With the rise of large language models and autonomous AI agents, this idea is experiencing a renaissance. However, there is no generally accepted definition of an AI software factory yet. Three different perspectives shape the current discussion.
1. Software Factory as an Organizational Production System#
Ganesh Datta, CTO of Cortex (June 2026) describes an AI software factory as an organizational system that turns customer needs into reliable software ready for production use. AI agents take over the development work, while software developers increasingly design, operate and improve the production system itself.
The focus is on the changing human role: from software developer to designer of software production.
2. Software Factory as an Automated Development Process#
Zach Lloyd, CEO of Warp (July 2026) defines a cloud software factory as an automation loop around the entire software development lifecycle: from triaging incoming requests and bug reports through specification, implementation, review and verification to shipping and monitoring.
The focus is on a repeatable process in which specialized agents and humans work together and whose quality can be improved continuously.
3. Software Factory as Autonomous Software Production#
Justin McCarthy, CTO of StrongDM AI (February 2026) describes a much more radical approach. Specifications and verifiable scenarios drive the AI agents. The agents implement the software, test it and fix errors on their own. Humans no longer write or review code.
The common ground: An AI software factory is more than a coding agent. It is a reproducible production system in which AI agents take over essential software development tasks, while defined processes, tools and quality controls safeguard the results.
Light and Dark Software Factories#
In his article Software Factories, Light and Dark (July 2026), Addy Osmani distinguishes two fundamental approaches.
Light Software Factory – Human-in-the-Loop#
In a light factory, AI agents take over a large share of the operational development work. Humans, however, remain actively involved in the development and approval process.
They make essential architecture decisions, assess technical solutions and review the agents’ results. Automated tests and quality checks support this work, but do not fundamentally replace human judgment.
This provides control, but it comes at a price: while agents can produce an almost unlimited number of changes in parallel, human attention remains a scarce resource.
The speed of software production is increasingly limited by human reviews, not by code generation.
Dark Software Factory – Lights Out#
The dark factory takes the opposite approach. Here, AI agents produce and verify software without humans having to read or approve individual changes.
Humans still define goals, requirements and constraints. The operational implementation and its verification, however, are fully automated.
This promises enormous throughput. At the same time, new risks emerge.
Osmani warns in particular about comprehension debt: the amount of software produced grows faster than human understanding of its inner workings. In the short term, all tests may pass, while in the long term architectural quality and maintainability suffer.
The crucial question is therefore not whether agents can develop software autonomously, but whether their results can be verified reliably enough without human intervention.
Gray Software Factory – Human-on-Demand#
Do we really have to choose between light and dark?
A light factory regularly demands human attention, even for changes whose risks could possibly be assessed in a fully automated way.
A dark factory, on the other hand, forgoes human case-by-case review, even when certain changes carry risks that automated checks do not reliably capture.
What if the decision about human involvement were itself part of the automated production process?
This is where the idea of a gray software factory comes in.
A gray factory works autonomously by default. Human involvement is not abolished across the board, though, but requested selectively based on an automated risk and quality classification.
Every change goes through automated checks. Based on them, the factory assesses whether the available evidence is sufficient for automatic approval or whether human judgment is required.
For low-risk, sufficiently verified changes, the factory can proceed on its own. For elevated risk, uncertainty or decisions that cannot be verified reliably, a human is brought in.
This is not only about technical errors. Potential security issues, far-reaching architecture decisions or hard-to-estimate effects on existing functionality can also be reasons for a human decision.
What matters is that the factory recognizes its own limits. When a reliable assessment is not possible, uncertainty must not be mistaken for low risk.
Not every change needs a human review. But every change needs a justifiable decision on whether a human review is required.
Not Simply Half Light, Half Dark#
The term gray factory has been used before. For example, Victor Rentea at Devoxx Belgium 2026 uses it to describe the gradual reduction of human code reviews as confidence in automated production grows.
The approach proposed here sets a slightly different focus: it is not the overall degree of automation of a factory that determines human involvement, but the individual assessment of each change.
A gray factory is therefore not necessarily a transitional stage on the way to a dark factory. It can be a permanent operating model.
Humans remain responsible for the rules, quality requirements and boundaries of the production system. But they no longer have to check every single change personally.
Conclusion: Autonomy Has to Be Earned#
The interesting question of the coming years will probably not be whether a software factory involves humans or works fully autonomously.
What will matter is how reliably a production system can judge when it may act autonomously and when human expertise is needed.
A gray software factory attempts to make this decision systematically, and thereby to resolve the apparent contradiction between speed and control.
Its goal is not maximum automation at any cost, but maximum responsible automation.
Instead of a dogma – always human or never human – there is a weighing that is made anew for every change.
Strictly speaking, though, the image of gray only gets it half right. Light that contains all colors is white; when every color is missing, it is black. A gray factory, however, does not simply dim everything evenly. Like a prism, it splits a change into its individual aspects, such as security, architecture or effects on existing functionality, and decides for each of these components whether human judgment makes sense. What looks like a shade of gray from the outside turns out, on closer inspection, to be a spectrum of individual decisions.
Risk decides: as much automation as justifiable, as much human judgment as necessary.
This article was translated from German with AI assistance.