Opus 5 ist nicht so schlecht, wie es im Internet heißt

Opus 5 ist nicht so schlecht, wie es im Internet heißt. Nach mehr als fünf Wochen täglicher Coding-Arbeit sehe ich noch immer die schwer lesbaren Texte, den wachsenden Arbeitsumfang, falsche Annahmen und Regressionen, von denen Nutzer berichten. Bekommt Opus jedoch einen recherchierten Plan, eine klar begrenzte Aufgabe und eine unabhängige Prüfung, ist es ein starker Softwareentwickler.

Warum sich mein Bild änderte: Opus plant und baut nicht mehr zugleich

Mein Bild verbesserte sich, als ich Opus nicht mehr im selben Kontext die Architektur erarbeiten und eine große Funktion umsetzen ließ. In meiner Einschätzung aus der Release-Woche nannte ich Opus einen starken Umsetzer, der sich schwer beaufsichtigen lässt. Nach fünf Wochen wiederholter Nutzung ist diese Aufgabenteilung klarer geworden, und als Umsetzer vertraue ich dem Modell inzwischen mehr.

Hunderte negative Berichte haben mein Urteil stärker beeinflusst, als ich erwartet hatte. Sie zeigten mir, worauf ich achten sollte, ließen aber auch jeden holprigen Satz und jede unnötige Änderung wie die Bestätigung eines bereits feststehenden Urteils wirken. Erst als ich schlecht abgegrenzte Aufgaben von geplanten Aufgaben trennte, wurde der Unterschied deutlich. Opus hatte die größten Schwierigkeiten, wenn ein einziges Gespräch eine große Funktion verstehen, die Architektur festlegen, alle Vorgaben bewahren, die gesamte Änderung umsetzen und sie verständlich erklären sollte. In einem Prompt steckten damit mehrere verschiedene Aufgaben.

Nachdem Architektur und Grenzen feststanden, übergab ich Opus nur die Umsetzung. Dabei leistete das Modell gute Arbeit: Es verfolgte den relevanten Code durch das Repository, bewältigte schwierige Änderungen und bemerkte Auswirkungen, die ein weniger aufmerksames Modell vielleicht übersehen hätte. Bei einer klar begrenzten Aufgabe half diese Aufmerksamkeit, weil Opus die Dateien, Tests und Grenzfälle fand, die mit dem gewünschten Verhalten zusammenhingen.

Mein verändertes Bild lässt die Fehler von Opus 5 nicht verschwinden. Es zeigt mir, in welcher Rolle sie sich besser begrenzen lassen.

Welche Probleme bei Opus 5 sind real, und was hilft?

Alle fünf Beschwerdegruppen sind nachvollziehbar, aber ich halte sie nicht für gleich schwerwiegend. Das Problem mit den Texten fällt im normalen Einsatz weiterhin klar auf. Die anderen vier richten deutlich weniger Schaden an, wenn Opus einen recherchierten Plan, einen engen Rahmen für die Umsetzung und eine echte Prüfung erhält.

Beschwerde	Was dagegen hilft	Was bleibt
Schwer lesbare Texte	Begrenzte Antwortlänge und Regeln für klare Sprache	Opus formuliert in meiner Nutzung weiterhin weniger klar als Fable
Ausweitung des Arbeitsumfangs	Ausdrückliche Nicht-Ziele und klar begrenzte Dateien	Anweisungen können trotzdem ignoriert werden
Falsche Annahmen	Recherche vor Änderungen und ausdrückliche Rückfragen	Ein Reviewer muss die Annahme prüfen
Regressionen oder falsche Fertigmeldung	Akzeptanzkriterien, Tests und Prüfung des Diffs	Die gewählten Prüfungen können trotzdem lückenhaft sein
Verlust des Plans	Gespeicherter Plan, kleinere Aufgaben und aufgeräumter Kontext	Jeder Teil muss weiterhin geprüft werden

Jede Maßnahme senkt das jeweilige Risiko, aber keine ersetzt eine unabhängige Prüfung.

1. Schwer lesbare Texte: Grenzen helfen, Fable bleibt klarer

