Es war ein Dienstagabend, und der Agent hatte alles richtig gemacht. Ticket gelesen, die drei relevanten Dateien gefunden, eine Änderung geschrieben, die genau das tat, was in der Beschreibung stand. Typecheck sauber, Tests grün. Dann git push - und ein Fehler in roter Schrift. Das Token, unter dem er lief, hatte Leserechte. Der Branch existierte nur in einem Container, den die Pipeline zwanzig Sekunden später aufräumte.
Die Arbeit war getan. Sie war trotzdem wertlos.
Wir erzählen diese Geschichte inzwischen häufiger, weil sie die Lücke ziemlich genau beschreibt, um die es geht. Zwischen einem Agenten, der in einer Demo beeindruckt, und einem, den du unbeaufsichtigt auf ein Repository loslässt, liegt nicht mehr Intelligenz. Es liegt Infrastruktur dazwischen.
In der Demo bist du der Transportweg
Wenn du einem Modell im Chatfenster eine Aufgabe gibst und es antwortet mit einer sauberen Lösung, dann passiert danach etwas, das niemand mitzählt: Du kopierst den Code in deinen Editor. Du legst die Datei am richtigen Ort an. Du merkst, dass ein Import fehlt, und ergänzt ihn beiläufig. Du führst die Tests aus. Du committest.
Das sind sechs Schritte, die du so selbstverständlich erledigst, dass sie in der Bewertung des Modells nicht auftauchen. Der Eindruck, der hängen bleibt, ist “das Ding kann programmieren”. Was du tatsächlich beobachtet hast, ist ein Vorschlag, den ein Mensch zu Software gemacht hat.
Nimm den Menschen heraus, und die sechs Schritte werden sichtbar. Jeder einzelne davon kann schiefgehen, und keiner davon hat mit Codegenerierung zu tun. Das ist die eigentliche Arbeit: Isolation, Verifikation, ein sauberer Übergabepunkt.
Isolation: ein Ort, an dem der Agent falsch liegen darf
Ein Agent braucht einen eigenen Arbeitsbereich - einen Worktree, einen Branch, einen Container. Nicht in erster Linie, weil er gefährlich wäre. Sondern weil eine halbfertige Änderung in einem geteilten Checkout alle anderen blockiert, und weil du zwei Agenten nicht parallel arbeiten lassen kannst, wenn sie sich dieselben Dateien teilen.
Isolation ist außerdem die Voraussetzung dafür, dass ein Fehlversuch billig ist. Wenn ein Agent in seinem eigenen Worktree eine Änderung schreibt, die nicht durchläuft, wirfst du den Worktree weg. Wenn er das im Hauptverzeichnis tut, räumt jemand hinterher auf. Der Unterschied entscheidet darüber, ob du den Agenten überhaupt laufen lässt, wenn du dir nicht sicher bist.
Verifikation: gegen eine echte Umgebung, nicht gegen ein Diff
Hier wird es interessant, und hier sehen wir die meisten Setups scheitern.
Die naheliegende Prüfung ist: Ein Mensch liest das Diff. Sieht plausibel aus, wird gemergt. Das Problem daran ist grundsätzlich - ein Diff ist die Absichtserklärung des Autors, nicht die Aussage des Systems. Es sagt dir, was jemand ändern wollte. Es sagt dir nicht, was danach passiert.
Wir haben genug Beispiele dafür gesammelt, dass das Muster erkennbar ist. Eine neue Route liegt an der richtigen Stelle im Code, taucht aber nicht im Build auf, weil sie das falsche Dateisuffix trägt - das Diff liest sich einwandfrei, die URL antwortet mit 404. Eine Übersetzung existiert als Datei, aber der Sprachumschalter verlinkt sie nie, weil ein Frontmatter-Feld fehlt. Eine Weiterleitung steht in einer Middleware, die bei einem statischen Build gar nicht erst ausgeführt wird. In allen drei Fällen ist das Diff korrekt in dem Sinne, dass es das enthält, was es enthalten soll. Und in allen drei Fällen ist die Änderung für den Besucher nicht vorhanden.
“Verifiziert” heißt deshalb bei uns: Jemand hat das laufende System gefragt. Nicht den Quelltext, das System. Die URL aufrufen und den Statuscode ansehen. Ins gerenderte HTML schauen, ob der Link tatsächlich in der Seite steht. Den Build starten und prüfen, ob die Datei in dist/ liegt.
Das ist etwas anderes als Review. Review fragt: Ist das guter Code? Verifikation fragt: Existiert das in der Welt? Beide sind nötig, und sie sind nicht austauschbar. Eine Karte kann zweimal als erledigt geschlossen werden und trotzdem nicht erledigt sein, weil beide Male nur die erste Frage gestellt wurde.
Der Fall, der uns am meisten beigebracht hat, ist der schon deployte: Die Änderung ist gemergt, die Pipeline ist grün, das Feature ist live. Was heißt “verifiziert” jetzt noch? Nicht “das Diff war in Ordnung” - das war es schon vor dem Merge. Es heißt: Die deployte Instanz zeigt das Verhalten, das im Ticket beschrieben war. Wer das nicht trennt, korrigiert am Ende einen Code-Stand, während der Fehler auf dem Server unverändert weiterläuft.
Der Übergabepunkt
Am Ende steht ein Mensch, und der Übergang zu ihm ist selbst ein Produkt.
Ein Agent, der einen Pull Request mit dem Titel “Fix” und dem Text “done” hinterlässt, hat keine Zeit gespart. Er hat sie verschoben - vom Schreiben zum Rekonstruieren, und Rekonstruieren ist die teurere Tätigkeit. Was wir stattdessen verlangen: was geändert wurde und warum, mit Bezug auf das Ticket. Die Testausgabe, die zeigt, dass die Änderung abgedeckt ist. Und ein Absatz darüber, was ein Reviewer sich genauer ansehen sollte, inklusive dessen, was nicht funktioniert hat.
Der letzte Punkt ist der wichtigste und der, den Agenten am seltensten von allein liefern. Ein Agent, der einen Teil der Aufgabe nicht geschafft hat und das offen sagt, ist brauchbar. Einer, der es verschweigt, kostet dich mehr, als wenn er gar nicht gelaufen wäre - weil du ihm beim nächsten Mal nichts mehr glauben kannst.
Wo die Arbeit heute liegt
Codegenerierung ist der Teil, der inzwischen weitgehend gelöst ist. Sie ist gut, sie wird besser, und sie ist keine Differenzierung mehr.
Der Rest ist es. Ein Agent, der in Isolation arbeitet, gegen eine echte Umgebung verifiziert und sauber an einen Menschen übergibt, liefert Software. Einer ohne diese Schleife liefert Vorschläge - manchmal exzellente, und trotzdem nur Vorschläge. Der Unterschied ist kein Modell. Er ist die Schleife drumherum, und die musst du bauen.
