Das Fließband, das niemand liest

Softwareentwicklung wird zunehmend zu einem Produktionsprozess, und die entscheidende Frage dabei ist, wo Sie das Licht anlassen. Sie können ein System aufbauen, in dem Agenten Code schreiben, testen und bereitstellen, während eine Person das Wesentliche überprüft, bevor der Code veröffentlicht wird. Oder Sie bauen ein System, in dem der Code veröffentlicht wird, ohne dass ein Mensch ihn je gesehen hat. Beides wirkt wie Fortschritt – doch nur eines davon bleibt langfristig kostengünstig.

Die Idee ist nicht neu. Bob Bemer beschrieb sie bereits 1968 in einem Papier mit dem Titel "The Economics of Program Production", in dem er sich Software vorstellte, die wie Autoteile vom Band rollt. Über ein halbes Jahrhundert lang scheiterte dieser Traum größtenteils, weil sich Ideen nicht so leicht stanzen lassen wie Blech. Die letzten beiden Jahre haben die Rahmenbedingungen jedoch so verändert, dass dieser Traum wieder einen genaueren Blick verdient. Der folgende Text basiert stark auf Dex Horthys Vortrag auf der AI Engineer World's Fair, "Harness Engineering is Not Enough: Why Software Factories Fail", ergänzt um Erkenntnisse aus der Praxis, die zeigen, was in solchen Systemen tatsächlich schiefgehen kann.

Fangen wir mit dem Punkt an, den alle falsch verstehen: der Engpass.

Der Engpass war nie die Geschwindigkeit

Ein System kann nur so viel Autonomie haben, wie es sich günstig und zuverlässig verifizieren lässt – nicht mehr. Die Generierung ist nicht das Nadelöhr. Die Verifikation ist es.

Stellen Sie sich die Pipeline wie einen Trichter vor. Die Öffnung ist die Generierung, und sie ist breit. Mehr Agenten, schnellere Modelle, höhere Parallelität – all das macht sie noch breiter, und das kostet fast nichts. Der Flaschenhals ist die Verifikation, und der bleibt schmal. Menschliche Aufmerksamkeit ist begrenzt und skaliert nicht mit der Rechenleistung. Wenn Sie mehr Generierung durch einen fixen Flaschenhals schieben, erhalten Sie nicht mehr ausgelieferte Arbeit – Sie bekommen einen immer größeren Stapel unbearbeiteter Pull Requests.

Dieser Zusammenhang verdient einen eigenen Namen: Rückstau. Autonomie kann die Verifikation nicht übersteigen. Jede Diskussion darüber, wie schnell eine Softwarefabrik sicher laufen kann, läuft auf diesen einen Satz hinaus.

Es ist verlockend, auf bessere Modelle zu warten, um die Lücke zu schließen. Doch das geht am Problem vorbei. Ein Modell darauf zu trainieren, Unit-Tests zu bestehen, ist relativ einfach, weil die Belohnung sofort und klar ist. Ein Modell aber darauf zu trainieren, Code zu schreiben, der auch nach einem Jahrzehnt wartbar bleibt, ist es nicht – denn das Signal, ob eine architektonische Entscheidung gut war, kommt erst nach Monaten oder Jahren. Saubere Gradienten über solch lange Zeiträume hinweg zu berechnen, ist unmöglich. Die Modelle, die sich derzeit am schnellsten verbessern, werden daher nur bei dem besser, was leicht messbar ist – nicht bei dem, was teuer ist, falsch zu machen. Bessere Generierung und bessere Verifikation sind unterschiedliche Probleme, und sie als eines zu behandeln, schafft falsche Sicherheit darüber, wie viel Autonomie tatsächlich sinnvoll ist.

Drei Begriffe, die alles erklären

Jedes agentenbasierte System, egal wie es vermarktet wird, beruht auf drei grundlegenden Konzepten.

Eine Schleife ist ein einzelner Agent, der einen Job immer wieder ausführt: Kontext sammeln, handeln, Ergebnis prüfen, wiederholen, bis eine Bedingung erfüllt ist. Es ist die kleinste Einheit agentenbasierter Arbeit. Die Kunst des Loop-Engineerings besteht darin, aufzuhören, den Agenten Schritt für Schritt zu steuern, und stattdessen ein kleines System zu bauen, das ihn für Sie steuert.

