← All articles
SDLC · 4 MIN READ

The dark factory still needs a product mind.

Autonomous delivery makes intent, acceptance criteria, and accountability more valuable—not less.

THE SHORT ANSWER

A dark software factory aims to automate software production with agents. For a product team, the challenge is deciding what should be produced and proving that the result serves a real user need. Autonomy needs boundaries and evidence.

The metaphor—and its limits

The factory metaphor shifts attention from individual coding tasks to the system that produces software. StrongDM’s software-factory work offers a concrete reference for exploring agent-driven implementation. Treat that reference as one approach, rather than evidence that every team can safely remove human oversight.

My product lens: faster implementation amplifies ambiguity. A vague request can now become a large amount of convincing software before anyone notices that the original problem was misunderstood.

Specify the outcome before the workflow

Start with a named user, a concrete task, and a constraint that must survive implementation. Define the behavior that would demonstrate success. Include what must not happen: unauthorized access, irreversible actions, or a misleading success state.

For example, an agent building a support triage tool should not merely pass a test that it can categorize a ticket. It should demonstrate how it handles uncertainty, protects restricted customer context, and routes consequential decisions to an accountable person. This is an illustrative design scenario, not a reported deployment.

Separate generation from evaluation

Use scenarios that test the business intent independently of the implementation. Ask whether the tool is useful under realistic inputs, how failure becomes visible, and whether the organization can reverse a bad change.

A passing automated check is evidence about what the check measures. It cannot establish that the team chose the right problem. Reserve explicit checkpoints for decisions with consequences that cannot be cheaply undone.

A useful first experiment

Choose one bounded, reversible workflow. Record the baseline effort, quality, and failure rate. Compare the automated path using the same scenarios, including difficult cases. Keep a named owner and a rollback route.

The interesting metric is useful work completed with acceptable risk. Code volume and agent activity can help explain that metric, but they should not replace it.

Questions worth asking

Does a dark factory eliminate product management?

No. It can automate parts of implementation. Product judgment still defines the problem, boundaries, and evidence of value.

Where should a team start?

Start with a bounded workflow that is reversible and has independently testable acceptance scenarios.

Sources & further reading

These sources inform the context. Recommendations and frameworks are editorial analysis, not claims of proven results. AI-assisted draft prepared for Yaron’s review; personal experience claims require his confirmation.