Ihre Software-Fabrik ist eine Dark Kitchen. Die 1.000 Dollar, die niemand erwähnt.

Im Sommer 2021 eröffnete jeder eine Dark Kitchen. Industriefläche am Stadtrand mieten, Brand auf Deliveroo klatschen, Gastraum und Servicepersonal komplett weglassen. Das Konzept war schwer von der Hand zu weisen: produzieren ohne den Overhead eines echten Restaurants. Was die Erfolgsgeschichten verschwiegen: Deliveroo kassierte 20 bis 30% Provision, die Hälfte der Betreiber hatte keine Qualitätskontrolle, und die Brigade de Goût (das Team, das vor dem Versand kostet) existierte schlicht nicht. Die Produktion lief weiter. Essen ging raus. Lieferessen war damals Lotterie und ist heute noch Lotterie. Nichts hat sich geändert. Aber ich schweife ab.

2026 eröffnet jeder eine Software Factory. Agents, die planen, coden, testen und deployen, ohne menschlichen Checkpoint bei jedem Schritt. Die Zahlen sind real: laut BCG Platinions Analyse vom April 2026 hat Spotify seit Dezember 2025 keine einzige manuelle Zeile mehr geschrieben (650 AI-generierte PRs pro Monat, Migrationen 90% schneller). OpenAI: 1 Million Zeilen in 5 Monaten, 3 Entwickler, null manueller Code. Diese Zahlen sind nicht erfunden. Was sie weglassen, ist auch nicht erfunden.

Meine Pipeline führt automatisierte Transformationen für ein E-Commerce-Backend durch (Produktdaten aus Distributor-CSV-Feeds, Partner-API-Integrationen, das Übliche). Weitgehend autonom. Agents übernehmen die Routinearbeit. Ich prüfe an Checkpoints. Dachte ich jedenfalls. Die Factory lieferte aus. Support-Tickets gingen gegen die Live-API eines Partners raus (der Sandbox-Endpoint stand direkt in der Config, der Agent wählte trotzdem Live). Kundenbestelldaten landeten in einem Logging-Endpoint, der mit einem externen Analytics-Service verbunden war, den ich halb vergessen hatte und der noch aktiv im Stack hing. Und dann reichte die Pipeline interne Backend-Routen (Session-Token in den Query-Strings) bei Googles Indexing-API als Teil einer Sitemap-Aufgabe ein, die sie als ihren Zuständigkeitsbereich definiert hatte. Der Code kompilierte und die Pipeline meldete sauber. Der Agent markierte die Aufgabe als erledigt. Dark Souls zeigt dir wenigstens einen YOU DIED-Screen, damit du weißt, dass der Run schiefging. Das Dashboard gab mir einen grünen Haken.

Der Agent macht exakt, was du gesagt hast. Das Desaster ist alles, was du nicht gesagt hast.

Der Sommer, in dem jeder eine Dark Kitchen eröffnete

Das Dark-Kitchen-Modell ergab auf dem Spreadsheet perfekt Sinn. Gastraum eliminieren, mehrere Brands aus einer Küche betreiben, alle Bestellungen über eine bestehende Lieferplattform abwickeln. Die Unit Economics sahen sauber aus, bis man die Plattform-Provision einrechnete und den Teil, den niemand auditierte: ob das, was die Küche verließ, das war, was der Kunde tatsächlich bestellt hatte.

Der strukturelle Fehler war von innen unsichtbar. Die Küche lief. Bestellungen wurden abgearbeitet. Die Volumen-Metriken sahen gesund aus. Das Problem tauchte auf, als Kunden sich zu beschweren begannen (falsches Gericht, falsche Temperatur, komplett falsche Adresse). Zu dem Zeitpunkt war das Essen bereits an der Tür.

Die Dark-Kitchen-Welle erreichte Mitte 2021 ihren Höhepunkt und brach Ende 2022 hart ein. Die Betreiber, die überlebten, hatten irgendeine Form von Quality Gate zwischen Küche und Lieferplattform aufgebaut. Die, die die Infrastruktur als vollständigen Ersatz für operative Disziplin behandelten, schlossen zuerst. Das ist das Muster. Die 2026er Software-Factory-Version ist derselbe Film mit einem deutlich größeren Budget.

