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 fuer die langfristige Form des Codes uebernimmt.

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 spaeter Probleme. Das klingt nach Produktivitaet. In gewachsenen Codebasen kann es aber genau das Gegenteil erzeugen: schneller mehr Code, der spaeter schwerer zu aendern 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 frueher Stunden oder Tage dauerte, kann Minuten oder wenige Stunden brauchen. Dadurch verschiebt sich der Engpass:

• Menschen schreiben weniger Code selbst.
• Menschen muessen 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 Loesungen, 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 Aenderungen, die spaetere Features teurer machen

Das Problem zeigt sich nicht sofort. Tests liefern Feedback in Sekunden. Schlechte Architektur kostet Wochen oder Monate spaeter Zeit, wenn eine kleine Aenderung ploetzlich elf Dateien beruehrt.

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 fuer "ist dieser Code in sechs Monaten noch gut aenderbar?"

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 groessten Hebel hat.

Der Artikel nennt vier Phasen:

1. Product Design: Was wird gebaut, fuer wen, und woran erkennt man Erfolg?
2. System Architecture: Welche Services, Datenmodelle, Endpunkte und Abhaengigkeiten sind betroffen?
3. Program Design: Welche Typen, Signaturen, Call-Stacks und Dateigrenzen braucht die Umsetzung?
4. Vertical Slices: In kleinen lauffaehigen Scheiben bauen, pruefen und nachsteuern.

Das ist kein nostalgisches "Menschen muessen alles selbst machen". Es ist ein Hebelmodell. Agenten duerfen 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 Auftraege, lauffaehige Zwischenziele und harte Verifikationspunkte bekommen. Sie sind riskant, wenn sie ueber Wochen ungestoert Code erzeugen, den niemand mehr wirklich versteht.

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

Der pragmatische Satz fuer 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 laestigen Restposten behandelt, baut moeglicherweise keine Fabrik, sondern eine Schuldenmaschine.

Fazit

"Why Software Factories Fail" ist ein nuetzlicher Gegenpol zum Autonomie-Hype. Der Text sagt nicht: Nutzt keine Coding Agents. Er sagt: Verwechselt Durchsatz nicht mit Qualitaet.

Die naechste 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"

Weiterfuehrend: Agentic Engineering: Warum CLI-first die eigentliche Produktivitaetsgrenze verschiebt