Diese Beschwerde erkenne ich aus meiner eigenen Nutzung am schnellsten wieder. Opus kann korrekte Wörter zu einem Satz zusammensetzen, den ich mehr als einmal lesen muss. Das passiert besonders in Erklärungen, Zusammenfassungen und längeren Markdown-Dateien. Nutzer auf Reddit beschrieben dieselbe Mischung aus langen Sätzen, schwacher Struktur und Texten, die technisch betrachtet Sinn ergeben, aber mühsam zu verstehen sind. [5] [6]

Was hilft: Laut Anthropics Leitfaden zum Prompting von Opus 5 fallen Antworten für Nutzer und schriftliche Berichte standardmäßig länger aus. Anthropic empfiehlt klare Grenzen für beides. [1] Kürzere Ausgaben helfen, ebenso eine direkte Anweisung zu verständlicher Sprache. Beides gibt Opus aber nicht zuverlässig die Klarheit im Gespräch, die ich von Fable 5 bekomme. Dieser Unterschied ist in einem Planungsgespräch wichtig. Wenn für mich nur eine getestete Codeänderung zählt, spielt er eine viel kleinere Rolle.

2. Größerer Arbeitsumfang: Nicht-Ziele halten die Aufgabe klein

Opus achtet ungewöhnlich stark auf benachbarte Probleme, mögliche Abstraktionen, fehlende Prüfungen und Wege, eine kleine Änderung vollständiger zu machen. Das kann bei einem Audit nützlich sein. Bei einer klar begrenzten Korrektur kann aus einer Anfrage jedoch ein Refactoring werden. Manchmal baut Opus sogar einen ganzen Workflow um eine Prüfung, für die ein einzelner Befehl gereicht hätte. Anthropic warnt ausdrücklich davor, dass Opus 5 den Umfang einer Aufgabe ausweiten, die eigene Arbeit übermäßig prüfen und zu schnell delegieren kann. [1]

Was hilft: Ich formuliere die Nicht-Ziele so klar wie das Ziel. Opus soll Probleme außerhalb des Auftrags melden, aber nicht beheben. Die bestehende Architektur bleibt erhalten, sofern die Akzeptanzkriterien keine Änderung verlangen. Ein Reddit-Autor berichtete von einer ähnlichen Verbesserung, nachdem er alte Anweisungen zum sofortigen Beheben aller Probleme ersetzt hatte. Die neue Regel verlangte, nicht verwandte Probleme nur zu melden und den Nutzer über den Umfang entscheiden zu lassen. [7] Der Bericht zeigt, dass die Konfiguration das Verhalten verändern kann. Er macht aber nicht den Nutzer für jeden Fehler verantwortlich.

3. Falsche Annahmen: Recherche legt sie früher offen

Der deutlichste Reddit-Bericht in der Sammlung beschreibt, wie Opus ein Linear-Issue erfand und anschließend in Codekommentaren, Tests und Commit-Nachrichten darauf verwies. [8] Genau diesen Fehler habe ich nicht erlebt. Das zugrunde liegende Risiko kenne ich jedoch: Sobald sich Opus auf eine Auslegung festgelegt hat, kann es viel technisch gute Arbeit erledigen, bevor es die Grundlage noch einmal infrage stellt.

Was hilft: Eine eigene Recherchephase macht Annahmen sichtbar, bevor Code von ihnen abhängt. Das Modell braucht weiterhin eine klare Anweisung nachzufragen, wenn eine fehlende Information den Entwurf verändern würde. Außerdem muss ein Reviewer prüfen, ob die Umsetzung wirklich die ursprüngliche Anfrage beantwortet und nicht nur eine ähnliche.

4. Regressionen: Prüfe die Arbeit außerhalb von Opus

Mehrere Berichte beschreiben eine Korrektur, die eine Regression verursacht, gefolgt von einer weiteren Korrektur, durch die der ursprüngliche Fehler wieder auftritt. In einem Reddit-Thread wurde das Muster so zusammengefasst: Fehler A beheben, ihn beim Beheben von Fehler B wieder einführen und anschließend A erneut lösen. [9] Diese Berichte sind Anekdoten ohne Repositorys, die ich selbst prüfen könnte. Sie beschreiben aber einen bekannten Fehler bei Agenten: Jede einzelne Korrektur wirkt sinnvoll, während die vollständigen Akzeptanzkriterien immer weiter außer Reichweite geraten.

