A dark factory is a factory where you can switch the lights off, because nobody is standing on the floor anymore. In China, phones are already built that way. In episode 8 of Prompt & Proper, Steffen Ochsenreither from Swiss Post and I take that concept and put it on software development: goal in, finished software out, no human in between. The episode is in German, and this post captures the core of the conversation.
Five Stages to Lights Out#
There are plenty of maturity models around for how you generate code with AI. I compress them into five stages.
Stage 1 is autocomplete. The AI completes, the human sits at the keyboard and types. Stage 2 is the coding assistant. You say “write me a test for this method”, and it writes the test. Stage 3 gets interesting because you have several agents. One helps with development, a second does quality assurance. Loosely coupled, human in the loop.
Stage 4 is full workflows. We implemented one that refines the requirements, writes the test specifications right away and takes over individual coding tasks. Several agents chained together, but not end to end: the human stands inside and reviews what comes out. The companies furthest along on AI coding today sit at this stage.
Stage 5 is the holy grail. I tell the system I would like a CRM, and a CRM pops out the back. That is the dark factory.
Where the Analogy Breaks#
Steffen went straight for the weak spot. In industrial manufacturing, dark factories run highly repetitive processes. Always the same thing, which is exactly why it works.
“Nobody checks whether the address being read off the letter or the parcel is correct.”
In Swiss Post logistics this has been reality for a while. The sorters have error rates, those get monitored, and the bulk of the shipments simply passes through. Anything else would no longer be feasible. So in that sense there already is a dark factory there, up to a point.
Which means the real question is not a technical one. Steffen puts it like this: how far do we accept errors, and how far do we accept the machine making decisions on its own? Given the volume of code an agentic system produces, that becomes the core question. If a CRM pops out the back, how do you still make sure it does what it is supposed to do?
The Difference Between Stage 4 and Stage 5#
At stage 4 you are in the loop. You check the specification, you check the tests, the designs, the code if you want, and you correct as you go.
In a dark factory you no longer intervene. Inside, the system specifies for itself, writes its own tests, implements, and then loops until it satisfies the specification it wrote itself. Watching it develop solutions along the way is genuinely interesting. The catch sits in that subordinate clause: it checks itself against its own document.
The Experiment: a Full V-Model on an Amiga Game#
I set this up twice, once rudimentary and once hardcore. Hardcore meaning a full V-model, from requirements through requirement verification, system design and system verification all the way down to the code. The way you specify properly on the way down and then implement.
The task was not a CRM but a 2D battle robot game from the Amiga that I like. Target: finished enough for Steam. The system asked me a few questions, went off, and at the end there actually was a game.
Would I spend money on that game? No.
That is the point where it gets honest. These models solve a task as efficiently as they can, or to put it differently:
“These damn LLMs are extremely lazy.”
What you get is the average. The robot’s legs move oddly, the ground moves oddly, and then you notice there is no understanding of physics in there. There cannot be. Same for taste. Why is this so dark? It makes it brighter, and it is brighter, but not any nicer to look at.
On cost: the thing churned across a weekend and burned a billion tokens. Steffen guessed 500 to 1000 francs. The invoice came to 145 dollars. Worth remembering: these providers are heavily subsidised right now, so the real cost is higher.
The Specification Beats the Code#
Steffen drew the consequence: you only work at two endpoints now. A clean specification at the front, control of the result at the back. What happens in between barely concerns you.
“The worse my spec is written, the worse my code inevitably gets, because the agent can only interpret what is in there.”
In my case that showed up fairly radically:
“I have to be honest, I did not look at the code. It does not interest me at all.”
That does not hold everywhere, though. At Zühlke we do a lot of critical development, medical devices among them. For a device that pumps a fluid into your body, you want the pump software to work 100 percent. Systems like that will keep being built by humans, and that is where you deliberately keep AI out. The settings dialog or the website next to it: generated.
So we are moving into an era where the specification matters more than the code. There will be subsystems a human implemented because they have to work 100 percent. Everything else gets generated.
Steffen adds a second point that matters operationally. If you let an agent write the specification and the same agent write the tests, the tests end up sitting very close to the spec and pass nicely. Everything outside it falls over.
You do not let your child write the dictation and then mark it as well.
Which model reviews the specification is not a neutral choice either. A review agent on the same LLM tends to be less critical, a different LLM turns ultra critical, which creates problems of its own. As far as I know there are no solid numbers on this yet, the topic is bleeding edge.
How Do You Measure a Dark Factory?#
Steffen raised the question, and it is harder than it sounds. Lines of code? Certainly not. Number of commits? Also no. How much coffee the developer gets to drink because there is nothing to do?
His candidates: how many loopbacks it takes to reach an acceptable result. Plus incident rate and overwrite rate. Token cost is a KPI you watch, but he would put it further back.
I measure on the outcome in the end. The purpose of software is that user behaviour changes, or that the user’s problem is solved and they pay for it. That is a lagging metric unfortunately, it only tells you late whether you got it right. Finding good leading indicators for it strikes me as very hard.
One finding from the experiment that I recognise from classic development: once you have landed at a poor level, it only goes downhill. Turning a bad product into a good one almost never works. You invest a lot of energy just to hold the line.
Same Context, or 50 Islands#
Steffen’s most important closing point is about repeatability. In a larger organisation you want software written to the same standards, so it holds up and other people can maintain it.
“Otherwise it is 50x vibe coding.”
So not 50 little dark factories operating autonomously on their own islands, but 50 running in the same context. The same instructions for how code should look, the same way of writing specs, the same way of producing an outcome.
The POC Graveyard#
Then there is the part I see at many companies and that shows up with dark factories too: proof of concepts that never arrive. You want to put the software into production, and that means monitoring, logging and the whole operational side.
That is exactly what I did not see in my dark factory. The agent does not look at it. This understanding of how you take software to production and run it is the entire DevOps movement, and right now it is being forgotten all over again, because standing up a POC has become so fast. Most of them die on the way to production, or they linger somewhere as zombies.
The Take-Away#
Steffen’s three points at the end of the episode: define your best practices before you start. The challenge is no longer writing the software, it is starting with a good specification. Long development times used to hide that bottleneck, and that is over.
And then the question the episode closes on:
“Does a developer still have to read every line, or is checking the results enough?”
If you enjoy the episode, subscribe to Prompt & Proper on Spotify, Apple Podcasts, Amazon Music or YouTube and tell us which AI topic you are wrestling with right now. All episodes: promptandproper.ai.