Why Software Factories Fail

# Warum Software Factories scheitern, wenn niemand mehr den Code liest

Die Vision klingt verlockend. KI-Agenten schreiben den Großteil des Codes, prüfen sich gegenseitig, spielen Änderungen automatisiert aus. Menschen definieren nur noch Ziele und beobachten Dashboards. Die „Lights-off Software Factory“ ist geboren.

Doch genau hier setzt die Kritik von Dex Horthy an, Gründer von HumanLayer. Seine zentrale These lautet: Harness Engineering allein reicht nicht. Mehr Loops, mehr Agenten, mehr Tokens lösen das Grundproblem nicht. Denn das Problem liegt tiefer, in der Art, wie Modelle trainiert und bewertet werden.

Für Führungskräfte, die Enterprise GenAI ernsthaft in ihre Softwareprozesse integrieren wollen, ist das keine akademische Debatte. Es geht um Resilienz, Wartbarkeit und Governance.

## Der alte Traum der Softwarefabrik

Der Begriff „Software Factory“ ist nicht neu. Er reicht zurück bis zur NATO-Konferenz von 1968, auf der erstmals systematisch über „Software Engineering“ gesprochen wurde. Schon damals war die Idee, Software wie in einer Fabrik zu produzieren: standardisiert, automatisiert, skalierbar.

Bis 2022 sah diese Fabrik in etwa so aus:

Menschen definieren Anforderungen.
Tickets landen im Tracker.
Ein Entwickler implementiert.
Pull Request, Tests, Code Review.
Deployment, Monitoring, Feedback.
Zurück zum Anfang.

Viele Schleifen, viel menschliche Abstimmung. Wichtig war dabei immer ein Prinzip: Alignment vor Implementierung. Man investierte Zeit in Planung und Architektur, um spätere Korrekturschleifen zu verkürzen.

Mit Agenten verschiebt sich das Kräfteverhältnis.

## Wenn Bauen plötzlich Minuten dauert

Ersetzt man „Ein Entwickler implementiert“ durch „Ein Agent implementiert“, sinkt die Bauzeit dramatisch. Minuten statt Tage.

Doch das Review bleibt. Jemand muss den Code lesen, testen, verstehen. Plötzlich wird Review zum Engpass.

Die logische Reaktion vieler Teams lautet: Dann automatisieren wir auch das. Agentische Code Reviews, automatisierte Regressionstests, Incident-PRs um drei Uhr morgens, User-Feedback direkt in die Queue.

Am Ende steht die radikale Variante: Niemand liest mehr Code. Stattdessen investiert man in bessere Tests, bessere Sandboxes, bessere Monitoring-Signale. Die Frage lautet nur noch: Wie viel können wir in die Pipeline schieben?

Das ist die Lights-off Software Factory.

Und genau hier setzt Horthys Warnung an.

## Das eigentliche Problem ist kein Skill-Issue

Oft heißt es, schlechte Ergebnisse mit Coding Agents seien ein „Skill-Issue“. Man müsse nur besser prompten, mehr Kontext geben, mehr Tokens investieren.

Horthy widerspricht. Sein Argument: Selbst mit perfektem Harness Engineering stoßen wir an eine Grenze, die im Training der Modelle liegt.

Moderne Coding-Modelle werden über Reinforcement Learning optimiert. Vereinfacht gesagt:

1. Ein Agent generiert eine Lösung.
2. Ein Verifier bewertet das Ergebnis.
3. Gute Lösungen werden wahrscheinlicher, schlechte unwahrscheinlicher.

Das Problem ist die Bewertungsfunktion.

In Benchmarks wie SWE-bench zählt im Kern nur: Bestehen die Tests oder nicht? Fail-to-pass, pass-to-pass. Eine binäre Welt.

Es gibt keine explizite Strafe für schlechte Architektur. Kein Malus für steigende Komplexität. Keine Bewertung für Wartbarkeit.

Ein Modell kann Try-Catch-Blöcke großzügig verteilen, Typen unsauber casten oder Logik duplizieren. Solange die Tests grün sind, bekommt es die Belohnung.

Das Resultat: Code, der heute funktioniert, aber morgen schwerer zu verändern ist.

## Wartbarkeit hat keinen schnellen Oracle

Hier liegt der Kern des Problems für Unternehmen.

Tests liefern Feedback in Sekunden. Architekturfehler zeigen sich in Wochen oder Monaten. Vielleicht erst dann, wenn ein neues Feature unerwartet fünf weitere Bereiche bricht. Vielleicht erst im Incident.

Es gibt keinen schnellen, zuverlässigen „Oracle“ für Wartbarkeit. Und ohne schnellen Oracle ist Reinforcement Learning schwer.

