Drei Ideen aus Agenten-News, als Prüfungen umgesetzt: was wir in unser Harness übernommen und was wir weggelassen haben

In einer Woche gingen drei Ideen über KI-Agenten durch jeden Kanal, den ich lese. Karpathy schlug vor, ein Modell wie ein Flugzeughandbuch schreiben zu lassen. Google Research veröffentlichte Harness², ein Framework, das alles um das Modell herum verbessert statt das Modell selbst. Die Ingenieure von OpenAI beschrieben, wie sie mit einem Agenten in zwei Wochen 800.000 Zeilen toten Code entfernt haben. Alle drei sind gut. Alle drei kommen auch in der Form „füge eine magische Zeile zu deinem Prompt hinzu“, und ein Prompt ist genau das, was beim nächsten Aufruf driftet. Deshalb haben wir sie in unsere offene Konfiguration, github.com/AnastasiyaW/codex-claude-code-config, als Prüfungen übernommen. Hier steht, was wir behalten und was wir verworfen haben und warum.

Das Flugzeughandbuch: zwei Regeln von neunzig

Der Standard ist ASD-STE100, Simplified Technical English. Die Luftfahrt nutzt ihn, damit ein Mechaniker in jeder Anweisung dieselbe Bedeutung liest. Am 2. Oktober ordnete Karpathy Wege, die Ausgabe eines Modells leichter lesbar zu machen. Text in diesem Stil kommt zuerst, dann ein Diagramm, dann eine interaktive HTML-Seite, dann ein eigens erstelltes Erklärvideo. Diese Leiter ist für sich nützlich. Die meisten Antworten brauchen die erste Sprosse, eine Architekturänderung braucht die zweite, und ein Vergleich mit vielen Zahlen verdient die dritte.

Die Zeile „schreib in striktem STE100“ ist schwächer, als sie aussieht. Der vollständige Standard hat ein kontrolliertes Wörterbuch von rund 900 Wörtern und Dutzende Regeln. Das Wörterbuch ist urheberrechtlich geschützt, und Modelle kennen es nicht zuverlässig. Verlangst du strikte Konformität, bekommst du eine Imitation: zerhackte Sätze, nicht den Standard.

Zwei Regeln tragen den größten Teil des Nutzens und brauchen kein Wörterbuch:

• Ein Begriff pro Konzept. Sagt das Projekt „worker“, sagt jeder Satz „worker“. Modelle lieben Synonyme zur Abwechslung. Ein technischer Leser muss dann herausfinden, ob „worker“, „handler“ und „executor“ drei Dinge oder eines sind.
• Kurze Sätze. STE begrenzt Anweisungen auf 20 Wörter und Beschreibungen auf 25.

Wir haben beide mechanisch gemacht. scripts/term_drift_check.py nimmt das Projektglossar und prüft, was der Agent geschrieben hat. Ein Glossareintrag wie обработчик* erfasst jede Form des Wortes, sodass die Prüfung auch auf Russisch funktioniert. Die vorhandenen STE-Linter tun das nicht, weil der Standard selbst für Englisch gedacht ist. Codeblöcke, Links und Kommentare werden übersprungen. Der Exitcode ist 0 für sauber, 1 für Befunde und 2, wenn die Prüfung nicht laufen konnte. Den dritten Zustand brauchen wir, weil eine Prüfung, die still nichts geprüft hat, schlechter ist als gar keine Prüfung.

Die erste Version hatte genau dieses Problem. Ein unabhängiger Prüfer, ein separater Agent mit frischem Kontext, fand drei Wege, ein grünes Ergebnis zu bekommen, ohne etwas zu prüfen. Text in einer Nicht-UTF-8-Kodierung, ein nicht geschlossener Codeblock und ein Glossar ohne Synonyme kamen alle sauber durch. Ein zweiter Prüfer fand fünf weitere. Alle sind behoben, und der Selbsttest enthält jetzt Fälle, die fehlschlagen müssen, damit ein kaputter Detektor nicht leise besteht.

Harness²: die Methode ja, der automatische Patcher nein

Die Idee hinter Harness² ist stark. Die Modellgewichte bleiben fest. Der Agent schlägt Änderungen an seiner Umgebung vor: Systemprompt, Memory, Werkzeughinweise, Skills, Skripte, Plug-ins. Er führt sie bei der Aufgabe aus, behält, was half, und merkt sich die Lehre für das nächste Mal. Auf drei Benchmarks für professionelle Arbeit hob eine Runde davon die Werte von GLM-5 und Gemini 3.5 Flash um bis zu 11,5 Punkte.

Wir haben es nicht unverändert installiert. Im README läuft sein Ausführer mit offenem Netz und abgeschalteter Codex-Sandbox, und es gibt kein Protokoll für zurückgehaltene Aufgaben. Für einen Agenten, der seine eigenen Regeln bearbeitet, ist das das Hauptrisiko: Er verbessert sich bei den Aufgaben, die er gesehen hat, und macht still die kaputt, die er nicht gesehen hat.

