Anthropic hat den System-Prompt von Claude Code um 80 Prozent reduziert. Context Engineering ist nicht mehr die Kunst des Hinzufügens, sondern des Weglassens. Wer in den letzten Monaten AGENTS.md-Dateien befüllt hat, sollte prüfen, ob sie den Agenten inzwischen behindern.
Jina Yoon beschreibt auf dem PostHog-Blog genau diesen Umschwung. Früher ging es darum, fehlendes Wissen in den Kontext zu packen, weil die Modelle bestimmte Dinge nicht wussten. Inzwischen sind die Modelle besser, und derselbe Kontext bremst sie. Beispiel: Ein Onboarding-Wizard landete in Monorepos oft im falschen Projekt, weil die Skripte standardmäßig auf das Root-Verzeichnis zeigten. Das Modell erkannte die Struktur längst selbst; die explizite Anweisung erzeugte nur Fehler.
Der Wandel: Vom Anreichern zum Ausdünnen
Context Engineering hat sein Ziel verändert. Früher galt: mehr relevante Informationen, besserer Agent. Heute gilt das Gegenteil. Zu viel Kontext senkt die Entscheidungsqualität. Anthropic hat den System-Prompt von Claude Code deshalb um 80 Prozent reduziert. Labs raten von übermäßigen Regeln und Wiederholungen ab – sie setzen auf Urteilsfähigkeit, klare Schnittstellen und progressive Gewöhnung.
Für deine Arbeit heißt das: Eine AGENTS.md, die du mühsam aufgebaut hast, kann dich inzwischen ausbremsen. Boris Cherny, der Schöpfer von Claude Code, empfiehlt, die eigene CLAUDE.md alle sechs Monate komplett zu löschen. Der Entwickler Theo berichtet, dass sich das handschriftliche Neuschreiben seiner AGENTS.md gelohnt hat. Klingt radikal, ist aber konsequent: Wenn weniger mehr ist, musst du regelmäßig ausmisten.
Methode 1: Mit claude doctor und einem ehrlichen Blick aufräumen
Der einfachste Weg, deinen Kontext gesund zu halten, ist, ihn selbst zu lesen und zu bearbeiten. Die meisten Coding-Agents bieten dafür einen integrierten Befehl an, bei Claude heißt er /doctor. Das Werkzeug führt grundlegende Checks durch: Es löscht redundante Prompts, erkennt kaputte Einstellungen, findet ungenutzte Plugins und optimiert für Lazy Loading. Am Ende erscheint ein Bericht, der anzeigt, wie oft jede Datei verwendet wurde und wie viel Kontext sich einsparen ließe.
Auf der PostHog-Website schlug der Befehl vor, drei ungenutzte Plugins und drei Skills zu deaktivieren. Das sparte durchschnittlich 6.000 Tokens pro Session. Ordentlich, aber verlass dich nicht darauf, dass der Arzt alle Fehler findet. claude doctor prüft nur, was sich aus dem Code ableiten lässt. Nicht, ob eine Anweisung inhaltlich noch stimmt.
Ein Beispiel aus dem Beitrag: Das PostHog-Team hatte in der AGENTS.md notiert, dass alle Merges in master über die Trunk-Merge-Queue laufen müssen und gh pr merge nie ausgeführt werden darf. Nach ein paar Tagen pausierte das Team die Queue, um fehlgeschlagene Tests zu beheben – und vergaß, die Anweisung zu aktualisieren. Die Agents arbeiteten 21 Stunden lang mit falschen Vorgaben. Ein Pull-Request hing zehn Stunden fest, ein anderer Entwickler verlor 45 Minuten bei der Fehlersuche. claude doctor hätte das nicht erkannt: Der Zustand der Queue liegt in einer GitHub-Einstellung, nicht im Code.
Die Empfehlung: Führe claude doctor nach jedem Update aus, lies die Datei danach aber selbst noch einmal durch. Für jede Zeile gilt: Kann ich genau benennen, welchen Fehler sie verhindert? Wenn nicht, streiche sie. Diese Regel ist einfach und überraschend wirkungsvoll.
Methode 2: Evals als Regressionstests für deinen Kontext
Die zweite Methode überträgt ein bekanntes Konzept aus der Softwareentwicklung auf den Kontext: Evals. Beim Beheben eines Bugs schreibst du einen Regressionstest. Beim Korrigieren deiner AGENTS.md legst du eine Prüfung an, die den ursprünglichen Fehler abfängt. Mit der Zeit entsteht so eine Test-Suite für die teuersten Kontextpassagen.
PostHog nutzt das in aufwendiger Form. Das Team betreibt einen wizard-ci, der den Onboarding-Wizard auf etwa 40 Beispiel-Apps laufen lässt und für jede App einen Pull-Request erstellt. Ein zweiter Agent, der pr-evaluator, bewertet diese PRs anhand der Diffs und Session-Logs. Das deckt Schwachstellen auf, etwa wenn der Wizard die Installation von PostHog überspringt, weil er fälschlich annimmt, das SDK sei schon vorhanden. So werden technische Fallstricke aus echten Läufen zu konkreten Anweisungen in den Kontextdateien.
Du musst diese Infrastruktur nicht nachbauen. Der Kern ist einfach: Jedes Mal, wenn ein Agent einen Fehler macht, nimm den Prompt, der ihn ausgelöst hat, und lege ihn in einer failures.md ab. Beim nächsten Umbau deiner AGENTS.md führst du diese Prompts erneut aus. So bekommst du schnell eine Rückmeldung, ob deine Streichungen den Fehler wieder ermöglichen. Ein pragmatischer Weg, Vertrauen in das Kürzen zu gewinnen.
Methode 3: Agents selbst nach Feedback fragen
Die dritte Methode ist fast zu naheliegend: Frag den Agenten. Agents können gut beschreiben, welche Informationen ihnen gefehlt haben oder welche Anweisungen verwirrend waren. Viele Entwickler nutzen das für Skills. Man kann es zur Standardroutine machen, indem man es direkt in den Prompt schreibt.
Beim PostHog-Wizard ist die letzte Anweisung, dass der Agent einen kurzen Kommentar über aufgetretene Fehler hinterlässt. Die Frage lautet ungefähr: Welche Information oder Anleitung wäre bei dieser Aufgabe nützlich gewesen, um Werkzeugfehler, falsche Bearbeitungen oder verschwendete Versuche zu verhindern? Daraus entsteht ein kontinuierlicher Strom von Fehlerberichten – eine einfache Form von AI-Observability.
Das Team geht noch weiter: Die Rückmeldungen werden in eine Art context-mill eingespeist, die daraus neue Anweisungen generiert. Wichtig ist die Verifikation, denn Agents sind nicht immer präzise. Die Rückmeldungen werden geclustert. Bei auffälligen Mustern wird ein Subagent losgeschickt, um das Problem nachzuvollziehen. Erst dann wird versucht, es zu beheben. Für dich reicht es, Agents in deinen Prompts zu bitten, die verwendeten Kontextdateien zu notieren. In Pull-Request-Vorlagen kann das ausreichen, um Inkonsistenzen zu entdecken.
Was du konkret für deine AGENTS.md tun kannst
Es geht nicht darum, deine AGENTS.md pauschal zu löschen. Behandle den Kontext als wartbares Produkt. Eine Datei, die einmal richtig war, kann kurz darauf schädlich sein. Die Werkzeuge dafür sind mechanisch, empirisch und sozial. Wer alle drei kombiniert, bekommt ein System, das sich selbst verbessert.
Der Aufwand ist überschaubar. Der erste Schritt: ein Termin mit claude doctor und eine ehrliche Revision deiner Regeln. Der zweite Schritt: eine failures.md, in der du zu jedem gemeldeten Agentenfehler den auslösenden Prompt festhältst. Der dritte Schritt: eine Frage an deinen Agenten – im Alltag, nicht nur in Testläufen.
Das ersetzt keine gesunde Skepsis. Vertrau keinem Bericht blind, auch nicht dem von claude doctor. Aber nutze die Signale, um deinen Kontext so schlank zu halten, dass die Modelle ihre Stärken ausspielen können. Das Ziel ist nicht, keine AGENTS.md zu haben, sondern eine, die nur das enthält, was ein modernes Modell nicht selbst erkennen kann.
Quelle: newsletter.posthog.com