Ein Harness ist die Begrenzung um eine Schleife herum. Es ist die Sandbox, in der die Schleife läuft, die Werkzeuge, die sie nutzen darf, der Speicher, der zwischen den Durchläufen erhalten bleibt, und die Regeln, die festlegen, was als "fertig" gilt. Die Schleife ist das Verhalten. Das Harness ist die Umgebung, in der dieses Verhalten ausgeführt wird. Gibt man einem Modell kein Harness, dreht es sich endlos im Kreis. Das Harness macht die Schleife nützlich und sicher.

Eine Softwarefabrik ist viele mit Harness ausgestattete Schleifen, die gleichzeitig laufen, von einer Queue gespeist und durch ein Review-Gate in die Produktion geleitet, mit Menschen, die das Ganze überwachen. Es ist kein größerer Agent. Es ist ein Organigramm aus Schleifen.

Diese Sichtweise erfordert einen echten Wandel. Sie hören auf, Code zu schreiben, und fangen an, die Maschine zu bauen und zu betreiben, die den Code schreibt. Die Arbeitseinheit verschiebt sich von der einzelnen Änderung zur Schleife, zum Harness und zu den Abläufen dazwischen.

Die Fabrik als geschlossener Kreislauf

Das einfachste Bild einer Softwarefabrik ist ein Kreislauf, der niemals stoppt.

Input kommt aus zwei Richtungen. Engineering-Führungskräfte und Entwickler schieben Arbeit in eine Queue. Zwischenfälle und Kundenanfragen landen als Signale in derselben Queue. Das Harness zieht ein Item heraus, erzeugt eine Änderung und reicht diese an eine Reihe automatisierter Prüfungen weiter: CI, Tests, statische Analyse, Sicherheits-Scans. Diese Prüfungen laufen fast kostenlos und ohne menschliches Zutun. Die Änderung erreicht das Review-Gate. Nach der Freigabe wird sie ausgerollt, in der Produktion überwacht und die Monitoring-Daten fließen zurück als Signale in den Kreislauf.

Betrachten Sie nun die Kosten der einzelnen Schritte. Generierung kostet fast nichts. Tests kosten fast nichts. Scans kosten fast nichts. Jeder Schritt läuft skalierbar und günstig – außer einem: dem Review-Gate. Dies bleibt teuer, egal wie viel Rechenleistung man für die anderen Schritte aufwendet. Dieses Gate ist Urteilsvermögen. Jede Diskussion darüber, wie schnell und wie oft man Code ausrollen kann, spielt sich genau dort ab.

Wenn die Lichter ausgehen

Eine dunkle Fabrik liefert Code, den kein Mensch je gelesen hat, geprüft nur von Maschinen. Der Begriff stammt aus der Fertigungsindustrie, nicht aus der Software.

Eine sogenannte "lights-out factory" wird mit ausgeschalteten Lichtern betrieben, weil auf der Produktionsfläche nur Roboter arbeiten, die kein Licht benötigen. FANUC betreibt seit 2001 solche Fabriken in Japan. Xiaomi eröffnete 2024 eine stark automatisierte Fabrik. Gemeinsam ist ihnen, dass Produkte gefertigt und ausgeliefert werden, ohne dass je ein Mensch sie geprüft hat. "Dunkel" beschreibt nicht die Stimmung, sondern ganz wörtlich einen Raum ohne Licht.

In der Software ist dieser Raum der Diff. In einer dunklen Fabrik sind alle, die den Diff geschrieben, überprüft oder veröffentlicht haben, nicht mehr beteiligt. Zurück bleibt eine Änderung, die nur die Maschinen gesehen haben, die sie erstellt haben.

Diesen Zustand zu erreichen, ist einfacher, als es sein sollte. Der Review-Schritt verlangsamt den Prozess, sodass dessen Entfernung den Durchsatz über Nacht scheinbar drastisch steigert. Es fühlt sich an, als hätte man eine Mauer durchbrochen. Dieses Gefühl ist ehrlich. Doch genauso ehrlich ist der verborgene Preis, der erst später sichtbar wird.

Die unsichtbare Schuld auf dem Dashboard

