Software-Fabriken: Licht und Schatten

• Software-Fabriken betreiben Schleifen, die Kontext sammeln, handeln und validieren, in einem Harness in großem Maßstab. Sie lassen sich in helle Fabriken, in denen Menschen urteilen, und dunkle Fabriken unterscheiden, in denen auch Code-Reviews Maschinen überlassen werden.
• Codegenerierung, Tests und Scans lassen sich nahezu kostenlos skalieren, doch menschliche Prüfung und Urteilsvermögen sind schwer skalierbar. Der Engpass ist daher nicht die Menge der Generierung, sondern die Geschwindigkeit, mit der Ergebnisse günstig und verlässlich validiert werden können.
• Wenn Menschen Code nicht lesen, entsteht zwischen dem Umfang des Codes und dem menschlichen Verständnis Verstehensschuld (comprehension debt). Selbst wenn Tests weiter bestehen, können sich in komplexen, langfristig betriebenen Systemen Wartungsprobleme erst spät zeigen.
• Vollautomatisierung sollte nur für kurze Schleifen zugelassen werden, die über sofortige, nicht driftende und schwer manipulierbare Bewertungskriterien verfügen. Bei Aufgaben wie Authentifizierung, Zahlungen oder öffentlichen APIs, bei denen die Kosten und der Wirkungsbereich falscher Entscheidungen groß sind, sollte menschliche Prüfung erhalten bleiben.
• Die Rolle von Ingenieuren verlagert sich vom direkten Schreiben einzelner Änderungen hin zum Entwerfen und Absichern der äußeren Schleifen. Sie müssen die Belege für Diagnose, Implementierung und Tests durch Agenten prüfen und Verantwortung für Freigaben und Ergebnisse übernehmen.

---

Von der Schleife zur Software-Fabrik

• Die Idee, Software zu einem wiederholbaren und messbaren Produktionsprozess zu machen, reicht bis zu Bob Bemers 1968 veröffentlichtem Artikel „The economics of program production“ zurück.
  • Weil Ideen schwer wie Autoteile in Serie zu fertigen waren, blieben solche Versuche im vergangenen halben Jahrhundert meist hinter den Erwartungen zurück.
  • Die Veränderungen der letzten zwei Jahre waren groß genug, um die alte Vorstellung der Software-Fabrik neu zu prüfen; zugleich können alte Fallstricke als neue Chancen verpackt erscheinen.
• Das Gesamtsystem besteht aus drei Ebenen: Schleife, Harness und Fabrik.
  • Eine Schleife ist die kleinste Arbeitseinheit: Ein Agent sammelt Kontext, handelt und prüft anschließend das Ergebnis; dies wiederholt er, bis die Abbruchbedingung erfüllt ist.
  • Loop Engineering ist ein Ansatz, bei dem Menschen nicht jedes Mal einen Prompt eingeben, sondern kleine Systeme entwerfen, die Agenten Prompts liefern.
  • Ein Harness umfasst die Sandbox, in der die Schleife läuft, die verfügbaren Werkzeuge, den zwischen Ausführungen erhaltenen Speicher und Gates, die entscheiden, ob die Aufgabe abgeschlossen ist.
  • Ein Modell ohne Harness kann endlos wiederholen; der Harness macht die Schleife nützlich und sicher.
• Eine Software-Fabrik nimmt Einträge aus einer Arbeitswarteschlange, führt mehrere harness-basierte Schleifen gleichzeitig aus und bringt Änderungen über Review-Gates in die Produktion.
  • Sie ähnelt weniger einem größeren einzelnen Agenten als vielmehr einem Organigramm aus Schleifen.
  • Auch die Arbeitseinheit von Ingenieuren verschiebt sich von einzelnen Codeänderungen hin zu Schleifen, Harnesses und den Flüssen zwischen Schleifen.

Arbeitsfluss und Engpässe der Fabrik

• Signale aus der Vision der Engineering-Führung, den Absichten der Ingenieure, Störungen und Nutzeranfragen fließen in eine gemeinsame Arbeitswarteschlange.
  • Ein Harness wählt einen Eintrag aus und erzeugt eine Änderung; CI, Tests, statische Analyse und verschiedene Scans prüfen die Änderung parallel.
  • Wenn das Review-Gate zustimmt, wird die Änderung bereitgestellt, und Monitoring-Daten aus der Produktion werden wieder zu Signalen, die neue Arbeit auslösen.
