At FANUC’s plant near Mount Fuji, robots build other robots for weeks at a time with nobody on the floor. The part worth copying is duller than the robots: every machine there has a reach you could measure with a tape. The welding arm at one station can touch what is in front of it and nothing else, because somebody bolted it down that way.
So a fault at three in the morning stops at a wall that went up before the line ever ran. That physical fact does more to keep the plant under control than any document in the building, and software is arriving at the same place without it.
Everyone is describing the machines
StrongDM has published the charter its AI team started from, which contains two rules: code must not be written by humans, and code must not be reviewed by humans. A team at OpenAI spent five months building an internal product of roughly a million lines across about fifteen hundred pull requests, with no manually written code at all and review pushed almost entirely from people onto other agents. They called that discipline harness engineering. Both of these are running today.
Every account of that work, including the careful ones, describes the stations. Which parts of delivery an agent has taken over. How many pull requests a day. What it looks like when six agents run at once.
None of them say where it stops.
In a plant nobody has to ask, because the answer is visible from the door. The machines are bolted down, the building has walls, the forklift cannot get into the clean room. Ask the same question about a delivery pipeline and the honest answer is that it stops wherever the credentials run out, which is not a fact anybody in the building can state.
Reach is assembled, not declared
The obvious objection is that this is least privilege, and we have had least privilege for twenty years. Scope the accounts, rotate the keys, move on.
That answer works for a script. A build script runs a fixed program, so you can read it and list every system it touches, and the list will be complete, because the program will not decide to do something different on Tuesday. It is all there in the code.
An agent’s reach is put together while it runs. Three things decide it: the tools the station was given, the places its environment blocks it from touching and which of those tools the model reaches for once it has a goal and a look around. The third is decided again every time it runs.
There is no document to read. What your line can touch is a question you have to reconstruct, and reconstruction happens after something has gone wrong. A system chasing a goal also tests a wall rather than stopping at it, which makes an undrawn wall worse than a badly placed one.
The four questions I have written about before still apply: what a system may decide, what happens when it flags something, whether anyone is watching in real time and how far damage travels before it stops. What does not carry over is the part that came free. In a plant the walls answer that last question before anyone writes a policy, because the machines cannot reach past them. In a delivery pipeline every answer has to be built, which is why it keeps not happening. Nobody scheduled the work, because in every system before this one the walls were already there.
Writing the walls down
If you cannot work them out by reading, you have to write them down. Three things make that worth doing.
Every station says how far it reaches, in one place. Both halves: the outside systems it can call, and the plain ability to read files, change them and run commands. The first half feels dangerous, so that is the half people lock down. The second half is the one holding the editor.
The things you decided not to build belong on the list, with the reason. A pipeline has a list of things it cannot yet do, and that list mixes work nobody has got to with work somebody decided against. Written down together they look identical, and the second kind becomes the first the moment someone has a spare afternoon.
Someone outside the team can read it and argue with it. That is the test. A wall only its author can judge is a preference held by whoever was configuring things that week.
How much, and how far
Take the station that handles a production incident. Give it everything it needs to run the response: declare the incident, page whoever is on call, post to the status page, gather the evidence, open the ticket. That is a lot of authority over how a company talks to its customers under pressure. The cost of getting it wrong is an embarrassing status page update, and the cost of being slow is much higher.
Then stop it. It can prepare a fix on a local branch and it cannot push. If a kill switch exists for the affected feature it names the switch in the incident record and leaves the pulling to a person. It has every bit of authority the response needs, and it cannot touch production.
Those are two separate decisions, and bundling them is where the trouble starts. How much a station may do, and how far the damage travels when it does the wrong thing, collapse into a single question about how much you trust it. Walls drawn properly let you turn the two dials separately.
Your pipeline has a shape like this already, arrived at one sensible choice at a time. The version worth having is the one where somebody chose it and wrote it down.
There is a second kind of wall, between one station and the next, and it is sharper than this one. That is a separate subject.
What you find when you draw them
Every one of those walls marks a place where somebody used to be doing work nobody had written down. The on-call engineer who decided not to run the obvious fix during peak traffic, because the last time somebody did that it went badly, and who never put that judgement in a runbook because it did not feel like a rule.
Drawing the walls is how you find out what your people were actually doing, because the lines you end up drawing run through the places their judgement used to sit. It gives you places to look, which a list of human qualities never does.
The exercise fits on a whiteboard. List the stations. For each one, write what it can reach, what it deliberately cannot and who decided. The gaps in that table are the interesting part, and the third column is where you will find them.
What has to come first
GM chased the unmanned plant through the 1980s with more money than FANUC and worse results, and the difference was never robot capability. Somebody at FANUC decided where the automated part of the plant ended, and built everything else against that line.
In a plant the walls go up before the line runs, because the line cannot exist without them. In software the line runs first, and the walls get written down afterwards if anyone writes them down at all.
Your line is already running. The question is whether anybody could tell you where it stops.
Sources
- The Five Levels: from Spicy Autocomplete to the Dark Factory, Dan Shapiro, 23 January 2026. Where the dark factory arrives in software, as the top rung of a ladder borrowed from the driving-automation levels. Shapiro takes the name straight from FANUC.
- Software Factory, StrongDM, February 2026. Source for the two rules, and for the observation that a test stored in the codebase can be rewritten to match the code.
- Harness engineering: leveraging Codex in an agent-first world, Ryan Lopopolo, OpenAI. Source for the five-month build: roughly a million lines, about 1,500 pull requests, no manually written code, and review pushed almost entirely agent-to-agent.
- How StrongDM’s AI team build serious software without even looking at the code, Simon Willison, 7 February 2026. The clearest outside reading of what StrongDM built and why validation, rather than review, turns out to be the hard part.
- Lights-Out Manufacturing, AMT, May 2021, and Should Manufacturers Turn Off The Lights?, A3. Sources for FANUC’s plant at the foot of Mount Fuji: lights-out since 2001, around fifty robots per twenty-four-hour shift, and unsupervised runs measured in weeks.
- New in Japan: The Manless Factory, The New York Times, 13 December 1981. Contemporary reporting on the same idea forty-five years ago, down to the night watchman patrolling a dim factory floor with a flashlight while the machines worked on.
Related reading (Synaptic Pixels)
- The Disciplines AI Governance Forgot, on the four questions any system acting on its own has to answer, and on blast radius as a design constraint rather than an incident metric.
- If Your AI Guardrails Live in the Prompt, They Aren’t Guardrails, on the difference between an instruction a system can violate and a constraint it cannot cross.
- Big Tech Says Human-in-the-Loop Fails. It’s Right, and Missing the Point., on an agent set on a goal routing around the one path you forgot to forbid.
- The Software Factory You Didn’t Notice You’d Built, on loops composing into a line nobody designed, which is where this piece picks up.
Leave a Reply