Du gibst einem neuen Mitarbeiter ein detailliertes Handbuch mit vielen Regeln: „Schreibe keine langen Kommentare“, „Erstelle niemals Analyse-Dokumente“, „Wiederhole dich immer am Ende.“ Anfangs verhindert das grobe Fehler. Mit der Zeit wird der Mitarbeiter erfahrener – die Regeln bremsen ihn. Statt sich auf die Aufgabe zu konzentrieren, muss er widersprüchliche Anweisungen entwirren. Diesen Wendepunkt hat Anthropic mit den neuesten Claude-5-Modellen erreicht. Die Entwickler haben über 80 Prozent des System-Prompts von Claude Code gestrichen – die Leistung in den Code-Aufgaben blieb gleich. Das verändert die Regeln des Context Engineering.
Bisher galt: Je präziser die Regeln, desto besser die Ergebnisse. Die neue Generation – Claude Opus 5 und Claude Fable 5 – zeigt ein besseres Urteilsvermögen. Laut Anthropic behinderten zu viele Einschränkungen die Modelle. Im alten System-Prompt fanden sich Sätze wie: „Standardmäßig keine Kommentare schreiben. Niemals mehrzeilige Docstrings oder Kommentarblöcke – maximal eine kurze Zeile.“ Oder: „Keine Planungs- oder Analyse-Dokumente erstellen, es sei denn, der Nutzer bittet explizit darum.“ Diese Regeln sollten als Sicherheitsnetz dienen, widersprachen sich aber mit anderen Anweisungen aus Skills oder CLAUDE.md-Dateien. Das Modell musste abwägen, welcher Regel es folgen soll – ein Denkprozess, der unnötig Ressourcen verbrauchte und oft zu suboptimalen Ergebnissen führte.
Die Lösung ist einfach: Vertrauen. Anthropic ersetzte die Regeln durch eine einzige Leitlinie: „Schreibe Code, der sich wie der umliegende Code liest – passe Kommentardichte, Benennung und Stil an.“ Das Modell entscheidet selbst, wann ein mehrzeiliger Kommentar sinnvoll ist, weil es den Kontext versteht. Es funktioniert. Die Leistung in den Evaluierungen blieb stabil, während Flexibilität und Geschwindigkeit der Antworten zunahmen. Das Ergebnis einer bewussten Design-Entscheidung: Moderne KI braucht weniger Gängelung, mehr Rahmenbedingungen.
Die fünf Mythen des alten Context Engineerings
Anthropic räumt in seinem Blogbeitrag mit fünf verbreiteten Annahmen auf. Jede war für ältere Modelle sinnvoll, für die neuen Generationen ist sie kontraproduktiv.
1. Mythos: Gib Claude klare Regeln – Fakt: Lass Claude sein Urteilsvermögen nutzen. Früher musstest du explizit verbieten, dass das Modell Dateien löscht oder unnötige Dokumente erstellt. Heute versteht Claude, wann solche Handlungen angebracht sind. Ein Beispiel aus dem alten System-Prompt: „Erstelle keine Planungs-Dokumente, es sei denn, der Nutzer fragt danach.“ Der neue Prompt sagt einfach: „Arbeite aus dem Gesprächskontext, nicht aus Zwischendateien.“ Das Modell erkennt selbst, ob ein Planungsdokument hilfreich ist – und erstellt eines, ohne darauf warten zu müssen, dass der Nutzer es explizit verlangt.
2. Mythos: Gib Claude Beispiele für Tool-Nutzung – Fakt: Gestalte die Tools intuitiv. Früher galt: Füge ein oder zwei Beispiele hinzu, damit das Modell versteht, wie ein Tool funktioniert. Das führt dazu, dass Claude die Beispiele nachahmt, anstatt kreative Wege zu erkunden. Besser ist es, die Tool-Schnittstelle selbst ausdrucksstark zu gestalten, sodass keine Beispiele nötig sind. Ein Todo-Tool sollte Parameter wie „Status: ausstehend, in Bearbeitung, erledigt“ enthalten – das sagt dem Modell, wie es das Tool verwenden soll. Der Hinweis, dass immer nur ein Eintrag „in Bearbeitung“ sein sollte, definiert das Verhalten, ohne es zu erzwungen.
3. Mythos: Gib alle Informationen auf einmal – Fakt: Setze auf progressive Offenlegung. Früher packtest du alle Anleitungen ins System-Prompt: Code-Review-Prozesse, Verifikationsschritte, Formatierungsregeln. Das füllte den Kontext und war meist unnötig. Heute entscheiden Modelle selbst, wann sie welche Informationen brauchen. Anthropic hat die Verifikationsanleitung in einen separaten Skill ausgelagert, den Claude bei Bedarf lädt. Für deine Projekte gilt: Statt einer riesigen CLAUDE.md-Datei, die alles enthält, lege eine Baumstruktur an – eine Hauptdatei mit den wichtigsten Gotchas und separate Dateien für spezielle Themen (Verifikation, Deployment-Standards, Naming-Conventions). Claude findet den richtigen Zweig selbst.
4. Mythos: Wiederhole dich – Fakt: Halte Tool-Beschreibungen einfach. Ältere Modelle beachteten Anweisungen am Ende des Kontextfensters stärker. Deshalb wiederholtest du dieselben Regeln an mehreren Stellen: im System-Prompt, in der Tool-Beschreibung, in der CLAUDE.md. Das war ein Workaround für eine Schwäche früherer Modelle. Heute reicht es, die Anweisung dort zu platzieren, wo sie hingehört: in der Tool-Beschreibung. Wiederholungen verwirren und kosten Kontext-Token, die du für wichtigere Informationen nutzen könntest.
5. Mythos: Speichere alles im Gedächtnis über CLAUDE.md – Fakt: Nutze Auto-Memory. Viele Benutzer haben manuell Notizen in ihre CLAUDE.md-Datei eingefügt. Claude 5 speichert automatisch relevante Informationen, die es während der Arbeit entdeckt – deine bevorzugte Art, Imports zu ordnen oder deine Lieblings-Bibliothek für Logging. Du musst nicht mehr aktiv daran denken, das festzuhalten. Das Modell erkennt selbst, was dir wichtig ist und hebt es für zukünftige Sitzungen auf.
Wie du diese Regeln in deiner eigenen Arbeit anwendest
Die Erkenntnisse von Anthropic lassen sich direkt auf deine Projekte übertragen – egal, ob du Claude Code, einen eigenen Agenten oder Prompts für die API optimierst. Der Schlüssel liegt im Loslassen alter Gewohnheiten. Statt immer mehr Regeln zu stapeln, vertraue deinem Modell. Gib eine klare, aber flexible Basis vor.
System-Prompt: Wenn du einen eigenen Agenten baust, ist das deine zentrale Stellschraube. Beschreibe, in welchem Produkt der Agent arbeitet und welche grundlegende Rolle er hat. Vermeide spezifische Verbote oder Gebote, die nicht für jeden Fall gelten. Ein guter System-Prompt sagt: „Du bist ein Code-Assistent, der in einem Python-Repository arbeitet. Hilf beim Schreiben, Refactoring und Testen.“ Mehr nicht.
CLAUDE.md: Halte sie leichtgewichtig. Maximal zwei bis drei Absätze. Beschreibe, worum es im Repository geht, aber verschwende keine Tokens für Offensichtliches – Dinge, die Claude aus der Dateistruktur erkennt. Investiere die Tokens lieber in echte Gotchas: „Achtung: Alle Typen sind in einer einzigen Datei models.py definiert“ – das ist nützlich, weil Claude sonst jede Datei durchsuchen würde. Nutze progressive Offenlegung, indem du aus der CLAUDE.md auf spezielle Skill-Dateien verweist: „Siehe .claude/skills/verification.md für detaillierte Testanweisungen.“
Skills: Denk an sie als schlanke Ratgeber, die nur geladen werden, wenn das Modell sie braucht. Vermeide Überregulierung. Ein Skill für Code-Review sollte nicht alle Regeln der Software-Engineering-Klassiker enthalten, sondern deine persönlichen Vorlieben: „Wir bevorzugen Early Returns statt verschachtelter Ifs“ oder „Jede neue Funktion muss einen passenden Test haben.“ Wenn ein Skill lang ist, teile ihn in mehrere Dateien auf – review-rules.md, test-guidelines.md und naming-conventions.md. Claude ruft sie bei Bedarf einzeln ab.
Referenzen: Statt einfacher Markdown-Pläne kannst du Claude reichhaltigere Referenzen geben. Ein Spezifikationsdokument muss nicht mehr nur Text sein; es kann eine HTML-Artifact mit interaktiven Elementen sein, oder besser: eine Testsuite, die genau definiert, was die Software können muss. Du kannst Claude auch Rubriken geben – eine Liste von Kriterien, anhand derer das Modell seine eigene Arbeit bewerten soll. Zum Beispiel: „Ein gutes API-Design ist einfach, konsistent und dokumentiert. Erstelle einen Verifier-Agenten, der jede neue Endpoint-Klasse mit dieser Rubrik prüft.“ Das ist mächtiger als eine statische Liste mit 20 Regeln.
Was das für die Zukunft der KI-Interaktion bedeutet
Dieser Wandel ist mehr als eine technische Optimierung. KI-Modelle sind an einem Punkt angekommen, an dem sie nicht mehr durch primitive Regeln gesteuert werden müssen, sondern durch ein feines Zusammenspiel aus Kontext, Zielvorgabe und Vertrauen. Das erinnert an die Entwicklung von Betriebssystemen: Früher mussten Programmierer genau wissen, wo im Speicher ihre Daten lagen; heute kümmern sich abstrakte Schichten darum. Ähnlich können wir jetzt die Aufgabe „Schreibe guten Code“ an Claude delegieren, ohne jede Zeile vorschreiben zu müssen.
Für Unternehmen bedeutet das: Weniger Aufwand beim Prompt-Engineering, mehr Fokus auf die Qualität des Feedbacks und der Daten, die dem Modell zur Verfügung stehen. Und für Entwickler: Es lohnt sich, alte Gewohnheiten zu hinterfragen. Vielleicht ist die umfangreiche CLAUDE.md, die du seit Monaten pflegst, eher eine Bremse als ein Turbo. Vielleicht reichen ein paar klare Sätze und das Vertrauen, dass Claude den Rest richtig macht.
Am Ende geht es darum, den richtigen Rahmen zu setzen – nicht mehr, nicht weniger. Wie ein erfahrener Handwerker, der seinem Gesellen die grundlegenden Prinzipien erklärt und ihn dann selbst die Lösung finden lässt. Die neuen Claude-5-Modelle sind bereit für diese Freiheit. Jetzt liegt es an uns, sie ihnen zu geben.
Quelle: claude.com
