Der Aufbau
Unser Coding-Agent hat eine Betriebsart, in der er seinen eigenen Quelltext bearbeitet. Er sucht eine Schwachstelle, ändert den Code und startet die Tests, die zur Änderung gehören. Bestehen sie, übernimmt das Gerüst die Änderung, und der nächste Durchgang baut darauf auf. Schlägt ein Test fehl, verwirft das Gerüst die Änderung. Ändert der Agent nichts, vermerkt das Protokoll den Durchgang als leer und zählt ihn nicht als Erfolg.
Im September 2026 lief diese Betriebsart mit Qwen3.8-27B in der vierbittigen NVFP4-Fassung, unter vLLM auf einer RTX 5090. Das Kontextfenster fasste damals 32.768 Token, und das Modell schrieb rund 24 Token pro Sekunde. Keine Anfrage verließ die eigene Karte; das Kostenjournal weist für alle Läufe null aus, Strom und Karte nicht gerechnet.
Die Läufe
| Lauf | Ergebnis | Dauer |
|---|---|---|
| Durchgang 1 | übernommen: die erste vom Agenten geschriebene Änderung, zwei Dateien | 119 s |
| Durchgang 2 | übernommen: Schutz vor leerem Suchtext in den Bearbeitungswerkzeugen, mit Tests | 198 s |
| 60 Minuten, 16 Durchgänge | 13 übernommen, 2 ohne Änderung, 1 verworfen | 13 bis 542 s je Durchgang |
| Lauf nach einer Korrektur am Gerüst | verweigert: Der Arbeitsstand war veraltet | — |
| 4 weitere Durchgänge | 2 übernommen, 2 ohne Änderung | 10 bis 117 s |
Der Versuch ist die Stunde mit 16 Durchgängen; die Zeilen davor und danach zeigen Vorlauf und Nachlauf. Die 13 übernommenen Durchgänge brachten rund 248 neue Zeilen, davon etwa 190 Zeilen Tests. Der verworfene Durchgang ließ einen bestehenden Test scheitern, und das Gerüst rollte ihn zurück, ohne dass jemand eingriff.
Was der Agent an sich verbessert hat
Der Agent überarbeitete vor allem Fehlermeldungen, aus denen er selbst den nächsten Schritt ableitet. Ein Anbieterfehler trennt seitdem „zu viele Anfragen“ von „Server gestört“, weil der erste Fall Warten verlangt und der zweite einen neuen Versuch. Die Suche sagt bei einem fehlerhaften regulären Ausdruck, was daran falsch ist. Fehlt die Datei, die gelesen werden soll, gibt die Meldung einen weiterführenden Hinweis. Trifft das Auflisten eines Verzeichnisses auf eine Datei, verweist die Meldung an das Lesewerkzeug. Jede dieser Änderungen sicherte der Agent mit einem Test, der den alten Fehler festhält.
Ein Entwickler schreibt solche Meldungen um, nachdem ihn dieselbe unklare Ausgabe dreimal aufgehalten hat. Hier fand das Modell die Stellen selbst, änderte sie und schrieb die Tests dazu, ohne dass eine Anfrage das Haus verließ.
Drei Fehler im Gerüst
Der Lauf legte drei Fehler offen, und keiner lag am Modell. Alle drei steckten im Gerüst, dem Programm um das Modell, das Werkzeuge ausführt, Tests startet und Änderungen verwaltet.
Der erste war ein Überlauf. Zweimal lehnte der Server eine Anfrage ab, weil sie 32.769 Token umfasste und 32.768 erlaubt waren. Das Gerüst verdichtete den Verlauf erst nach dem Absenden und nahm die jüngste Ausgabe davon aus, sodass eine einzige Testausgabe von rund 14.000 Token das Fenster sprengte. Seitdem kennt die Kontextverwaltung die harte Grenze und kürzt im Notfall auch große Ausgaben im geschützten Bereich, nur nie die neueste. Im letzten Lauf trat der Fehler nicht mehr auf; die Einzelheiten beschreibt Kontext, der nicht überläuft.
Der zweite traf das Übernehmen. Ein bestandener Durchgang erreichte den Hauptzweig nicht, weil das Gerüst einen Zweig mit sich selbst zusammenführen wollte und über nicht eingecheckte Reste stolperte. Die fertige Änderung blieb neben dem Hauptzweig liegen.
Der dritte steckte im Projektgedächtnis. Die Datei mit den Projektnotizen war auf rund 30 Kilobyte gewachsen, und das Gerüst lud sie bei jedem Start vollständig in ein Fenster von 32.768 Token. Jetzt begrenzt es sie auf 8.000 Zeichen.
Auch die Zeile „verweigert“ in der Tabelle geht auf das Gerüst zurück. Nach der Korrektur des Überlaufs startete es den nächsten Lauf nicht, weil seine Arbeitskopie den neuen Code noch nicht enthielt. Das Protokoll hielt den Abbruch fest, und vor dem letzten Lauf war der Fehler behoben.
Grenzen
Die volle Testsuite braucht gut fünf Minuten und hätte, in jedem Durchgang gestartet, die Stunde aufgezehrt. Je Durchgang liefen deshalb nur die gezielten Tests, und die volle Suite lief auf dem Endstand, mit 1.785 bestandenen Tests. Bricht eine Änderung einen Test außerhalb ihres Umfelds, fällt das erst dann auf. Gemessen haben wir am eigenen Projekt des Agenten, das er gut kennt und dessen dichte Testsuite jede Änderung prüft. Einem fremden Projekt ohne Tests fehlt diese Prüfung, und die Zahl der übernommenen Durchgänge sagt dann nichts. Die Änderungen waren klein; ob dieselbe Schleife größere Umbauten trägt, haben wir nicht gemessen. Seit diesem Lauf arbeitet dieselbe Karte mit größerem Fenster und schneller, wie der Artikel zum spekulativen Dekodieren zeigt.