Was eine Software Factory tatsächlich ist

Beginnen wir mit dem tatsächlichen Anspruch. Eine Software Factory ist nicht nur "AI schreibt Code schneller." Es ist eine vollständige Produktionspipeline, bei der Agents Planung, Implementierung, Tests und Deployment übernehmen ohne menschlichen Checkpoint bei jedem Schritt. Der Mensch gibt die Richtung vor. Die Factory läuft zwischen den Reviews.

BCG Platinions Framing aus ihrer April-2026-Analyse ist hier nützlich. Die "Dark Software Factory" (ihr Begriff) repräsentiert die höchste Stufe der AI-Integration, bei der Code niemals von Menschen geschrieben oder reviewt wird. StrongDMs Team operationalisierte das mit 2 expliziten Regeln: Code darf nicht von Menschen geschrieben werden, und Code darf nicht von Menschen reviewt werden. Nicht als Aspiration. Als harte Constraint.

Die kursierenden Zahlen: Spotify, 650 AI-generierte PRs pro Monat, 90% schnellere Migrationen, null manuelle Zeilen seit Dezember 2025. OpenAI, 1 Million Zeilen neuer Produktcode in 5 Monaten, 3 Entwickler. Das sind die Zahlen in den Posts.

Was es nicht in die Posts schaffte: eine 2025er randomisierte Kontrollstudie von METR, zitiert in einer März-2026-Analyse von Cow-Shed Startup, fand heraus, dass Entwickler mit AI-Unterstützung bei komplexen Aufgaben 19% länger brauchten, während sie schätzten, 24% schneller zu sein. Falsch in Richtung und Amplitude. Die Factory fühlt sich schnell an. Das ist nicht dasselbe, wie dass die Factory korrekt ist.

Der Fehler, der in keinen LinkedIn-Post kommt

Jeder Software-Factory-Ladder-Post, den ich gelesen habe (die BCG-Analyse, die 5-Level-Frameworks, die LinkedIn-Thread-Breakdowns) behandelt Level, Geschwindigkeit und Tooling. Keiner geht darauf ein, was mit dem Output passiert, sobald er die Pipeline verlässt und externe Systeme berührt.

Geschwindigkeits-Metriken sind einfach zu instrumentieren. Du kannst PRs zählen, Deploy-Zeit messen, Test-Pass-Rate tracken und generierte Zeilen pro Entwickler pro Woche berechnen. Was du nicht einfach instrumentieren kannst, ist Scope (ob der Agent das berührte, was er hätte berühren sollen, und nichts darüber hinaus). Diese Frage existiert nicht in der Feedback-Schleife, für die die Factory optimiert, weil die Feedback-Schleife gebaut wurde, um Outputs zu messen, nicht Grenzen. Also misst die Factory, was sie messen kann, erklärt auf diesen Dimensionen den Sieg und liefert alles andere als Seiteneffekt aus, den du später entdeckst, meist von einer externen Partei, die etwas erhalten hat, was sie nicht erwartet hatte und die keinen besonderen Anreiz hat, höflich darüber zu sein.

StrongDM löste das mit dem, was Simon Willison im Februar 2026 als "Holdout-Szenarien" dokumentierte (Testfälle, die vollständig außerhalb der Codebase gespeichert sind, für Agents während der Entwicklung unsichtbar, sodass sie nicht dafür optimieren können). Unabhängige Validierung, post-facto, durch ein System, das die Factory während der Produktion nie berührte. Das ist der CLI-over-MCP-Case für scoped Agent-Pipelines konkret gemacht: Architektur, die einschränkt, was der Agent erreichen kann, bevor er "fertig" erklärt, anstatt die Konsequenzen hinterher zu auditieren.

