We have been going through the era of AI enabled Software development automation for quite some time. If Level-0 is simple auto complete then Level - 5 is Software Dark Factory.

I have talked about it in this video which you can check out here in this video.

Context: What “Dark Factory” means (conceptually)

In the usual SDLC, “correctness” is a blend of human inspection (reviews), tests, and operational feedback. The “Dark Factory” idea pushes a provocative boundary:

No human writes code. No human reviews code.

Instead, humans move upstream to define intent, constraints, and evaluation—while agents do the implementation and iterate until the system converges. Simon Willison summarizes StrongDM’s approach as non-interactive development where specs + scenarios drive agents that write code, run harnesses, and converge without human review.

StrongDM themselves describe it similarly: humans define intent, scenarios, and constraints; agents generate code, validate against real-world behavior, and iterate until it converges—without hand-tuning or human review.

The interaction flow

This diagram is the minimum viable mental model of the Software Dark factory. Everything else in this article is a deeper drill-down into what each block actually implies in engineering terms—and what additional “missing layers” are required to make it operational.

StrongDM Software Dark Factory Interaction Flow

1) Humans define intent & specs: the “WHAT + constraints” control plane

As you can see in the diagram, humans contribute in two places:

1. Define intended outcomes / specs
2. Write external scenarios

StrongDM puts it plainly: humans define what the system should do, scenarios it needs to handle, and the constraints that matter—then agents take it from there.

Why this is not “requirements as usual”

At Software Dark Factory level, specs are not “nice-to-have documentation.” They become the control plane:

• define functional intent (“what success looks like”)
• define constraints (security, latency, compatibility, economic limits)
• define non-goals
• define boundaries of the problem space

So what this means is Specs become less like a Jira epic and more like an API contract + invariants (rules that you don't expect to change) + threat model constraints—because there’s no downstream code review safety net.

2) External scenarios: not “why,” but the behavioural contract

What scenarios are (in factory terms)

StrongDM uses scenarios as end-to-end ‘user stories’ often stored outside the codebase—similar to a holdout set in model training.

The key point: scenarios aren’t implementation instructions. They are observable behavior expectations.

Why scenarios live outside the codebase

If agents write both code and tests, they can cheat (e.g., assert true). So scenarios function like an external QA oracle:

• the builder (agent) should not be able to rewrite the judge (scenario suite)
• you want to prevent reward hacking / overfitting (LLMs are know to do that)

We can think of scenarios like an external conformance test suite (or a security certification harness) that your implementation must pass—but cannot modify.

3) Autonomous agents: the “HOW engine” (implementation + iteration)

Agents interpret the spec and implement the system (the how part). Then they iterate based on validation feedback.

Agents generate code, validate it against real-world behavior, and iterate until it converges. Agents execute scenarios and calculate satisfaction. Please pay attenion to the wording here satisfaction. We are not saying Definition of Done, Code Coverage, Unit Tests or other such traditional terms that we currently used in human driven software development.

Validation provides feedback for improvement. In the loop agents re-run and refine.

That feedback loop is the essential “factory” attribute:

• not a one-shot codegen demo
• but an industrialized repeatable loop that converges on behavior

4) Digital Twin Universe: the scaling lever that makes validation feasible

DTU is a set of behavioral clones of third-party services their software depends on. StrongDM says they built twins of Okta, Jira, Slack, Google Docs, Drive, and Sheets—replicating APIs, edge cases, and observable behaviors.

What DTU enables (why it matters)

StrongDM lists concrete DTU benefits:

• High-volume validation: thousands of scenarios per hour without rate limits or API costs
• Dangerous failure modes: test edge cases unsafe or impossible against live services
• Avoid abuse detection during stress testing :contentReference[oaicite:9]
• Determinism: replayable, controlled test conditions

DTU enables scenario tests to become scripts agents constantly execute as the system is being built—and highlights a screenshot of their Slack twin fed by simulated users.

How it works (boundary replication)

StrongDM says the key insight is to replicate behavior at the boundary: build doubles from API contracts + observed edge cases, validate against live dependency until behavioral differences stop appearing.

DTU is a flight simulator—you can stress reality cheaply, repeatedly, and safely, without crashing in production.

5) Scenario execution & validation: from “tests green” to “satisfaction”

What “satisfaction” changes

As you might already see, we are not dealing with normal code quality aspects such as Unit Tests, code coverage. There is a inherent shift:

• from boolean success (“test suite is green”)
• to probabilistic, empirical success—satisfaction:
  “of all observed trajectories through all scenarios, what fraction likely satisfy the user?”

This is a profound shift:

