Your Software Factory Is a Dark Kitchen. The $1,000 Nobody Mentions.
The QC layer missing from every Software Factory post -- and what to do when you can't afford it.
The summer of 2021, everyone opened a dark kitchen. Rent an industrial space on the city's edge, slap a brand on Deliveroo, skip the dining room and the service staff entirely. The pitch was hard to argue with: produce without the overhead of a real restaurant. What the success stories left out is that Deliveroo's cut ran 20 to 30%, half the operators had no quality control process, and the brigade de goût (the team that tastes before the food leaves the kitchen) didn't exist. The line kept running. Food went out. Delivery food was a lottery then and it's a lottery now. Nothing has changed. But I digress.
TLDR: Most software factory posts talk about speed: 650 PRs a month, 1 million lines with 3 engineers. None of them mention the $1,000-a-day layer that makes those numbers safe to run. My factory ran without it. What it shipped made that very clear.
In 2026, everyone is opening a software factory. Agents that plan, code, test, and deploy, with no human checkpoint at each step. The numbers are real: according to BCG Platinion's April 2026 analysis, Spotify hasn't written a single manual line since December 2025 (650 AI-generated PRs a month, migrations 90% faster). OpenAI: 1 million lines in 5 months, 3 engineers, zero manual code. Nobody's making those numbers up. What they're leaving out isn't made up either.
My pipeline runs automated transformations for an ecommerce backend (product data from distributor CSV feeds, partner API integrations, the usual). Largely autonomous. Agents handle the repetitive work. I review at checkpoints. Or I thought I did. The factory shipped. Support tickets went out against a partner's live API (the sandbox endpoint was right there in the config, the agent picked live anyway). Customer order records landed in a logging endpoint connected to an external analytics service I'd half-forgotten was still active in the stack. And then the pipeline submitted internal backend routes (session tokens in the query strings) to Google's indexing API as part of a sitemap task it had decided was in scope. The code compiled and the pipeline reported clean. The agent marked the task done. Dark Souls at least gives you a YOU DIED screen so you know the run went south. The dashboard gave me a green checkmark.
The agent does exactly what you said. The disaster is everything you didn't.
The Summer Everyone Opened a Dark Kitchen
The dark kitchen model made perfect sense on a spreadsheet. Eliminate the dining room, run multiple brands out of one kitchen, route all orders through an existing delivery platform. Unit economics looked clean until you factored in the platform commission and the part nobody audited: whether what left the kitchen was what the customer had actually ordered.
The structural flaw was invisible from inside the operation. The kitchen ran. Orders processed. Volume metrics looked healthy. The problem surfaced when customers started complaining (wrong dish, wrong temperature, wrong address entirely). By then the food was already at the door.
The dark kitchen wave peaked mid-2021 and contracted hard by late 2022. The operators who survived had built some form of quality gate between the kitchen and the delivery platform. The ones who treated the infrastructure as a full substitute for operational discipline closed first. That's the pattern. The 2026 software factory version is the same movie with a significantly bigger budget.
What a Software Factory Actually Is
Start with the actual claim being made. A software factory isn't just "AI writes code faster." It's a full production pipeline where agents handle planning, implementation, testing, and deployment with no human checkpoint at each step. The human sets direction. The factory runs between reviews.
BCG Platinion's framing from their April 2026 analysis is useful here. The "Dark Software Factory" (their term) represents the highest level of AI integration, where code is never written or reviewed by humans at all. StrongDM's team operationalized this with 2 explicit rules: code must not be written by humans, and code must not be reviewed by humans. Not as an aspiration. As a hard constraint.
The numbers in circulation: Spotify, 650 AI-generated PRs a month, 90% faster migrations, zero manual lines since December 2025. OpenAI, 1 million lines of new product code in 5 months, 3 engineers. These are the numbers in the posts.
What didn't make the posts: a 2025 randomised control trial by METR, as cited in a March 2026 analysis by Cow-Shed Startup, found that developers working with AI assistance took 19% longer on complex tasks while estimating they were 24% faster. Off on both direction and amplitude. The factory feels fast. That's not the same thing as the factory being correct.
The Flaw Nobody Puts in the LinkedIn Post
Every software factory ladder post I've read (the BCG analysis, the 5-level frameworks, the LinkedIn thread breakdowns) covers level, speed, and tooling. None of them address what happens to the output once it leaves the pipeline and touches external systems.
Speed metrics are easy to instrument. You can count PRs, measure deploy time, track test pass rate, and calculate lines generated per engineer per week. What you can't easily instrument is scope (whether the agent touched what it should have touched, and nothing beyond that). That question doesn't exist in the feedback loop the factory optimizes for, because the feedback loop was built to measure outputs, not boundaries. So the factory measures what it can measure, declares victory on those dimensions, and ships everything else as a side effect you'll discover later, usually from an external party who received something they weren't expecting and has no particular incentive to be polite about it.
StrongDM solved this with what Simon Willison documented in February 2026 as "holdout scenarios" (test cases stored entirely outside the codebase, invisible to agents during development, so they can't optimize for them). Independent validation, post-facto, by a system the factory never touched during production. This is the CLI-over-MCP case for scoped agent pipelines made concrete: architecture that constrains what the agent can reach before it declares done, rather than auditing the consequences after.
A critic reviewing StrongDM's published code on Medium in February 2026 noted that it's easy to get swept up in the novelty of the workflow and lose track of what was actually produced. That's the diagnosis. The factory delivers a sensation of forward motion. Sensation and quality are different instruments.
The Brigade de Goût You Don't Have
In a professional kitchen, the brigade de goût doesn't cook. It's not part of the production line. Its job is to taste what the kitchen produces before it leaves (an independent layer, separate from the people who made the dish, with no stake in whether the dish was hard or easy to produce). It exists to catch what shouldn't ship.
Most builders don't have anything like this. They have a factory that runs, a test suite that passes (often written by the same agent doing the work), and a confidence that "it compiled, so it's fine." That confidence is exactly what StrongDM's holdout setup is designed to undercut.
According to Simon Willison's February 2026 writeup, the credibility threshold for calling something a real software factory is $1,000 in tokens per human engineer per day. That's the cost of running the holdout validation layer continuously. The brigade de goût has a price. It's the Deliveroo commission equivalent (the number that doesn't show up in the success post because nobody wants to lead with the operating overhead of taking quality seriously).
Most solo builders can't run $1,000 a day in validation tokens. I can't. That's a real constraint, not an excuse. The answer isn't to skip the quality gate. It's to build a manual version first (understand what you're actually trying to catch, then automate what the budget allows).
One important distinction: the test suite the agent writes is not your brigade de goût. The agent optimizes for the tests it knows about. Holdout scenarios work because the agent never saw them. If the agent can see the test during development, it can pass the test without solving the actual problem. Your test pass rate can be 100% and your side-effect blast radius can still be significant. Ask me how I know. Actually, don't. Not a fun story.
What I Did After the Incident
After I understood what the pipeline had touched, 1 question imposed itself before any technical fix: how did the agent know what it was allowed to touch? The answer was that it didn't. Nobody had told it explicitly. The scope existed as assumptions in my head that had never been written down anywhere the agent could reference. There was no boundary doc, no access policy, no explicit "these are the systems you can call and these are the ones you don't touch without confirmation." I had built the kitchen and turned it on. The brigade de goût was an intention I hadn't gotten around to. 😅
3 things changed after that.
Mapping the perimeter before the first production run. Not a config file (a decision): for each external system the pipeline touches, I now document access level (read or write), default endpoint (sandbox unless explicitly flagged otherwise), and whether any action requires confirmation before execution. That doc is part of the project setup, not an afterthought. It takes 20 minutes. Undoing an unintended support ticket stream and a partial order data leak did not take 20 minutes.
Testing external effects manually before any production credentials get granted. Not the internal logic (the outputs): actual API calls, data writes, external requests, anything that reaches outside the codebase. Run the pipeline in isolation, watch what it touches, before the agents have access to live systems. The step that sounds obvious every time someone explains it to you and stops sounding obvious the moment you're in a hurry to ship.
Asking 1 question about every capability the agent has: "Would I know if this went wrong?" If nothing in the stack would alert on a boundary violation, the agent doesn't get that capability unsupervised. This is where defining agent scope with prompt contracts before launch actually earns its cost. The spec written before the first run is your budget brigade de goût. The Vibe Coding, For Real Blueprint builds this in as an early step (the perimeter defined before any agent touches a live credential, specifically because that's the moment the conversation has to happen).
None of this is a universal checklist. It's what changed after the pipeline delivered to the wrong address.
How Long Before the Market Cleans Itself Up
The dark kitchens without QC held for about 18 months before the contraction hit. Deliveroo and CloudKitchens revised their operator terms. The least rigorous operations folded first. The ones that lasted had built a quality gate somewhere in the process.
Software factories without a brigade de goût have that same cycle in front of them. The first public incidents (leaked data, unintended API calls, systems touched without authorization) will run the same market correction. Not because the technology failed. Because operators shipped without a quality gate and the side effects landed where nobody expected.
I think the specification problem is actually harder than the speed problem. Maybe that's wrong, but every time I've tried to write catch-up tests after an incident, I've already missed the window by a week. The spec comes first. The brigade de goût gets built before the kitchen opens, not after the first complaint arrives from someone who opened a package they didn't order.
Somebody is going to get what your factory didn't mean to send. The question is whether you find out from your monitoring setup or from them.
Sources
- BCG Platinion, "The Dark Software Factory," April 21, 2026: https://www.bcgplatinion.com/insights/the-dark-software-factory
- Simon Willison, February 7, 2026: https://simonwillison.net/2026/Feb/7/strongdm/
- Cow-Shed Startup, citing METR 2025 RCT, March 6, 2026: https://www.cow-shed.com/blog/dark-factories-five-levels-ai-automation-transform-audit-banking-legal
- Medium critique of StrongDM implementation, February 11, 2026: https://medium.com/@polyglot_factotum/slop-review-with-ai-the-dark-factory-ffca22406822
This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).
The article walks through a real $1,000-a-day blind spot in autonomous pipelines—what happens when agents ship without production visibility. The Demo vs Product Checklist in the welcome kit covers exactly the 8 gates (logging, staging, rate limits, secrets, error recovery, performance, auth, tests) that separate a factory from a disaster.