• Generierung, Tests und Scans lassen sich zu vernachlässigbaren Kosten skalieren, doch menschliches Urteilsvermögen am Review-Gate ist schwer skalierbar.
  • Ob Entwicklungsgeschwindigkeit und Deployment-Frequenz steigen können, hängt davon ab, wie dieser Urteils-Engpass behandelt wird.

Dunkle Fabriken und Verstehensschuld

• Eine dunkle Fabrik in der Fertigung ist eine Anlage, die ohne Licht betrieben wird, weil Maschinen keine Beleuchtung benötigen.
  • FANUC betreibt solche Fabriken seit 2001, und Xiaomi eröffnete 2024 ebenfalls eine hochautomatisierte dunkle Fabrik.
• In einer dunklen Software-Fabrik lesen Menschen den Code nicht; Änderungen werden allein auf Basis der Validierung bereitgestellt, die die Maschine ausgeführt hat, welche den Code erzeugt hat.
  • Dunkelheit meint hier keine negative Stimmung, sondern dass Menschen aus dem Prozess des Schreibens, Prüfens und Deployens von Diffs verschwunden sind.
• Entfernt man menschliche Reviews, verschwinden Reibungspunkte, und der vertikale Durchsatz eines Teams kann sprunghaft gestiegen wirken.
  • Wegen versteckter Kosten ist es jedoch schwieriger, solche Arbeitsabläufe langfristig aufrechtzuerhalten, als es scheint.
• Orchestrierung, sandbox-basiertes Prototyping und Tool-Aufrufe werden weiter leistungsfähiger werden, doch Harnesses allein reichen nicht aus, um langfristig die Qualität einer Codebasis zu erhalten.
• Verstehensschuld ist die Lücke zwischen der Menge an vorhandenem Code und der Menge an Code, die Menschen tatsächlich verstehen.
  • Dunkle Fabriken häufen Verstehensschuld schnell an, selbst während die Tests bestehen.
  • Anders als bei sofortigen Änderungen an kleinen Codebereichen oder Wochenendprojekten müssen komplexe Bestandssysteme, die über mehr als zehn Jahre entwickelt wurden, kontinuierlich mit professioneller Geschwindigkeit gewartet werden.
  • Nach drei bis sechs Monaten Betrieb eines Automatisierungsprojekts kann man von ungelesenem Code überwältigt werden.
• Als Dex Horthy etwa vier Monate lang eine vollständig automatisierte Fabrik betrieb, in der Menschen den generierten Code nicht ansahen, war mühsames manuelles Debugging nötig, um die Ursache von Problemen zu finden.
  • Je stärker der Token-Verbrauch maximiert wird, desto stiller nimmt das menschliche Verständnis des Systems ab.
  • Fehler treten möglicherweise nicht als plötzlicher Zusammenbruch eines Systems auf, dessen Tests zuvor bestanden, sondern spät und leise.

Warum Validierung stärker begrenzt als Generierung

• Backpressure ist das Prinzip, Schleifen nur so viel Autonomie zu geben, wie günstig und verlässlich validiert werden kann.
  • Das Kernproblem ist die Lücke zwischen nahezu unbegrenzter Generierungsfähigkeit und begrenzter menschlicher Aufmerksamkeit.
  • Wenn der Validierungsabschnitt nicht breiter wird, stauen sich Änderungen; erhöht man nur die Menge ohne vertrauenswürdige Gates, entstehen minderwertige PRs und fabrizierte Defekte.
• Verbesserungen der Modellleistung schließen die Lücke zwischen Generierung und Validierung nicht automatisch.
  • Der Wert guter Architektur zeigt sich nicht über Sekunden oder Minuten, sondern über Monate und Jahre.
  • Für architektonische Exzellenz lassen sich saubere Kostenfunktionen oder unmittelbare Bewertungssignale nur schwer berechnen, weshalb komplexe Designentscheidungen auch schwer als gute Beispiele trainierbar sind.

Wie man das Licht wieder einschaltet