• Traditional CI: correctness = boolean gates.
• Dark Factory: correctness = empirical behavioral confidence.

It’s like moving from “unit tests passed” → to “SLO achieved across chaos experiments” however except now the scenarios are the chaos experiments.

6) Validated software output: “converged behavior” instead of “approved diff”

In the diagram, the system outputs “validated software” when satisfaction is sufficient. StrongDM frames this as validation replacing code review and the system improving by iterating against reality.

This means the final gate is no longer - “a senior engineer approved the diff”. But rather “the behavior converged across scenario+DTU validation”

That’s why the diagram’s final label “converged behavior” is exactly right.

But diagram that we see does't capture all the nuances associated with Dark Factory Concept. A working factory also needs:

• repeatability
• observability
• guardrails
• economics control

This is where StrongDM’s published techniques and tools become the “infrastructure beneath the flow.”

7) Techniques layer: patterns that make agents reliable over long horizons

StrongDM’s techniques page highlights several operational patterns that address real-world failure modes of agentic development (context loss, inconsistent style, inability to reuse patterns, etc.).

When an AI agent works for more than a few minutes on a real codebase, a few predictable problems show up:

• It forgets earlier decisions (“Wait, didn’t we decide to use Approach A?”)
• It becomes inconsistent (naming style changes, folder structure changes)
• It re-invents things that already exist in the repo
• It loses track of what’s the source of truth (spec? code? docs?)

All of this can lead to so called hallucination or what father of AI Geoffrey Hinton calls confabulations. In plain English honest lying.

StrongDM’s “techniques” are basically ways to reduce these failures and make agent output more stable.

7.1 Gene Transfusion

What it means (simple)

Gene Transfusion means:

“Don’t ask the agent to invent a solution from scratch. Instead, give it an existing high-quality example and tell it: ‘Do it like this.’”

So the “gene” is the pattern (structure/style/approach), and you’re “transfusing” it into new code.

Why it helps

Agents are much better at copying a good pattern than designing a perfect pattern from zero.

If you say:

• “Implement OAuth login”

The agent might implement it in an okay way, but not the way your org expects.

If instead you say:

• “Look at how we implemented SSO login in Module A. Now implement OAuth login in Module B using the same structure, same error handling, same logging style.”

Now the agent has something concrete to follow.

Real-life analogy

It’s like mentoring a junior engineer:

• Bad instruction: “Write a clean PR.”
• Good instruction: “Here’s one of our best PRs. Follow this style—same patterns, same structure.”

Mini example

You can literally do this in an agent prompt:

• “Open auth/login/ folder. Find existing login flow. Mirror it for new flow.”
• “Reuse the same error mapping style.”
• “Reuse the same telemetry events.”

7.2 Filesystem as memory

What it means (simple)

This means:

“Instead of expecting the agent to remember everything inside the chat, let it store notes and indexes in files.”

Humans do this too. We don’t keep the whole system in our head. We use:

• docs
• READMEs
• TODO files
• architecture notes
• code search

StrongDM is applying that same idea to agents:

• the agent writes “notes to self” as files
• it creates small “indexes” so it can find things again later
• it uses search tools (like grep) to quickly locate relevant code

Why it helps

AI agents have limited “working memory” in a conversation. If the problem is large, they forget earlier details.

But if the agent stores key knowledge in files, it can “refresh its memory” later by reading those files.

Real-life analogy

Think of it like a developer creating:

• NOTES.md
• DECISIONS.md
• ARCHITECTURE.md
• TODO.md

So even if they step away for a day, they can come back and continue consistently.

Mini example

While implementing a feature, an agent might create:

• design-decisions.md

  • “We chose approach X because of Y”
  • “We must keep endpoint backward compatible”

• integration-map.md

  • “Service A calls Service B”
  • “Auth token is passed via header Z”

Later, the agent can search and read these files instead of “guessing”.

7.3 Shift Work

What it means (simple)

Shift Work means:

“Humans do the back-and-forth discussion early. Once the intent is clear, the agent runs on its own for a longer stretch.”

So the work happens in two phases:

Phase A: Interactive phase (human + agent)

This is where humans clarify:

• what exactly we want
• edge cases
• constraints
• expected behavior
• what success looks like

Phase B: Non-interactive phase (agent runs end-to-end)

Once everything is clear, the agent:

• implements
• runs validation/tests/scenarios
• fixes issues
• repeats until stable

Why it helps

If you ask an agent to run autonomously while requirements are still unclear, it will:

• make assumptions
• choose wrong paths
• waste time building the wrong thing

StrongDM’s point is:

• don’t run the “autonomous factory mode” until the “what” is settled

