"Code Must Not Be Reviewed by Humans": What the Dark Factory Gets Right, and Why Almost Nobody Runs One

What Is a Dark Factory, and Why Is Everyone Arguing About It?

The term comes from manufacturing, where a lights-out factory runs without anyone on the floor. In January 2026, Dan Shapiro applied it to programming in a five-level model borrowed from driving automation. Level 3 is a developer managing agents and reading their diffs, and Shapiro writes that "almost everyone tops out here." Level 5 is the dark factory, which he describes as "a black box that turns specs into software."

A few weeks later the idea got a concrete example. Simon Willison wrote up StrongDM's AI team, three people working since July 2025 under a charter with two blunt rules: code must not be written by humans, and code must not be reviewed by humans. A third line added a spending test: if you have not spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.

It is easy to see why this travelled. It takes a question most engineering leaders are privately asking, whether reading every line can last, and gives it a provocative answer. It also comes from a company that builds access management software, which is hardly a field known for casual attitudes to risk.

Both the enthusiasts and the critics tend to skip the useful part. The interesting thing about the dark factory is not that nobody reads the code. It is what the team had to build before that became defensible, and how much of that work is worth copying even if your engineers keep reading every diff.

How Many Companies Actually Ship Code Nobody Has Read?

Very few, on the best data available. Jellyfish telemetry reported by R&D World, covering more than 1,300 companies, 276,000 developers and 100 million pull requests, shows software factory pull requests rounding to 0.0% even at the 90th-percentile company. At the 99th percentile the share reached 9.4% in September, up from about 1.7% in March. This is a steep curve, but it is a curve at the very edge of the distribution.

The adjacent numbers tell you where the middle of the market is. In the same dataset, agents opened or committed code to 27.7% of pull requests at the median company in September, up from about 2% in January. Yet merges approved on AI review alone were just 0.5% at the median and 8.5% at the 90th percentile. Agents have moved into authorship far faster than they have been trusted with approval.

Sentiment may even be cooling. A VentureBeat survey found that the share of agent-deploying respondents allowing or building toward production changes based on automated evaluation alone fell from 75% in July to 56% in August. Those expecting to keep human review for the foreseeable future rose from 20% to 42%. The 56% is also narrower than it sounds: the 32% already doing this allow it for specific low-risk agents or changes, and the other 24% are still building toward it.

Neither source is a census. Jellyfish sells engineering analytics, and its customers are not a random sample of the industry. The VentureBeat waves were separate, self-selected groups, with 118 agent-deploying respondents in August, and the publication itself says they do not prove an enterprise-wide change. Still, the direction is hard to miss: the conversation about removing humans is running well ahead of the practice.

Why Is Line-by-Line Review Under So Much Pressure?

It would be a mistake to treat the dark factory as a stunt, because the problem it answers is measurable. The clearest evidence is a longitudinal study of a mid-sized software company whose CTO set a goal of doubling merged pull requests per engineer with AI. Tracking 802 developers and 196,212 pull requests, the researchers found that the company hit the target in the tenth month. Review load per reviewer doubled, and automated review overtook human review in coverage within months of the mandate.

Nobody in that company had to decide to stop reviewing. The arithmetic moved the work. The authors are careful to say that throughput is only a proxy for productivity, and that the size of the effect is uncertain because assignment was not randomised. But the mechanism will sound familiar to anyone running a team today: generation scales cheaply and attention does not.

This is the uncomfortable point the dark factory forces into the open. Many companies have already lowered the quality of human review without admitting it. An approval given in ninety seconds to a thousand-line change generated by an agent still looks like a review in the audit trail, but it verifies little. A team in that position is not safer than StrongDM just because a person clicked the button. In some ways it is worse off, because it believes it has a control it no longer has.

So the right question is not whether humans should read every line. Often, they already do not, not really. The right question is what evidence should stand behind a release, and how much of that evidence can come from a person's sustained attention, which is the scarcest input in the whole process.

What Did StrongDM Build Instead of Code Review?

