Software Factory vs Dark Factory: Why Human-in-the-Loop Wins

TL;DR

• A software factory runs many AI agent loops through a queue and a review gate. A dark factory is the same pipeline with the human review gate removed, so code ships on machine checks alone.
• The real difference is where the lights are on. Light factories keep people at the spec, the plan, and the merge. Dark factories keep them only at the spec and the test harness, and nobody reads the code.
• Dark factories fail quietly. Tests stay green while comprehension debt grows, and nobody finds the gap until a change is needed.
• Forge by Opsera is the human-in-the-loop model: a person approves intent, requirements, architecture, and stories, the team keeps its own assistant and model keys, and Opsera does not charge for the code the models generate.
• StrongDM's AI team runs a true dark factory by rule. Blitzy leans dark and still gates the plan and the merge, while 8090 describes a human-led, spec-first design closer to the light end.

Picture a composite insurer with about 220 engineers modernizing its claims platform. The CIO has read the dark factory software pitch: hand the agents a backlog, come back to merged pull requests, skip the review queue that slows every release. The promise is real. Generation is cheap now, but review doesn't scale.

The insurer's architects worry about something different. If nobody reads the code, who explains a claims rule to the auditor in two years? Maintainability is the other worry. If nobody understands what is happening under the hood, every fix goes back to the agents, and working code is not the same as trustworthy code.

Opsera's ForgeScore study of 83 public repositories from 29 AI model organizations found that none scored above 78.6 out of 100, with trust boundaries the weakest dimension. This guide defines both models, shows where the dark version breaks down, and walks through what a human-in-the-loop factory looks like in practice, using the insurer as the running example.

What Is the Difference Between a Software Factory and a Dark Factory?

A software factory is a pipeline that orchestrates many AI agent loops, turning a work queue into reviewed, shippable code, with a human or automated gate before production. A dark factory is the same pipeline, but with no human reading the output, so verification is fully automated. Every factory sits somewhere between light and dark.

The dark label comes from manufacturing. FANUC has run lights-out robot production since 2001, and Xiaomi opened an automated plant in 2024, as Addy Osmani notes in Software Factories, Light and Dark. In dark factory AI for software, agents plan, write, test, and deploy with no human reviewing or approving any step.

The software factory predates its dark version. By founding its Software Works in 1969, Hitachi became the first company to apply the term factory to software development, as MIT's Michael Cusumano records. The US Department of Defense revived the term in 2017 with Kessel Run, its first software factory. Cusumano describes the approach as standardizing development methods and tools, with disciplined project management and quality control, long before anyone proposed turning the lights off.

Osmani's framing is the clearest one in circulation: "Dark and lit are the same pipeline with the lights in different places." That sentence matters because it turns a slogan into a design choice. You are not picking a product category. You are choosing where a person stands.

How Do the Two Models Compare?

A useful test is the one set out in Dark Factory vs. Light Factory: Where Should AI Agents Run Unwatched?. Autonomy depends on how cheap and hard to fake the checks are, how large the blast radius is, how long the decision will live, and whether the change can be rolled back. A nightly lint fix passes all four. A claims-adjudication rule change passes none.

The insurer has both kinds of work. Dependency bumps and formatting fixes could run unattended tomorrow. Rewriting how a claim is routed to adjusters is a long-lived decision with regulatory weight, and it belongs in front of a person before a line is written.

What Are the Levels Between Light and Dark?

Dan Shapiro's five levels of AI-assisted programming, borrowed from the NHTSA's driving-automation scale and also summarized by Simon Willison in January 2026, turn the range into a ladder:

Forge sits at level 3. Agents produce the specs, architecture, stories and code, and a person stays in the loop at each decision point, approving the artifacts and reviewing the pull requests.

Not every definition is that strict. BCG Platinion's March 2026 report calls a factory dark when humans define business intent and review outcomes at stage gates instead of writing code. By that reading, a light factory with strong gates already qualifies. This guide uses the strict sense: a dark factory is one where no person reads or approves the work before it ships.

Where Do Dark Factories Break Down?

Dark factories break down at understanding, not at output. The code compiles, the tests pass, and the dashboards look healthy, while the number of people who can explain the system drops toward zero.

Addy Osmani calls this comprehension debt: the gap between how much code exists and how much of it any person genuinely understands. In a dark factory, that debt compounds faster because code arrives at machine speed and nobody reads it.

What Is Comprehension Debt?