Selbst neuere Benchmarks, die längere Aufgaben oder Code-Quality-Regeln einbeziehen, ändern das Grundproblem nur graduell. Wenn ein Modell perfekt erkennen könnte, was guter Code ist, hätte es ihn vermutlich direkt geschrieben.

Für Governance und Risiko-Management bedeutet das: Benchmark-Verbesserungen sind kein belastbarer Indikator für langfristige Codequalität.

## Wenn Codebasen langsam erodieren

Horthys Beobachtung aus der Praxis ist deutlich: Modelle werden besser bei isolierten Aufgaben, beim One-off-Feature oder beim Marketing-Site-Prototyp.

Aber sie werden kaum besser darin, eine bestehende Codebasis über Monate hinweg strukturell zu verbessern.

Ohne menschliches Steering verschlechtert sich die Wartbarkeit schleichend. Änderungen werden teurer. Kleine Anpassungen ziehen größere Kreise. Das klassische „Shotgun Surgery“-Problem.

Für Enterprise-Umgebungen mit regulatorischen Anforderungen, Audit-Pflichten und langen Lebenszyklen ist das kritisch. Geschwindigkeit allein ist kein Wert, wenn sie zukünftige Flexibilität zerstört.

## Die Lichter wieder einschalten

Die Konsequenz ist nicht, Agenten abzuschaffen. Sondern sie anders einzubetten.

Horthy plädiert dafür, die menschliche Review-Schleife wieder bewusst einzuführen. Allerdings nicht als reine Nachkontrolle, sondern als früheren Hebel.

Vier Phasen sind entscheidend:

Erstens, Product Review. Klare Definition von Problem und Erfolgskriterien, idealerweise mit Mockups statt reiner Textbeschreibung. Das reduziert Missverständnisse zwischen Intention und Implementierung.

Zweitens, Systemarchitektur. Services, Schnittstellen, Datenmodelle. Nicht im Detail, aber klar genug, um grobe Fehlrichtungen früh zu erkennen.

Drittens, Program Design. Die konkrete Form des Codes, Typen, Methodensignaturen, Call-Stacks. Hier entstehen viele Wartbarkeitsentscheidungen, die sonst implizit während des Reviews getroffen würden.

Viertens, vertikale Schnitte. Statt horizontal die gesamte Datenbank-, Service- und Frontend-Schicht getrennt zu bauen, wird ein Ende-zu-Ende-Strang umgesetzt, getestet und iteriert. So bleibt das System früh erlebbar.

Der Gedanke dahinter ist simpel: 30 Minuten Planung sparen Stunden an Review und Rework.

## Sie haben nicht zu viele Pull Requests

Ein prägnanter Satz aus dem Text lautet: Sie haben nicht zu viele PRs. Sie haben zu viele schlechte PRs.

Gute Pull Requests sind leicht zu reviewen. Schlechte PRs kosten kognitive und emotionale Energie. Gerade bei KI-generiertem Code, der 20 bis 50 Prozent Rework benötigt, entsteht Friktion.

Für Führungskräfte heißt das: Das Ziel darf nicht „mehr Output“ sein, sondern „besser vorbereiteter Output“. Sonst verschiebt sich der Engpass lediglich von der Implementierung ins Review oder in den Betrieb.

In früheren Diskussionen über Software Factories wurde bereits betont, dass Agenten nicht wie ein magischer Chatbot funktionieren, sondern wie eine Produktionspipeline. Horthys Beitrag ergänzt eine wichtige Dimension: Ohne Qualitätsanker erodiert diese Pipeline von innen.

## Realistische Beschleunigung statt 100x-Illusion

Die vielleicht wichtigste Botschaft lautet: Akzeptieren Sie die Constraints.

Modelle sind hervorragend bei bestimmten Aufgaben. Sie sind schwach bei langfristiger struktureller Qualität. Wer diese Grenzen versteht, kann Prozesse so gestalten, dass 2 bis 3x Beschleunigung möglich sind, ohne die Codebasis zu gefährden.

Wer hingegen 10x bis 100x Geschwindigkeit erzwingen will und Code-Review als lästiges Relikt betrachtet, riskiert technische Schulden in neuer, schwerer kontrollierbarer Form.

Für Enterprise GenAI bedeutet das: Governance ist kein Bremsklotz. Sie ist das Fundament, auf dem nachhaltige Automatisierung aufbaut.

Oder einfacher gesagt: Lesen Sie den Code. Noch zumindest.

Quelle: Dex Horthy, „Why Software Factories Fail“
https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md

Credit: humanlayer/advanced-context-engineering-for-coding-agents