Dark Factories Optimize the Wrong Thing

The dark software factory has an appealing promise: give agents the specification, let them build and verify, and collect the result. More execution. Less waiting. Work that keeps moving after the conversation ends.

That is a useful capability. It becomes the wrong ambition when the factory treats unattended completion as the prize. The question that matters is whether the work was worth doing—and whether what arrives is something people actually want to use.

A faster implementation of a weak idea is still a weak idea. A larger queue of technically correct changes can still leave the organization struggling to make a decision, reconcile a design, or ship a coherent release.

The specification is not the finish line

Consider a team building an approval workflow. The agent follows the brief: three approvers, reminders, a status page, and an audit trail. The tests pass. The implementation is complete.

Then someone uses it. The routine case requires too many clicks. The exception is hard to understand. The third approval adds delay without changing the decision. A polished implementation has made the wrong workflow easier to repeat.

This is a hypothetical example, but the distinction is practical. Verification can establish that the system behaves as specified. Judgment can reveal that the specification deserves to change. Good engineering needs both.

Creativity reframes the problem. Taste recognizes the unnecessary step. Judgment decides which constraint matters and which habit can go. Agents can contribute to that work too. The factory should make those contributions easier to develop together.

Autonomous execution has a place

The strongest argument for a dark factory is work with clear intent and a dependable way to evaluate the result. A protocol implementation, a known migration, or a well-defined repair can benefit from agents executing without repeated interruption.

StrongDM's own Shift Work documentation distinguishes interactive work, where people and agents develop intent together, from non-interactive work whose intent is already fully specified. That is a useful distinction. It also exposes the limit of making one execution mode the philosophy for an entire organization.

Product work does not stay fully specified. Customer feedback changes the priority. A design review changes the interaction. Another team changes an interface. An apparently small request turns out to need a different solution.

The valuable system lets execution proceed when the intent is clear, and helps the right judgment reach the work when it is not. Autonomy should serve that purpose.

The bottleneck moves beyond coding

More changes create more integration decisions. Someone must connect the customer request to the current requirements, the implementation to the design, and the review to the intended outcome. When that context lives in separate conversations, the team spends its attention reconstructing it.

DORA's 2025 research describes AI as magnifying an organization's existing strengths and weaknesses, with the surrounding organizational system central to its returns. Our conclusion is that speeding up an isolated activity cannot substitute for improving how the whole piece of work reaches a useful outcome.

The factory worth building connects the work to its reasons, its dependencies, and the people and agents responsible. It keeps decisions available as the work moves. It makes it possible to approve, redirect, or question a result with enough context to make that intervention useful.

Build at the ceiling

We want agents to execute more. We also want the additional capacity to produce better software: clearer interactions, stronger decisions, fewer unnecessary steps, and more ambitious solutions.

That is why Lit Factory focuses on human + AI craft. Teams keep the coding-agent environments they have optimized for their workflow. Shared context, connected work, and task autonomy help people and agents contribute across the delivery process. The goal is to preserve creativity, taste, and judgment as execution expands.

A useful factory can accommodate collaborative work and independent execution. It should help the organization choose the right level of involvement for the work in front of it, rather than reward the longest possible stretch without a conversation.

Measure what the work becomes

Code output is worth measuring. It is not enough to settle whether the factory is succeeding.

Look at what reached users, what came back for rework, how long decisions and reviews waited, and whether the result solved the problem. Ask whether the team can take on more consequential work while maintaining its standard for what deserves to ship.

The prize is better software delivered with less friction. A factory that optimizes only for unattended output is aiming below the ceiling.