• Auch in einer hellen Fabrik übernehmen Agenten den Großteil der Implementierung, doch an Stellen, an denen falsche Entscheidungen teuer sind, wird das Licht eingeschaltet: Menschen lesen die Ergebnisse und deployen sie erst danach.
• Menschliches Urteilsvermögen sollte nicht erst an das letzte Code-Review angehängt werden, sondern vor dem Start der Agentenschleife in Produkt-, Design- und Architekturphasen verlagert werden.
  • Wenn man vorab eine Stunde lang einen 200-Zeilen-Plan prüft, kann das ein langes Review ersparen, bei dem man nach der Implementierung 2.000 Zeilen generierten Code nach Designentscheidungen durchsucht.
  • Je teurer und langlebiger eine Entscheidung ist, desto früher sollten Menschen vor der Implementierung beteiligt sein; selbst nach einer Vorabprüfung wird der Diff bei Bedarf direkt kontrolliert.
• Das Sicherheitsnetz besteht nicht aus neuen Techniken, sondern aus vertrauten Architekturpraktiken.
  • Gute Typen und Methodensignaturen fangen Fehler im Compiler statt in der Produktion ab.
  • Test-Seams schaffen Angriffspunkte, um Verhalten festzuschreiben und Änderungen beobachtbar zu machen.
  • Code wird so angeordnet, dass sowohl Menschen als auch Modelle den benötigten Code leicht finden.
  • Call Stacks bleiben kurz und gut lesbar.
  • Klare Komponentengrenzen begrenzen den Wirkungsbereich von Änderungen.
  • Dependency Injection macht Komponenten austauschbar.
• Diese Architektur erfüllt eine zweite Aufgabe: Sie verhindert Fehler automatischer Coding-Agenten auf günstige und schwer auszutrick­sende Weise.
  • Agenten wie Claude Code und Codex sind für ihren eigenen Harness und Tool-Einsatz per Reinforcement Learning optimiert, liefern aber keine langfristige Wartbarkeit.
  • Das Sicherheitsnetz muss außerhalb des Modells existieren; Investitionen in Architektur werden zu einem Mittel, um sicher mehr Autonomie zu ermöglichen.
• In Verbindung mit sicherer Infrastruktur können einige kurze, risikoarme Schleifen unbeaufsichtigt laufen.
  • Beispielsweise kann jede Nacht ein GitHub-Actions-cron genau ein Antipattern, einen Lint-Verstoß oder einen unnötig optionalen prop korrigieren, committen und einen kleinen PR öffnen.
  • Bei Zielen mit hohen Fehlerkosten, etwa Authentifizierungssystemen, Payment Engines oder öffentlichen API-Verträgen, müssen Menschen mit Systemwissen und Urteilsvermögen prüfen.

Schleifen, die sich Automatisierung verdienen

• Damit eine Schleife vollständig automatisiert werden kann, muss ihre Prüfung günstig und häufig ausführbar sein und auf Kriterien beruhen, die nicht leicht zu täuschen sind.
  • Dazu gehören Richter, die klar wahr oder falsch zurückgeben, Type-Gates, property-basierte Tests und Review-Agenten in Verbindung mit realen Bewertungsrubriken.
  • Entscheidungen müssen sofort vorliegen und dürfen mit der Zeit nicht driften.
  • Automatisiert werden kann, wenn nicht nur Menschen, sondern auch Maschinen den Abschlusszustand beweisen können.
• Kurze Schleifen sind leichter zu validieren als lange.
  • Nach Dex’ Faustregel funktionieren Agenten bei 3 bis 10 Schritten gut, beginnen aber jenseits von 20 Schritten den Faden zu verlieren.
  • Je mehr Kontext sich ansammelt, desto größer wird die Wahrscheinlichkeit, dass ein Agent vom Pfad abkommt; lange Schleifen verstecken Fehler in den Ecken.
• Wenn die Kosten einer falschen Antwort hoch sind und nur Menschen sie erkennen können, muss das Licht eingeschaltet werden.
  • Dazu gehören subtile Produktionsbugs, die Tests nicht erfassen, ein großer Wirkungsbereich und Entscheidungen, die Arbeit über ein Jahr oder länger prägen.
  • In solchen Fällen ist menschliche Aufmerksamkeit das eigentliche Produkt und eine teure, aber unverzichtbare Ressource.
• Wenn alle Schleifen im selben Modus laufen, scheitern beide Seiten.
  • Läuft alles dunkel, muss das System nach einigen Monaten möglicherweise zerlegt werden.
  • Läuft alles hell, wird Review zum riesigen Engpass.
  • Die Kernkompetenz besteht darin zu entscheiden, an welcher Stelle jeder Schleife das Licht eingeschaltet wird.

