A customer reports a bug. An agent investigates, writes the fix, runs the tests, and opens a pull request. Somewhere along the way a person answers a question in Slack and approves an approach. The factory reports success.

Two weeks later the customer still has the bug. The fix is sitting in a branch, waiting for someone with enough time and enough understanding of the system to decide whether it should ship.

That is the dead dark factory I worry about: a plant that never stops producing code while customer fixes go stale in branches.

How dark is it really?

We have a new name for the machinery, the dark factory, and I have a question about the first word. How dark is a factory that needs someone in Slack to keep the work moving?

A message that starts a job tells us little about autonomy. Neither does a notification that the work is done. Humans can define the goal, set the constraints, and keep authority over a production release. But if the system keeps needing a person to interpret a failure, settle an implementation decision, or say what to do next, those interventions are part of how it operates. Measure them. Budget for them. Describe the autonomy as what the system actually handles on its own.

StrongDM gives a concrete reference point. Its Software Factory description says humans specify intent, scenarios, and constraints, then agents implement and validate the result without human code review. That is a company describing its own system, with an explicit boundary around what has been specified. A workflow that needs continuing human direction has a different boundary. It may still be valuable, but its throughput depends on the people supplying that direction. It is the same line I drew in The Jig : once the human steps out of the loop, something other than a person has to hold the path.

Who can accept the result?

Say the system does get all the way to a pull request on its own. The next constraint is the person who receives it.

That engineer probably had no part in the investigation. They have to reconstruct the requirement, understand the decisions, judge the tests, and work out what else the change could touch. That can take knowledge of customer contracts, old incidents, data migrations, infrastructure, security boundaries, and peculiar behavior that exists for a reason nobody put in the ticket.

The agent produced a solution. The reviewer inherits the job of deciding whether that solution belongs in this system. This is where the conversation about cheaper code becomes a conversation about scarce judgment, and where accountability stays with a person no matter who wrote the patch.

What the data says

There are numbers behind the worry.

In an August 2026 working paper on bottlenecks in software production , Harvard researchers Fiona Chen and James Stratton analyze roughly 300 million work events across 718 firms. After adopting AI coding agents, firms see 30% more lines of code and 23% more pull requests, and a 49% increase in pull request review time, measured from submission to merge. They find no statistically significant increase in completed Jira issues or epics.

Faros AI’s 2025 telemetry report covers more than 10,000 developers across 1,255 teams. In its high-adoption comparisons, teams merge 98% more pull requests and spend 91% longer in review.

And in a June 2026 GitLab survey run by The Harris Poll , 85% of 1,528 developers and technology buyers agreed that AI has shifted the bottleneck from writing code to reviewing and validating it.

None of these proves dark factories fail. One is a quasi-experimental working paper, one is a vendor’s observational data that is mostly autocomplete usage, and one measures perception. Different methods, different populations, different kinds of AI assistance. Together they are enough reason to take downstream capacity seriously.

The queue math

Take a deliberately simple example. A factory produces 40 changes a week and the team can responsibly review and integrate 20. After five weeks, 100 more changes are waiting. Faster generation only makes that queue grow faster.

Then the waiting starts creating work. Main moves forward. Interfaces change. Another fix touches the same behavior. The original tests pass against yesterday’s assumptions, so someone has to update the branch, rerun validation, and reconsider the result. DORA’s guidance on trunk-based development describes the pattern: delayed integration raises conflict risk, and large changes get harder to review and wait even longer.

AI did not invent branch rot. A factory just accumulates it faster. Some of those branches will be recovered, some superseded, and some closed after the customer has waited through the whole exercise. A closed branch can be the right engineering call. It still has to be counted when someone presents the factory’s output as delivered value.

Judgment is the scarce part

My architectural inference, and not a headcount conclusion from any of these studies, is that operating these systems takes more access to engineers who know the system being changed. That means expertise matched to the change, not a title. A senior title does not supply familiarity with a particular service, and someone newer to the profession may know that service better than anyone.

Google’s code review guidance sets the expectation: reviewers consider design, functionality, concurrency, tests, and the wider system, and bring in a qualified reviewer when specialist knowledge is needed. Expand implementation capacity without expanding access to that judgment and you build a queue around the few people who can approve the hard changes.

Those people are already carrying incidents, architecture, mentoring, and the most sensitive customer problems. “Have the principal engineer look at it” is a capacity commitment, and ten agents can make it ten times before that engineer finishes the first review. So broaden the expertise. Pair reviewers, preserve decision history, improve the documentation, and give engineers time to learn the systems they are expected to own. Otherwise every escalation returns to the same small group.

Teams can adapt, though. A July 2026 preprint on 802 developers at one company reports merged pull requests per developer reaching 2.09 times the earlier baseline. Code review was restructured around automation, with automated review overtaking human review and reviewer load roughly doubling, while merge and revert rates held steady. It is one observational case, and those rates do not establish product quality. It does show that higher output can get through review when review itself changes.

What I would put in the factory

I would start with five expectations.

1. Assign ownership before generating the change. Identify who can accept it, what expertise it needs, and whether that capacity exists. Match work in progress to the team’s ability to finish it.

2. Deliver evidence with the code. Include the customer problem, the relevant context, the implementation decisions, the test results, the unresolved assumptions, and the expected effect on other parts of the system. For risky changes, add deployment and rollback plans. A reviewer should be able to verify the investigation, not redo it.

3. Keep changes small and current. Separate unrelated work, validate against the current integration target, and revisit the evidence when dependencies change. A green run on an old branch is a dated observation.

4. Automate validation and keep improving its coverage. Use tests, static analysis, behavioral scenarios, and automated review to take over routine checking, and feed recurring findings back so each run benefits from what the team learned.

5. Measure the customer’s wait. Track request-to-production time, review wait, branch age, human interventions, abandoned changes, and failures after release, along with the qualified human effort per accepted change.

None of this can be bolted on after the factory is running. Each of these has to be built into the process and validated against real work, and the factory needs all of it in place before launch, not after the first fixes start going stale.

A factory that produces branches faster than its team can responsibly ship them is manufacturing a backlog.