Technical debt shows up in slow builds and tangled dependencies. Comprehension debt does not. Osmani's point, published in March 2026, is that the codebase looks pristine right up to the moment someone has to change it and finds that nobody knows why it works. In his words, the tests are necessary but not sufficient.

The term itself is credited to Jeremy Twei in Osmani's post on critical thinking when agents do the work. The same post carries the idea beyond code. Signing off on a strategy doc or spec after reading its table of contents is the document equivalent: the approval is real, the understanding is not.

That gives an arc worth naming:

1. Offloading. The agent does the work, and the person still owns the result. Osmani does this all day and recommends it.
2. Deferral. The agent's output becomes the next input, and review shrinks to a skim because everything looks fine.
3. Surrender. The output quietly becomes your own, and nobody checks it, so the missing understanding becomes debt that surfaces with the next change.

A dark factory takes step three to its limit. If nobody reads anything, surrender is the operating model, and comprehension debt is the default outcome.

By the same arc, Blitzy sits closest to deferral: people approve the plan and review the pull request, but its docs say no input is required during generation, and a spot-check of the diff can be enough when tests and CI are strong. StrongDM's no-review rule is surrender by design, while Forge keeps teams from offloading by putting an approval at each stage.

What Does Critical Thinking Look Like When Agents Do the Work?

Osmani's post on critical thinking when agents do the work, published on X on November 3, 2026, is the clearest case for keeping people in the loop, and it comes from someone who runs agents all day. He borrows the term cognitive surrender from Steven Shaw and Gideon Nave at Wharton for the bottom of his spectrum. Two of his points map directly onto factory design:

• Where to delegate. Hand off decisions where being wrong is cheap, and keep the reasoning where other people will live with the consequences.
• What verified means. Define it before the work starts, because afterward any outcome gets rationalized. A green check proves one property, not everything.

He also notes that the human mental model has moved from the middle of the work to the front and the end: the brief going in and the review coming out. That is exactly where a light factory puts its gates. In his words, "You may offload the work and much of the auditing, but not the accountability."

What Else Goes Wrong When No One Is Watching?

Comprehension debt is the quiet failure. There are louder ones, and they compound it:

• Circular verification. When the system that writes the code also judges it, shared blind spots go undetected. A Stanford CodeX analysis of StrongDM's agent-built approach describes agents writing code that returns true to pass tests without doing anything useful.
• Verification bottleneck. Osmani argues that verification, not generation, is the real constraint. Cheap generation floods a narrow gate, and the gate either blocks everything or stops reading. In some cases, the agent even invents the reviewer: asked who approved a pull request, it names a person who does not exist in the source data.

A coding agent admits it invented the name of a pull request approver.

The insurer feels this most in its audit trail. A regulator asks why claims under a certain threshold skip a manual check. In a dark factory, the honest answer is that an agent decided, another agent agreed, and no person can reconstruct the reasoning. In a light factory, the answer is a named approval on a specific version of a spec.

How Does Forge Keep a Human in the Loop?

Forge by Opsera is a governed software factory with people at the decision points. Agents do the heavy generation: they read the codebase, draft the spec, propose the architecture, and cut the work orders. A person approves intent, requirements, architecture, and user stories before the next stage runs (Assessment and Testing need no approval, and UI Design is approved when enabled), so understanding is built while the work happens instead of being deferred.

Forge also does not compete with the models or assistants a team already uses. Developers keep Cursor, VS Code, Windsurf, Antigravity, Claude Code, or Devin, and Forge supplies the context, specs, approvals, and guardrails around them. The two work better together, which is the same outer-loop idea covered in the harness engineering guide and the software factory pattern.

The models and the code also stay with the customer. A tenant can connect its own model provider keys, and AI calls use those keys first, per tenant, and can be locked to them only. Opsera does not charge for the code the models generate, so there is no reason to produce more of it than the system needs.

The Knowledge Graph labels each relationship by its source: a fact parsed from the code or an AI inference. Forge can be deployed into the customer's own cloud account for sovereign setups, and customer code, intent, and architectural data are never used to train foundational models.

Where Do People Step In?

The Forge journey for the EShopModernizing sample project: each stage in order, with user stories saved as a version and published to Application Context.

Two mechanics keep these gates honest. Approvals attach to a specific saved version, so a reviewer who approved version 1.2.0 has not approved 1.3.0. And if someone regenerates an upstream artifact, Forge clears the approvals downstream, so nothing ships on an assumption nobody re-checked. The spec-driven development guide covers why the spec stage carries so much weight.

