Why executives need a dark factory

An executive can have a productive hour with an AI assistant and still leave with another job to finish. The conversation produced an outline, some research, perhaps the beginnings of a model. Turning those pieces into something usable still depends on the executive returning to the keyboard.

A dark factory is a production system that carries a defined assignment through to a checked result without continuous human direction. The idea comes from manufacturing and has a specific meaning in software. For executives, it offers a practical possibility: work can advance while their attention is elsewhere.

Executives should own a small version of that capability: a way to explore ideas before committing a team and to learn firsthand how to commission AI work.

What the term means

The manufacturing idea behind a lights-out factory is production that can run without people continuously present on the floor. The darkness describes the absence of a continuous human operator, rather than the absence of human responsibility for the operation.

In software, the term has a stricter meaning. In Dan Shapiro’s account of AI development, the dark factory is the endpoint of increasing automation: a system that turns specifications into software. The human defines what should be built; the production process no longer depends on someone writing or reviewing every increment of code.

StrongDM describes a concrete version of this approach. In its software factory account, agents write code and run validation from specifications and scenarios without human code review. Its team describes using scenarios outside the codebase to make it harder for a generated implementation to pass by merely satisfying tests it can rewrite. This is the company’s report of its own method, rather than evidence that unattended development will work equally well for every business.

For executive work, we propose a broader application: a small production system that can carry an assignment through several steps, check its output, and deliver something you can use to make progress. Its output might be software, a research-backed prototype, or an analytical model with an explanation of its assumptions.

A chatbot waiting for your next prompt does not yet provide this capability. Nor does a scheduled email become a factory by acquiring a new name. The important property is delegated production: the system can choose and execute intermediate steps toward an agreed result without requiring you to supply each next instruction.

Give it something worth making

Consider a hypothetical commercial director exploring a self-service onboarding option. The idea is promising enough to examine, but too unsettled to justify putting a full project on the product team’s schedule.

She commissions a private overnight exercise. Using a limited set of public product documents, the system should compare how several providers handle onboarding, identify the choices her team would need to make, and build a small working demonstration using synthetic customer records. The assignment includes a spending limit, a stopping time, and a specific destination for the finished files.

The demonstration must let her try both a straightforward customer and one that needs specialist help. She supplies those acceptance cases separately from the build instructions. A checking step must run the demonstration against them, verify that the comparison links to supporting sources, and report any unsupported claim or unfinished behavior. The system can revise its work within the agreed limits.

The desired return is a runnable prototype, a short comparison, the results of those checks, and a clear account of what remains unresolved. Nobody has contacted customers or changed a live process. The director still decides whether the work is sound enough to share and whether the idea merits investment.

An overnight run might fail. The sources may not answer the question, or the demonstration may reveal that the proposed flow depends on an exception nobody specified. A useful factory returns that finding plainly. It should not manufacture a complete-looking answer to conceal an incomplete job.

The return is more than faster output

The first benefit is freedom from continuous attendance. A sequence that requires a fresh prompt at every turn occupies attention even when each individual response is quick. Delegating the sequence lets the director spend her next morning reviewing an object she can inspect and use, instead of reconstructing where yesterday’s conversation stopped.

The second benefit is room to explore before an idea becomes an organizational commitment. Asking a team to investigate a vague executive suggestion can consume time and signal a priority that the executive never intended to set. A private prototype can help her find the real question first. She can discard it, refine it, or bring colleagues a more concrete proposition.

This is where relatively inexpensive production matters. A rough demonstration may be worth attempting even when the idea has a substantial chance of going nowhere. The relevant cost includes setup, model use, checking, and maintenance. If those costs exceed what the experiment teaches, it has not earned its place. The opportunity is to make more useful questions affordable to investigate, not to keep a machine busy overnight.

The third benefit is better judgment about other people’s AI proposals. Working through even a small factory teaches the difference between a clear objective and a convincing brief. You discover which omissions stop production, which checks expose a weak result, and which apparent successes depend on someone quietly repairing the output.

Those observations improve the questions you ask when a supplier or internal team proposes a larger system. What can it finish without intervention? What does it return when it cannot finish? How do we know the output works? You can ask from experience rather than from a demonstration’s choreography.

Own the capability, keep the scale modest

An executive does not need to build the infrastructure personally. Technical help may be necessary to set up the environment, connect permitted tools, and maintain it. Ownership means understanding the assignment, choosing the acceptance conditions, reviewing the return, and knowing who supports the system when it fails.

A sensible first factory makes one kind of thing. The onboarding exercise could become a repeatable way to turn an early service idea into a source-backed comparison and a working demonstration. Expanding to every recurring executive task would make it harder to learn where the method is useful.

Keep its work in an appropriate environment, with bounded spending and access. Private exploration using synthetic inputs is a good starting point because mistakes can be inspected before they reach other people. Independent checks should reach the evidence or run the artifact; a second model’s agreement alone does not establish that the first one was right.

There is a management choice here. If every experiment must wait until you can personally guide every step, the number of ideas you can examine remains tied to your available hours. Some ideas deserve that attention. Others deserve a clear assignment and a chance to produce something while you do the rest of your job.

Choose one question you have postponed because investigating it felt disproportionate. Define what you would like to examine on its return: a working screen, a comparison you can trace to sources, a model you can change. Then commission a small run and judge whether the result makes the next conversation better. That is enough production to begin learning from.