AI coding is a Golem, not a “Factory”
Everyone building with generative AI reaches for the same word: factory. AI-powered software factory. Code factory. Factory-scale development.
It’s the wrong word. And the wrongness isn’t cosmetic — it hides the actual risk.
Factories are the wrong shape
A factory’s entire purpose is to produce identical outputs at scale. Tolerances measured in micrometers. Same input, same process, same output, ten thousand times. That’s the point. That’s what you’re paying for.
If a factory produces something different each run, you have a defect. You stop the line.
Software doesn’t work like this. If you’re writing the same code twice, something is wrong — you should have abstracted it, templated it, deleted the duplicate. Every piece of software worth writing solves a problem nobody has solved in exactly that shape before. Different constraints, different context, different tradeoffs. Variance isn’t a defect in software. It’s the whole job.
So when we say “software factory,” we’re importing a mental model — repeatability as virtue, deviation as failure — that’s backwards for what we’re actually doing. And that matters, because the mental model shapes how people treat the risk. If you think you’re running a factory, you think the problem to solve is consistency. You’re not. The problem to solve is specification.
What the AI actually does
Here’s what generative AI code tools are actually good at: taking your instructions and executing them, fast, tirelessly, without complaint, at a scale no human team could match.
Here’s what they’re not good at: knowing what you meant when what you said wasn’t quite right.
That gap — between what you specified and what you actually wanted — is the entire risk surface of AI-generated code. Not “will it work at scale,” not “will it be consistent.” Will it do the thing you actually needed, or the thing you technically asked for.
There’s a word for an entity that does exactly this. It’s older than software by about four hundred years.
The golem
Prague, 16th century. Rabbi Judah Loew builds a creature from river clay to protect the Jewish community. He animates it with a shem — a name of God, placed in its mouth or written on its forehead. The golem is powerful. Obedient. Tireless.
And it has no judgment of its own.
That’s not a footnote to the legend. That’s the legend. Every golem story has the same failure mode: told to fetch water, the golem fetches water, and keeps fetching water, and floods the house — because nobody told it when to stop. It doesn’t disobey. It executes literally, without the implicit context a human would fill in automatically. Told to guard, it can’t distinguish “protect the community” from “destroy anyone who might be a threat.”
The golem never gets the instruction wrong. It gets the specification wrong — or rather, you did, and it had no way to know that.
To stop it, someone has to physically intervene — erase a letter, remove the shem. It has no off switch it manages itself. Shutting it down is a human decision, made by someone paying attention, not a feature the golem provides.
If you’ve shipped AI-generated code that did precisely what the prompt said and precisely not what the team needed, you’ve already lived this story. You just didn’t have the word for it.
Why this beats “factory” — and beats “genie” too
Genie is the other word people reach for, and it’s closer than factory but still wrong. A genie grants wishes instantly, and the danger is a curse baked into the wish itself — be careful what you wish for. That’s a joke about greed, not a lesson about specification.
Golem is different. The danger isn’t in what you asked for. The danger is in the distance between what you asked for and what you meant — even when the ask was perfectly reasonable. That’s exactly the failure mode of AI-generated code. Not “I wished for the wrong thing.” “It did exactly what I said, and that wasn’t enough.”
Golem keeps everything factory throws away:
- The complexity is real. A golem is built through elaborate, arcane process — same as the training, the prompting, the tooling stack underneath a code-gen system. None of that complexity disappears just because the user never sees it.
- The output is unique, not replicated. Every golem is built for a specific task, a specific threat, a specific community. There’s no assembly line.
- The risk is specification, not scale. The golem legend isn’t a cautionary tale about too much output. It’s a cautionary tale about insufficiently precise instruction meeting an entity with no judgment to fill the gaps.
- Human oversight is structural, not optional. Someone has to stay close enough to notice when the golem’s gone past the point you meant, and has the authority to stop it. That’s not a bug in the system. That’s the design.
What this means if you’re building with AI code-gen
If the golem is the right analogy, it changes what you optimise for.
You stop asking “how do we scale this consistently” — the factory question — and start asking “how good are we at specifying what we actually want, and how quickly do we notice when the output has drifted from the intent.” That’s a completely different set of skills and a completely different set of controls.
It means the real bottleneck isn’t generation speed. It’s the quality of the shem — the instruction, the spec, the constraint you write down before the golem starts moving clay. Teams that get good at AI-assisted development won’t be the ones with the fastest golem. They’ll be the ones who’ve gotten disciplined about writing the name correctly, and who’ve built in someone whose job is to watch for the flood before the house is underwater.
Factory tells you to worry about throughput.
Golem tells you to worry about what you actually asked for — and whether anyone’s watching closely enough to catch it when the answer is “not quite that.”