Removing review is the headline, but the replacement is the substance. The first piece is what StrongDM calls scenarios: end-to-end user stories, often stored outside the codebase, much like a holdout set in model training. The point of holding them back is that a coding agent cannot easily shape its code to pass tests it has not seen. That addresses a known weakness, since agents under pressure to make tests pass will sometimes alter the tests.

The second piece is a change in what passing means. Rather than a green or red test suite, StrongDM measures satisfaction: of all the observed trajectories through all the scenarios, what fraction likely satisfy the user? This suits software with non-deterministic behaviour, where one passing run proves very little. An LLM does the judging, which is both what makes the approach flexible and, as we will see, its most exposed point.

The third piece is the Digital Twin Universe, a set of behavioural clones of the third-party services the software depends on: Okta, Jira, Slack, Google Docs, Google Drive and Google Sheets. The team can run thousands of scenarios per hour without hitting rate limits, triggering abuse detection or accumulating API costs, and it can test failure modes that would be dangerous or impossible against live services.

None of this requires a dark factory to be useful. Holdout scenarios, realistic simulators and repeated runs would improve almost any test strategy, and they are cheaper to adopt than they were, since agents can now write much of the scaffolding. If you take one idea from StrongDM, take this one: invest in verification first, and treat any reduction in human review as something you earn afterwards.

Where Does the Model Break?

The strongest objection is circularity. Eran Kahana of Stanford's CodeX puts it plainly: "the same class of technology that writes the code also decides whether the code works." Human tests are useful partly because their authors bring different assumptions from the people who wrote the code. When the same kind of model does both jobs, those differences shrink, and shared blind spots can pass straight through.

The field evidence supports that caution. In the VentureBeat August wave, 61% of 133 respondents using pre-deployment evaluations reported a customer-facing failure after passing internal tests. The most common barrier to trusting automated evaluation, at 27%, was misalignment with real-world outcomes. An eval suite measures what you thought to ask, and closing that gap is an engineering discipline in itself.

The raw material also matters. CodeRabbit's analysis of 470 open-source pull requests found about 1.7 times more issues in AI-co-authored changes, 10.83 against 6.45 per pull request, with logic and correctness issues 75% more common. CodeRabbit sells AI code review and could not guarantee that the human-labelled changes were purely human, so treat the ratio with care. It also says that no category of issue was unique to AI, which suggests volume and frequency are the concern rather than some exotic new class of bug.

Twins have limits as well. A clone reproduces the behaviour you have observed, not the undocumented change a vendor ships next Tuesday, so a passing run proves compatibility with your model of the world. Willison's own framing of the open problem is the right one: agent-written tests only help if the agents do not cheat, and LLMs are prone to what he calls "inhuman mistakes." Your system also has to catch the failures nobody thought to imagine, which is why progressive delivery and fast rollback matter more, not less, as review gets lighter.

Who Answers for Software Nobody Has Read?

Kahana's sharpest line is about law rather than engineering: "Existing legal frameworks assume someone, somewhere, looked at the work." He identifies gaps in liability, disclosure and contracts, and notes that no industry standard defines a sufficient satisfaction score. He also observes that no audit methodology covers agent-built software tested against replicas. A buyer asking how a product was verified may get an answer that nobody yet knows how to evaluate.

For anyone selling into Europe, this will soon stop being theoretical. The revised EU Product Liability Directive applies to products placed on the market after 9 December 2026 and treats software as a product. Meanwhile, insurers are writing AI exclusions into technology policies and AI vendors are pushing responsibility for outputs onto customers. An unreviewed release does not move the risk anywhere. It stays with whoever shipped the software.

Amazon shows how quickly this becomes an operational question, and also how contested the facts can be. Fortune reported that after a code deployment took the site and app down for some users in March 2026, with more than 22,000 Downdetector reports, the Financial Times described an internal email citing a trend of high blast radius incidents linked to "Gen-AI assisted changes" and new senior sign-off requirements. Amazon disputed this, saying only one incident discussed was AI-related, none involved AI-written code, and junior and mid-level engineers were not required to get senior sign-off.

