Autonomes Coden entwickelt sich von besseren Prompting-Ansätzen hin zu besseren Kontrollsystemen. Der wichtigste Wandel besteht darin, dass Ingenieure lernen, Agenten mit Zielen, Evaluatoren, Schleifen und Artefakten zu umgeben, die es ihnen ermöglichen, weiterzuarbeiten, nachdem der Mensch aufgehört hat, einzugreifen.
Das ist entscheidend, weil ernsthafte Entwicklungsarbeit meist über lange Zeiträume stattfindet: unklare Anforderungen, versteckte Einschränkungen, partielle Fehlschläge, sich ändernde Kontexte und wiederholte Überprüfungen. Die neue Grenze besteht darin, das System so um den Agenten herum zu gestalten, dass er planen, ausführen, seine Arbeit überprüfen, Fehler beheben und Fortschritte erzielen kann – ohne ständige menschliche Steuerung.
Dieser Beitrag basiert auf einer DAIR.AI Academy Session über autonome langlaufende Coding-Agenten, in der ich Claude Codes /goal-Modus, den neueren /loop-Befehl, Verifizierer, Artefakte und Orchestrierungsmuster in der Praxis vorgestellt habe. Erstellt in Zusammenarbeit mit Codex und Claude Code.
Vom Prompting zum Goal-Design
Die Kernidee hinter Funktionen wie Claude Codes /goal ist einfach: Ein Coding-Agent bleibt der Ausführende, aber der Mensch interagiert nicht mehr im Ping-Pong-Stil mit ihm. Stattdessen spezifiziert der Mensch den gewünschten Endzustand, die erforderlichen Nachweise für den Erfolg, die unbedingt einzuhaltenden Einschränkungen und, wo möglich, die Anzahl der Iterationen und das Budget.
Dieses Ziel (Goal) fungiert eher wie ein Vertrag als wie ein längerer Prompt. Ein schwaches Ziel gibt dem Modell Raum, vorzeitig abzubrechen, Abkürzungen zu nehmen oder Erfolg so umzudefinieren, dass es im Transkript plausibel wirkt, im realen System aber scheitert. Ein starkes Ziel hingegen gibt dem Agenten eine Messlatte, an der er sich immer wieder messen kann.
Ingenieursverstand ist hier weiterhin gefragt. Die besten Goals kodieren Domänenwissen, das das Modell sonst nur erraten würde. Für ein Forschungsexperiment könnte das ein bestimmter Benchmark-Score, eine zurückgehaltene Evaluierung, eine erforderliche Loss-Kurve und die Regel sein, dass das Ergebnis eine anfängliche Baseline übertreffen muss. Für eine UI-Aufgabe könnte es eine Screenshot-Referenz, konkrete Layout-Vorgaben und einen Browser-Verifizierungsschritt bedeuten. Das Modell kann ausführen, aber der Mensch definiert weiterhin, was „erledigt“ eigentlich bedeutet.
Der Evaluator wird zur erstklassigen Komponente
Langlaufende Agenten brauchen eine zweite Rolle neben dem Ziel. Dieser Evaluator kann ein weiterer Coding-Agent, ein LLM-as-Judge, ein Skript, eine Testsuite, ein Benchmark-Harness oder eine Mischung aus alledem sein. Die entscheidende Designentscheidung ist die Abstimmung des Evaluators auf die Aufgabe. Wenn Erfolg klar definiert ist, sind deterministische Prüfungen besser. Typüberprüfungen, Unit-Tests, Lint-Regeln, Integrationstests und Benchmark-Skripte sollten verwendet werden, wann immer sie die Bedingung eindeutig ausdrücken können.
Wenn Erfolg unscharf ist, wird ein Agent-Evaluator nützlich. Ein Skript kann sagen, ob Tests bestanden werden, aber es kann nicht einfach entscheiden, ob ein generierter Forschungsbericht kohärent ist, ob eine Implementierung einem Paper treu folgt oder ob eine UI einer Designabsicht entspricht. Hier profitiert der Evaluator von Sprachverständnis, Urteilsvermögen und manchmal auch von Bilderkennung.
Das praktische Muster verwendet deterministische Prüfungen als Basis und die Agentenbewertung als übergeordnete Kontrolle. Diese Kombination reduziert halluzinierte Erfolgsmeldungen, während sie gleichzeitig Autonomie bei Aufgaben ermöglicht, die sich nicht sauber in eine Test-Assertion einfügen lassen.
Verifizierer definieren die Vertrauensgrenze
Der tiefere Punkt ist, dass Autonomie nur funktioniert, wenn das System einen zuverlässigen Verifizierer hat. Ein Coding-Agent kann einen Plan erstellen, eine Funktion implementieren und erklären, warum er glaubt, dass die Arbeit abgeschlossen ist – aber diese Erklärung sollte nicht als Beweis gewertet werden. Beweise kommen von einer externen Prüfung, die der Agent nicht einfach umgehen kann.
Für Code kann der Verifizierer eine Testsuite, ein Typprüfer, ein Benchmark, ein Browserlauf, ein Screenshot-Vergleich oder ein reproduzierbares Skript sein. Für Forschungsarbeit könnte es eine zurückgehaltene Evaluierung, eine reproduzierte Tabelle, eine Loss-Kurve oder ein Benchmark-Score sein, der die Baseline verbessert. Für Designarbeit könnte es ein Referenz-Screenshot plus ein visueller Prüfschritt sein. Der Verifizierer verwandelt einen langlaufenden Agenten von einem selbstbewussten Textgenerator in ein System, dem man mehr Zeit anvertrauen kann.
Die meisten Abkürzungen treten an dieser Grenze auf. Ist der Verifizierer vage, wird das Modell oft die einfachste Interpretation der Aufgabe erfüllen. Ist der Verifizierer zu eng gefasst, könnte das Modell darauf überoptimieren und die breitere Absicht verfehlen. Ein guter autonomer Workflow benötigt daher abgestufte Verifikation: billige deterministische Prüfungen fangen grundlegende Fehler ab, und eine übergeordnete Überprüfung kümmert sich um urteilsintensive Fehler. Einige der fortschrittlichsten Modelle können bereits ein gewisses Maß an Verifikation leisten, aber basierend auf meiner Forschung gibt es noch ein deutliches OOD-Problem: Fällt die dem Agenten zugewiesene Verifikationsaufgabe außerhalb der Trainingsverteilung, tun sich Modelle schwer.
Verifizierer sind noch ein offenes Forschungsfeld, aber ich erwarte, dass mehr Unternehmen beginnen werden, massiv in diesen Bereich zu investieren. Auch das Konzept von feinabgestimmten Verifizierern ist in Unternehmen stark gefragt.
Schleifen machen Autonomie dauerhaft
Ein Ziel gibt dem Agenten eine Richtung, aber eine Schleife (Loop) hält die Arbeit am Laufen. Diese Unterscheidung ist wichtig, weil Modelle oft aufhören, bevor die eigentliche Aufgabe erledigt ist. Sie erreichen vielleicht ein Iterationslimit, verlieren das Vertrauen, erschöpfen den Kontext oder entscheiden, dass eine Teillösung ausreicht.
Die Schleife ist das äußere Kontrollsystem. Sie wacht auf, prüft den Fortschritt, führt Kontrollen durch, vergleicht das Ergebnis mit dem Ziel und schickt den Agenten mit der nächsten Anweisung wieder los, wenn das Ziel nicht erreicht wurde. In seiner einfachsten Form ist dies das Ralph-Loop-Muster mit einem Coding-Agenten und einer deterministischen Bedingung. In einer flexibleren Form enthält die Schleife einen Evaluator-Agenten, der den Fortschritt beurteilen und entscheiden kann, was als Nächstes passieren soll.
Langlaufende Autonomie funktioniert als wiederholter Einsatz unter Aufsicht einer Kontrollebene, nicht als ein einziger kontinuierlicher Akt der Intelligenz. Der Agent kann immer noch scheitern, aber die Schleife gibt dem System die Möglichkeit, das Scheitern zu bemerken und weiterzumachen, anstatt stillschweigend den Sieg zu erklären.
Planung ist, wo Expertise ins Spiel kommt
Eines der stärksten Themen der Session war, dass Planung entscheidend bleibt. Man kann ein fortschrittliches Modell bitten, einen Plan zu erstellen, aber man muss ihn trotzdem prüfen, Annahmen hinterfragen und die Erfolgskriterien schärfen, bevor man die Aufgabe einer autonomen Schleife übergibt.
Dies führt zu einer sinnvollen Arbeitsteilung. Ein stärkeres Planungsmodell kann helfen, das Ziel zu definieren, fehlende Einschränkungen zu identifizieren und die Evaluierung zu strukturieren. Ein anderes Ausführungsmodell kann dann die Implementierung übernehmen, sobald der Plan klar ist. In der Praxis bedeutet das, dass Ingenieure aufhören sollten, „das Modell“ als eine einzige Wahl zu betrachten. Die Modellwahl wird zu einer Architekturentscheidung.
Manche Modelle sind bessere Planer. Manche sind bessere Ausführer. Manche sind günstigere Evaluatoren. Manche sind besser bei visuellen Überprüfungen. Ein guter Orchestrator ermöglicht es, diese Rollen auszutauschen, anstatt darauf zu warten, dass ein Anbieter die perfekte Coding-Agenten-Schnittstelle bereitstellt.
Visuelle Artefakte werden zu Steuerungsoberflächen
Terminal-Transkripte skalieren nicht, wenn viele Agenten gleichzeitig laufen. Sobald mehrere Sitzungen parallel arbeiten, wird Rohtext zu einer schlechten Schnittstelle, um den Fortschritt zu verstehen.
Live-Artefakte sind wichtig, weil ein Dashboard mit Loss-Kurven, Benchmark-Scores, Aufgabenstatus, Screenshots, Kostenschätzungen und letzten Entscheidungen dem Menschen eine viel bessere Möglichkeit gibt, die Autonomie zu überwachen. Das Artefakt wird zur Steuerungsoberfläche für die Entscheidung, wann eingegriffen werden muss – und nicht zu einem Bericht, der im Nachhinein erstellt wird.
Das nützlichste Muster ist die Trennung von Speicherung und Präsentation. Markdown oder ein Vault können dauerhafte Beweise, Logs, Notizen, Pläne und Ergebnisse speichern. HTML-Artefakte können diesen Zustand in etwas Visuelles und Interaktives umwandeln. Der Agent kann das Markdown durchsuchen, während der Mensch das Artefakt überwachen kann.
Für UI- und Produktarbeit sind visuelle Hinweise besonders mächtig. Ein Screenshot-Referenz kann Designabsichten präziser vermitteln als Prosa, und ein visionsfähiger Evaluator kann die Implementierung mit dieser Referenz vergleichen. Dies reduziert das häufige Fehlerbild, bei dem der Agent die angeforderte Komponente technisch implementiert, aber Abstände, Hierarchie, Ausrichtung oder das Produktgefühl verfehlt.
Session Mining verwandelt Nutzung in Gedächtnis
Eine weitere wichtige Erkenntnis ist, dass vergangene Agenten-Sitzungen eine reichhaltige Quelle von Workflow-Daten sind. Wenn ein Agent immer wieder auf die gleiche Weise scheitert, vergisst, die gleiche Prüfung durchzuführen, den falschen Pfad verwendet oder denselben kaputten Befehl wiederholt, sollte dieses Muster nicht in Logs vergraben bleiben.
Session Mining verwandelt diese Transkripte in Betriebsregeln. Ein Agent kann die letzten dreißig Tage Arbeit scannen, wiederkehrende Fehlermodi finden und Aktualisierungen für Projektanweisungen, Vault-Learnings oder Agentenregeln vorschlagen. So kann ein Team seine Umgebung schrittweise verbessern, ohne sich manuell an jeden Fehler erinnern zu müssen.
Das Ziel ist es, die lokale Umgebung intelligenter zu machen, ohne ein Modell von Grund auf zu trainieren. Eine kleine Regel in einer Agent-Anweisungsdatei kann wiederholte Fehler in zukünftigen Sitzungen verhindern, besonders wenn die Regel projektspezifisch ist.
Ein praktisches Betriebsmodell
Für KI-Ingenieure sieht der entstehende Workflow so aus:
- Beginnen Sie mit einer kleinen, günstigen Teilmenge, bevor Sie den vollständigen autonomen Lauf starten.
- Schreiben Sie ein Ziel mit messbaren Erfolgskriterien, expliziten Einschränkungen und (wo möglich) einem Iterations- oder Zeitbudget.
- Trennen Sie den Ausführenden vom Evaluator, sodass Implementierung und Beurteilung nicht in einer Rolle zusammengefasst werden.
- Definieren Sie externe Verifizierer, bevor die langlaufende Schleife startet.
- Verwenden Sie deterministische Prüfungen wo immer möglich und fügen Sie dann Agenten-Review für unscharfe Kriterien hinzu.
- Fordern Sie Nachweisartefakte wie Logs, Screenshots, Benchmark-Kurven oder geänderte Dateien an.
- Analysieren Sie vergangene Sitzungen und überführen Sie wiederkehrende Lektionen in Projektanweisungen.
Das ist der Unterschied zwischen der Nutzung eines Coding-Agenten und der Entwicklung eines autonomen Codierungssystems. Eins gibt Ihnen ein Gespräch. Das andere gibt Ihnen ein Geschirr (Harness).
Was immer noch schiefgeht
Nichts davon beseitigt die schwierigen Probleme. Agenten nehmen immer noch Abkürzungen. Sie hören immer noch zu früh auf. Sie überschätzen immer noch den Fortschritt. Sie erstellen immer noch zuversichtliche, aber schwache Pläne, besonders bei neueren Papern, unbekannten Benchmarks oder Systemen außerhalb ihrer Trainingsverteilung.
Ihnen mehr zu vertrauen, wird das nicht lösen. Bessere Kontrollsysteme werden es. Ziele, Schleifen, Evaluatoren, deterministische Prüfungen, visuelle Artefakte und Sitzungsspeicher sind alles Wege, um Autonomie beobachtbar und korrigierbar zu machen.
Die Richtung ist klar. Die Zukunft von Coding-Agenten hängt von einer besseren Orchestrierung leistungsfähigerer Modelle ab, bei der Ingenieure die Bedingungen entwerfen, unter denen Agenten sicher stunden- oder tagelang laufen können und dennoch überprüfbare Arbeit abliefern.
