Dark Software Factories in 2026: Who Does What

Everyone agrees that the dark factory is coming. Nobody agrees on what it is. We mapped the debate and our own enterprise design onto one question: where should the lights stay on?

The problem: one term, many factories

When a client told us they wanted to buy a dark factory, we assumed they meant the version that circulates on engineering blogs: specifications in, software out, nobody reading the code. After discovery, it became clear they were asking for something different. They had a large portfolio of legacy portals spread across several technology stacks and migrating them one at a time would never finish. They needed to industrialize the work without losing control of it.

That gap is not unusual. In nine months, "dark factory" has gone from one engineer's taxonomy to a consulting offering, a conference debate and a vendor category. Dan Shapiro's five-level model of AI-assisted programming introduced the term in January, placing the dark factory at Level 5, where specs go in and software comes out. StrongDM then described a working version, run by a three-person team, where agents write, test and converge without human code review. By mid-year, BCG Platinion was publishing frameworks for an "Agentic Software Factory," while HumanLayer's Dex Horthy argued at AI Engineer World's Fair that fully autonomous factories cannot sustain complex codebases.

Each of these accounts describes a different system under the same name. For an enterprise deciding what to buy, that lack of consensus is the first risk.

How we looked at this

This piece draws on two sources. The first is the public record: the founding accounts from Shapiro and StrongDM, the critiques from Horthy and Addy Osmani, and enterprise frameworks from consultancies. The second is our own experience designing a dark factory for a large enterprise's portal migration program, including the operating model, the evaluation criteria and the roles we proposed.

This is not a systematic review, and the framework below is interpretive. Its purpose is to give engineering leaders a way to reason about a decision the public debate tends to frame as all-or-nothing.

The stations of a factory

Strip away the branding and every account describes roughly the same stations. Intent and requirements come first, followed by architecture context and planning. Then comes code transformation, code review against standards, security validation and testing. Evaluation decides whether the output is good enough or needs another pass, and deployment closes the loop.

The disagreement isn't about the stations. It's about which ones a human should staff.

Two questions that decide where the lights go

Osmani offers the most useful principle so far: a loop should only receive as much autonomy as can be cheaply and reliably verified. We turned that into two questions and asked them of every station:

1. How cheaply can a machine verify this work?
2. How expensive is it to get this work wrong?

Plotting each station against both produces four quadrants.

Lights off: cheap to verify, low cost of error. Code transformation within an approved pattern, unit tests, documentation and style compliance. A compiler, a test suite or a linter gives an immediate answer that is hard to fake. This is where agents run unattended.

Automated gates, human audit: cheap to verify, high cost of error. Security validation and architecture compliance. Machines check every change, but a mistake is expensive enough that people should periodically audit the gates themselves.

Supervised: hard to verify, low cost of error. Migration planning for routine cases and UI fidelity. A wrong call is recoverable, yet no oracle fully confirms the answer, so people review samples and patterns rather than every output.

Lights on: hard to verify, high cost of error. Defining intent, agreeing on what "correct" means, setting target architecture, handling exceptions and approving what reaches production. These are long-lived decisions that no test can settle. Horthy's warning applies most strongly here: this is where unread code turns into what Osmani calls comprehension debt, the gap between how much code exists and how much anyone understands.

The quadrant a station lands in can change. Calibration moves work from the right side of the matrix to the left.

Who does what

Grouping the stations by quadrant gives a division of labor:

In our design, the move from the lights-on quadrant to the lights-off one was deliberate. We started with a small set of representative portals, one per technology pattern, and used them to calibrate the workflows. Before anything scaled, the client's engineers and ours agreed on ten evaluation dimensions, from functional equivalence and architecture compliance to UI fidelity and deployment readiness. That agreement turned "correct" from a judgment call into a gate machines could apply.

The ownership question

The matrix explains who staffs each station. It does not answer who owns the factory.

In one model, a provider operates the factory and delivers migrated code. In the other, the provider installs it inside the client's environment, configures it for their stacks, trains their teams by role and steps back. We built our design around the second, with migrated code, the knowledge base and the calibrated workflows belonging to the client, and with success measured partly by the share of migrations completed without our direct support.

Ownership matters because the lights-on quadrant is where institutional knowledge lives. If the people who define intent and approve exceptions work for someone else, comprehension debt accrues to the wrong balance sheet.

Open questions

Several important questions still lack evidence. Nobody has published long-term data on how dark-factory codebases age; Horthy himself acknowledges that current benchmarks can't prove his quality concerns, and no account yet spans more than a year or two. We also lack good measures of how quickly work can safely move between quadrants, and whether that rate differs between greenfield development and legacy migration. Finally, the economics remain mostly anecdotal: BCG's 3–5× productivity figures are practitioner reports, not independent benchmarks.

These gaps are a reason to adopt deliberately, not to wait.

What we'd tell anyone buying one

Don't buy the word "dark." Ask where each station sits in the matrix, who decides when a station moves, and who will still understand the system in three years. The factories that last won't be the darkest ones. They'll be the ones where every switch was set on purpose.

That’s the thinking behind Softtek's FRIDA (Framework for Intelligent Digital Automation): agents take the work a machine can check, and people keep the calls that need judgment.