Was ist passiert?
Ein neuer Vorabdruck, der am 11. August veröffentlicht wurde, bezeichnet einen beobachteten Fehlermodus in Repositories für die Agentencodierung als „katastrophales Erinnern“: Projektanweisungsdateien häufen ständig Regeln an, weil das Hinzufügen einer Vorsichtsmaßnahme kostengünstig ist, während das sichere Löschen einer alten Regel schwieriger wird, wenn ihre ursprüngliche Begründung verschwindet.
Die Forscher sammelten 247.694 Befehlslebensdauern und 299.440 Commit-zu-Commit-Übergänge aus 1.867 öffentlichen Repositories, die Dateien wie CLAUDE.md enthielten. Sie verfolgten einzelne Anweisungen durch Bearbeitungen und berichten, dass die Dateien im Laufe ihrer beobachteten Lebensdauer um 226 % wuchsen, was durchschnittlich 4,9 Nettoanweisungen pro modifizierendem Commit hinzufügte. Die Studie betrachtet diese Zahlen als Beweis für eine anhaltende Anhäufung in ihrer Stichprobe und nicht als Beweis dafür, dass jede Anweisung unnötig war oder dass sich alle Agenten-Codierungsprojekte gleich verhalten.
Der zentrale Mechanismus des Papiers ist die asymmetrische Evidenz. Ein Betreuer oder Coding-Agent kann nach einem Fehler eine neue Anweisung anhängen, ohne jede Interaktion zwischen den bereits vorhandenen Regeln zu rekonstruieren. Eine spätere Löschung ist riskanter: Sobald der motivierende Fehler und der umgebende Kontext verschwunden sind, muss beim Entfernen einer Richtlinie möglicherweise überprüft werden, ob eine Regression unter vielen Kombinationen der verbleibenden Anweisungen immer noch verhindert wird. In den Repository-Daten sank die geschätzte Löschgefahr mit zunehmendem Alter einer Anweisung, mit einem gemeldeten Log-Hazard-Gefälle von -0,032 pro Commit.
Um eine mögliche Abhilfe zu testen, erstellten die Autoren Aufgaben zur Befolgung von Anweisungen, indem sie IFEval-Einschränkungen umkehrten, und verglichen dann Eingabeaufforderungen, die einfache Regeln enthielten, mit Eingabeaufforderungen, die auch kurze Kommentare enthielten, die erklärten, warum jede Regel existierte. In ihrem kontrollierten Setup sammelten unkommentierte Eingabeaufforderungen einen Überschuss von 211,3 % an Anweisungen, während kommentierte Eingabeaufforderungen mit einem Überschuss von 1,4 % endeten. Bei den Kommentaren handelte es sich nicht um zusätzliche Befehle für das Modell; Es handelte sich um kompakte Provenienzen, die spätere Entfernungsentscheidungen überprüfbar machen sollten.
Das Team bewertete außerdem, ob kleinere, besser dokumentierte Eingabeaufforderungen den Agenten dabei halfen, den Anweisungen zu folgen. Auf dem von WildIFEval abgeleiteten Benchmark meldet das Papier Gewinne von bis zu 23,1 Prozentpunkten, wenn Begründungen beibehalten und veraltete Regeln entfernt werden konnten. Bei diesen Ergebnissen handelt es sich um Behauptungen aus einem neu veröffentlichten, nicht von Experten begutachteten Vorabdruck. Die Arbeit beweist nicht, dass Kommentare allein jeden Codierungsagenten, jedes Repository, jede Sprache oder jeden Produktionsworkflow verbessern.
Lesen Sie die Primärquelle: Catastrophic remembering research paper on arXiv ↗
Warum es wichtig ist
Befehlsdateien auf Repository-Ebene werden zum dauerhaften Betriebsspeicher für Codierungsagenten, sodass unkontrolliertes Wachstum die Token-Kosten erhöhen, veraltete Einschränkungen beibehalten und die Regeln für automatisierte Codeänderungen für Benutzer schwieriger verständlich machen kann.
Das praktische Risiko besteht nicht nur in einer langen Datei. Jede Anweisung konkurriert um die Aufmerksamkeit eines Modells und kann mit neueren Regeln, Werkzeugbeschreibungen, Codekontext und der Anfrage des Benutzers interagieren. Eine Anweisung, die geschrieben wurde, um einen historischen Fehler zu verhindern, kann nach Änderungen der Codebasis irrelevant werden, mit einer neueren Richtlinie in Konflikt geraten oder nicht verwandte Arbeiten zu stark einschränken. Wenn niemand rekonstruieren kann, warum es existiert, besteht die sicherste lokale Wahl oft darin, es beizubehalten, wodurch die Bereinigungskosten auf zukünftige Commits verlagert werden.
Dieses Muster ist über CLAUDE.md hinaus von Bedeutung. Teams speichern zunehmend Konventionen, Sicherheitsgrenzen, Testbefehle, Architekturentscheidungen und Einsatzwarnungen in maschinenlesbaren Projektleitfäden. Diese Dateien können die Konsistenz verbessern und wiederholte Fehler reduzieren, aber sie werden auch zu einer Governance-Oberfläche: Die Menschen sollten in der Lage sein zu erkennen, wer eine Folgeregel eingeführt hat, welche Beweise sie rechtfertigten und unter welchen Bedingungen sie außer Kraft gesetzt werden konnte. Ein Begründungskommentar ist eine vereinfachte Version dieses Audit-Trails.
Das Ergebnis legt ein nützliches Gestaltungsprinzip für das Agentengedächtnis nahe: Das Erinnern sollte die Bedingungen für das Vergessen einschließen. Anstatt nur „Immer X ausführen“ aufzuzeichnen, kann ein System den beobachteten Fehler, den Umfang der Regel, die relevante Komponente oder den relevanten Test sowie einen Überprüfungsauslöser beibehalten. Dadurch wird das Löschen nicht automatisiert, aber es liefert einem späteren Betreuer Beweise für die Entscheidung, ob die Einschränkung immer noch die Richtigkeit schützt oder lediglich eine alte Umgebung widerspiegelt.
Es gibt auch einen Aspekt des öffentlichen Interesses, da Codierungsagenten mit folgenreicherer Software in Berührung kommen. Gesammelte private Anweisungen können im Stillen Sicherheitsentscheidungen, das Zugriffsverhalten, die Datenverarbeitung oder die Reaktion eines Agenten auf Fehler beeinflussen. Kleinere Dateien sind nicht automatisch sicherer und eine aggressive Bereinigung könnte einen wichtigen Schutz aufheben. Das nützliche Ergebnis ist die Rückverfolgbarkeit: weniger ungeklärte Regeln, explizite Eigentumsverhältnisse und Überprüfungspraktiken, die es Menschen ermöglichen, sowohl Hinzufügungen als auch Löschungen anzufechten.
Was Sie als nächstes sehen sollten
Der nächste Test ist die unabhängige Replikation über Sprachen, Organisationen, Agentenprodukte und langlebigere Repositorys hinweg, gefolgt von prospektiven Versuchen, die messen, ob eine dokumentierte Bereinigung die Codequalität verbessert, ohne wichtige Sicherheitsmaßnahmen zu löschen.
Die Beobachtungsstichprobe unterliegt Auswahlgrenzen. Öffentliche Repositorys, die Agentenanweisungsdateien übertragen, können sich von den Codebasen privater Unternehmen unterscheiden, und der Repository-Verlauf kann nicht jede Diskussion oder jeden Vorfall außerhalb der Plattform offenlegen, der eine Regel motiviert hat. Wachstum kann auch rational sein, wenn ein Projekt erweitert wird. Zukünftige Analysen sollten die nützliche Abdeckung neuer Komponenten von doppelten, widersprüchlichen oder veralteten Anweisungen trennen und berichten, wie die Ergebnisse je nach Alter, Größe, Sprache, Anzahl der Mitwirkenden und Agentenplattform des Repositorys variieren.
Die kontrollierten Experimente benötigen eine umfassendere Validierung. Die Aufgaben wurden aus Benchmarks zur Befolgung von Anweisungen und nicht aus monatelanger Live-Softwarewartung abgeleitet, und die Matching-Pipeline des Papiers wurde anhand einer Stichprobe mit 50 Übergängen überprüft. Ein Autor erstellte die Handanmerkung, die in einem Teil der Validierung verwendet wurde. Die Studie umfasste keine nicht englischsprachigen Anleitungsdateien und berücksichtigte nicht alle Schwellenwerte, anhand derer entschieden wurde, wann eine Änderung als Neufassung und nicht als Fortsetzung einer Anleitung gewertet wurde.
Kommentare können falsche Begründungen genauso gut wiedergeben wie richtige. Teams sollten daher die strukturierte Herkunft anhand von Alternativen wie verknüpften Problemen, fehlgeschlagenen Regressionstests, Ablaufdaten, Eigentumsfeldern oder automatisierten Prüfungen testen, die doppelte und widersprüchliche Anweisungen kennzeichnen. Der sicherste Arbeitsablauf würde Entfernungen vorschlagen, Beweise und betroffene Tests vorlegen und eine Überprüfung auf Regeln mit großer Auswirkung erfordern, anstatt einem Agenten zu erlauben, Anweisungen nur zu bereinigen, um Tokens zu sparen.
Nützliche Folgenachweise würden die End-to-End-Ergebnisse messen: Umfang der Eingabeaufforderung, Einhaltung der Anweisungen, Aufgabenerfolg, Regressionen, Überprüfungszeit und die Anzahl der nach dem Löschen wiederhergestellten Regeln. Forscher sollten auch testen, ob Modelle Begründungskommentare tatsächlich wie beabsichtigt verwenden oder sie manchmal mit zusätzlichen Anforderungen verwechseln. Bis diese Ergebnisse vorliegen, ist das katastrophale Erinnern eine fundierte Beschreibung des Datensatzes und der Experimente der Autoren, kein universelles Gesetz oder ein Grund, ausgereifte Projektleitfäden pauschal zu löschen.
