Warum Anthropic 80 Prozent der eigenen Regeln löschte
Jahrelang galt: Wer von einer KI gute Arbeit will, muss ihr genau sagen, was sie tun soll. Anthropic hat diese Annahme am eigenen Produkt geprüft und den größten Teil der Anweisungen entfernt, ohne dass die Ergebnisse schlechter wurden. Ich habe dasselbe an meiner eigenen Konfiguration versucht.
In einem Satz
Anthropic hat die Anweisungen für sein Entwicklerwerkzeug um mehr als 80 Prozent gekürzt, ohne messbaren Qualitätsverlust, weil lange Regellisten sich irgendwann selbst widersprechen und ein Modell vorsichtig statt hilfreich machen; bei meiner eigenen Konfiguration fielen 71 Prozent weg, und dabei kamen zwei Fehler ans Licht.
Der Kollege mit dem widersprüchlichen Handbuch
Stell dir einen neuen Kollegen vor. An seinem ersten Tag bekommt er ein Handbuch mit vierzig Seiten Verhaltensregeln. Er nimmt seine Aufgabe ernst und liest alles.
Auf Seite zwölf steht, er solle Dokumentation schreiben, wo sie hilft. Auf Seite einunddreißig steht, er solle niemals Kommentare hinterlassen. Beide Sätze im selben Handbuch, unterschrieben von derselben Person.
Was macht der Kollege? Er wird vorsichtig. Er fragt lieber zweimal nach, statt eine Entscheidung zu treffen, die gegen eine der beiden Regeln verstößt. Aus einem fähigen Mitarbeiter wird jemand, der sich absichert.
Genau dieses Handbuch haben viele Menschen ihren KI-Werkzeugen geschrieben, ich eingeschlossen. Je unzuverlässiger ein Modell arbeitete, desto länger wurde die Liste der Vorschriften, und jahrelang war das auch der richtige Weg. Mit der aktuellen Modellgeneration ist es das nicht mehr. Die Frage ist nur: warum eigentlich? Und was gehört dann überhaupt noch aufgeschrieben?
Was Anthropic gestrichen hat
Den deutlichsten Hinweis liefert der Hersteller selbst. Anthropic entwickelt Claude, eines der verbreiteten KI-Modelle, und hatte für das eigene Entwicklerwerkzeug Claude Code über Jahre eine Systemanweisung gepflegt: einen Text, den das Modell vor jeder einzelnen Unterhaltung mitliest. Er war über die Zeit immer weiter gewachsen.
Für die neue Modellgeneration hat Anthropic diesen Text radikal gekürzt. Nach eigenen Angaben fielen mehr als 80 Prozent weg. In den Programmiertests ließ sich kein messbarer Qualitätsverlust feststellen.
Dazu gehören zwei Einschränkungen. Die Zahl stammt aus Anthropics eigenen Messungen, unabhängig geprüft hat sie niemand. Und "kein messbarer Verlust" bezieht sich auf Programmieraufgaben, nicht auf jede denkbare Nutzung. Ich halte den Befund trotzdem für belastbar, aus einem einfachen Grund: Ich habe ihn im Kleinen nachgestellt. Dazu gleich.
Warum zu viele Regeln schaden
Denn Regeln kosten nicht nur Platz. Sie widersprechen sich, sobald es viele werden. Und ein Modell, das einen Widerspruch bemerkt, verhält sich wie der Kollege mit dem Handbuch.
Anthropic nennt ein Beispiel aus den eigenen Protokollen, und es ist fast wörtlich das von oben: Die Anweisung "dokumentiere, wo es angemessen ist" stand neben der Anweisung "füge niemals Kommentare hinzu". Das Modell konnte nicht beiden zugleich folgen.
Solche Widersprüche entstehen nicht aus Nachlässigkeit. Sie entstehen, weil Regeln zu verschiedenen Zeitpunkten aus verschiedenen Anlässen dazukommen, jede in ihrem Moment sinnvoll, und weil niemand die ganze Liste noch einmal von vorn liest.
Wie absurd das werden kann, habe ich in meinen eigenen Dateien gesehen. Eine meiner Hausregeln lautete sinngemäß: Verwende niemals einen langen Gedankenstrich, nutze stattdessen einen normalen Bindestrich. Irgendwann beim Speichern war das lange Sonderzeichen in der Regel selbst zu einem normalen Bindestrich geworden. Die Regel verbot damit wörtlich genau das Zeichen, das sie im nächsten Halbsatz vorschrieb. Jahrelang hat das niemand bemerkt. Auch ich nicht.
Das Buch im Regal statt an der Wand
Anthropic beschreibt die Änderung nicht als Kürzung, sondern als Verschiebung. Statt Regeln vorzugeben, lässt man dem Modell mehr Urteil: nicht "schreibe keine Kommentare", sondern "schreibe Code, der sich liest wie der Code drumherum". Statt Beispiele zu liefern, die den Lösungsraum einengen, benennt man die Möglichkeiten so gut, dass sie sich selbst erklären. Jede Information steht an genau einer Stelle. Und was sich das System merken muss, merkt es sich inzwischen selbst.
Der wichtigste Punkt trägt einen sperrigen Namen, Progressive Disclosure, sinngemäß schrittweise Offenlegung. Er klingt technischer, als er ist. Niemand klebt alle Rezepte seines Kochbuchs an die Küchenwand, nur weil er später vielleicht eines davon braucht. Das Buch steht im Regal, und du greifst danach, wenn der Kuchen ansteht. Genau so sollen Anleitungen für ein Modell funktionieren: Sie liegen bereit, aber nicht dauerhaft im Blickfeld.
Die blauen und grauen Blöcke stehen für Anleitungen, das helle Feld für den verbleibenden Arbeitsraum.
Das ist mehr als eine Frage der Ordnung. Ein Modell kann nur eine begrenzte Menge Text gleichzeitig überblicken, sein Kontextfenster. Jedes Zeichen, das dauerhaft darin liegt, nimmt Platz weg, der dann für das fehlt, worum du das Modell eigentlich gebeten hast: den Text, den Code, die Tabelle mit den Zahlen von gestern. Regeln verdrängen Arbeit.
Was bei mir übrig blieb
So weit die Theorie. Im August habe ich sie auf meine eigene, über Monate gewachsene Konfiguration angewendet und vorher und nachher gezählt. Dauerhaft mitgelesen wurden vier Blöcke: ein allgemeines Regelwerk, ein zweites Regelwerk auf Projektebene, die Kurzbeschreibungen aller verfügbaren Skills und der Zusatzblock einer Erweiterung.
Zusammen waren das 24.290 Zeichen. Das sind gut acht eng bedruckte Seiten, die vor jeder einzelnen Frage mitgelesen wurden, auch dann, wenn die Frage nur lautete, wie spät es ist. Nach dem Umbau blieben 6.880 Zeichen, gut zwei Seiten. In der Einheit, in der KI-Modelle tatsächlich rechnen, sind das rund 6.000 Token vorher und etwa 1.700 nachher, bei jeder Anfrage, den ganzen Tag, in jedem Projekt.
Beide Balken im selben Maßstab. Gemessen in Zeichen, nicht geschätzt.
Wichtiger als die 71 Prozent waren aber zwei Dinge, die ich nicht gesucht hatte.
Erstens waren die beiden Regelwerke nahezu identisch. Dieselben Sätze wurden zweimal mitgelesen, weil ich irgendwann eine Vorlage in ein Projekt kopiert hatte. Das fiel nicht auf, weil beide Dateien für sich genommen vernünftig aussahen.
Zweitens war das Kürzen selbst die eigentliche Prüfung. Ein Verweis zeigte auf eine Anleitung, die es gar nicht gab. Ein Automatismus rief ein Programm auf, das unter Windows nie existiert hat, und schlug seit Monaten still fehl. Beides kam erst ans Licht, als jede Zeile begründen musste, warum sie da ist.
Das ist auch der Unterschied zwischen Aufräumen und Löschen. Weniger Anweisungen heißt nicht, alles zu entfernen und zu hoffen. Es heißt, dass jede Zeile sich rechtfertigen muss.
Wie du deine eigenen Regeln prüfst
Dafür braucht es keine Spezialwerkzeuge, nur eine Frage, die du jeder einzelnen Zeile stellst: Könnte das jemand anderes wissen? Ergibt es sich aus dem Code, aus dem Projekt, aus dem gesunden Menschenverstand, dann fliegt es raus. "Arbeite sorgfältig" ändert nichts am Ergebnis. Es kostet nur Platz.
Danach lohnt ein zweiter Durchgang mit Blick auf Widersprüche, denn zwei Regeln, die sich beißen, schaden mehr als zehn, die fehlen. Sag jede Sache genau einmal, sonst driften die Kopien auseinander, und dann gilt keine mehr. Formuliere lieber Ziele als Verbote, weil ein Ziel auch in Fällen trägt, an die niemand gedacht hat. Und zähle vorher und nachher. Gefühlte Verbesserung ist keine.
Was trotzdem aufgeschrieben bleibt
Drei Dinge kann auch ein sehr gutes Modell nicht erraten.
Stolperfallen zum Beispiel. Dass ein bestimmter Befehl auf diesem einen Rechner nicht funktioniert, steht in keiner Datei und lässt sich aus keinem Code ableiten. Dann Absichten: warum etwas so gebaut ist, wie es gebaut ist. Der Code zeigt das Was, nie das Warum. Und schließlich Geschmack. Wie ein Text klingen soll, welche Wörter nicht vorkommen dürfen. Das ist keine Regel, das ist eine Entscheidung.
Damit hat sich die Frage verschoben, die ich mir beim Schreiben von Anweisungen stelle. Sie lautet nicht mehr: Was muss ich alles vorschreiben? Sie lautet: Was kann außer mir niemand wissen?
Kurz erklärt
Systemanweisung
Der Text, den ein KI-Modell vor jeder Unterhaltung mitliest, ohne dass du ihn siehst. Er legt fest, wie sich das Modell verhält und was es über seine Aufgabe weiß. Bei einem Entwicklerwerkzeug kann er mehrere Seiten lang sein, und er ist der Ort, an dem sich Regeln über die Jahre ansammeln.
Progressive Disclosure
Sinngemäß schrittweise Offenlegung. Statt alle Informationen von Anfang an bereitzulegen, wird eine Anleitung erst geholt, wenn sie tatsächlich gebraucht wird. Der Vorteil liegt nicht in der Ordnung, sondern im frei bleibenden Platz für die eigentliche Aufgabe.
Kontextfenster
Die Menge an Text, die ein Modell gleichzeitig überblicken kann. Stell es dir als Schreibtisch vor: Was darauf liegt, ist verfügbar, alles andere nicht. Der Tisch ist groß, aber nicht unendlich, und was dauerhaft darauf liegt, nimmt der eigentlichen Arbeit den Platz.
Skill
Ein abrufbarer Baustein mit einer Anleitung für eine bestimmte Aufgabe, etwa "so veröffentlichen wir einen Artikel". Dauerhaft sichtbar ist nur ein Einzeiler, der beschreibt, wofür der Baustein gut ist. Der ausführliche Inhalt wird erst geladen, wenn er passt.
Token
Die Einheit, in der Text für ein Modell gemessen und abgerechnet wird. Ein Token entspricht im Deutschen grob drei bis vier Zeichen, also etwas weniger als einem kurzen Wort. Die 24.290 Zeichen aus dem Beispiel entsprechen ungefähr 6.000 Token.
Quellen
- Anthropic: The New Rules of Context Engineering for Claude 5 Generation Models
- Eigene Messung beim Umbau meiner Claude-Code-Konfiguration