Where Dark Factories Belong

I do not think desktop coding assistants are going away any time soon. The terminal, editor, and the person steering the model line by line still has plenty of road ahead. But I think we are slowly drifting toward a world where you do not always have to be sitting there for the work to happen.

I have written about dark factories a few times now. The usual mental image is a machine you point at a problem, with code coming out the other end and barely a human in sight. I have mostly talked about them in the context of production, and I have started to think that is the wrong place to put them. A dark factory is probably not a production tool. It fits better in open-ended work, where the goal is discovery rather than shipping.

The reason is fairly simple. Once you have a reasonable baseline for a piece of software, the work stops being open and starts being specific. Specifics have to be right. At that point someone has to actually read the code, and in my opinion that someone is still a person. You can try to hand the review to another model, but even with the frontier labs we still see the models make fairly basic mistakes, no matter how much we chaperone them. So for production you keep a human in the loop, and the dark factory does not really change that. It just produces more for that human to check.

Exploration is different, because there is nothing to sign off on. When the space is open-ended you are not asking the agent for the one correct answer. You are asking it to try a hundred different things and see if any of them land in an interesting way. Most of them will not, and that is fine, because you were never grading them one by one. You are just looking through the pile for something that catches your eye.

This is what is exciting to me. I do not particularly enjoy sitting in front of a terminal for no good reason. What I would rather do is set something up, leave it running, and come back later to see how it is going and whether it managed to surprise me. If it fails ninety percent of the time but the other ten percent turns up something worth having, and the cost is not too high, then I think that is time and money well spent. For production that trade makes no sense. For exploration it is more or less the whole idea.

I have a couple of these running in the open. The arcade puts out a new game on its own, and the coder picks what to build for itself and pushes the result into the relentlessworks organisation. I would not call either of them impressive if you judge the output the way you would judge a finished product, and that is not really why I keep them going. What I like is being able to watch ideas take shape. Some of the games in the arcade are things I had honestly never seen before. I am not saying they are novel in any grand sense, just that I personally had not come across them. And some of the code the coder has written is interesting too, not because it is useful, but because it points at something I would have taken a while to get to on my own.

So that is the reframe I keep coming back to. Aimed at production, a dark factory is mostly an expensive way to make more work for a reviewer. Aimed at open problems, it becomes something that goes off and explores on your behalf, and every so often brings back something you would not have found by sitting in the chair yourself.