Patrick Debois on Dark Factories: Why Risk, Not Code, Decides What Ships

Patrick Debois joins Benedikt Stemmildt to compare software factories with the CI/CD pipelines he helped popularise as one of the people behind the DevOps movement. Patrick organised the first DevOpsDays in Ghent in 2009, and he is now an independent advisor and Product DevRel Lead at Tessl.

The conversation starts with an observation from Patrick's research into factory products. Most of them automate the same loop of writing, reviewing and deploying code, so the real difference lies elsewhere. Once a factory is expected to act on its own, the important decision becomes whether a change can go to customers without a human reviewing it, and that is a question of risk rather than of code. Patrick argues that architecture absorbs part of that risk, in the same way that a container platform absorbs the failure of a single container.

From there, they discuss how far orchestration can be left to the model. Patrick prefers to turn whatever he can into deterministic checks, and he notices that most teams who start with a loose orchestrator end up building something close to a state machine. He also makes the case for factories that explore as well as build, running research loops and generating options, so that a software factory becomes a dream factory that lets a team try ideas it could never have reached before.

The second half of the episode turns to people and organisations. Patrick sees teams shrinking to four or five people without going below four, roles splitting between the people who run the factory and the people who shape specs and products, and a factory that only creates real value once it is shared across the organisation. He closes with two metrics he uses to judge a factory: how many human touches a process still needs, and how much of the factory's work is reused by others.

• Most factory products automate the same loop of writing, reviewing and deploying code. The harder question is when a change can reach customers without a human reviewing it, and that is a question of risk.
• Architecture absorbs risk. If the parts of a system are compartmentalised, a dark factory can act on its own where a mistake is cheap and leave the payment system to humans.
• Dark factories come in gradations: the level of autonomy should follow the impact and likelihood of a failure, not a single switch for the whole codebase.
• Turn whatever you can into deterministic checks. Teams that start with a loose orchestrator usually end up building something close to a state machine.
• A software factory should explore as well as build. Research loops and generated options make it a dream factory that reaches ideas a team could never have tried before.
• Teams can shrink to four or five people, but Patrick would not go below four, because someone still needs to hold the latent knowledge of the domain and cover when a person leaves.
• Two metrics for a factory: how many human touches a process still needs, and how much of the factory's work is reused by the rest of the organisation.

When Patrick compared companies that sell factory solutions, he found that most of them automate the same loop. They produce code, review it and deploy it, with new capabilities such as AI review and adversarial checks layered on top. Because that loop looks much the same everywhere, he expects the real difference between factories to come from something else: deciding whether a change can go in front of customers without a human looking at it.

That decision has always been there in CI/CD, even if it was rarely automated. Teams could provision a new machine in minutes, but many still kept a manual step for changes such as database schema migrations, because the risk outweighed the time they would save. Patrick sees the same conversation returning with factories, only now the question covers far more of the work and the factory is expected to make the call itself.

His answer is that architecture absorbs part of that risk. A container platform can kill a container and start a new one because the system was designed to tolerate it. In the same way, a codebase split into compartments lets a dark factory act on its own where a mistake is cheap, such as a change of colour, and keep humans involved where it is not, such as a payment system. He also warns that it is a fallacy to believe everything can be tested, because production always behaves differently from a test environment.

This leads Patrick to describe dark factories as a spectrum rather than a switch. For each part of a system, the level of autonomy follows the impact and likelihood of a failure, much like the decisions teams already make before putting something into production. Benedikt notes that this shifts his own framing from trust in the factory to risk, which connects automation to the trust a team has earned in each part of the system.

A common argument at the moment is that factories no longer need fixed pipelines, because an orchestrator can work out the next step on its own. Patrick is sceptical. Language models are poor at some tasks, such as keeping a counter, and in his own tools he has seen a model start inventing database IDs after a while instead of reading them from an API. Because of that, he turns whatever he can into deterministic checks, which are also faster and cheaper than asking a model.

He notices the same pattern in what teams actually build. They often start with a loose orchestrator that picks the next task, and over time they end up with something close to a state machine, with defined steps and transitions. Patrick connects this to a lesson from DevOps: assuming a system will not fail was the fallacy the industry fought for a decade, and assuming it will fail is what forces you to think about risk. Benedikt adds that the right approach also depends on whether someone is watching the agent or the factory is meant to run unattended.

Patrick also wants factories to do more than turn a spec into code. Developers already hand agents research tasks, such as investigating what is causing a bug and coming back with the results. A factory could run research loops of its own and generate several options before anyone writes a line of code. He suggests thinking of it as a dream factory, because the strongest case for its return on investment is the work a team could never have reached before, not only faster testing and deployment.

The same idea extends beyond engineering. Sales, go-to-market and legal teams all run pipelines with intake, triage, work and review, and documentation often falls behind once a factory produces more output. Patrick expects the first generation of factories to settle on the code loop before teams start adding these other pipelines, and he is keen to see that happen.

Patrick does not think agile is dead, because fast feedback and focusing on what matters remain the same practices. What changes is the rhythm. Instead of discussing a change and waiting for engineering capacity, someone can start the factory, create the pull request and leave an engineer to review it. That makes smaller teams possible, moving from around eight people to four or five, although Patrick would not go lower than four.

The reason is the knowledge that sits outside the code. Someone in the team needs to understand what good looks like and what impact a decision will have, and people leave or become unavailable. He describes a team that combines development, product and operations with a backup person, who could be a junior learning alongside the others. A solo developer can skip most of this, but the bus factor and the response time to customers remain the limit.

Patrick expects roles to split roughly into two groups: people who build and run the factory, and people who shape specs, requirements and products. The first group needs a holistic view of prompts, sandboxes, costs and risks, and it is not yet clear whether they will come from AI engineering or from platform teams. He compares the factory to an internal platform that should be run as a product, centralising machinery such as inference gateways and prompt-injection detection while letting teams configure their own flows.

On juniors, Patrick hears both sides. Seniors worry that juniors will lose the chance to learn, while juniors tell him they learn faster than ever with AI. He compares the moment to photography, where phone cameras reduced the number of professional photographers but opened up a whole new world of creators, and to early CI/CD, which was messy until it settled into something newcomers could pick up easily. His advice to anyone starting out is to pick a project they care about and get some skin in the game.

When Benedikt asks how companies should start, Patrick describes a progression he has seen. Developers first tune agents on their own laptops, then check shared context and harnesses into the repository, and finally expose them through a factory that other people can use. That last step had the biggest impact, because it aligned teams on the same standards and let anyone in the company raise a ticket and ask the factory for a change.

He suggests two metrics alongside the usual delivery measures. The first is the number of human touches a process still needs, which should go down where the risk allows it. The second is how much of the factory's work is reused by other people, because a factory that only lives on one laptop makes one person faster, while a shared factory makes the whole organisation better at the work. Patrick points to the centralised engineering groups at large companies such as Uber as examples of this approach.

Patrick does not dismiss factories that run on a single laptop, since they can take one engineer a long way. If a colleague cannot use them, though, the impact stays limited, which is why he describes the path as going from solo to shared to multiplayer. He also asks whether skills should be deployed centrally rather than installed one by one, so that everyone can use the same skill with the right credentials and environment.

Looking further ahead, he expects loops to become installable units, such as a code review loop or a spec-to-code loop, and perhaps one day factory configurations that move from one factory to another. His closing advice is to start playing with factories if you are new to them and, if you are more experienced, to think beyond the coding loop and into the wider business, as senior engineers already do.