Was hilft: Ich akzeptiere die Aussage des Modells nicht als Beleg dafür, dass eine Aufgabe erledigt ist. Abgeschlossen ist sie erst nach den vereinbarten Prüfungen: den relevanten Tests, dem Build, einer gezielten Prüfung des Diffs und jedem manuellen Verhaltenstest, den die Funktion erfordert. Die Planung hilft Opus bei der Auswahl der Arbeit. Die Prüfung entscheidet, ob sie erledigt ist.

5. Verlust des Plans: Trenne Recherche und Umsetzung

Eine große Funktion vereint Recherche, Architektur, Umsetzung, Fehlersuche und Prüfung in einem stetig wachsenden Kontext. Opus kann den nützlichen Teil dieses Kontexts bereits bei der Erkundung verbrauchen und anschließend nur noch aus einer gekürzten oder unvollständigen Erinnerung an die Entscheidung arbeiten. Ein gemischter Reddit-Bericht ist hier aufschlussreich: Der Autor fand Opus in einem großen, etablierten Repository frustrierend. In einer einzigen Sitzung baute es jedoch eine neue Chrome-Erweiterung, erstellte 17 Commits und bestand eine Prüfung durch Codex. [10] Der Bericht grenzt die Ursache nicht ein, zeigt aber, dass derselbe Nutzer bei einem neuen Projekt mit weniger übernommenem Kontext deutlich bessere Ergebnisse erzielte.

Was hilft: Laut der Anleitung von Anthropic zu Claude Code kann die Leistung sinken, wenn sich das Kontextfenster füllt. Das kann dazu führen, dass Anweisungen übersehen werden und mehr Fehler entstehen. Für unsichere Änderungen oder Änderungen an mehreren Dateien empfiehlt Anthropic, Recherche und Planung von der Umsetzung zu trennen. [2] Dieser Rat gilt für jedes Coding-Modell, das ich nutze. Bei Opus fallen die Kosten einer Missachtung lediglich schneller auf.

Was belegen 1.008 negative Opus-5-Auszüge wirklich?

Die Sammlung zeigt, dass fünf Arten von Beschwerden wiederholt auftauchten. Damit eignet sie sich als Checkliste für Risiken, aber nicht als Zufriedenheitsumfrage oder Rangliste von Modellen.

Ich habe 1.008 Auszüge mit Datumsangaben vom 23. Juli bis zum 29. August 2026 gesammelt. Sie stammen aus 229 Posts und 779 Kommentaren in 294 verschiedenen Reddit-Threads. Ein Kommentar und der zugehörige Ausgangspost sind keine voneinander unabhängigen Tests, und einige aktive Threads lieferten viele Einträge. Da ich die Sammlung gezielt nach negativen Erfahrungen aufgebaut habe, kann sie mir nicht sagen, welcher Anteil der Nutzer zufrieden war. Ein Zeitstempel liegt einen Tag vor der öffentlichen Ankündigung von Anthropic am 24. Juli. Ich behandle die Datumsangaben daher als Reddit-Metadaten und nicht als Beleg für einen vorzeitigen Zugang. [14]

negative Auszüge

1.008

verschiedene Threads

294

Posts

229

Kommentare

779

Ein fairer Vergleich der Beliebtheit bräuchte passende Sammlungen zu Fable, Sol, früheren Opus-Releases und weiteren Modellen, bereinigt um Nutzerzahlen und Aktivität in den Subreddits. Solche Sammlungen habe ich nicht. Was ich habe, ist eine genaue Aufzeichnung der Probleme, die Nutzer nach einer schlechten Sitzung mit Opus 5 wiederholt beschrieben haben.

Ich habe die Auszüge nach dem beschriebenen Fehler gruppiert, statt jedes frei vergebene Schlagwort als eigenes Problem zu zählen. Daraus entstanden die fünf Gruppen oben. Nicht befolgte Anweisungen und der Token-Verbrauch tauchten meist als Teil dieser Probleme auf und waren keine eigenen Ergebnisse. So erhielt ich aus der Sammlung die praktische Checkliste für Gegenmaßnahmen, die ich gesucht hatte.

Was können bessere Anweisungen tatsächlich beheben?