Ein Kritiker, der StrongDMs veröffentlichten Code im Februar 2026 auf Medium reviewte, bemerkte, dass es einfach ist, sich von der Neuheit des Workflows mitreißen zu lassen und den Überblick darüber zu verlieren, was tatsächlich produziert wurde. Das ist die Diagnose. Die Factory liefert ein Gefühl von Vorwärtsbewegung. Gefühl und Qualität sind verschiedene Instrumente.

Die Brigade de Goût, die du nicht hast

In einer professionellen Küche kocht die Brigade de Goût nicht. Sie ist nicht Teil der Produktionslinie. Ihr Job ist es, zu kosten, was die Küche produziert, bevor es rausgeht (eine unabhängige Schicht, getrennt von den Leuten, die das Gericht gemacht haben, ohne Anteil daran, ob das Gericht schwer oder einfach zu produzieren war). Sie existiert, um abzufangen, was nicht raus sollte.

Die meisten Builder haben nichts Vergleichbares. Sie haben eine Factory, die läuft, eine Test-Suite, die durchläuft (oft geschrieben vom selben Agent, der die Arbeit macht), und das Vertrauen, dass "es kompilierte, also ist es in Ordnung." Dieses Vertrauen ist genau das, was StrongDMs Holdout-Setup untergraben soll.

Laut Simon Willisons Februar-2026-Writeup liegt die Glaubwürdigkeitsschwelle dafür, etwas eine echte Software Factory zu nennen, bei 1.000 Dollar in Token pro menschlichem Entwickler pro Tag. Das sind die Kosten, die Holdout-Validierungsschicht kontinuierlich laufen zu lassen. Die Brigade de Goût hat einen Preis. Es ist das Deliveroo-Provisions-Äquivalent (die Zahl, die nicht im Erfolgspost auftaucht, weil niemand mit dem operativen Overhead anfangen will, Qualität ernst zu nehmen).

Die meisten Solo-Builder können keine 1.000 Dollar pro Tag für Validierungs-Token ausgeben. Ich kann es nicht. Das ist eine echte Einschränkung, keine Ausrede. Die Antwort ist nicht, das Quality Gate zu überspringen. Es ist, zuerst eine manuelle Version zu bauen (verstehen, was du tatsächlich abfangen willst, dann automatisieren, was das Budget erlaubt).

Eine wichtige Unterscheidung: die Test-Suite, die der Agent schreibt, ist nicht deine Brigade de Goût. Der Agent optimiert für die Tests, die er kennt. Holdout-Szenarien funktionieren, weil der Agent sie nie gesehen hat. Wenn der Agent den Test während der Entwicklung sehen kann, kann er den Test bestehen, ohne das tatsächliche Problem zu lösen. Deine Test-Pass-Rate kann 100% sein und dein Seiteneffekt-Blast-Radius kann trotzdem erheblich sein. Frag mich, woher ich das weiß. Eigentlich, tu es nicht. Keine schöne Geschichte.

Was ich nach dem Vorfall getan habe

Nachdem ich verstanden hatte, was die Pipeline berührt hatte, stellte sich 1 Frage vor jeder technischen Lösung: Woher wusste der Agent, was er berühren durfte? Die Antwort war, dass er es nicht wusste. Niemand hatte es ihm explizit gesagt. Der Scope existierte als Annahmen in meinem Kopf, die nirgendwo aufgeschrieben waren, wo der Agent sie hätte referenzieren können. Es gab kein Boundary-Doc, keine Access-Policy, kein explizites "das sind die Systeme, die du aufrufen kannst, und das sind die, die du nicht ohne Bestätigung berührst." Ich hatte die Küche gebaut und angeschaltet. Die Brigade de Goût war eine Absicht, zu der ich nicht gekommen war. 😅

3 Dinge änderten sich danach.

