--- title: "Die Software-Fabrik: KI-gesteuerte Entwicklung ohne menschliches Code-Review" date: "2026-02-08" description: "Das KI-Team von StrongDM eliminiert menschliches Codeschreiben und Code-Review vollständig. Stattdessen werden Coding Agents durch Holdout-Szenario-Tests und agent-erstellte Klone von Drittanbieter-APIs validiert, um zu beweisen, dass Software im großen Maßstab funktioniert." language: de url: "https://pablooliva.de/the-closing-window/de/the-software-factory-ai-driven-development-without-human-code-review/" markdownUrl: "https://pablooliva.de/the-closing-window/de/the-software-factory-ai-driven-development-without-human-code-review.md" translations: - language: ar url: "https://pablooliva.de/the-closing-window/ar/the-software-factory-ai-driven-development-without-human-code-review/" - language: es url: "https://pablooliva.de/the-closing-window/es/the-software-factory-ai-driven-development-without-human-code-review/" - language: en url: "https://pablooliva.de/the-closing-window/the-software-factory-ai-driven-development-without-human-code-review/" - language: zh url: "https://pablooliva.de/the-closing-window/zh/the-software-factory-ai-driven-development-without-human-code-review/" --- **Quelle:** [Software Factory](https://simonwillison.net/2026/Feb/7/software-factory/) von Simon Willison (7. Feb. 2026) Simon Willison berichtet darüber, wie das KI-Team von StrongDM das umgesetzt hat, was Dan Shapiro die **„Dark Factory"**-Stufe der KI-Adoption nennt — bei der kein Mensch den Code schreibt oder auch nur reviewed, den Coding Agents produzieren. Der vollständige Bericht: [Software Factories and the Agentic Moment](https://factory.strongdm.ai/). ## Kernprinzipien Das KI-Team von StrongDM (gegründet im Juli 2025, nur 3 Personen) arbeitet unter radikalen Einschränkungen: - Code **darf nicht** von Menschen geschrieben werden - Code **darf nicht** von Menschen reviewed werden - Wenn du nicht mindestens **1.000 $ pro Tag pro Entwickler für Tokens** ausgibst, hat deine Software-Fabrik noch Luft nach oben Der Auslöser: Mit Claude 3.5 Sonnet Revision 2 (Oktober 2024) begannen langfristige agentische Coding-Workflows, **Korrektheit zu kumulieren** statt Fehler zu kumulieren. Der Wendepunkt im November 2025 (Claude Opus 4.5, GPT 5.2) verbesserte die Zuverlässigkeit weiter. ## Schlüsselinnovation #1: Szenario-Tests als Holdout-Sets **Das Problem**: Wenn Agents sowohl Implementierung ALS AUCH Tests schreiben, können sie schummeln (`assert true`). Wie beweist du, dass von Agents produzierte Software tatsächlich funktioniert? **Die Lösung**: Vom ML abschauen — Test-Szenarien wie **Holdout-Sets** im Modelltraining behandeln: - End-to-End „User Stories", die **außerhalb der Codebase** gespeichert werden, unsichtbar für Coding Agents - Wechsel von booleschem Pass/Fail zu **probabilistischer Zufriedenheit**: „Von allen beobachteten Trajektorien durch alle Szenarien, welcher Anteil erfüllt wahrscheinlich die Bedürfnisse des Nutzers?" - Repliziert effektiv aggressives externes QA-Testing — historisch teuer, aber hocheffektiv **Warum das für Entwickler wichtig ist**: Das verändert die Testing-Philosophie von „macht dieser Code, was ich ihm gesagt habe" hin zu „erfüllt dieses System die Nutzer über realistische Szenarien hinweg." Es ist ein Perspektivwechsel von Unit-Test-Korrektheit zu Verhaltensvalidierung. ## Schlüsselinnovation #2: Digital Twin Universe (DTU) **Das Problem**: Du kannst nicht Tausende von Integrationstests pro Stunde gegen echte SaaS-APIs ausführen (Rate Limits, Kosten, Missbrauchserkennung). **Die Lösung**: Coding Agents **Verhaltensklone** von Drittanbieter-Diensten erstellen lassen: - Twins von Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets erstellt - Deren APIs, Randfälle und beobachtbares Verhalten repliziert - Vollständige öffentliche API-Dokumentation in den Agent Harness eingespeist, um eigenständige Go-Binaries zu produzieren - Vereinfachte UIs darübergelegt für vollständige Simulation **Der Durchbruch**: Hochpräzise Klone von SaaS-Anwendungen zu erstellen war immer *möglich*, aber nie *wirtschaftlich machbar*. LLM-Agents senken die Kosten für den Bau dieser Repliken drastisch. Jetzt kannst du: - In Volumina validieren, die Produktionslimits übersteigen - Fehlermodi testen, die gegen Live-Dienste gefährlich wären - Tausende Szenarien pro Stunde ausführen, ohne Rate Limits oder API-Kosten **Warum das für Entwickler wichtig ist**: Auch wenn du keine vollständige „Software-Fabrik" baust, ist das DTU-Konzept direkt anwendbar. Jedes Team, das Integrationstests gegen externe APIs durchführt, kann von agent-generierten Service-Mocks profitieren, die weit über handgeschriebene Stubs hinausgehen. ## Schlüsselinnovation #3: Wiederverwendbare Agent-Techniken StrongDM hat mehrere benannte Muster auf ihrer [Techniques-Seite](https://factory.strongdm.ai/techniques) veröffentlicht: | Technik | Beschreibung | Entwickleranwendung | |---------|-------------|---------------------| | **Gene Transfusion** | Agents extrahieren Muster aus bestehenden Systemen und verwenden sie anderswo wieder | Architekturmuster automatisch zwischen Services migrieren | | **Semports** | Direkte Code-Portierung von einer Sprache in eine andere | Sprachübergreifende Migrationen (z.B. Python-Service nach Go) | | **Pyramid Summaries** | Mehrere Zusammenfassungsebenen — Agents zählen zuerst kurze Zusammenfassungen auf und zoomen dann bei Bedarf in Details | Große Codebases mit Agents verwalten; progressives Context Loading | ## Schlüsselinnovation #4: Spec-Driven Agent Software (Attractor) StrongDM hat [Attractor](https://github.com/strongdm/attractor) veröffentlicht — ihren nicht-interaktiven Coding Agent — als Repo, das **null Code** enthält. Nur drei Markdown-Dateien, die die Spec in akribischem Detail beschreiben, mit Anweisungen, sie in den Coding Agent deiner Wahl einzuspeisen. Das repräsentiert einen Wandel, bei dem **die Spezifikation DIE Software-Distribution IST**. Die Annahme: Jeder kompetente Coding Agent kann aus einer ausreichend guten Spec implementieren. ## Praktische Erkenntnisse 1. **Test-Erstellung von Code-Erstellung trennen**: Auch ohne die volle „Dark Factory" verhindert das Aufbewahren von Szenario-Definitionen außerhalb des sichtbaren Kontexts des Agents ein Austricksen. 2. **In Umgebungssimulation investieren**: Agent-generierte Service-Mocks/Twins sind jetzt wirtschaftlich machbar und verbessern den Test-Durchsatz dramatisch. 3. **Probabilistische Validierung statt binärer Tests**: Erwäge, „Zufriedenheitsraten" über Szenario-Trajektorien hinweg zu messen, anstatt nur Pass/Fail-Testsuiten. 4. **Progressives Context-Management**: Pyramid Summaries helfen Agents, große Codebases zu navigieren, ohne das Context Window zu sprengen. 5. **Spec-First-Entwicklung**: Gut geschriebene Spezifikationen werden zum primären Artefakt; die Implementierung wird austauschbar. ## Kosten-Realitätscheck Das Ziel von 1.000 $/Tag pro Entwickler (20.000 $/Monat) wirft ernsthafte Fragen zur wirtschaftlichen Tragfähigkeit auf. Willison merkt an, dass dies den Ansatz bei diesem Preisniveau „weit weniger interessant" macht — es wird eher eine Geschäftsmodell-Übung als eine universelle Technik. Zudem könnten Wettbewerber Features potenziell mit ein paar Stunden Agent-Arbeit klonen, was traditionelle Software-Burggraben in Frage stellt. Für einzelne Entwickler und kleinere Teams sind die konzeptionellen Muster (Holdout-Testing, DTU, Pyramid Summaries) auch bei deutlich geringerem Budget wertvoll, wie dem 200-$/Monat Claude Max Plan. ## Open-Source-Veröffentlichungen - **[Attractor](https://github.com/strongdm/attractor)**: Spec-only Repo für einen nicht-interaktiven Coding Agent - **[cxdb](https://github.com/strongdm/cxdb)**: AI Context Store — unveränderlicher DAG für Konversationshistorien und Tool-Outputs (16K Zeilen Rust, 9,5K Go, 6,7K TypeScript)