The Dark Factory Still Needs a Night Shift

Lights Out Over the Code

In manufacturing, a dark factory is a plant that runs with the lights switched off. Not as a slogan. Literally off, because robots and CNC cells do not need to see. Material goes in at one end, finished product comes out at the other, and the only humans on site are maintenance staff who show up when something jams.

The software version of that idea has been around for a while, and for most of that time it was a joke. Code generators produced scaffolding somebody still had to rewrite. The lights never really went off.

That has changed. Every model release moves the line a little further. The work that used to be "generate a skeleton and let an engineer finish it" is now closer to "generate the interface, the mappings, the error handling and the tests, and have an engineer approve it". In integration work especially, where a large share of the code is transformation, protocol handling and glue, the share that can be produced without a human writing a line keeps growing.

So the question stops being whether a dark factory is possible and becomes an architecture question: which parts of your system can run with the lights off, and what has to be true for that to be safe.

A dark factory is not a factory without people

This is the part that gets lost. Lights out plants still employ people. They moved. Instead of standing at the line, they sit upstream in process design and downstream in quality control and maintenance.

Software is the same. If nobody reads the implementation, then human judgment has to live somewhere else, and there are only two places left: the specification going in, and the evidence coming out. Everything in between goes dark.

Most teams adopting this get the productivity part immediately and skip the relocation. They generate ten times more code and keep the same thin spec and the same manual test approach they had before. That is not a dark factory. That is an unstaffed line with no quality gate.

Decide where the lights go out

The most useful architectural decision here is not how to generate code. It is where you allow generated code to live.

Good candidates share the same properties: narrow contracts, high repetition, cheap and complete verification. Interface implementations, mappings, adapters, protocol handling, migration code, test fixtures, infrastructure definitions. The kind of work where correctness is decidable by running it against realistic data.

Bad candidates are the opposite: authorization logic, money movement, anything encoding a business rule that exists nowhere else in written form, anything where "correct" is a judgment call rather than a test result. Keep those lit.

The point is not that models cannot write authorization logic. It is that when you cannot verify it cheaply, you have moved risk to a place where nobody is looking.

The spec and the tests become the source code

If the implementation is disposable, then the artifacts you actually maintain are the ones that produce it and prove it.

That means machine readable contracts rather than tribal knowledge: schemas, API definitions, idempotency keys, explicit error semantics. It means a test suite built against production shaped data, not a handful of happy path cases. In one migration I have written about before, the thing that made a big bang cutover defensible was not more people. It was replacing manual testing with automated comparison, so the sentence changed from "we believe the mappings are correct" to "here is the evidence, for all of them".

That shift is a prerequisite for going dark, not a nice to have. Generated code is cheap. Trusted code is not. The cost moved into the harness.

Generate at build time, freeze at runtime

There is a real difference between a dark factory and an agentic runtime, and mixing them up causes most of the trouble I see.

A dark factory produces artifacts. Code that gets committed, versioned, signed, deployed and rolled back like any other release. The non deterministic step happens once, at build time, under review, and what runs in production is a fixed thing you can diff against yesterday.

An agentic runtime decides at execution time. Sometimes that is exactly what you want. But it means the behaviour you debug on Tuesday is not necessarily the behaviour that ran on Monday, and in an enterprise integration layer that is a very expensive property to buy by accident.

Instrument it for someone who has never read it

Observability is usually treated as an operational concern. In a dark factory it is an architectural one, because the person handling the incident has no mental model of the code.

Structured errors that say what failed and on which record. Correlation IDs across every hop. Naming conventions enforced at generation time, not agreed in a wiki. Alerts routed to whoever can act, not broadcast by severity. All of this is worth more than it used to be, because the usual fallback of "ask the engineer who wrote it" no longer exists.

The bill nobody puts in the business case

Here is the downside, and it is not small.

Throughput goes up. Time to first version collapses. And your mean time to repair gets worse, sometimes much worse, at precisely the moment it matters most.

A production incident at two in the morning, in an interface nobody in the room has read, is a different kind of problem. In a real dark factory you can walk onto the floor and turn the lights on. There is no floor here. There is a repository full of correct looking code that somebody has to understand under pressure, and the person best placed to explain it is a model that will happily produce a confident explanation of code it did not write.

The specific failure pattern is worth naming: the fix is fast to generate and slow to trust. You can have a candidate patch in minutes. Establishing that it did not quietly change behaviour in the other three hundred interfaces is where the night goes. And regeneration only helps if the spec was precise enough to exclude the bug in the first place. If it was thin, the model reproduces the same defect with the same confidence, and you have burned an hour proving it.

There is a slower cost underneath that one. Engineers build intuition by reading and fixing systems. Take that away entirely and in two years you have a team that can specify and approve but cannot diagnose. Lights out plants keep a small crew who genuinely know the machines. That is not sentimentality, it is a design requirement.

What I would keep lit

Three things, in every case.

The architecture, because no model is going to tell you which boundaries are load bearing in your business.

The verification, because it is the only thing standing between velocity and a very fast way to be wrong.

And a small number of people who still read the code on purpose, not because the process demands it, but because someone has to be able to walk onto the floor.

The lights go out over the implementation. They never go out over the architecture.