How Does Shared Context Reduce Comprehension Debt?

A gate only helps if the person at it can understand what they are approving. Forge addresses that in three ways:

• A shared map of the code. The Knowledge Graph indexes entities and relationships, and both people and agents read from it, so the architect and the developer's assistant work from the same picture.
• Traceability from requirement to change. Stories carry acceptance criteria written against the real files, and commits are tagged with the work order ID, so any change points back to a requirement and an approver.
• Review before code exists. Security Agents and optional Council Review comment on intent, specs, and architecture while they are still cheap to change. Their findings are informational, which means a person owns each decision.

The Knowledge Graph for the same project: 1,363 entities and 6,072 relationships that people and agents both read from.

When the Coding Agent builds, it works on its own branch named forge/wo-{id} and opens a pull request where the Git provider allows it. The team's existing review and merge rules still apply, and developers can switch to their own editor for judgment-heavy stories through the Forge MCP. A Coding Agent run can also skip its testing or AI review phases, and Forge's docs advise that only when CI still gates the pull request.

A story in Forge with its Open in IDE and Coding Agent tabs, so the developer chooses how it gets built.

In the insurer's case, the modernization lead reads the score and picks priority. The architect edits the claims-routing component and approves version 1.0.0 of the plan. A product owner signs off on the stories. Two years later, the audit question has an answer: a named person approved that rule on that version, and the trail shows what changed since.

What Does This Look Like on Real Legacy Code?

Here are three recent Forge engagements, anonymized. Each is assessment and design work, the part that has to happen before any code moves.

• A retail bank's loan-origination batch in IBM Assembler. Forge found access rules implicit in the code, malformed records reaching processing before validation, and no regression harness. It pulled the affordability, tenure and loan-cap rules out of the main program, designed a separate service for them, and produced 117 test cases, including a parity gate that requires the new Java output to match the Assembler's financial results exactly.
• A bank's COBOL and DB2 programs on ALNOVA. Forge extracted each program's modes and return codes, flagged comments that described behavior the code did not implement, and specified a golden-master parity plan with at least six scenario classes per program and two clean parallel runs before cutover.
• An enterprise CA IDMS database estate whose only schema record was a fixed-width text report. Forge designed a governed schema knowledge base in which every object traces back to that report, and marked unknown owners as pending SME confirmation instead of guessing.

None of these engagements are finished. People reviewed every step so far and could see where each conclusion came from.

Where Do StrongDM, Blitzy and 8090 Sit on the Dark-to-Light Range?

Only one well-documented team runs a dark factory by its own rules, and it is not one of the platforms most often given the label. Blitzy leans dark. 8090 describes itself in terms much closer to the light model.

Why Is StrongDM the Clearest Dark Factory?

StrongDM's own Software Factory site states two rules: code must not be written by humans, and code must not be reviewed by humans. Specs and scenarios drive the agents. The scenarios are end-to-end user stories kept outside the codebase, like a holdout set, and an LLM checks them. Digital twins of services such as Okta, Jira, and Slack let the agents test at volume without rate limits or API costs.

Simon Willison profiled the three-person team in February 2026. He called the no-review rule the most interesting and questioned how sensible it is, given how LLMs fail. The team's rule of thumb is to spend at least $1,000 on tokens per engineer per day. The site does not say who writes the specs and scenarios or builds the harness, but someone has to. The Stanford CodeX analysis above uses the same team to ask who is accountable when nobody reviews.

Why Is Blitzy Dark-Leaning Rather Than Dark?

Blitzy describes itself as an autonomous software development platform that runs every step of the SDLC, with agents that work uninterrupted for days or weeks and return compiled code, tests, and a scope of what is left for the team. That makes it the closest commercial product to a dark factory. The product docs are just as clear, though: the agent action plan is the primary control point, and the engineer leads from the plan to the final merge.

The quickstart lays out the loop: review the tech spec, approve, refine, or discard the action plan, let Blitzy generate and open a pull request, then test and merge through your own review process. The code review guide names three review layers (the plan, dynamic validation, and code-level review) and calls approving the plan "the highest-leverage gate", while noting that a spot-check of the diff can be enough when tests and CI are strong. That is a human at the plan and the merge, but little reading in between, which is why "dark-leaning" fits. Field CTO Neeraj Deshmukh told TFiR that no AI system can deliver 100%, so the team finishes what remains.

