There is an idea going around in AI circles called the dark factory. It comes from manufacturing: a fully automated plant has no people on the floor, and a floor without people doesn’t need lighting. The machines produce in the dark.
Applied to software, the picture is seductive. AI agents take in requirements, write the code, run the tests, fix what breaks, review each other’s changes and ship. Human involvement trends toward zero, so why keep watching?
I think the dark factory is directionally right about autonomy and completely wrong about the lights.
I know because I run one of these factories. For over a year now, an autonomous agent system I built (Jengo) has been doing real production work for me and my clients: picking up tasks from a board, writing code in isolated worktrees, opening pull requests, deploying to servers, and reporting back. Some days it lands more changes than I could review line by line even if I did nothing else.
That experience taught me one thing above everything else: autonomy and transparency are independent dimensions. You can max out both. And you should.
“Done” is not an answer
Give an autonomous system a simple instruction: add this feature to the application. A few hours later it reports: done.
Impressive. Also useless, on its own. Because now you have questions:
- What requirements did it derive from my one-line instruction?
- What did it change, and did anything fall outside the original scope?
- Which tests prove the feature actually works?
- What needed approval, and who gave it?
- Can I trace the path from my request to every line that changed?
If those answers are hard to get, you haven’t built a capable factory. You’ve built a capable factory and turned off the lights. The capability is real; the accountability is gone.
Everything is a chain
The fix is not more supervision. It’s structure. In my system, every piece of work exists as a link in a chain:
Requirement → task → agent → branch → commit → pull request → test → review → approval → deployment.
Nothing floats free. A pull request points back to the task that caused it. The task points back to the requirement. The deployment log points back to the pull request. When something in production behaves strangely, I don’t reconstruct history from memory or from raw Git archaeology · I follow the chain backwards.
This is more than an audit log. Git tells you what changed. The chain tells you why it exists: a history of intent, not just a history of edits.
Traceability is not micromanagement
Here is the part people get wrong. “Keeping the lights on” does not mean a human approves every command. That would throw away the entire point of autonomy.
The distinction that matters is risk. In my setup, the agent merges a refactor, fixes a failing test or updates internal tooling entirely on its own. But certain actions are gated, always: touching production, sending anything to a client, spending money, handling credentials. Those requests land as push notifications on my phone, with context, and wait for an explicit yes.
The system knows the difference between a reversible internal change and a consequential external one. That single design decision is what lets me step away from the production line without losing sight of production. I govern the factory. I don’t operate the machines.
From code review to decision review
As agents get more capable, this shift becomes unavoidable. Traditional governance assumes humans write the software, so we built our safeguards around reading code. But when agents produce hundreds of changes a week, “did a human read every line?” stops being the right question.
The right question becomes: can we prove why this change exists, how it was validated, and under whose authority it shipped?
That is a different kind of review. Not line-by-line inspection, but decision review: were the boundaries respected, did the tests cover the requirement, was the risky part explicitly approved? It scales where line-by-line reading doesn’t, and honestly, it catches more of what matters.
A lit factory can learn
There is a bonus that surprised me in practice. When everything is connected, the factory becomes measurable, and a measurable factory can improve itself.
My system keeps a running log of every mistake and every lesson. Patterns that repeat get promoted into hard rules the agents load at startup, each with a confidence score. A deployment that went wrong in week one becomes a rule that prevents the same failure in week forty. The transparency layer isn’t compliance overhead; it’s the substrate the system learns from. A dark factory repeats its mistakes in the dark.
Keep the lights on
So no, the difference between a dark factory and a light factory is not humans versus AI. Both can be fully autonomous. The difference is visibility.
The dark factory says: the machines are working, you don’t need to be inside.
The light factory says: the machines are working, you don’t need to operate them · but you can see exactly what is happening, and you can prove it afterwards.
I wrote earlier about why workflow beats autonomy. The light factory is what that workflow looks like once agents do most of the work: not people babysitting machines, and not a black box producing code nobody fully understands, but an autonomous factory where requirements, tasks, changes, tests, approvals and deployments form one observable system. More autonomy never has to mean less control.
Let the factory run itself. But leave the lights on.
Terug naar overzicht