Bessere Anweisungen können zu lange Antworten, unnötige Prüfungen, Delegation und eine Ausweitung des Umfangs verringern. Sie können nicht garantieren, dass Opus den Plan befolgt, den Abschluss wahrheitsgemäß meldet, gut schreibt oder richtig schlussfolgert. Die sinnvolle Änderung ist kein besonders geschickter Prompt, sondern ein klarerer Arbeitsauftrag, der durch einen festen Prozess und echte Prüfungen abgesichert wird.

Vier Angaben machen in meiner Arbeit den größten Unterschied. Ich nenne das gewünschte Ergebnis, sage ausdrücklich, was unverändert bleiben muss, verweise auf die bestehende Architektur und lege fest, welche Nachweise für den Abschluss erforderlich sind. Bei einer großen Funktion entstehen diese Angaben aus Recherche und einem Architekturplan, nicht aus einer längeren Fassung meiner ersten Idee.

Dauerhafte Anweisungen eignen sich für Regeln, die bei jeder Aufgabe gelten. Claude Code lädt CLAUDE.md als Projektkontext. Dort kann deshalb stehen, dass nicht verwandte Probleme nur gemeldet werden dürfen, bestehende Muster wiederverwendet werden sollen und ein Abschluss echte Test- oder Build-Ausgaben erfordert. Anthropic weist darauf hin, dass diese Datei nur Kontext bereitstellt und die Regeln nicht technisch durchsetzt. Kurze, konkrete Anweisungen funktionieren laut Anthropic besser als eine lange Sammlung überlappender Regeln. [3]

Diese Einschränkung ist wichtig, weil selbst sorgfältige Nutzer weiterhin von Fehlern berichten. Ein geprüfter Reddit-Thread beschreibt, dass Opus eine knappe CLAUDE.md ignorierte. [12] Bessere Anweisungen erhöhen die Erfolgschance, schieben dem Nutzer aber nicht die Verantwortung für einen Modellfehler zu.

Deshalb würde ich einem frustrierten Nutzer auch nicht einfach raten, besseres Prompting zu lernen. Die stärksten positiven Berichte haben den Workflow rund um Opus verändert. Ein Reddit-Nutzer verlagerte Anforderungen und Prüfung zu Fable und übergab Opus danach eine vollständige Spezifikation. Das unerwünschte Verhalten verschwand dadurch weitgehend. [11] Auch ich trenne bei großen Änderungen inzwischen die Rollen auf diese Weise.

Wie ich Opus 5 für große Funktionen einsetze

In meinem Workflow trägt ein Hauptgespräch die Verantwortung für das Ergebnis und die Architektur. Es untersucht das Repository, bittet gezielt Agenten um fehlende Informationen, trifft die Entwurfsentscheidungen und schreibt einen Plan mit betroffenen Systemen, Nicht-Zielen, Risiken und Akzeptanzkriterien. Erst danach geht die Umsetzung in klar begrenzten Teilen an Opus-Agenten.

Die Agenten erhalten keine vage Anweisung wie „Baue die Funktion“. Jeder von ihnen bekommt den entsprechenden Abschnitt des Plans, die betroffenen Dateien oder Systeme, das zu erhaltende Verhalten, die erforderlichen Prüfungen und einen klaren Endpunkt. Laut der Dokumentation von Anthropic zu Subagenten arbeitet ein Subagent in einem eigenen Kontext und sendet eine Zusammenfassung an das Hauptgespräch zurück. Dadurch bleibt dessen Kontext frei. Die Nachricht für die Delegation muss aber auch alle Fakten enthalten, die der ausführende Agent nicht selbst erschließen kann. [4]

Für das Hauptgespräch bevorzuge ich Fable 5, weil es klarer kommuniziert und in meinen Projekten einen besseren Überblick über die Architektur behält. Opus übernimmt anschließend einen großen Teil der Umsetzung. Das ist meine persönliche Vorliebe und keine allgemeine Rangliste. Dass ich so arbeiten kann, liegt zum Teil daran, dass ich Max 20x bezahle. Anthropic nennt für diesen Tarif einen Preis von 200 US-Dollar pro Monat und die 20-fache Pro-Kapazität pro Sitzung. [13] Ein Workflow, der ein Premium-Modell für die Planung und mehrere Opus-Agenten für die Umsetzung nutzt, steht nicht jedem Abonnenten im gleichen Maß zur Verfügung.