Real-life analogy

This is like cooking:

• First you agree on the recipe and ingredients (interactive phase)
• Then you let someone cook without interrupting every 30 seconds (execution phase)

Or like software:

• First you write the design doc / acceptance criteria
• Then the implementation can proceed with fewer interruptions

Mini example

• Human clarifies: “Must support SSO, must log every session, must block access after 15 minutes idle.”
• After that: agent can implement + validate without asking 25 follow-up questions.

How these 3 techniques connect (simple picture)

• Gene Transfusion keeps the agent consistent by copying proven patterns
• Filesystem as memory keeps the agent consistent over time (it doesn’t “forget”)
• Shift Work keeps the agent efficient (don’t let it run wild before requirements are clear)

Together, they reduce:

• “random changes”
• “inconsistent style”
• “wrong assumptions”
• “lost context”

8) Observability layer: why a “context store” becomes necessary

Once you run multi-agent loops with retries, branching, tool calls, and long-lived sessions, “logs” alone don’t cut it.

StrongDM uses CXDB as an “AI Context Store” for conversation histories and tool outputs in an immutable DAG (Directed Acyclic Graph), and notes the sheer amount of generated implementation code that went into it.

CXDB’s DAG is more like a history/lineage graph showing how one “turn” leads to the next, including branching and forks (and sometimes merges).

Sample DAG

Think of it like Git commits or an agent run history: each step points to the previous step, and the run can branch into multiple attempts. Those branches form a DAG.

CXDB-style systems are to agentic development what distributed tracing is to microservices.

9) Guardrails layer: Leash + Cedar + MCP as agent security infrastructure

At Dark Factory levels, agents are effectively privileged workloads:

• they can call tools,
• access internal systems,
• run code,
• touch data.

StrongDM’s Leash is positioned as security/visibility/authorization for agents, including sandboxed execution, policy enforcement using Cedar, and explicit MCP authorization.

Their Leash blog post adds operational detail:

• Leash intercepts agent activity and evaluates against Cedar-defined (about that in a moment) policies
• It operates inside the kernel network stack to enforce policy before connections are established
• It parses MCP and can control which MCP providers/tools are permitted, preventing authorization bypass

Leash (from StrongDM) is an open-source tool that:

• runs AI coding agents in a sandboxed container
• monitors their activity (filesystem access + network connections)
• enforces Cedar policies in real time
• provides a control UI so you can see what the agent is doing

StrongDM describes it as a way to:

• eliminate blind spots in agent behavior
• prevent runaway agents
• apply “hot-reloadable” policies without redeploying

Cedar is an open-source authorization policy language from AWS. It lets you write clear rules like:

• “This agent can access GitHub, but not production.”
• “This agent can read source code, but cannot read .env files.”
• “Only agents with tag ci-runner can deploy.”

Cedar’s whole job is to answer one question:

ALLOW or DENY this action?

Leash and Cedar go together like seatbelts + traffic rules for AI agents.

10) Economics layer: token burn as a dial, not a side effect

StrongDM’s mantra-like framing:

“If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.”

In other words: compute is treated like fuel:

• more tokens → more iteration → more validation → more convergence opportunities

That creates a new optimization surface:

• routing models,
• caching prompts,
• reducing wasted loops,
• controlling validation scope.

Extended view: a fuller “factory stack” over your diagram

If you put all these new things together in the earlier AI interaction flow diagram, it adds lot of other nuances which earlier diagram doesn't really capture. Below diagram is more near real world interaction flow of Software Dark Factory.

Software Dark Factory Deep Dive Interaction Pattern

What is still unanswered

So it looks like with all this information we have at our disposal, we might want to implementing this Dark Software Factory pattern in our org tomorrow. But there are still many unresolved pieces in this puzzle

Declaration (to place above the diagram / section)

This is my understanding and interpretation of the Software Dark Factory idea, based on what I’ve read across multiple articles and public GitHub repositories. I’m synthesizing these sources into a single mental model to explain how the pieces fit together.

Original links referenced

• StrongDM Software Factory (site)
• StrongDM Software Factory Techniques
• DTU – Digital Twin Universe (technique)
• Simon Willison – StrongDM Software Factory analysis
• StrongDM blog – Building software with AI (Software Factory)
• Leash – Policy enforcement for agentic AI (StrongDM blog)
• Leash (product/site)
• Leash (GitHub repository)
• Cedar (AWS announcement / overview)

Thanks for reading a long article, but if you have reached here you might be wondering this means there would be need for completely new set of skills from AI era software engineers and you are right. Even orgs have to rethink what it means to run a Software development org. I have talked about it. Please check it out.