The software factory, explained for working teams

On February 6, 2026, StrongDM published its software factory: "non-interactive development where specs + scenarios drive agents" that write code, run harnesses and converge without human review. Its two rules are blunt: "Code must not be written by humans" and "Code must not be reviewed by humans." Source: factory.strongdm.ai.

Simon Willison wrote it up the next day ("How StrongDM's AI team build serious software without even looking at the code"). Two ideas from his write-up matter for anyone building toward this: validation by "satisfaction," the fraction of scenario runs that likely satisfy the user, and a "Digital Twin Universe" of cloned SaaS dependencies so agents can test against realistic services. The lesson is that removing human review only works when validation is strong enough to replace it. Source: simonwillison.net/2026/Feb/7/software-factory/.

Dan Shapiro's January 2026 post models AI coding on the NHTSA driving-automation levels. At Level 0, "not a character hits the disk without your approval." At Level 5, the dark factory is "a black box that turns specs into software," a place "where humans are neither needed nor welcome." Source: danshapiro.com, "The five levels: from spicy autocomplete to the software factory."

The useful part of the framework is that it names the middle. Between "I approve every change" and "I never look" there is a lot of room. For a team running several coding agents, the practical question is how to move along that scale without losing track of what the agents are doing.

AWS introduced the AI-Driven Development Life Cycle on July 31, 2025 (Raja SP). It treats AI as "a central collaborator and teammate" across three phases: Inception, Construction and Operations. Sprints become "bolts," shorter cycles measured in hours or days, and "Mob Elaboration" has the whole team validate the AI's questions and proposals. AI-DLC is the opposite pole to the dark factory: humans are explicitly in the loop at every phase. Source: aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/.

A row of isolated agents in worktrees is a useful tool, but it is not a factory. A factory implies flow: work moves from one station to the next, and the output of one step is the input to the next. In a parallel runner, every agent's output flows to you. You are the conveyor belt. That caps how many agents you can usefully run, because each one adds relay work.

Between "I relay everything" and "lights out" is a layer most setups lack: agents that can see each other's work, hand off tasks with context, and stop to ask a human only when a decision is needed. That is the layer BAND for desktop provides. Agents hand work to each other in shared rooms (Claude Code via BAND's plugin (documented in docs.band.ai); Codex, GitHub Copilot and OpenCode are listed as coding-agent integrations on band.ai/integrations); BAND lists a kanban board for desktop, marked Coming July 2026 on its site; you answer where an agent needs direction; coding sessions run locally and only coordination messages go over the wire.

It is not a dark factory. BAND says it is "not a replacement for agents, GitHub, tests, or developer judgment." In Shapiro's terms, it helps teams move up the levels while keeping a human on the moves that matter. In AI-DLC terms, it is where the team and the agents meet during Construction.

1. Start with two agents whose work depends on each other (for example API and tests). Measure how often you relay context by hand.
2. Put them on a shared board so handoffs are explicit and visible. Keep human approval on merges.
3. Strengthen validation before you reduce review: tests, scenario checks, and staging environments. StrongDM's "satisfaction" metric and digital twins are examples of how far that can go.
4. Only then reduce human review, one class of change at a time.