What Is a Dark Software Factory?
It's mostly a hypothetical, honestly. It's an idea that has gained a lot of popularity over the last year: as we increasingly use coding agents in software development, the end state is to use only them as the vehicle by which we edit the code and ultimately turn the lights off. It becomes a dark factory, named after lights-out manufacturing. We don't even read the code. We interact only with agents and maybe our spec files.
This is meant to function in a scaled software engineering context, where we have real scale and users, code changing over time, and risk. That's opposed to vibe coding, which was basically this exact idea of only using agents and forgetting about the code, except we all realized over a year ago that it doesn't really scale.
Dark factory is meant to be the reboot of vibe coding, one that should work in scaled software engineering, the way vibe coding was found to be mostly a good idea for prototypes and smaller-scale solo dev things.
A Non-Solution to a Non-Problem
I am anti-dark factory. I feel this is a non-solution to a non-problem that is being given so much credence for very dubious reasons, and in general, it will be harmful.
Why would we think of agents any differently than humans? Agents are not humans. LLMs are not humans. Tools are not humans. There's no reason we would expect them to be comparable. It's almost ridiculous to have to defend the idea that we think of tools differently than people.
Reading Code Considered Helpful
I laid this out in a pretty long blog post called Reading Code Considered Helpful, where I summarize all the opinions I could find. Every credible person in this debate says some amount of reading code is helpful. We can back off from it to some degree, but if we stop doing it completely, we lose track of all these second-order effects. We stop understanding our systems, and we lose control of maintainability issues.
We keep introducing more and more problems the more we try to eliminate reading code completely.
It's just much easier to think about it in terms of "let's do it to a manageable degree," rather than "let's try to devise some way, which most people agree doesn't really exist, to stop reading it entirely."
Start with Continuous Delivery
People raise the point that you should have automated tests, that you shouldn't just be looking at the code for every little possible logic error. I agree with that. In fact, if we limit the set of dark factory recommendations to the things the continuous delivery people have been saying for a decade, all of those are good and vetted, and we know how to teach them. You can have most of the value of a dark factory just by reading about continuous delivery, practicing it, and learning it from people who know it.
We have layers of guardrails: automated tests, linters, and other things. It would be foolish of me to say we should rely on reading the code for all of those concerns. Even agentic review works somewhat. It doesn't displace all the other needs, but it's a nice tool to add to the equation. Defense in depth is a thing.
But how you set up all your other layers, what you need to defend against, what's testable—it's good that I have tests, but does the testing strategy cover all the risks I care about? You accomplish these things by doing some level of reading the code. Most of the people telling you how to do this will say you're supposed to tune your harness, and if you press them on it, they're doing that by seeing enough of the code to know how to tune it.
I think most of the people who are telling you not to read code are actually doing some lowercase form of reading the code, and just telling you something very confusing and unhelpful.
Stay Close to the Details
Reading code informs your thinking about guardrails. We could be here for a while naming all the kinds of automated checks we know: unit tests, integration tests, property tests, and linters. It would be bad advice for someone to hear all that and just implement all of those things uncritically. You have to understand how each of them is going to be leveraged in the context of your needs, and all of this requires staying very close to the details.
If reading the code sounds to you like you're the only guardrail against every line, I agree with getting away from that. But staying close to the details is how you keep the whole thing running.
You shouldn't see leaving the details as a virtue. If you feel the need to do that, I'd say something has gone wrong.
Define the Factory by What It Reveals
When you had Bob Martin on, he started out by saying, "I don't read the code," but then he said, "Well, I do read the Gherkin." He wants to read that code, the executable specs. So again, the people who sound close to the dark factory end up saying there's a category of code you should definitely read.
If we talk about the spec layer, we're able to make nearly a source of truth, or absolutely a source of truth; now we're having an interesting conversation.
We're not defining our factory based on what it hides—the code—but on what it reveals. The success factors are what this process reveals to you. I don't think there's a reason to completely blindfold yourself to one of your best sources of signal.
My official response to dark factory is a blog post called The Show Me Method. Under this, you should see the code by default. If you want to stop looking at it so closely, and there are different levels you might back off to, you should have seen a good reason why this is an exceptional case with lower risk. What have you done to lower that risk? This does extend all the way to: we've seen enough evidence that these components can go completely dark.
Making that what everyone is trying to lead toward is just generally bad advice, which will have bad results. We're emphasizing it to that degree because, as an industry, we're trying to eliminate developers.
Software Isn't a Self-Driving Car
When the pilot and copilot put a plane on autopilot, there are all sorts of ways they need to stay somewhat close to how the autopilot might break down. But they're also not making the plane more complicated in flight, as we do with software.
Self-driving cars are mostly not how cars are driven. If we want to study the role of automation in driving, we'd have infinitely more success stories of doing it with a driver. Even when there wasn't one driver, automated cars were actually remote-controlled, with one person keeping several cars going. So if we compare assisted driving to a dark factory, most assisted driving is not fully autonomous.
Nobody Needs a 50,000-Line PR
If we read code, as every credible person suggests we should to some degree, then how will I merge this 50,000-line PR? Generally speaking, that is a bad idea. There are extraordinary cases where we know exactly how it was generated and we've controlled for the risks. But in general, merging a 50,000-line PR is not a business need. It's a symptom of your process.
What are you trying to do? What has caused you to think that between you and success is regularly merging unreviewed 50,000-line PRs?
Get Your Steps In Where the Risk Is Low
When I talk about reading the code and all these risks, I'm trying to prepare you for your average or worse-than-average case. People have code at all different risk levels and stuff they're experimenting on. I've always done a lot of experimenting on internal apps at companies. You've got a new programming language you want to play with: they don't want you to put it in production, but they'll let you make an internal app. This is a similar situation. That's very low risk, and then there are less risky components where you can push more agentically and get your steps in.
What I'm discouraging is seeing "more agentic" as better. Try to understand what is valuable to you in the delivery cycle. If we're modeling our problem as "let me merge as many PRs as possible," it's very likely you have a lot of not-very-valuable work you're trying to push through, instead of deciding what the most valuable work is, getting it done, and lowering your work in process so you can focus on the best thing.