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. Die Ergebnisse wurden nicht schlechter.
Kurz gesagt
Moderne KI-Modelle brauchen weniger Vorschriften und mehr Spielraum. Lange Regellisten widersprechen sich irgendwann selbst und machen das Modell vorsichtig statt hilfreich. Wer heute mit KI arbeitet, sollte Regeln streichen und nur behalten, was niemand sonst wissen kann.
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 stehen 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. Je unzuverlässiger ein Modell arbeitete, desto länger wurde die Liste der Vorschriften. Das war jahrelang der richtige Weg. Seit der aktuellen Modellgeneration ist es das nicht mehr.
Was Anthropic tatsächlich gemacht hat
Anthropic entwickelt Claude, eines der verbreiteten KI-Modelle. Für das eigene Entwicklerwerkzeug Claude Code hatte das Unternehmen ü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 Programmier-Tests ließ sich kein messbarer Qualitätsverlust feststellen. Intern nennt das Unternehmen den Vorgang "Claude entfesseln".
Das ist kein Versprechen über künftige Modelle, sondern die Beschreibung einer bereits vorgenommenen Änderung. Zwei Dinge sollte man trotzdem wissen: Die Zahl stammt aus Anthropics eigenen Messungen, eine unabhängige Prüfung gibt es nicht. Und "kein messbarer Verlust" bezieht sich auf Programmieraufgaben, nicht auf jede denkbare Nutzung.
Warum zu viele Regeln schaden
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 aus dem ersten Absatz.
Anthropic nennt ein Beispiel aus den eigenen Protokollen: Die Anweisung "dokumentiere, wo es angemessen ist" stand neben der Anweisung "füge niemals Kommentare hinzu". Beide Sätze im selben Dokument. Das Modell konnte beiden nicht gleichzeitig folgen.
Solche Widersprüche entstehen nicht aus Nachlässigkeit. Sie entstehen, weil Regeln zu verschiedenen Zeitpunkten aus verschiedenen Anlässen hinzugefügt werden. Jede einzelne war in ihrem Moment sinnvoll. Niemand liest die ganze Liste noch einmal von vorn.
Beim Aufräumen einer gewachsenen Konfiguration für diesen Beitrag tauchte ein besonders hübsches Exemplar auf. Eine Hausregel lautete sinngemäß: "Verwende niemals einen langen Gedankenstrich, nutze stattdessen einen normalen Bindestrich." Beim Speichern der Datei 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 Satz vorschrieb.
Beide Sätze standen in derselben Systemanweisung. Das Modell konnte ihnen nicht gleichzeitig folgen.
Eine Anweisung, die sich selbst widerspricht, richtet mehr Schaden an als eine Anweisung, die fehlt.
Fünf Dinge, die sich verschoben haben
Anthropic beschreibt die Änderung nicht als Kürzung, sondern als Verschiebung. Fünf Punkte fassen sie zusammen.
| Früher | Heute | Was das bedeutet |
|---|---|---|
| Regeln vorgeben | Urteil zulassen | Statt "schreibe keine Kommentare" besser "schreibe Code, der sich liest wie der Code drumherum". |
| Beispiele liefern | Auswahl gestalten | Beispiele engen den Lösungsraum ein. Gut benannte Auswahlmöglichkeiten erklären sich von selbst. |
| Alles vorab laden | Bei Bedarf nachladen | Details wandern in abrufbare Bausteine statt in ein Dauerdokument. |
| Sich wiederholen | Einmal sagen | Eine Information gehört an genau eine Stelle. |
| Notizen von Hand pflegen | Automatisches Gedächtnis | Das System merkt sich Relevantes inzwischen selbst. |
Das Kernprinzip: erst holen, wenn man es braucht
Der dritte Punkt trägt einen englischen Fachbegriff: 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. Man greift danach, wenn der Kuchen ansteht. Genau so funktioniert das neue Vorgehen: Anleitungen liegen bereit, aber sie liegen nicht dauerhaft im Blickfeld.
Das ist mehr als eine Frage der Ordnung. Ein Modell kann nur eine begrenzte Menge Text gleichzeitig überblicken, das sogenannte Kontextfenster. Jedes Zeichen, das dauerhaft darin liegt, verdrängt Platz für die eigentliche Aufgabe. Wer den Platz mit Regeln füllt, hat weniger davon für den Text, den Code oder die Daten, um die es eigentlich geht.
Die farbigen Blöcke stehen für Anleitungen, der grüne Bereich für den verbleibenden Arbeitsraum.
Ein echter Umbau, mit Zahlen
Die Theorie ist schnell erzählt. Interessanter wird es, wenn man sie auf eine gewachsene Konfiguration anwendet. Der folgende Umbau stammt aus der eigenen Werkstatt. Vorher und nachher wurde gemessen.
Dauerhaft mitgelesen wurden vier Blöcke: ein allgemeines Regelwerk, ein zweites Regelwerk auf Projektebene, die Kurzbeschreibungen aller verfügbaren Skills und ein Zusatzblock einer Erweiterung.
| Was dauerhaft mitgelesen wurde | vorher | nachher |
|---|---|---|
| Regelwerk, allgemein | 6.817 | 1.800 |
| Regelwerk, Projekt (fast identische Kopie) | 6.100 | 1.554 |
| Kurzbeschreibungen der Bausteine | 8.923 | 3.526 |
| Zusatzblock einer Erweiterung | 2.450 | 0 |
| Summe in Zeichen | 24.290 | 6.880 |
24.290 Zeichen klingen abstrakt. Es sind gut acht eng bedruckte DIN-A4-Seiten, die vor jeder einzelnen Frage mitgelesen wurden. Auch dann, wenn die Frage nur lautete, wie spät es ist. Nach dem Umbau sind es gut zwei Seiten.
Gerechnet wird bei KI-Modellen allerdings nicht in Zeichen, sondern in Token. In dieser Einheit waren es vorher rund 6.000, nachher etwa 1.700. Diese Menge fällt bei jeder Anfrage neu an, den ganzen Tag, in jedem Projekt.
Beide Balken im selben Maßstab. Gemessen in Zeichen, nicht geschätzt.
Zwei Beobachtungen sind dabei wichtiger als die Prozentzahl.
Erstens waren die beiden Regelwerke nahezu identisch. Dieselben Sätze wurden zweimal mitgelesen, weil eine Vorlage in ein Projekt kopiert worden war. Das fiel jahrelang niemandem 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 fiel erst auf, als jede Zeile begründet werden musste.
Weniger Anweisungen heißt nicht: einfach alles löschen und hoffen. Es heißt: jede Zeile muss sich rechtfertigen. Der Unterschied zwischen einer aufgeräumten und einer leeren Konfiguration ist derselbe wie zwischen einem sortierten und einem ausgeräumten Werkzeugkasten.
Was du konkret tun kannst
Die folgenden sieben Punkte lassen sich auf jede Sammlung von Anweisungen anwenden, ob in einem Entwicklerwerkzeug, in den eigenen Chat-Voreinstellungen oder in einer Team-Dokumentation.
- Streiche, was selbstverständlich ist. "Arbeite sorgfältig" ändert nichts am Ergebnis. Es kostet nur Platz.
- Behalte, was niemand erraten kann. Stolperfallen, Sonderwege, der Grund hinter einer Entscheidung.
- Suche gezielt nach Widersprüchen. Zwei Regeln, die sich beißen, kosten mehr als zehn, die fehlen.
- Sage jede Sache genau einmal. Doppelte Dokumente driften auseinander, und dann gilt keines mehr.
- Formuliere Ziele statt Verbote. Ein Ziel trägt auch in Fällen, an die niemand gedacht hat.
- Lagere Details aus. Was selten gebraucht wird, gehört ins Regal, nicht an die Wand.
- Miss nach. Zähle vorher und nachher. Gefühlte Verbesserung ist keine Verbesserung.
Nicht jede Regel muss weg. Nur die, deren Antwort sich aus dem Projekt selbst ergibt.
Für Claude Code gibt es dafür inzwischen ein eigenes Kommando. Ein Aufruf von /doctor prüft die vorhandenen Anweisungen und schlägt Kürzungen vor.
Was trotzdem bleibt
Drei Dinge kann auch ein sehr gutes Modell nicht erraten. Sie gehören weiterhin aufgeschrieben.
Stolperfallen. Dass ein bestimmter Befehl auf diesem einen Rechner nicht funktioniert, steht in keiner Datei und lässt sich aus keinem Code ableiten.
Absichten. Warum etwas so gebaut ist, wie es gebaut ist. Der Code zeigt das Was, nie das Warum.
Geschmack. Wie ein Text klingen soll. Welche Wörter nicht vorkommen dürfen. Das ist keine Regel, sondern eine Entscheidung.
Diese drei Dinge kann auch ein sehr gutes Modell nicht erraten.
Die Frage hat sich damit verschoben. 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 man ihn sieht. 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. 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. Man kann es sich als Schreibtisch vorstellen: Was darauf liegt, ist verfügbar, alles andere nicht. Der Tisch ist groß, aber nicht unendlich. Was dauerhaft darauf liegt, nimmt dem eigentlichen Vorgang den Platz weg.
- 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 und weiterführende Links
- Anthropic: The New Rules of Context Engineering for Claude 5 Generation Models
- Eigene Messung beim Umbau einer gewachsenen Claude-Code-Konfiguration
Quellen
- Anthropic: The New Rules of Context Engineering for Claude 5 Generation Models
- Eigene Messung beim Umbau einer gewachsenen Claude-Code-Konfiguration