Whichever account is closer, the takeaway does not depend on it. When a serious failure happens, the first questions are who approved this, on what evidence, and can you show me. Kahana's warning goes further: "when it fails, nobody will know why," because the expertise needed for diagnosis may have eroded. That connects to the comprehension debt many teams already carry. Someone still has to be able to open the system at 3 a.m. and understand it, whether or not they reviewed the diff that broke it.

What Would a Dark Factory Actually Cost?

StrongDM's $1,000-a-day benchmark is, as Willison calculates, roughly $20,000 per engineer per month. He finds the patterns far less interesting at that price, because it turns into "a business model exercise." He also points out that a product built this way may be easy for a competitor to clone with a few hours of agent work.

Compare that with what companies spend today. Jellyfish puts median Claude Code spending at $252 per active developer per month, with the 90th percentile at $1,666. The StrongDM benchmark is about twelve times that 90th-percentile figure, for one tool's spend. It may be a provocation more than a budget, but it shows that this model buys verification with large amounts of compute, and most token budgets are not set up for that.

Tokens are also only the visible line. Writing scenarios that capture what users really need is specification work, and building and maintaining faithful simulators of your dependencies is ongoing engineering. StrongDM's team is three people, and its published outputs include a coding agent and a context store. That is a very different starting point from a fifteen-year-old payments platform with undocumented behaviour, regulated data and customers who notice everything.

For most companies the better investment is the cheapest part of the factory: better specifications, holdout scenarios on critical journeys and stronger release controls. Spec-driven development pays back whatever level of autonomy you eventually choose, and it does so without betting the budget on an unproven operating model.

Which Changes Can Safely Ship Without a Human Reviewer?

The useful version of this debate is a sorting exercise, not a philosophy. The respondents already allowing this in the VentureBeat survey are limiting it to specific low-risk agents or changes rather than removing review wholesale, and that is the right instinct. Blast radius and reversibility matter more than who or what wrote the change.

The table below is our recommended starting point, not an industry standard. Promotion from one tier to the next should be earned with data: escaped defects, rollback rates and incident reviews for that class of change. Sampling also matters, because a person reading a random selection of auto-merged changes each week will find out whether the automated gates deserve their trust. Then keep the record, since auditors will ask who approved what.

Notice what stays with people at every tier: choosing the tier itself. A change that claims to be a copy edit but touches a permission check has to be caught by path rules and automated classification, not by the agent's own description of its work. Those rules, and the protected paths they guard, are among the highest-value things a senior engineer can own right now.

What Should You Ask a Development Partner About Unreviewed Code?

If an outside team ships code for you, this has already become a procurement question. A vendor can move to agent-only approval without changing its invoices, its status reports or its demo, and the risk moves to you without any conversation. Standard outsourcing contracts rarely say anything about it, and as Kahana notes, warranty and liability language has hardly changed even though the production process has.

So ask directly. Which classes of change reach production without a person reading them? Who is named as accountable for each release? Can we see the evidence for a sample of merges from the last 90 days, including the auto-merged ones? Who writes the scenarios, and can the coding agent see them? What is the rollback time on our critical services? And who on your team could diagnose a failure in agent-written code without asking another agent to explain it?

Then put the answers in writing. A contract can define which paths require human review, require disclosure before any review policy changes and give you access to the audit trail. A good partner will welcome those clauses, because they describe what it should already be doing. A partner whose AI productivity story depends on nobody asking may be less keen, and that is useful to learn early.

This is where the shape of the team matters more than the rate. Dark factories are built around very few people with deep context, and a dedicated development team gets closer to that than a rotating project bench, since the same engineers stay with your system long enough to understand its risks. At Stepto, our dedicated nearshore teams in Serbia work inside your repositories, under your review rules and in your time zone, using AI heavily and staying accountable for what ships. If you want to add verification capacity, our QA and testing services and AI engineers can help build the scenarios and gates described here, and a two-week paid trial lets you judge that work on your own codebase.