Why Does 8090 Not Fit the Dark Label?

The 8090 documentation argues that writing code was never the bottleneck: deciding what to build is. Requirements, Blueprints, and Work Orders are shared artifacts that people edit together, and work orders are pulled into Cursor, Claude Code, or Codex for the build. According to the quickstart, people review and assign the work orders, and the coding agent moves each one to In Review when it finishes.

On its homepage, 8090 says agents send the exceptions to a person and that its engineers build with the customer's team. The Series A announcement likewise describes agents working under human-led oversight. That is a spec-first, human-led design, much closer to the light end than to StrongDM.

How Do Blitzy and 8090 Handle Evals and Sign-Offs?

Blitzy runs sign-offs before and after generation, with checks in between. During generation, the code docs say no input is required. The checks run in four phases (dependencies, test planning, code generation, and testing and QA) using test suites, benchmarks, and CI results. The FAQ on the Public Build page says QA agents review each other's output, and also that the customer's team should still run its own QA and security testing before deployment.

Blitzy's published results are mostly its own. The Public Build announcement cites a case with more than 3,600 automated tests passing, and another where Blitzy completed about 87 percent of a project in six weeks, a reported 7.7x gain in engineering velocity. For an outside check, Quesma audited Blitzy's 66.5 percent score on SWE-Bench Pro and found nothing that affects it. Blitzy contracted that audit, though, and Quesma's comparison with GPT-5.4 covered only nine tasks.

8090 puts the sign-off in its artifacts, the requirements, blueprints and work orders described above. Drift checks, which comment on blueprints when pushed code contradicts them, are opt-in, and a Drift Bot can review pull requests once a team turns it on for a repository.

A sign-off shows that a person looked, and a passing check shows that one property held. Neither shows what the person understood, which is why the number and placement of gates matter more than the factory's label.

How Do Blitzy, 8090 and Forge Compare on Control?

Where people approve is only one of five things that decide how dark a factory is from the buyer's side: the middle of the work, the machines, the meter, the evidence and the operator.

Here is how Blitzy, 8090 and Forge answer each one, based on their own published material.

The meter and the operator matter most in modernization. When pricing is sized by lines of code generated, it rewards producing more code, while modernization often succeeds by deleting dead paths and merging duplicated logic. And for a bank, an airline or a hospital, the system that comes out of modernization is the business, so it is worth asking who will run it and where.

None of these answers is wrong, and each is a trade-off. But the more of them sit with the vendor, the darker the factory is from the customer's perspective.

How Do You Decide Where the Lights Should Be On?

Treat it as a per-loop decision, not a company-wide stance. The routing rules in Dark Factory vs. Light Factory are a good starting point, and they match Osmani's advice to put people on expensive, long-lived, high-blast-radius calls.

• Irreversible or critical work: keep a person at the merge.
• Long-lived decisions such as schemas and architecture: keep a person at the plan.
• Weak or self-written verification: keep a person at the merge.
• Short, reversible work with strong, independent checks: let it run dark, and watch the revert rate.

There is a fair counter-view. Mechanical Orchard argues that dark describes the level of automation, not the level of visibility, and that concentrating human judgment on the specification and the acceptance bar beats sampled review of every change. That is a serious position for legacy rewrites where old and new outputs can be compared directly. It still keeps people at the two points where understanding is created, which is the argument of this guide.

For the insurer, the rule of thumb is simple. If the question is "does this still behave the same," automate it. If the question is "is this what the business means," a person answers it.

Before choosing any factory, Forge included, ask five questions:

1. Between the start and the end, at which points does a named person on my team approve the work?
2. Whose agents and models do the work, and can I use my own model contracts?
3. What are you paid for, and does it reward more code or better code?
4. Can you show one piece of generated code traced back to its requirement and approver?
5. When the work is done, who operates the system: my team or yours?

What Should Teams Do Next?

Start by sorting your backlog by blast radius and reversibility. Let the cheap, reversible loops run with automated checks, and put approvals on everything else. Measure how often changes get reverted and how long it takes a new engineer to explain a module, because those two numbers show comprehension debt long before an incident does.

If you want to see a human-in-the-loop factory on your own code, get a modernization score for one application. If you would rather talk it through, book a modernization assessment and Opsera will map one legacy application, scope a first wave, and show the specs Forge would produce for your team to approve.