thoughts-on-dark-factories

We run dark factories internally alright. They are real. Point one at a problem and code comes out the other end with very little human touch. The question worth asking now is what they are actually good for.

In my own observations, where they work best is on good foundations. A dark factory is a solid pattern when the system around it has strong defaults and strict rules, because once the stage is set it becomes hard for the coding assistant to stray. A plugin is the clearest case. There is an interface, and for the plugin to load at all the interface has to match. The code behind the interface is almost an afterthought. Frameworks behave the same way with more room to move. The convention does the steering, and the model follows it because there is no comfortable way not to.

That gets you production. Distribution is a separate problem, and it is the harder one. If nobody uses what you built, why did you build it? Standing up a new project has never been cheaper, and it is a trap. The ease of creation says nothing about whether the thing deserves to exist. A dark factory can hand you a working product that no one, not even you, will ever open again. It is the equivalent of the spreadsheet that looked like a good idea at the time, but now is just a dusty file on the hard drive.

And the ongoing cost is something that needs to be considered. You pay once to produce the code, and then you pay forever to keep it alive. Every feature you add makes the codebase bigger, and a bigger codebase costs more tokens to reason about the next time you touch it. LLMs love to write more code, so the curve bends the wrong way. Each new project is another open-ended subscription you signed without reading.

Dark factories just happen to solve the part of the problem that was already getting easier, and leave the hard part alone. The hard part is writing the right code, the kind that turns out to be useful. If you spend a thousand dollars making something, you have to recoup a thousand in value just to break even, and with AI the bar is higher, because the whole pitch is that it scales. People expect five or ten times back.

The industry is only starting to feel this because we are still in the experimental stage, where the properties of these systems are not well understood. For decades the binding constraint was that code is hard to produce. Now the constraint moves to deciding what is worth producing in the first place. In the short term, plenty of teams leaning on coding assistants and dark factories will spend more on tokens than they ever did on engineers. That will stop once they sober up.

The quickest solution right now is to weigh down on cost. An extension to something that already exists is far cheaper than a project built from nothing. A WordPress plugin is easier than WordPress. On ChatBotKit we can stand up almost any agentic or conversational system on demand, because the frameworks, the SDKs and the API already dictate how things are done, and the model just follows the path and does so efficiently. We have a drawer full of these projects and no clear idea what to do with most of them. We may open source them, because we cannot realistically carry them all.

Maybe that is the real tell. When you can make anything, the scarce thing is no longer the making. It is knowing what is worth keeping.