Warum Software-Fabriken mit KI-Agenten scheitern

Dex Horthy beschreibt in "Why Software Factories Fail" eine unbequeme Grenze agentischer Softwareentwicklung: Mehr Loops, bessere Harnesses und schnellere Review-Bots reichen nicht aus, wenn niemand mehr Verantwortung für die langfristige Form des Codes übernimmt.

Der Text richtet sich gegen die Idee der "lights-off software factory": Aufgaben kommen in eine Queue, Agenten schreiben Code, Tests und Review-Agenten winken durch, Monitoring meldet später Probleme. Das klingt nach Produktivität. In gewachsenen Codebasen kann es aber genau das Gegenteil erzeugen: schneller mehr Code, der später schwerer zu ändern ist.

Die Fabrik ist nicht das Problem

Eine Software-Fabrik ist kein neues Konzept. Schon vor KI bestand Entwicklung aus Schleifen: Produktidee, Ticket, Implementierung, Pull Request, Review, Deployment, Monitoring, Nutzerfeedback.

KI-Agenten beschleunigen vor allem den Implementierungsschritt. Was früher Stunden oder Tage dauerte, kann Minuten oder wenige Stunden brauchen. Dadurch verschiebt sich der Engpass:

• Menschen schreiben weniger Code selbst.
• Menschen müssen mehr Ergebnisse bewerten.
• Review wird zur knappen Ressource.
• Die Versuchung steigt, Review ebenfalls zu automatisieren.

Genau dort beginnt das Risiko. Wenn der Mensch aus der Code-Review-Schleife entfernt wird, bleibt oft nur noch die Frage: "Bestehen die Tests?" Das ist zu wenig.

Tests messen nicht Maintainability

Der wichtigste Punkt des Artikels ist nicht, dass Coding Agents schlecht sind. Der Punkt ist: Heutige Modelle und Benchmarks belohnen Lösungen, die sichtbare Aufgaben bestehen, aber sie bestrafen schlechte Architektur nur indirekt oder gar nicht.

Ein Agent kann einen Bug fixen, alle Tests bestehen lassen und trotzdem die Codebasis verschlechtern:

• durch grobe try/catch-Pflaster
• durch schwache Typisierung
• durch versteckte Kopplung
• durch Logik an der falschen Stelle
• durch Änderungen, die spätere Features teurer machen

Das Problem zeigt sich nicht sofort. Tests liefern Feedback in Sekunden. Schlechte Architektur kostet Wochen oder Monate später Zeit, wenn eine kleine Änderung plötzlich elf Dateien berührt.

Harness Engineering hat eine Decke

Harness Engineering ist wichtig: gute Tools, saubere Sandboxes, klare Editiermechanik, Linting, Tests, Regression Checks und Agenten-Review verbessern die Ergebnisse deutlich.

Aber ein Harness kann nur begrenzt kompensieren, was das Modell nicht stabil gelernt hat. Dex argumentiert: Wenn das Training und die Verifikation schnelle, eindeutige Signale brauchen, bleibt Maintainability schwer zu optimieren. Es gibt keinen einfachen Oracle-Test für "ist dieser Code in sechs Monaten noch gut änderbar?"

Das macht automatische Software-Fabriken nicht nutzlos. Es macht sie begrenzt. Die Grenze liegt nicht bei Geschwindigkeit, sondern bei Design-Verantwortung.

Das Gegenmodell: Lights On

Der produktive Weg ist nicht, Agenten auszubremsen. Der produktive Weg ist, menschliche Urteilsarbeit an die Stellen zu setzen, an denen sie den größten Hebel hat.

Der Artikel nennt vier Phasen:

1. Product Design: Was wird gebaut, für wen, und woran erkennt man Erfolg?
2. System Architecture: Welche Services, Datenmodelle, Endpunkte und Abhängigkeiten sind betroffen?
3. Program Design: Welche Typen, Signaturen, Call-Stacks und Dateigrenzen braucht die Umsetzung?
4. Vertical Slices: In kleinen lauffähigen Scheiben bauen, prüfen und nachsteuern.

Das ist kein nostalgisches "Menschen müssen alles selbst machen". Es ist ein Hebelmodell. Agenten dürfen schnell sein, aber Menschen definieren die Struktur, in der Geschwindigkeit nicht zu technischer Schuld wird.

Der ag3nt.id Take

Agentic Engineering gewinnt nicht durch mehr Autonomie allein. Es gewinnt durch bessere Arbeitsteilung.

Coding Agents sind stark, wenn sie klare Kontexte, begrenzte Aufträge, lauffähige Zwischenziele und harte Verifikationspunkte bekommen. Sie sind riskant, wenn sie über Wochen ungestört Code erzeugen, den niemand mehr wirklich versteht.

Die reife Software-Fabrik ist deshalb nicht "lights off". Sie ist "lights on": Agenten übernehmen Umsetzung, Recherche, Tests, Varianten und Review-Vorarbeit. Menschen behalten Produkturteil, Architektururteil und finale Verantwortung für Maintainability.

Der pragmatische Satz für Teams lautet: Bewege dich 2- bis 3-mal schneller, ohne die Codebasis blind zu setzen. Wer auf 10- bis 100-mal schneller zielt und Review als lästigen Restposten behandelt, baut möglicherweise keine Fabrik, sondern eine Schuldenmaschine.

Fazit

"Why Software Factories Fail" ist ein nützlicher Gegenpol zum Autonomie-Hype. Der Text sagt nicht: Nutzt keine Coding Agents. Er sagt: Verwechselt Durchsatz nicht mit Qualität.

Die nächste Stufe agentischer Softwareentwicklung wird nicht nur durch bessere Loops entstehen. Sie wird durch bessere Schnittstellen zwischen Agentenarbeit und menschlichem Designurteil entstehen.

Quelle: Dex Horthy / HumanLayer, "Why Software Factories Fail"

Weiterführend: Agentic Engineering: Warum CLI-first die eigentliche Produktivitätsgrenze verschiebt