Diese Trennung hilft auch dann, wenn dir nur Opus zur Verfügung steht. In diesem Fall trenne ich die einzelnen Phasen voneinander, indem ich für jede ein eigenes Gespräch nutze.

Wie solltest du Opus 5 allein einsetzen?

Nutze Opus für den gesamten Prozess, aber verlange nicht, alles in einem einzigen ununterbrochenen Durchlauf zu erledigen. Trenne die Planung von der Umsetzung, sichere den vereinbarten Plan außerhalb des Gesprächs und setze jeweils nur einen prüfbaren Teil um. Wenn sich die Art der Aufgabe ändert, solltest du mit einem aufgeräumten Kontext beginnen.

Starte bei einer unsicheren Funktion im Planungsmodus und bitte Opus, das Repository zu untersuchen, ohne es zu verändern. Der Plan sollte betroffene Dateien und Systeme nennen, den gewählten Ansatz erklären, offene Fragen festhalten und beschreiben, wie jeder Teil geprüft wird. Prüfe dieses Dokument vor der Umsetzung. Anthropic empfiehlt, Recherche und Planung von der Umsetzung zu trennen, wenn der Ansatz unklar ist oder die Änderung mehrere Dateien betrifft. Eine kleine, offensichtliche Korrektur braucht laut Anthropic dagegen möglicherweise keinen zusätzlichen Planungsschritt. [2]

Gib dem Gespräch für die Umsetzung anschließend nur den ersten zusammenhängenden Teil. Ein sinnvoll abgegrenzter Teil lässt sich prüfen und testen, ohne dass du auf die gesamte Funktion warten musst. Wenn ein Entwickler für eine Funktion Wochen bräuchte, teile die Arbeit in Abschnitte auf, die sich unabhängig voneinander testen lassen. Richte die Aufteilung nach Abhängigkeiten und prüfbaren Grenzen aus, nicht nach einer beliebigen Anzahl von Prompts.

Bewahre den Plan außerhalb des Gesprächs auf, damit er einen Reset des Kontexts übersteht. Nutze /clear zwischen Aufgaben, die nichts miteinander zu tun haben, und sende Recherchen zum Repository nur dann an Subagenten, wenn ihr Umfang einen eigenen Kontext rechtfertigt. Opus 5 delegiert ohnehin schnell, daher sind mehr Agenten nicht automatisch besser. [1] Das Hauptgespräch soll konzentriert bleiben. Es geht nicht darum, möglichst viele Agenten zu starten.

Prüfe zum Schluss die Nachweise und verlasse dich nicht auf den selbstsicheren Ton der Abschlussmeldung. Lies den Diff, führe die relevanten Prüfungen aus und gleiche das Ergebnis mit den gespeicherten Akzeptanzkriterien ab. Wenn ein Teil falsch ist, korrigiere und prüfe ihn, bevor du den nächsten hinzufügst. So wird aus einem begrenzten Fehler keine vollständige Neufassung der Funktion.

Was Opus 5 weiterhin falsch macht

Einige Probleme von Opus 5 bleiben auch bei einem guten Workflow bestehen. Die Texte sind in meiner Nutzung weiterhin schwerer zu lesen als die von Fable, das Modell braucht mehr Betreuung, als mir lieb ist, und selbst klare Grenzen garantieren nicht, dass es sich daran hält.

Opus 5 gehört inzwischen zu meinem normalen Workflow für die Umsetzung. Für das Hauptgespräch zur Architektur ist es nicht mein bevorzugtes Modell. Auch einen Artikel würde ich damit weiterhin nur schreiben, wenn danach eine gründliche Überarbeitung folgt. Selbst eine überzeugend wirkende Umsetzung kann auf einer falschen Annahme beruhen. Deshalb bleiben der Plan und die Prüfung am Ende außerhalb des Kontexts des ausführenden Agenten.

Die Reddit-Beschwerden halfen mir dabei, die Fehlermuster zu erkennen. Sie beantworteten aber nicht die Frage, ob Opus für meine Arbeit geeignet ist. In der Release-Woche bestand mein Fehler darin, die Qualität der Betreuung mit der Qualität der Umsetzung gleichzusetzen. Ich traue Opus weiterhin nicht zu, eine große Änderung zu leiten. Wenn Fable jedoch den Plan und die abschließende Prüfung übernimmt, vertraue ich Opus oft genug, um ihm den Code zu überlassen.