"Lösch einfach deine Anweisungen" ist kein Rat, den ich befolgen kann
Claude Opus 5 ist ein besseres Modell, das in meinem System schlechtere Arbeit liefert. Der allgemeine Konsens verlangt, dass ich das wegwerfe, was das System überhaupt erst wertvoll macht.
Claude Opus 5 wurde am 24. Juli ausgeliefert. In jeder relevanten Benchmark schlägt es Opus 4.8. SWE-bench Pro stieg von 69,2 % auf 79,2 %. Anthropics eigener Coding-Benchmark hat sich mehr als verdoppelt.
Ich betreibe mein gesamtes Unternehmen über Claude Code. Dutzende Projekte in sechs Bereichen, etwa dreißig benutzerdefinierte Skills, ein Gedächtnissystem, geplante Wartungsagenten, harte Regeln, die ich über Monate durch Fehlschläge gelernt habe. Ungefähr 20.000 Token Kontext laden, bevor ich ein einziges Wort tippe.
Vier Tage später konnte ich nicht mehr damit arbeiten. Zwei vollständige Sessions – eine Kundenwebsite und ein SaaS-Produkt – produzierten Ergebnisse, die ich nicht ausgeliefert hätte.
Ich habe inzwischen fast alles gelesen, was dazu geschrieben wurde, und der allgemeine Konsens ist bemerkenswert einheitlich: Lösche dein Instruction-Scaffolding. Anthropic hat 80 % des System-Prompts von Claude Code gestrichen. Every's CEO löschte seine Skills und berichtete, dass es "dramatisch besser" wurde.
Ich glaube nicht, dass dieser Rat für mich funktioniert, und ich möchte genau erklären, warum, weil ich denke, dass viele Leute im Begriff sind, etwas zu löschen, das sie vermissen werden.
Drei Dinge, die kaputt gingen
Es macht selbstbewusste Fehler. Aus Anthropics eigenem System Card:
„Das Modell halluziniert leicht mehr faktische Behauptungen als Opus 4.8, obwohl es insgesamt genauer ist."
Lies das zweimal. Insgesamt genauer, mehr halluzinierend. Das widerspricht sich nicht – zusammen beschreiben sie genau das, was sich im täglichen Gebrauch anfühlt. Ein offensichtlich falsches Modell ist billig. Ein Modell, das falsch liegt, aber selbstbewusst klingt, ist teuer, weil man aufhört zu prüfen.
Es hört auf, bevor die Arbeit erledigt ist. Kieran Klaassen, der einen autonomen Workflow betreibt:
„Es gab die Kontrolle immer wieder an den Benutzer zurück. Obwohl es ein autonomer Workflow ist. Das ist extrem nervig."
Das deckt sich mit dem, was ich gesehen habe. Aufgaben wurden umgeformt statt ausgeführt, Teilarbeiten als abgeschlossen gemeldet, Widerstand, wo das vorherige Modell die Sache einfach erledigt hat.
Es redet zu viel. Das am besten dokumentierte der drei Probleme, wiederholt in Anthropics eigenem Migrationsleitfaden eingeräumt:
„Standardmäßige sichtbare Antworten und geschriebene Ergebnisse sind bei Claude Opus 5 länger als bei früheren Opus-Modellen, und eine geringere Anstrengung reduziert das Denkvolumen, ohne die sichtbare Antwort zuverlässig zu verkürzen."
Beachte die zweite Hälfte. Der Effort-Parameter behebt es nicht.
Der Mechanismus, auf den sich alle einigen
Hier ist der Teil, der es für mich neu eingeordnet hat. Aus Anthropics Engineering-Post, veröffentlicht am Tag, als Opus 5 startete:
„Wir haben Claude Code übermäßig eingeschränkt, sowohl durch unseren System-Prompt als auch durch unsere CLAUDE.md-Dateien und Skills."
Sie haben etwa 80 % ihres System-Prompts gestrichen. Dan Shipper berichtete, dass Opus 5 „nicht gut mit unseren bestehenden Skills und Plugins zusammenspielte" und dass das Löschen dieser Skills es „dramatisch besser" machte. João Queirós: „Einfache Prompts lieferten vielversprechendere Ergebnisse als ausgereifte, anweisungsintensive Workflows."
Vier unabhängige Quellen plus der Anbieter, alle zeigen auf dieselbe Variable: Je mehr Instruction-Scaffolding du angesammelt hast, desto schlechter performt dieses Modell.
Das erklärt auch, warum die Diskussion gespalten wirkt und nicht einhellig. Wenn deine CLAUDE.md zwölf Zeilen lang ist, ist Opus 5 eindeutig besser und die Kritiker wirken dramatisch. Wenn du Monate damit verbracht hast, ein System aufzubauen, befindest du dich in einer völlig anderen Diskussion.
Wo der allgemeine Konsens scheitert
Dann lösche es doch, sagen alle. Hier ist das Problem: Meine Anweisungen sind nicht eine Sache. Sie sind zwei Dinge, die in einer Textdatei identisch aussehen und völlig unterschiedlicher Natur sind.
Kompensationen. Anweisungen, die existieren, um eine Modellschwäche auszugleichen. „Überprüfe deine Arbeit." „Standardmäßig delegieren" – das habe ich geschrieben, als das vorherige Modell zu wenig delegiert hat. „Fasse zusammen, bevor du fortfährst." Das ist im wörtlichen Sinne ein Gerüst: eine temporäre Konstruktion um eine Lücke im Gebäude herum.
Kompensationen können bedenkenlos gelöscht werden, und Opus 5 macht viele von ihnen tatsächlich überflüssig. Es überprüft sich selbst, ohne Aufforderung. Es delegiert bereitwillig. Gut. Weg damit.
Verfassung. Fakten und Standards, die nirgendwo sonst existieren. Dass ein grüner Build mich schon einmal belogen hat, also Beweis echtes WebKit und eine Marker-Zeichenkette im HTML bedeutet, nicht ein HTTP 200. Welcher Host hinter welchem Projekt steht. Welcher Kunde geschützt ist und welcher nicht. Was die Typografie dieser Marke darf. Welche Fehlerklasse mich am meisten gekostet hat und was genau dagegen schützt.
Das ist kein Nörgeln. Es sind Informationen. Und es ist bei keiner Modellqualität ableitbar, weil es kein Denkproblem ist – es ist Wissen, das nur in meinem Unternehmen existiert. Ein klügeres Modell errät es nicht besser. Es errät es selbstbewusster.
Der allgemeine Konsens unterscheidet nicht zwischen diesen beiden. Er sagt „lösche deine Anweisungen", und die Leute werden beides löschen, weil es in einer Markdown-Datei gleich aussieht.
Ich weiß das, weil ich es getan habe. Dem Migrationsleitfaden folgend, habe ich Überprüfungsanweisungen aus meinem Done-Gate entfernt. Der Leitfaden hat recht: „Überprüfe deine Arbeit" ist jetzt überflüssig. Aber ich habe auch die Definitionen dafür entfernt, was in meinem Stack als Beweis gilt – und Verify-Illusionen sind mit Abstand mein teuerster wiederkehrender Fehler. Ich habe die Schutzvorrichtung gelöscht, die speziell gegen meine eigene schlimmste Fehlerart gebaut wurde, weil eine allgemeine Empfehlung mir sagte, ich solle kürzen.
Zwei weitere Sessions später habe ich alles rückgängig gemacht.
Die Behauptung, die ich eigentlich aufstellen möchte
Überall heißt es, dass Opus 5 weniger Anweisungen braucht. Ich denke, das ist die falsche Beschreibung dessen, was passiert.
Opus 5 ist schlechter darin, unter Anweisungen zu arbeiten. Und für eine ganze Klasse von Nutzern ist das Arbeiten unter Anweisungen kein Overhead – es ist die gesamte Aufgabe.
Ich bezahle nicht für ein Modell, das guten generischen Code schreibt. Das kann ich jetzt überall bekommen. Ich bezahle für eines, das Code schreibt, der in ein System passt – mit Konventionen, Compliance-Anforderungen, Markenregeln, kundenspezifischen Einschränkungen und einer dokumentierten Geschichte davon, was hier schon einmal schiefgelaufen ist. Entferne die Einschränkungen, und du hast meine Ausgabe nicht verbessert. Du hast das Modell bequemer gemacht und meine Ausgabe generischer.
Wenn ich also lese „lösche deine Skills und es funktioniert dramatisch besser" – besser worin? Wahrscheinlich in uneingeschränkter Code-Flüssigkeit. Aber nicht darin, Arbeit zu produzieren, die in mein System passt, denn genau das, was die Arbeit in mein System einfügt, wurde gelöscht.
Ich bin zu etwa 90 % sicher, dass Opus 5 ohne mein Instruction-Scaffolding niemals die Qualität erreichen wird, die ich damit bekomme. Nicht weil das Modell schwach ist, sondern weil die fehlende Zutat nicht Intelligenz ist. Es ist das Wissen um mein Unternehmen, und keine noch so große Rohleistung kann es ersetzen.
Was ich tue, und was ich vorschlagen würde
Ich bin zurück auf Opus 4.8 mit meinem vorherigen Setup, byteidentisch wiederhergestellt. Nicht als Protest – sondern weil es funktioniert und ich Deadlines habe.
Ich behaupte nicht, dass Opus 5 ein schlechteres Modell ist. Die Benchmarks sind real, Leute, die ich respektiere, berichten von echten Verbesserungen, und ich habe zwei Variablen gleichzeitig geändert – Modell und Setup, am selben Tag – also kann ich meine eigenen Ergebnisse nicht sauber zuordnen. Das ist eine echte Einschränkung meiner Beweise, keine rhetorische Einschränkung.
Was ich behaupte, ist enger gefasst: Ein besseres Modell kann in einem ausgereiften System schlechtere Arbeit liefern, und der Fehler ist still. Nichts gibt einen Fehler aus. Nichts warnt dich. Deine Anweisungen hören einfach auf, das zu bedeuten, was sie einmal bedeuteten.
Wenn du darauf stößt, hier die Reihenfolge, die ich jetzt verwenden würde:
- Sortieren, bevor du kürzt. Gehe deine Anweisungen durch und markiere jede: gleicht dies eine Modellschwäche aus, oder ist es etwas, das nur ich weiß? Ein einziger Durchlauf ist mehr wert als jede Kürzungsheuristik.
- Kompensationen bedenkenlos löschen. Besonders alles, was dem Modell sagt, es solle überprüfen, delegieren oder zusammenfassen. Dieser Rat ist solide.
- Deine Verfassung verteidigen. Bereichsfakten, Beweisdefinitionen, Markenstandards, Kundeneinschränkungen. Wenn das Löschen einer Zeile dazu führen würde, dass ein kompetenter Neuling falsche Arbeit abliefert, bleibt sie.
- Immer nur eine Variable ändern. Modell oder Setup, niemals beides. Ich habe diese Regel gebrochen und meine Fähigkeit verloren, irgendetwas zuzuordnen.
- Rückgängig machbar machen. Ein einziger Commit, sodass ein Rollback exakt und nicht nur ungefähr ist.
- Dein eigenes dokumentiertes Fehlermuster sticht jeden allgemeinen Ratschlag des Anbieters. Das ist der, den ich mir irgendwo tätowieren lassen würde.
Das Unangenehme ist, dass sich Kompensationen und Verfassung identisch anfühlen, wenn du sie geschrieben hast. Jede Regel in meinem System existiert, weil einmal etwas schiefgelaufen ist. Sie hinterher zu unterscheiden, ist die eigentliche Arbeit – und „lösche es einfach" setzt stillschweigend voraus, dass niemand etwas hat, das zu behalten sich lohnt.
Quellen: Claude Opus 5 System Card und Migrationsleitfaden (Anthropic, Juli 2026); Anthropic Engineering Blog, 24. Juli 2026; Dan Shipper und Kieran Klaassen via X, Juli 2026; João Queirós, Juli 2026.
