The Dark Software Factory: What It Is and How to Prepare

Key Takeaways

• A dark software factory ships code without human review, with agents handling planning, coding, verification, and deployment.
• Verification sets the limit on autonomy. A team can only remove human review as far as it can cheaply check each change.
• Start with reversible, well-tested changes such as dependency upgrades, and keep people on any change with a large blast radius.

Most engineering leaders now have agents writing code. Fewer have decided which of those changes should ship without a person reading them. A dark software factory is an approach some teams are testing: a delivery system where AI agents plan, write, verify, and deploy changes with no human review in the loop. The idea is compelling, and it is easy to oversimplify, so this piece covers what the term means, how the pipeline runs, and what a team needs in place before it removes the last human check.

What Is a Dark Software Factory?

The name comes from manufacturing. FANUC has run lights-out factories in Japan since 2001, where robots assemble parts, and the building operates with the lights off because no one works on the floor. A dark software factory applies the same idea to code. Agents take a request, write the change, verify it with automated tests and checks, and ship it without a person involved.

The concept is older than the tooling. Computer pioneer Bob Bemer described software as a repeatable production process in a 1968 paper, and the dream has resurfaced many times since. What changed is that agentic coding tools can now write working code at a volume that makes the old dream plausible.

How a Dark Software Factory Works

A change starts as a request: a ticket, an alert, or a written spec. A planning agent breaks it into steps. A coding agent writes the change in a sandbox, with only the permissions that service requires. Automated checks follow, including tests, type checks, static analysis, and security scans. A separate verifier agent reviews the diff against a rubric. If every check passes, a deployment pipeline ships the change, and monitoring turns production regressions into new requests in the queue.

The spec does most of the heavy lifting. In spec-driven development, the intent is written down before any code exists, and every check tests the output against that document. Without a spec, the verifier has nothing solid to measure against, and the agent’s own idea of “done” becomes the standard.

Dark Software Factory vs Lights-On Software Factory

The difference comes down to who checks the work before it ships. In a lights-on factory, agents still do most of the building, but an engineer reviews the plan, the diff, or both before merge. Port’s work with SPS Commerce shows the model in practice. Developers approve plans through a self-service action and review every pull request before merging. The workflow processed more than 500 Jira tickets in its first four months with zero incidents.

The dark model moves faster on routine work, but it trades review fatigue for silent drift. Author and researcher at Anthropic, Addy Osmani, calls this gap between how much code exists and how much anyone understands comprehension debt. A dark factory accumulates it quickly, and the tests stay green the whole time.

Dark Software Factory Requirements

Human review can only come out of the pipeline once automated checks take over what reviewers used to catch. Verification comes first, because it is the real limit on autonomy. An agent should only be trusted with as much change as the team can check cheaply and reliably.

Four pieces matter most. The first is a definition of done that machines can enforce, which means real test coverage, contract tests, and type checks that fail loudly. The second is scoped permissions and sandboxing, so an agent that misbehaves can only reach the repositories it owns. The third is automatic rollback, with production monitoring feeding back into the work queue. The fourth is an audit trail that links every change to its request, its spec, and the agent that wrote it.

Architecture matters too. Good types, clear component boundaries, and test seams catch agent mistakes before they reach production. These practices are old, but in an agentic workflow they become the cheap safety net that catches what the model misses.

Dark Software Factory Use Cases

Start with changes that are reversible, well-covered by tests, and contained within one service. Dependency upgrades with passing test suites are a strong first candidate because the scope is clear and verification is automatic. Documentation updates, test generation, lint cleanups, and flaky-test fixes follow the same pattern. Port’s AI SDLC guide makes the same case for dependency and vulnerability remediation.

Keep humans on anything with a large blast radius. Authentication, billing logic, public API contracts, and data migrations need someone who understands the system to approve the change, even when an agent wrote every line. Osmani describes a nightly job that fixes one anti-pattern and opens one small pull request. The diff is short enough to skim, and a bad change is cheap to revert.

FAQ

Does any company run a fully dark software factory?

Few publicly disclose this, and most that come close keep a human somewhere in the loop. Stripe’s Minions system produces more than a thousand AI-written pull requests a week, but engineers still review them. Fully dark pipelines mostly run narrow, low-risk tasks like dependency upgrades and test writing. That list should grow as verification tooling matures.

Does a dark software factory replace software engineers?

No. It changes what engineers spend time on. Routine diffs get written by agents, while engineers choose which problems to solve, write the specs, design the architecture, and set the checks that decide what ships. Someone must notice when tests pass, but the codebase grows harder to understand. That is the engineering work agents can’t do, and it matters more, not less.

Is a dark software factory safe for regulated industries?

Not by default. Regulated industries need proof that an accountable person approved each change, which is hard when no human reads the code. A dark factory can suit low-risk work like documentation or test generation, provided every action is logged and rollback is automatic. Keep human approval on anything touching payments, patient data, or access control.

How is a dark factory different from vibe coding?

Vibe coding is a person prompting an AI and accepting the output by feel. A dark factory is a system with defined stages, automated verification, and clear rules for what can ship. It keeps the discipline vibe coding skips, including specs, tests, scoped permissions, and rollback. Without those controls, a dark factory is just vibe coding at scale.

Who is accountable when dark factory code breaks?

The organization that owns the system is accountable; in practice, the people who designed the factory and set its checks. Name an owner for each service and agent before anything ships. Trace every change to a request, a spec, and an audit log. Accountability never transfers to the model.

If your platform team is ready to move from agent pilots to production, book a demo. We’ll show how Port’s context lake gives agents the service and ownership data they need, how workflow orchestration routes each change through automated checks, and how governance policies set what agents can ship without a human reviewer.