Imagine a customer reports a broken export at the end of the day. By morning, the failure has been reproduced, a patch has been tested, a small rollout has completed, and the service is behaving normally. Nobody had to move the ticket between those steps.
Now change the request: a large customer wants exports to include data that another customer’s administrators are not supposed to see.
Both requests might arrive as “fix the export.” They should take very different paths through a software factory.
That difference is where I would start a conversation about the dark factory: a software delivery system that can carry eligible work from an accepted request through implementation, verification, release, and operational feedback without routine human intervention. The name is borrowed from lights-out manufacturing: plants automated enough to run with the lights off, because nobody is on the floor to need them.
“Eligible” matters. An unattended delivery path for a known class of changes is a concrete engineering target. An organization that autonomously decides what is valuable, resolves every conflict, and accepts every consequence is a much larger proposition. I would not treat the first as evidence that we have achieved the second.
The progression below is my proposed operating model, not an industry maturity standard or a forecast that every team will reach the final stage.
Starting with the lifecycle we already have
Classic software development already has a feedback loop:
Understand the problem → define and design → implement → verify → release → observe → revise.
That does not require waterfall. An agile team can move through the loop in small increments, and a mature delivery platform can already automate builds, tests, deployments, and recovery procedures. The starting point is not “everything is manual.” It is that people normally connect the stages, interpret exceptions, and authorize consequential decisions.
AI-assisted delivery initially keeps that arrangement. An engineer asks for a design comparison, uses a coding assistant, generates test cases, and reviews the result. Individual activities change before the operating model does.
I use AI SDLC for the broader redesign: intent, context, execution, verification, authority, and feedback become explicit parts of a lifecycle in which agents can carry work across stages. Assistance is the entry point to that redesign.
| Delivery mode | What the system carries | What people still carry |
|---|---|---|
| Classic SDLC with CI/CD | Repeatable build, test, and release mechanics | Interpretation, implementation, coordination, exceptions |
| AI-assisted delivery | Suggestions and delegated local tasks | Integration of the work and most transitions between stages |
| Agentic AI SDLC | A bounded request through planning, implementation, and evidence collection | Acceptance of intent, consequential approvals, unresolved ambiguity |
| Bounded software factory | Eligible changes through release and observation under enforced policy | Policy ownership, exception handling, sampled audits, expansion decisions |
| Dark factory for a defined domain | The routine delivery loop, including safe recovery and feedback | Direction, accountability, novel tradeoffs, and redesign of the factory |
These modes can coexist in one company. Documentation maintenance might use an unattended path while authorization changes require detailed review. A team can also move backward after an incident or a significant model change.
The distinguishing question is: which decisions can the system make, on what evidence, with what consequences if it is wrong? Counting agents or generated lines of code does not answer it.
This extends the coordination argument in From Manual to Agentic Orchestration. Here, the additional question is what must be true before removing a handoff is responsible.
What holds the factory back
“Human judgment” is too broad to be a useful backlog item. Some judgment is an undocumented rule. Some is expertise that can be supported with better evidence. Some is a choice between competing interests that no test suite can settle on its own.
| Constraint | Why automation stalls | A practical way to reduce it |
|---|---|---|
| Ambiguous intent | Several implementations satisfy the words but produce different outcomes | Record examples, exclusions, acceptance criteria, and an owner for unresolved choices |
| Missing domain context | The repository omits customer promises, operational history, or data assumptions | Maintain authoritative context with owners, scope, and review dates |
| Weak verification | Passing tests can confirm the wrong interpretation | Add independently specified scenarios, invariants, and production outcome checks |
| Hidden coupling | A small patch changes behavior outside the apparent task | Clarify interfaces, exercise dependencies, and restrict the initial change boundary |
| Irreversible effects | Reverting code does not undo an email, a payment, or destroyed data | Separate preparation from execution; require explicit authority for irreversible actions |
| Conflicting priorities | Speed, cost, compatibility, and customer trust point in different directions | Name the decision owner and document the tradeoff before execution |
| Unreliable feedback | Missing or misleading telemetry makes success hard to distinguish from silence | Define observable outcomes and stop when required evidence is unavailable |
A concrete example of the domain gap appears in the April 10, 2026 arXiv preprint Can Coding Agents Be General Agents?. Its ERP case study reports reliable completion of simple tasks but characteristic failures on complex ones involving business logic. One case study on one ERP system cannot settle how agents perform in general. I take it as a reason to evaluate the business workflow as well as the code change.
I would separate human interventions into three categories.
| Category | Looks like | What it calls for |
|---|---|---|
| Recoverable knowledge | A reviewer repeatedly explains that exports must preserve the customer’s timezone | A maintained requirement, a test fixture, and a check. Keeping it in the reviewer’s head makes every future change depend on the same person. |
| Judgment under uncertainty | A change could simplify the product but disrupt a valuable customer’s workflow | AI can collect evidence, describe alternatives, and suggest an experiment. A person still needs to decide how much uncertainty the organization is willing to carry. Better evidence can narrow the decision without making it disappear. |
| Authority and accountability | Someone has to own the choice of whose interests take priority and which risks the company accepts | Even if a model becomes better at recommending that choice, capability alone does not grant it authority. Delegation needs a named owner, a scope, and a way to revoke it. |
The book chapter Human in the Loop goes further into writing that authority down before an incident forces the question.
The second export request from the opening belongs in this last category. No test suite can tell the factory whether one customer’s wish outranks another customer’s data boundary. The factory’s job there is to recognize the question and route it to the person who owns the answer.
This is why “remove humans from the loop” is an incomplete target, a point I also made at the end of Stretching the Limits of AI SDLC. Removing repeated explanations is useful. Removing the only person authorized to resolve an unresolved conflict leaves the conflict inside the automation.
Build one unattended path before expanding the factory
Consider a fictional team responsible for a reporting service. It starts with reproducible CSV formatting defects. Changes to permissions, billing, data retention, and database schemas are excluded. Even within formatting, a change to how spreadsheet cells are escaped receives security review.
That boundary is intentionally narrow. “Small diff” would be a poor substitute: a one-line authorization change can have a larger consequence than a substantial rendering refactor.
The team can expand autonomy through a sequence of experiments:
- Establish the baseline. Record elapsed delivery time, review effort, escaped defects, and recovery time for this class of work. Include abandoned attempts and rework. Preserve examples of both acceptable fixes and plausible failures.
- Run in shadow mode. Let the agent propose a plan, patch, and evidence while the existing human process remains authoritative. Compare decisions, not just final code. Investigate why the agent would have shipped something the reviewer rejected.
- Delegate implementation. Give the agent an isolated environment and bounded permissions. It can prepare a patch and run checks; a person authorizes release. Every interruption gets a reason, such as missing context, conflicting requirements, inadequate tests, or an actual product decision.
- Delegate a limited release. After a representative evaluation, allow eligible changes to reach a restricted rollout through an external policy gate. Enforce eligibility outside the agent. If the patch touches an excluded area, a required check is unavailable, or the recovery procedure cannot be used, it stops.
- Delegate the routine loop. Extend rollout only when the agreed observation window and outcome checks pass. Continue sampled human audits. Widen the eligible class only after reviewing its own evidence, and reduce autonomy when that evidence deteriorates.
Against the earlier table: steps 1 and 2 leave the team’s existing delivery mode in charge, step 3 is the agentic AI SDLC row, step 4 is the bounded software factory, and step 5 is a dark factory for this one class of work.
Promotion criteria should be written before the experiment. The service owner sets acceptable defect severity and frequency, required scenario coverage, recovery objectives, and review capacity. There is no universal number of successful patches that makes an arbitrary service safe to automate. The book chapter Evaluation and Release Evidence covers promoting and revoking authority by task class in more detail.
A dozen clean runs on nearly identical examples tells us little about a rare but severe failure. Deliberately exercise malformed input, missing dependencies, stale context, denied permissions, and failed recovery. Require the system to demonstrate that it can stop, as well as succeed.
The request itself needs enough structure to support that process. The AI-Executable Ticket describes the input side: outcome, scope, non-goals, validation, and risk. For a factory, I would add allowed actions, a time and cost budget, escalation conditions, and the evidence needed to close the task.
The agent should not be able to rewrite those acceptance rules merely because its implementation fails them. It may propose a policy change through a separately reviewed path.
For our reporting team, a useful failure might be an export that looks correct but changes column order for an older integration. The immediate response is to contain the change. The longer-term improvement is to capture the compatibility requirement, add the missing scenario, replay it against the workflow, and check whether the same gap affects other export formats. “Be more careful next time” contributes nothing the factory can execute.
Predictability needs more than a green pipeline
I would define predictable delivery as a bounded distribution of time, cost, and consequences for a specified class of work. It does not require the model to generate identical code on every run. It requires the surrounding system to produce acceptable outcomes consistently and handle unacceptable ones within known limits.
That means limiting work in progress, bounding retries, and budgeting both compute and human attention. An agent that retries indefinitely is not reliably autonomous. Neither is a fleet of agents that fills a review queue faster than people can assess it.
Keep an evidence trail for each change: the accepted request, repository revision, relevant context versions, model and harness configuration, tool actions, evaluated artifact, results, release decision, and observed outcome. Revalidate after rebasing or changing the artifact. These records support investigation; they do not guarantee an identical replay of a probabilistic model or a changing external service.
The quality checks need different jobs:
- Before execution: clarify intent, classify risk, restrict permissions, and establish what must remain true.
- Before release: check behavior against independently maintained scenarios, test integrations and security boundaries, and inspect maintainability where automated measures are insufficient.
- During rollout: limit exposure, compare operational and product signals, and stop on missing or contradictory evidence.
- After release: look for delayed regressions, review a sample of apparently successful work, and incorporate new failure cases into future evaluations.
Drawn as one path, the first three checks become gates, and each gate has the same exit.
- Accepted requestOutcome, scope, non-goals, evidence to close
- Before executionEligibility gateStops when the change touches an excluded area
- Patch and evidenceIsolated environment, bounded permissions
- Before releaseRelease evidence gateStops when a required check fails or is unavailable
- Limited rolloutRestricted exposure, recovery plan ready
- During rolloutObservation gateStops when signals are missing or contradictory
- Wider rolloutSampled human audits continue
Stop and return control to a person.A named owner decides, and the reason for the stop is recorded.
After releaseNew failure cases become scenarios for the next run.
Generated tests are useful contributions, but an agent can encode the same mistaken assumption in both implementation and tests. Another reviewing agent may share that blind spot. Independent evidence means checking against requirements and observations that the implementation cannot redefine, not merely asking a second model whether the patch looks good.
The April 3, 2026 arXiv preprint Beyond Isolated Tasks proposes SWE-STEPS to evaluate chains of dependent changes. In its settings, isolated PR evaluations overshoot success rates by as much as 20 percentage points relative to sequential work, and agents that do resolve issues still leave code with higher cognitive complexity and technical debt than human developers. Those figures belong to the paper’s settings and will differ elsewhere. The evaluation choice they support travels better: test the factory across accumulated changes as well as fresh repositories and isolated tickets.
Recovery deserves the same scrutiny. A code rollback may restore an executable while leaving already-written data incompatible. A rollout is eligible for unattended operation only if its actual side effects fit the recovery plan. Otherwise the correct automated action may be to halt and request a decision.
For the reporting team, I would review a compact scorecard:
| Measure | What it helps reveal |
|---|---|
| Median and tail delivery time for eligible work | Whether the workflow is becoming consistently faster, including its slow cases |
| Escaped defects and change failures, grouped by severity | Whether throughput is being purchased with downstream damage |
| Detection and recovery time | How long an unacceptable change remains harmful |
| Human intervention time and reason | Which constraints are shrinking, and which have only moved |
| Total cost per accepted outcome, including failed attempts and rework | Whether autonomy is economically useful |
| Customer outcome and compatibility checks | Whether the change solved the intended problem |
Track the share of incoming work that qualifies too. An apparently perfect factory handling only the easiest one percent of requests is a different achievement from broad unattended delivery. Keep comparisons within similar risk and complexity classes, and show sample sizes. Low observed failure counts alone do not establish low risk. Stop Measuring Motion makes the longer case for measuring outcomes over activity.
Improving the factory becomes engineering work
The improvement loop is straightforward to describe and demanding to maintain:
Observe an intervention → classify its cause → change the relevant control → evaluate the change → expand or withdraw authority.
| If the intervention was | Change |
|---|---|
| A repeated explanation | Improve the context |
| A missed behavior | Improve the specification and verification |
| A fragile environment | Fix the environment |
| A conflict between stakeholders | Bring the conflict to an accountable decision-maker |
A longer prompt is not the answer to all four.
There is research support for treating the feedback interface as an engineering variable. The April 15, 2026 arXiv preprint AI Coding Agents Need Better Compiler Remarks reports that precise compiler remarks gave agents actionable feedback on the TSVC benchmark (the abstract cites a 3.3x success rate), while ambiguous remarks triggered hallucinated transformations that broke program semantics. Its scope is narrow. My inference is broader: before replacing the model, investigate whether the workflow gives it actionable evidence.
Changes to the factory itself need controlled evaluation. A new model, prompt, tool, context source, or permission policy creates a new configuration. Compare it against the previous configuration on representative tasks, retained failure cases, and unseen evaluation scenarios. Roll it out gradually. Keep a way to restore the earlier configuration, and prevent the agent from weakening its own release gates.
Human expertise also needs maintenance. Rotate engineers through exception handling, sampled audits, and recovery exercises. If nobody understands the system well enough to challenge an automated decision, keeping an approval button does not provide meaningful supervision.
For a team starting now, I would choose one frequent, bounded class of work and write down three things: what qualifies, what evidence permits release, and what immediately returns control to a person. Then run the shadow workflow and use its disagreements to decide what to improve first.
An unattended delivery path is worth building when it produces useful changes with acceptable cost and consequences. Some paths may remain supervised indefinitely. The organization should be able to explain that choice as clearly as it explains where the lights can go out.
Research checked October 1, 2026. The three external papers were first submitted in April 2026 and fall within the six-month source window at drafting. They are cited as arXiv preprints; hosting on arXiv does not establish peer review. The reporting-service example and the proposed progression are illustrative, not reported company outcomes.