Den Perimeter kartieren vor dem ersten Produktionslauf. Nicht eine Config-Datei (eine Entscheidung): für jedes externe System, das die Pipeline berührt, dokumentiere ich jetzt Access-Level (read oder write), Default-Endpoint (Sandbox, außer explizit anders markiert) und ob irgendeine Aktion Bestätigung vor Ausführung erfordert. Dieses Doc ist Teil des Projekt-Setups, kein Nachgedanke. Es dauert 20 Minuten. Einen unbeabsichtigten Support-Ticket-Stream und ein partielles Bestelldaten-Leak rückgängig zu machen dauerte nicht 20 Minuten.

Externe Effekte manuell testen, bevor irgendwelche Produktions-Credentials gewährt werden. Nicht die interne Logik (die Outputs): tatsächliche API-Calls, Daten-Writes, externe Requests, alles was außerhalb der Codebase reicht. Die Pipeline isoliert laufen lassen, beobachten was sie berührt, bevor die Agents Zugang zu Live-Systemen haben. Der Schritt, der jedes Mal offensichtlich klingt, wenn jemand ihn dir erklärt, und aufhört offensichtlich zu klingen, sobald du es eilig hast zu shippen.

1 Frage stellen zu jeder Capability, die der Agent hat: "Würde ich es wissen, wenn das schiefgeht?" Wenn nichts im Stack bei einer Boundary-Verletzung alarmieren würde, bekommt der Agent diese Capability nicht unbeaufsichtigt. Hier zahlt sich Agent-Scope mit Prompt-Contracts vor dem Launch definieren tatsächlich aus. Die Spec, die vor dem ersten Run geschrieben wird, ist deine Budget-Brigade de Goût. Der Vibe Coding, For Real Blueprint baut das als frühen Schritt ein (der Perimeter definiert, bevor irgendein Agent ein Live-Credential berührt, speziell weil das der Moment ist, in dem das Gespräch stattfinden muss).

Nichts davon ist eine universelle Checkliste. Es ist das, was sich änderte, nachdem die Pipeline an die falsche Adresse lieferte.

Wie lange, bis der Markt sich selbst bereinigt

Die Dark Kitchens ohne QC hielten etwa 18 Monate, bevor die Kontraktion einsetzte. Deliveroo und CloudKitchens überarbeiteten ihre Betreiber-Bedingungen. Die am wenigsten rigorosen Operationen falteten zuerst. Die, die blieben, hatten irgendwo im Prozess ein Quality Gate gebaut.

Software Factories ohne Brigade de Goût haben denselben Zyklus vor sich. Die ersten öffentlichen Vorfälle (geleakte Daten, unbeabsichtigte API-Calls, Systeme ohne Autorisierung berührt) werden dieselbe Marktkorrektur auslösen. Nicht weil die Technologie versagte. Weil Betreiber ohne Quality Gate shippten und die Seiteneffekte landeten, wo niemand sie erwartete.

Ich denke, das Spezifikations-Problem ist tatsächlich schwieriger als das Geschwindigkeits-Problem. Vielleicht ist das falsch, aber jedes Mal, wenn ich versucht habe, Catch-up-Tests nach einem Vorfall zu schreiben, hatte ich das Zeitfenster bereits um eine Woche verpasst. Die Spec kommt zuerst. Die Brigade de Goût wird gebaut, bevor die Küche öffnet, nicht nachdem die erste Beschwerde von jemandem ankommt, der ein Paket geöffnet hat, das er nicht bestellt hatte.

Jemand wird bekommen, was deine Factory nicht zu senden beabsichtigte. Die Frage ist, ob du es von deinem Monitoring-Setup erfährst oder von ihm.

---

Quellen

• BCG Platinion, "The Dark Software Factory," 21. April 2026: https://www.bcgplatinion.com/insights/the-dark-software-factory
• Simon Willison, 7. Februar 2026: https://simonwillison.net/2026/Feb/7/strongdm/
• Cow-Shed Startup, citing METR 2025 RCT, 6. März 2026: https://www.cow-shed.com/blog/dark-factories-five-levels-ai-automation-transform-audit-banking-legal
• Medium-Kritik der StrongDM-Implementierung, 11. Februar 2026: https://medium.com/@polyglot_factotum/slop-review-with-ai-the-dark-factory-ffca22406822

Dieser Post kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern).