I Will Not Help You Run an AI Dark Factory If…

Before 2022, I led a team of 100+ people. Team leads, QA, analysts, DevOps, architects, developers, QA automation. Scrum, boards, reviews, escalations. I know this machine from the inside — and I know where it breaks.

Humans make mistakes without process automation via code.

Now I am running AI Dark Factories: dozens of agents doing work that previously required entire teams. I even recorded a quick 3-minute video that explains what an AI Dark Factory means.

But I will not help you run one if…

Inside a dark factory: agents at every station, a human architect on top.

1. Your process is chaos — and you want agents to fix it

Clients come to me with no backlog structure, no gates, no clear workflow. "We'll figure it out with AI." — No. You won't.

Agents don't fix broken processes. They scale them.

Garbage in — garbage out. But with agents, it's garbage out at 100x speed.

Gates, backlogs, code review — these exist to manage unpredictable performers. An LLM is unpredictable. A human is unpredictable. Control works on top of both.

You don't need to rewrite your process for AI. You need a process that works before AI. Put agents into mature workflows. Not into chaos.

Recently, an agent built a feature on a large monolith in four hours. Deployment took three months. AI wasn't the bottleneck for a single second. Infrastructure and process were.

So I tell clients honestly: no mature process — no benefit from agents. Turn them on, don't turn them on — makes no difference. Except now the chaos moves faster. If you don't have the right process now, I will tell you about that — and be ready for changes!

2. An LLM in every step, including orchestration

Structure? No! It must read my mind and know what I want!

An LLM is for intellectual work: understanding a requirement, writing code, proposing a test. A script is for mechanics: who takes the task, when it moves, which checks are mandatory.

Put an LLM into orchestration — and every "where should this ticket go?" becomes a lottery. Expensive, slow, unpredictable. LLM at every step is chaos you also have to pay for.

Same with humans: when you don't have algorithms to manage your deliverables at scale, priorities, and so on — it's chaos. You need a clear DOR for each step in the SDLC.

3. A factory without guardrails kills itself

"We're not ready to pay for VMs, CICD."

Let agents loose without a protected main and without the rule that "every PR must be up to date" — and in an hour or two, everything stops. Agents start breaking each other's code — breaking each other's code without unit tests, without integration tests before deployments.

I once ran tests overnight. For three hours, the agent honestly followed the branching rules — and then decided to "be faster" and started pushing directly to main. And I have seen a factory kill itself because of one badly defined task.

No mandatory tests at the gate, no protected branch, no auto-rework on conflict — this is not a factory.

It is a debris generator.

4. Saving money in the wrong place

"Run the factory, but we have only $500 per month."

"Let's take a cheaper model and save on tokens." With a cheap model, prompts bloat, cycles become 10–20 instead of two, instructions get heavier. And you pay for it with the most expensive thing: your time.

And it is not only about models. Over one weekend, running agents on mobile builds consumed 80 hours of runners: emulators, builds, hardware. Count the whole chain.

The point of the factory is to save human time. If an agent costs more than the human it replaces, there is no factory.

A smart expensive model is often cheaper than a cheap stupid one. And an interesting fact: the most expensive models are cheaper than VM time to run them. Is your CICD platform ready for that?

5. The human is removed from the wrong place

The human shifts to instructions building and orchestrating — or starts to find another job.

Take people away from routine work — and you leave them with the hardest part: supervision, failure analysis, decisions at disputed points.

The factory still needs a human. Not to write code — but to hold the end-to-end picture. Design the pipeline. Know what goes into and comes out of each agent. Intervene when the factory cannot pull itself out.

And one more thing. I don't know many programming languages. But I've built working things with them — because I understand system design. That's the skill that won't depreciate. Not the language.

Work doesn't disappear. It moves up in qualification. I smile now when people rush to learn Python… Cool… But we need a wide E2E architecture vision. Python code? Agents handle that very well.

When it works

And now — when it works. For me it works, with projects, streams, and accounts who trust me.

A mature process. LLMs for thinking, scripts for mechanics. Strict guardrails. The right model for the right task. And a human on top — not a machine operator, but the architect of the factory.

Do this — and dozens of agents will go to production around the clock. And trust will move from "I checked the code manually" to "the system proved that the result is reproducible."

Dark Factory is not about "AI replacing developers." It is about predictable deliverables in reasonable time. It is a new operating model for software delivery — and in this model, trust moves from individual execution to system transparency, evidence, and reproducibility of results.

One agent that can produce an output with an 80%+ predictable result — this is a true agent of a Dark Factory. Otherwise it's a loss of money.

The lights are off. The AI factory is running.

FAQ