Neues KI-Modell? Erst alles löschen, dann neu aufsetzen

Vor einem Jahr galt in der KI-Entwicklung eine einfache Regel: Je mehr Kontext, desto besser. Eine lange AGENTS.md, eine CLAUDE.md, eine DESIGN.md, Dutzende Skills, Hooks für jeden Fall und Leitplanken in Großbuchstaben. Wer viel erklärte, bekam bessere Ergebnisse.

Mit den Modellen von 2026 kippt das. Das beste Setup für ein neues Modell beginnt oft mit dem Löschen. Danach testest du, was das Modell von selbst kann, und baust nur das wieder auf, was wirklich fehlt.

So sah ein KI-Setup bisher aus

Ein typisches Projekt mit KI-Agenten hatte 2025 diese Bausteine:

• Kontextdateien. AGENTS.md oder CLAUDE.md mit Projektübersicht, Ordnerstruktur, Befehlen und Stilregeln. Oft mehrere hundert Zeilen.
• Design- und Textregeln. Eigene Markdown-Dateien für Farben, Abstände, Tonalität und verbotene Wörter.
• Skills. Fertige Anleitungen für wiederkehrende Aufgaben, vom Commit bis zum Deployment.
• Hooks. Skripte, die vor oder nach jeder Aktion des Agenten laufen und eingreifen.
• Leitplanken im Prompt. „KRITISCH: Du MUSST immer …“, „Denk Schritt für Schritt“, „Prüf alles dreimal“.

Das hatte einen Grund. Die Modelle vergaßen Konventionen, übersprangen Tests oder bauten Dinge, die keiner bestellt hatte. Jede Regel war eine Antwort auf einen echten Fehler.

Warum das bei neuen Modellen bremst

Die Fehler, gegen die diese Regeln geschrieben wurden, machen neue Modelle oft nicht mehr. Die Regeln bleiben aber. Und sie wirken weiter, nur jetzt in die falsche Richtung.

Neue Modelle folgen genauer

Ältere Modelle überhörten Anweisungen. Darum schrieb man sie laut: in Großbuchstaben, mit „IMMER“ und „NIE“. Neue Modelle hören genau zu. Anthropic schreibt schon in seinen Prompt-Empfehlungen für die Claude-4-Modelle, dass solche Formulierungen jetzt zu Übereifer führen. Ein Werkzeug, das „KRITISCH“ immer genutzt werden soll, wird dann auch dort genutzt, wo es nicht passt. Die Empfehlung: ruhig formulieren, etwa „Nutze dieses Werkzeug, wenn …“.

Alte Krücken widersprechen neuen Fähigkeiten

Claude Opus 5.5 denkt vor jeder Antwort selbst nach und wählt die Tiefe selbst. Eine Zeile wie „Denk Schritt für Schritt“ ist damit überflüssig. Laut Anthropic starten Antworten ohne diese Zeile schneller, ohne erkennbaren Qualitätsverlust. Ähnlich bei „Sei knapp“ oder „Prüf alles dreimal“: Anthropic empfiehlt, solche Korrekturen am neuen Modell neu zu testen, statt sie einfach zu übernehmen.

Mehr Kontext kostet mehr und bringt wenig

Forscher der ETH Zürich haben im Februar 2026 untersucht, ob AGENTS.md-Dateien Coding-Agenten wirklich helfen. Getestet wurden unter anderem Claude Code und Codex. Das Ergebnis: Kontextdateien verbessern die Erfolgsquote kaum. Von KI erzeugte Dateien verschlechtern sie sogar leicht. Die Kosten steigen dagegen im Schnitt um über 20 Prozent, weil der Agent mehr Schritte macht.

Besonders aufschlussreich: Die Agenten befolgen die Anweisungen in den Dateien gut. Sie tun also, was drinsteht. Nur hilft vieles davon nicht. Eine Übersicht über die Ordnerstruktur braucht ein Agent nicht, der das Repository selbst lesen kann. Nützlich sind die Dateien laut Studie vor allem für ungewöhnliche Konventionen, die das Modell nicht erraten kann.

Was die Hersteller selbst tun

Boris Cherny hat Claude Code bei Anthropic entwickelt. In einem Interview mit Y Combinator im Juli 2026 erzählte er, dass sein Team rund 80 Prozent des Systemprompts von Claude Code gestrichen hat, ohne dass die Ergebnisse schlechter wurden. Sein Rat an alle, die mit KI-Agenten arbeiten: Lösch alle sechs Monate deine CLAUDE.md, deine Skills und deine Hooks. Und schau, was das Modell ohne sie macht.

Das ist bemerkenswert. Die Leute, die das Modell bauen, behandeln ihr eigenes Setup als Verbrauchsmaterial. Ein Harness, also die Hülle aus Prompts, Werkzeugen und Regeln um ein Modell, hält nur bis zum nächsten Modell.

So setzen wir nach einem Modellwechsel neu auf

1. Bestand sichern. Das alte Setup kommt in einen eigenen Branch. Gelöscht wird im Arbeitsstand, nicht im Archiv.
2. Alles abschalten. Kontextdateien, Skills, Hooks, Leitplanken im Prompt. Übrig bleibt das nackte Modell mit Zugriff auf den Code.
3. Mit echten Aufgaben testen. Fünf bis zehn typische Aufgaben aus dem Alltag: ein Bugfix, eine neue Seite, ein Umbau, eine Textänderung. Wir schauen zu und notieren jeden Fehler.
4. Nur zurückholen, was wiederholt schiefgeht. Ein einzelner Ausrutscher ist keine Regel wert. Ein Fehler, der zweimal passiert, schon. Die Regel wird so eng wie möglich formuliert, ruhig und mit Begründung.
5. Prüfbares in Code statt in Text. Was ein Linter, ein Test oder eine Typprüfung erkennen kann, gehört dorthin. Ein fehlschlagender Test überzeugt jedes Modell. Eine Regel in einer Markdown-Datei nicht immer.
6. Datum notieren. Mit dem nächsten Modell beginnt die Runde von vorn.

Welche Regel bleibt, welche geht

Was bleiben darf

Löschen heißt nicht, ohne Kontext zu arbeiten. Es bleibt, was das Modell nicht aus dem Code ablesen kann:

• Geschäftsregeln und Kundenwünsche, die nirgends im Code stehen.
• Ungewöhnliche Konventionen, die gegen den Standard laufen.
• Befehle zum Testen und Prüfen, wenn sie nicht offensichtlich sind.
• Grenzen bei allem, was Geld, Kundendaten oder Produktivsysteme betrifft.

Der letzte Punkt braucht mehr als Text. Sicherheitsgrenzen gehören in Rechte, Sandboxen und Freigaben. Eine Regel in einer Markdown-Datei hält keinen Angreifer auf, der dem Agenten über eine E-Mail oder eine Webseite neue Anweisungen unterschiebt. Mehr dazu in unserem Beitrag über agentische Angriffe. Und weniger Hooks und Skills heißt auch: weniger Dateien, in denen sich Schadcode verstecken kann. Wie Angreifer genau solche Konfigurationsdateien nutzen, liest du im Beitrag über Agentjacking.

Häufige Fragen