Graphen und Zustandsmaschinen um Schleifen herum

• Agentenarbeit wird wahrscheinlich letztlich aus gerichteten Graphen bestehen, ob man sie nun endliche Zustandsmaschinen oder bedingte Service-Aufrufe nennt.
  • Jeder Knoten ist ein expliziter Schritt, und die Kanten zwischen Knoten sind explizite Bedingungen.
  • Da sich jeder Code als Control-Flow-Graph darstellen lässt, ist die Struktur selbst nicht neu.
  • Die Autonomie des Agenten wird nicht auf den gesamten Graphen, sondern auf das Innere einzelner Knoten begrenzt.
• Der neue Versuch bestand darin, Flussdiagramme zu entfernen und das Modell bei jedem Tool-Aufruf den Pfad wählen und am Ende selbst die Fertigstellung erklären zu lassen.
  • Nach der Kollision mit alten Codebasen ähnelt die Bewegung, die Kontrolle über den Control Flow wieder zu übernehmen, der Wiederherstellung bestehender Graphen um Schleifen herum.
• Eine Bugfix-Aufgabe verläuft in einer reinen Schleife anders als in einem Graphen.
  • In einer reinen Schleife werden Problemuntersuchung, Codeänderung, Auswahl und Reihenfolge der Tests, Wiederholungen und Abschlussentscheidung laufend entschieden.
  • In einem Graphen werden Reproduktion des Bugs oder Anforderung zusätzlicher Informationen, Ursachenanalyse, Fix, Tests und Review vorab als Pfad definiert.
  • Testfehler führen zurück in den Fix-Schritt, Erfolg führt zum Review, und abgeschlossen wird nur bei Freigabe.
  • Der Agent handelt innerhalb jedes Knotens intelligent, kann aber nicht auf nicht erlaubte Pfade ausweichen.
• Graphen sind eine Form von visualisierter Backpressure.
  • Man gibt einen Teil der Freiheit des Agenten auf und erhält dafür Pflichtprüfungen und lesbare Fehlerpunkte.
  • Wenn eine Ausführung fehlschlägt, lässt sich identifizieren, welcher Knoten sie gestoppt hat.
• Wie beim Ansatz der 12-factor agents ähneln viele Agentensysteme eher „größtenteils deterministischem Code mit LLM-Schritten an den passenden Stellen“.
  • Dasselbe Muster zeigt sich bei LangGraph und LlamaIndex Workflows, Jerry Lius hybriden Workflow-Graphen über Agenten sowie in den von David Khourshid verknüpften Zustandsmaschinen und dem Actor Model.
• Mit Graph ist hier kein Knowledge Graph gemeint, sondern ein gerichteter Graph mit vorab definiertem Arbeitsfluss und bedingten Kanten.

Menschen besitzen die äußere Schleife

• Menschen verschwinden nicht aus der Fabrik, sondern wechseln von der Ausführungslinie in die äußere Schleife.
  • Agenten übernehmen die innere Schleife: Bugs untersuchen, Diagnosen schreiben, Fixes implementieren, Tests ausführen und Ergebnisse berichten.
  • Ingenieure beurteilen, ob das Problem auf die richtige Weise gelöst wird, prüfen Diagnose und Implementierung, geben Änderungen frei und tragen Verantwortung für falsche Ergebnisse.
• An der Grenze zwischen innerer und äußerer Schleife liegen Belege wie Diff, Tests, Logs und kurze Erläuterungen, die diese verbinden.
  • Mit Typen, Test-Seams und Bewertungsrubriken lässt sich die Ausführung von Agenten überwachen, ohne bei jeder Änderung viel Handarbeit zu leisten.
• Die Position von Ingenieuren verschiebt sich von der Produktionslinie, an der sie Änderungen selbst schreiben, hin zum Entwerfen der Linie und Bewachen der Gates.
  • Modelle und Harnesses lassen sich verbessern, doch menschliches Urteilsvermögen bei der Identifikation langfristig teurer Probleme ist schwer zu automatisieren.
  • Am gefährlichsten ist es, alle Arbeitsbereiche dunkel zu machen, sodass Menschen weder sehen können, was geschieht, noch den Lichtschalter finden.