Hier ist der Preis, klar benannt:

Verständnisschuld ist die wachsende Lücke zwischen der Menge an existierendem Code und dem, was Menschen davon noch verstehen. Eine dunkle Fabrik zahlt diese Schuld nicht ab. Sie nimmt sie so schnell wie möglich auf, während die Tests grün bleiben.

Modelle bewältigen gut definierte, lokalisierte Aufgaben effektiv. Doch bei Änderungen, die große oder unbekannte Teile eines reifen Codebases betreffen, stoßen sie an strukturelle Grenzen. Ein Wochenendprojekt erreicht in wenigen Zyklen einen funktionierenden Zustand. Ein zehn Jahre altes Enterprise-System hingegen ist eine andere Herausforderung. Es muss unter Produktionsbedingungen und gegen Entscheidungen, die längst verlassene Personen getroffen haben, professionell gewartet werden. Nach drei bis sechs Monaten in einem vollautomatisierten Workflow für solch ein System schwimmt man bereits in Code, den niemand gelesen hat. Das Modell scheitert nicht aus Mangel an Fähigkeiten, sondern weil die Umgebung mehr enthält, als das Harness einfangen kann.

Die Beweise hierfür sind direkt. Dex Horthy betrieb vier Monate lang eine vollständig automatisierte Codefabrik, ohne dass ein Mensch die Ergebnisse las. Der Fehler, der letztlich auftauchte, erforderte mühsames manuelles Debugging, um ihn zu finden. Darunter lag ein Konflikt zwischen zwei Werten: Token-Auslastung, die die Branche derzeit als Fortschritt feiert, und dem Verständnislevel des Systems, das die dunkle Fabrik stillschweigend gegen null treibt. Sie optimiert massiv für das eine und opfert das andere, ohne dass es in den Metriken sichtbar wird.

Die Rechnung kündigt sich nicht an. Sie kommt leise, spät und teuer.

Lichter wieder an, weiter oben

Eine beleuchtete Fabrik ist dieselbe Pipeline, nur mit eingeschaltetem Licht dort, wo Urteilsvermögen gefragt ist. Agenten übernehmen weiterhin den Großteil der Arbeit. Ein Mensch liest jedoch das Wesentliche, bevor es veröffentlicht wird, und das Licht bleibt überall dort an, wo Fehlentscheidungen teuer wären.

Der Fehler liegt darin zu denken, "beleuchtet" bedeutet, das Review an das Ende anzuhängen. Das tut es nicht. Eine beleuchtete Fabrik verlagert menschliches Urteilsvermögen nach oben, in Produkt, Design und Architektur – bevor ein Agent überhaupt eine Schleife startet. Eine Stunde, um einen 200-Zeilen-Plan zu prüfen, ist besser investiert als ein Tag, um einen 2000-Zeilen-Diff zu analysieren, um den Plan zu rekonstruieren. Sie prüfen die Entscheidung, bevor sie umgesetzt wird, statt sie im Nachhinein zu analysieren.

Das Sicherheitsnetz, das dies ermöglicht, ist unspektakulär. Es ist eine Reihe architektonischer Praktiken, die schon immer empfohlen, aber oft vernachlässigt wurden:

Starke Typen und Methodensignaturen, damit Fehler beim Kompilieren statt in der Produktion sichtbar werden.

Testnähte, damit Verhalten fixiert und Änderungen beobachtet werden können.

Lesbare Code-Struktur, damit der nächste Leser, ob Mensch oder Modell, weiß, wo er suchen muss.

Kurze Call-Stacks und klare Komponentenabgrenzungen, damit Änderungen nur eine kleine Auswirkung haben.

Dependency Injection, damit einzelne Teile ersetzt werden können, ohne den Rest zu zerstören.

Nichts davon ist neu. Neu ist jedoch der zweite Zweck der Architektur. Sie ist nicht länger nur Hygiene, sondern wird zu einem schwer zu fälschenden Sicherheitsnetz gegen die Fehler, die Agenten machen werden. Dieses Netz muss außerhalb des Modells existieren, da es vom Modell nicht gestellt wird. Die Agenten, die am fähigsten wirken, wie Claude Code und Codex, sind gegen ihre eigenen Harnesses und Tools trainiert. Sie sind geschickt im Schreiben von Code, aber nicht darauf trainiert, langfristige Wartbarkeit sicherzustellen, weil kein Belohnungssignal dies auf einer nützlichen Zeitskala misst.