Deshalb haben wir die Methode als kleinen Pilotversuch mit harten Grenzen übernommen:

• eine eingefrorene Menge von drei bis fünf Aufgaben, plus mindestens eine zurückgehaltene Aufgabe, auf die die Änderung nicht abgestimmt wurde;
• eine Änderung pro Kandidat, damit die Ursache offensichtlich ist;
• mechanische Belege pro Aufgabe, keine Meinung über das Ergebnis;
• ein Kandidat gewinnt nur mit einer strikten Verbesserung und ohne Rückschritt bei Sicherheit oder bei der zurückgehaltenen Aufgabe;
• Live-Hooks, Berechtigungen und Leitplanken sind nie das Ziel des Pilotversuchs.

Der Vergleicher liest zwei Belege und schreibt ein Urteil. Er startet keine Agenten und fasst die laufende Konfiguration nicht an. Ein angenommenes Ergebnis ist ein Beleg für ein Review, keine Auslieferung.

Dead Code: der Beleg kommt aus der Produktion

Die Zahlen von OpenAI sind beeindruckend. Über 1.400 zusammengeführte PRs und über 800.000 gelöschte Zeilen in etwa zwei Wochen. Ein Container-Image wurde um 48 % kleiner, und die mediane CI-Zeit sank von etwa zehn auf viereinhalb Minuten. Die Prompts haben das nicht bewirkt. Der Prozess hat es bewirkt.

Code zu löschen ist eine besondere Art von Änderung. Nichts schlägt fehl, wenn unerreichbarer Code verschwindet. Ebenso schlägt nichts fehl, wenn du dich darin irrst, dass er unerreichbar ist, bis die Produktion ausfällt. Der Beleg muss deshalb aus der Produktion kommen: Telemetrie, der aktive Flag-Zustand, jede Aufrufstelle, auch indirekte, der Verantwortliche. Das Audit ist nur lesend. Jede Entfernung ist ein kleiner Entwurfs-PR mit dem Beleg und der Begründung in der Beschreibung. Killswitches und Sicherungen werden nie auf das Wort des Agenten hin entfernt.

Wir haben das als Verweis in den Skill refactoring-safely aufgenommen. Der Skill greift jetzt auch, wenn jemand nach dem Entfernen von totem Code oder veralteten Feature-Flags fragt.

Kommentare im Code: die Forschung sagt etwas leicht anderes

Gleichzeitig wollte ich eine Idee prüfen, nach der wir ohnehin handeln: Wenn Agenten den Code schreiben und lesen, verschwenden die meisten Kommentare nur Kontext. Seit dem 15. Oktober gilt bei uns diese Regel, und ich habe nach Forschung dazu gesucht. Die Antwort war interessanter als „Kommentare sind Rauschen“.

• Veraltete Kommentare ziehen generierten Code zur alten Implementierung zurück.
• Modelle können einem Kommentar mehr trauen als dem Code, dem er widerspricht.
• Ein fehlender Kommentar spielte in den Studien, die ich fand, kaum eine Rolle.
• Ein korrekter Kommentar zu nicht offensichtlichem Code half: In einer Studie zu Legacy-Mainframe-Code stieg die Genauigkeit von etwa 84 % auf 90–96 %.

Die Stichproben sind klein, und zwei der Arbeiten habe ich nur als Abstract gelesen, deshalb würde ich die genauen Zahlen vorsichtig behandeln. Die Richtung ist aber klar: Ein Kommentar, der lügt, ist gefährlicher als ein Kommentar, der fehlt. Also haben wir der Regel eine Anforderung hinzugefügt. Wer den Code ändert, ändert oder löscht im selben Commit auch den Kommentar daneben. Den Code nur nachzuerzählen fliegt raus. Der Grund, die Herkunft einer Zahl und die Falle, die der nächste Agent sonst „reparieren“ würde, bleiben.

Was jetzt im Repository liegt

• docs/output-legibility.md: die Lesbarkeitsleiter und die zwei Regeln, mit einer Prompt-Zeile, die besser funktioniert als „schreib in STE100“;
• scripts/term_drift_check.py: die Glossarprüfung, mit Tests und einem Selbsttest;
• docs/harness-improvement-pilot.md und sein Vergleicher: der begrenzte Pilotversuch;
• references/dead-code-sweep.md im Skill refactoring-safely;
• die aktualisierte Kommentarregel in rules/quality-code.md.

Alles steht im Release v2026.10.24, und die vollständige Liste der Änderungen steht in UPDATES.md. Ein Agent kann sich direkt aus dem Repository nehmen, was er braucht: Beginne mit CLAUDE.md und README.md, dann die Skills, die in skills-lock.json aufgeführt sind.

Wenn dir etwas davon einen Tag Arbeit spart, hilft ein Stern auf GitHub, dass andere das Repository finden. Wenn etwas kaputtgeht, eröffne ein Issue: Daher stammen die meisten unserer Regeln ursprünglich.