Investitionen in eine durchdachte Architektur kaufen somit Autonomie zurück. Die Architektur fängt auf, was das Modell nicht kann, und ermöglicht es Ihnen, einige Schleifen unbeaufsichtigt laufen zu lassen, ohne Verständnisschuld anzuhäufen. Ein nächtlicher Job, der einen einzelnen Lint-Fehler behebt, committet und einen kleinen Pull-Request öffnet, ist eine sichere lights-out-Schleife. Die Aufgabenstellung ist eng, der Diff ist lesbar, die Prüfung unmissverständlich. Eine Schleife, die Authentifizierung, Abrechnung oder einen öffentlichen API-Vertrag betrifft, ist es nicht. Hier bleiben die Lichter an.

Was einer Schleife Autonomie verleiht

Die Rückstau-Regel bestimmt jede Entscheidung über Autonomie, egal wie Sie sie nennen.

Eine Schleife verdient vollständige Automatisierung nur, wenn ihre Prüfung günstig, häufig durchführbar und schwer zu fälschen ist. Grün-oder-Rot-Testresultate, Typsperren, Eigenschaftstests und ein Review-Agent mit klaren Kriterien qualifizieren sich. Die Prüfung muss sofortige Antworten liefern und darf im Lauf der Zeit nicht "driften". Wenn "fertig" von einer Maschine bewiesen werden kann, statt vom Agenten behauptet, verdient die Schleife das "dunkel".

Auch die Länge ist entscheidend. Kurze Schleifen lassen sich einfacher prüfen als lange. Ein Agent behält etwa drei bis zehn Schritte lang den Überblick und verliert ab zwanzig den Faden. Die Ursache ist Kontextanhäufung: Je mehr der Agent mitschleppen muss, desto wahrscheinlicher ist, dass er vom Kurs abkommt. Kurze Schleifen produzieren kurze Diffs, die sich günstig prüfen lassen. Lange Schleifen verbergen ihre Fehler in späteren Schritten – ein klares Zeichen dafür, dass sie nie den lights-out-Status verdient hatten.

Lassen Sie die Lichter an, wenn eine falsche Entscheidung teuer ist und nur ein Mensch sie auffangen kann. Subtile Produktionsfehler, die kein Test abdeckt, Änderungen mit großem Wirkungsradius und Entscheidungen, die ein Jahr Arbeit formen, gehören dazu. Hier ist Aufmerksamkeit keine Nebenkosten – sie ist der wesentliche, kostenintensive Teil des Prozesses und bleibt unersetzlich.

Die größte Gefahr besteht darin, den Schalter für alle gleich einzustellen. Alles dunkel zu machen, führt dazu, dass alles nach ein paar Monaten zusammenbricht, wenn die Schuld fällig wird. Alles beleuchtet zu lassen, macht das Review-Gate zu einer unüberwindbaren Hürde, und der Durchsatz kollabiert. Die eigentliche Fähigkeit besteht darin, Schleife für Schleife zu entscheiden, wo der Schalter hingehört.

Warum das Flussdiagramm zurückkehrt

Wenn Sie eine Schleife sorgfältig entwerfen, werden Sie feststellen, dass Sie ein gerichtetes Diagramm gebaut haben – ob Sie es so nennen oder nicht. Jeder Knoten ist ein expliziter Schritt. Jede Kante ist eine explizite Bedingung.

Das klingt nach schwerfälliger Struktur, aber das meiste davon war schon immer da. Jedes Programm kann als Kontrollflussdiagramm ausgedrückt werden. Die einzige echte Neuheit der rein agentenbasierten Schleife bestand darin, das Diagramm wegzuwerfen und dem Modell zu erlauben, den Pfad Schritt für Schritt selbst zu wählen, bis es sich für fertig erklärte. Das fühlte sich nach Freiheit an – bis das Modell auf ein zehn Jahre altes Codebase ohne lesbare Karte traf. Die Disziplin, die alle gerade wiederentdecken – den Kontrollfluss selbst zu steuern –, bedeutet einfach, das Diagramm wieder um die Schleife zu legen. Programme wurden aus gutem Grund einst als Flussdiagramme gezeichnet. Dieser Grund gilt noch immer.

Betrachten Sie einen Bugfix auf zwei Arten. Als reine Schleife entscheidet der Agent alles im Moment: Welches Problem er verfolgt, welchen Code er ändert, welche Tests er ausführt, ob er überhaupt Tests ausführt und ob er weitermacht oder aufhört. Als Diagramm zeichnen Sie den Pfad zuerst: Den Fehler reproduzieren oder Infos einholen, die Ursache finden, eine Lösung implementieren, Tests ausführen, ein fehlerhafter Durchlauf geht zurück an die Lösung, ein erfolgreicher zur Überprüfung, und nur eine genehmigte Änderung erreicht "fertig". Der Agent bleibt clever in jedem Knoten, aber er kann nicht von Ihrem vorgegebenen Pfad abweichen.

Der größte Vorteil des Diagramms ist, dass es Rückstau als Grafik darstellt. Sie tauschen etwas von der Freiheit des Agenten gegen zwingende Prüfungen und übersichtliche Fehlerpunkte ein, sodass Sie bei einem Fehler direkt auf den Knoten zeigen können, der ihn verursacht hat. Dieses Muster sehen Sie bei LangGraph, in LlamaIndex Workflows, in Jerry Lius hybrider Methode, wo eine äußere Schleife Teile des Diagramms während des Prozesses aufbaut, und in David Khourshids Erinnerung, dass dies nichts anderes ist als Zustandsautomaten und das Akteurmodell in neuen Gewändern. Die Namen variieren, die Struktur nicht.

Eine Klarstellung: Ein Diagramm hier bedeutet ein vordefiniertes gerichtetes Diagramm des Arbeitsflusses, mit Bedingungen und allem. Es ist kein Wissensgraph. Das Ziel ist, der Schleife eine Struktur zu geben, der Sie tatsächlich vertrauen können.

Der Mensch ist nicht verschwunden. Er hat sich verlagert.

Betrachten Sie die Fabrik genau, und Sie werden sehen, dass der Mensch immer noch da ist. Er hat sich nur die Linie hochbewegt.

Ingenieure müssen die äußere Schleife besitzen. Ein Agent kann einen Fehler reproduzieren, die Ursache diagnostizieren, die Lösung implementieren, Tests durchführen und einen Bericht schreiben. Das ist die innere Schleife, und der Agent kann sie genauso gut ausführen wie jeder andere. Aber die innere Schleife war nie der Job.

Die äußere Schleife bleibt menschlich. Entscheiden, ob dies überhaupt das richtige Problem ist. Verifizieren, ob Diagnose und Lösung fundiert sind. Die Änderung genehmigen. Die Konsequenzen tragen, wenn man falsch liegt. Die Grenze zwischen beiden Schleifen ist die Beweisführung: die Diffs, die Tests, die Logs und eine kurze Erklärung, die sie miteinander verbindet. Starke Typen, Testnähte und explizite Kriterien ermöglichen es, diese Beweise zu prüfen, ohne die Arbeit selbst noch einmal zu machen.

Die einfachste Möglichkeit, diesen Wandel zu beschreiben, lautet so: Sie stehen nicht mehr am Fließband und schreiben einzelne Änderungen. Sie stehen am Ende der Linie, entwerfen und überwachen sie. Sie können das Modell weiter vorantreiben und das Harness leistungsfähiger machen, aber Fehler zu erkennen, die über Jahre teuer werden, ist nichts, was aktuelle Tools automatisieren können – und die Kostenfunktion deutet darauf hin, dass zukünftige Tools es auch nicht können werden. Die Ausführung kann automatisiert werden. Die Beurteilung, ob diese Ausführung korrekt war und ob sie sich überhaupt gelohnt hat, nicht.

Roboter funktionieren gut im Dunkeln. Menschen nicht. Wenn jede Ecke der Fabrik dunkel ist, Sie die Arbeit nicht sehen und nicht einmal den Schalter finden können, ist das keine Geschwindigkeit. Dort lauert die Gefahr.