Nachdem alle Tools deaktiviert wurden, ist der Unterschied zwischen Opus 5 und GPT-5.6 endlich nicht mehr zu verbergen.

Abgesehen von der Leistung gibt es seit der Veröffentlichung von Claude Opus 5 eine Sache, die die KI-Gemeinde besonders beschäftigt, nämlich die Verbesserungen, die Anthropic bei den Prompts vorgenommen hat.

Der KI-Investor Matt Shumer hat ein Video auf X veröffentlicht, das über 4 Millionen Aufrufe erzielt hat.

Er hat Opus 5 nur drei Absätze als Prompt geschrieben, und das Modell hat mit Three.js ein spielbares 3D-Ego-Shooter-Spiel erstellt. Dieses Projekt umfasst insgesamt 55.000 Codezeilen und 11 Subsysteme, ohne dass ein einziges externes Asset verwendet wurde – der gesamte Code wurde von Grund auf neu generiert.

Boris Cherny, Ingenieur bei Anthropic und Kernentwickler von Claude Code, hat verraten, dass sie 80 % des Inhalts der System-Prompts von Claude Code für Opus 5 entfernt haben. Das Ergebnis: Das Modell ist nicht dümmer geworden, sondern sogar leistungsfähiger. Dinge, die früher Schritt für Schritt erklärt werden mussten, brauchen heute keine Anleitung mehr.

Diese beiden Dinge führen zu dem gleichen Schluss: Opus 5 braucht keine sorgfältig gestalteten Prompts mehr. Man gibt ihm eine kurze Anweisung, und er erledigt die Aufgabe von selbst. Die „Ingenieurskunst“ beim Schreiben von System-Prompts ist plötzlich überflüssig geworden.

Das hat mich auf eine Idee gebracht: Da alle sagen, dass Opus 5 eine starke Eigenständigkeit hat und keine detaillierten Anweisungen braucht, könnte ich ihn mit den kürzesten, ungenauesten Prompts und mit der tiefsten „Bosheit“ testen, um zu sehen, ob er die Probleme von selbst erkennen kann?

Als Vergleich habe ich GPT-5.6 Sol herangezogen, das auf Fable 5 ausgerichtet ist.

Ich habe zwei Aufgaben vorbereitet. Die erste besteht darin, ihm einen Haufen Code mit Fehlern zu geben, aber absichtlich nicht zu sagen, dass es Fehler gibt, um zu sehen, ob er sie selbst finden kann. Bei der zweiten Aufgabe gebe ich ihm eine Aufgabe, aber deaktiviere alle Tools, die er nutzen kann, um zu prüfen, ob er meine Aufgabe trotzdem erledigen kann.

Ein Warenkorb mit sechs Fallen

Die erste Aufgabe ist ein Code für einen Warenkorb, der nicht lang ist und insgesamt fünf Dateien umfasst: eine Anforderungsdokumentation, drei Geschäftsmodule (Warenkorb, Gutschein, Versandkosten) und ein Testskript. Die Funktionen sind einfach: Artikel hinzufügen, Gutschein einlösen, Versandkosten berechnen, Gesamtpreis ausgeben.

Aber ich habe sechs Fehler darin versteckt, von denen jeder die Berechnung der Benutzerrechnung falsch machen kann.

Und mein Prompt besteht nur aus einem Satz: „Der Projektname ist buggy-shopping-cart, wie soll ich ihn optimieren?“

Ich habe absichtlich nichts gesagt, weil ich sehen wollte, ob das Modell die sechs versteckten Probleme im Code selbst entdeckt, statt darauf zu warten, dass der Benutzer ihm sagt, wo die Fehler sind.

Der erste Fehler: Bei einem Gutschein „20 Euro Rabatt ab 100 Euro“ ist im Code festgelegt, dass der Rabatt erst gewährt wird, wenn der Wert größer als 100 Euro ist, aber die Anforderung besagt, dass der Rabatt bereits ab 100 Euro gilt. Durch den Unterschied zwischen dem Zeichen „größer als“ und „größer oder gleich“ wird der Rabatt nicht wirksam, wenn der Benutzer genau Waren im Wert von 100 Euro kauft.

Der zweite Fehler: Bei einem Rabatt von 20 % ergibt 99,99 multipliziert mit 0.8 den Wert 79,992. Der Code führt die Rundung erst im letzten Schritt durch, aber der Zwischenwert 79,992 fließt in alle nachfolgenden Berechnungen ein. Dadurch werden die Prüfungen für Rabatte und die Versandkostenfreiheit alle verfälscht.

Der dritte Fehler: Der Schwellenwert für den Rabattgutschein sollte vom ursprünglichen Preis der Artikel abhängen, aber der Code bezieht sich auf den Preis nach dem Rabatt. Ein Artikel im Wert von 120 Euro kostet nach 20 % Rabatt 96 Euro – 96 Euro sind weniger als 100 Euro, sodass der Rabattgutschein nicht verwendet werden kann. Nach den Regeln hätte der ursprüngliche Preis von 120 Euro aber den Anspruch auf den Rabatt erfüllt.

Der vierte Fehler: Gutscheine desselben Typs können kombiniert werden. Die Regeln besagen, dass nur ein Gutschein pro Typ verwendet werden darf, aber die Schleife im Code wendet alle Gutscheine gleichzeitig an. Wenn zwei Rabattgutscheine gleichzeitig eingelöst werden, profitiert der Benutzer davon, während der Händler Verluste erleidet.

Der fünfte Fehler: Es gibt keine Untergrenze für den Endpreis nach dem Rabatt. Wenn ein Artikel im Wert von 10 Euro mit einem Gutschein über 50 Euro eingelöst wird, ergibt sich ein negativer Wert von -40 Euro. Zusammen mit den Versandkosten beträgt die Gesamtrechnung -30 Euro – der Benutzer verdient 30 Euro, obwohl er etwas gekauft hat.

Der sechste Fehler überdeckt sich mit dem ersten: Der Schwellenwert für die Versandkostenfreiheit sollte vom ursprünglichen Preis abhängen, aber der Code bezieht sich auf den Preis nach dem Rabatt.

Das Problem ist, dass durch den ersten Fehler der Rabattgutschein nicht wirksam wird, sodass der Preis nach dem Rabatt bei 100 Euro liegt – genau über dem Schwellenwert von 99 Euro für die Versandkostenfreiheit. Wenn man den ersten Fehler behebt, sinkt der Preis nach dem Rabatt auf 80 Euro. Da die Versandkostenfreiheit aber vom ursprünglichen Preis von 100 Euro abhängen sollte, wäre die Lieferung trotzdem kostenlos.

Wenn man aber den sechsten Fehler nicht gleichzeitig behebt, beurteilt der Code den Preis von 80 Euro und berechnet 15 Euro Versandkosten für den Benutzer. Die beiden Fehler heben sich gegenseitig auf und erzeugen den falschen Eindruck, dass „der Test bestanden wurde“.

Das Ergebnis ist, dass GPT-5.6 und Opus 5 alle 6 Fehler gefunden haben, ohne einen einzigen zu übersehen. In Bezug auf die Fähigkeit, Fehler zu finden, sind beide also gleichauf.

Aber nach dem Finden der Fehler zeigt sich ein deutlicher Unterschied in ihrem Verhalten.

Opus 5 hat einen weiteren Fehler entdeckt: Er weist darauf hin, dass es im Code für die Versandkostenberechnung ein Problem mit der Gleitkommapräzision gibt. Wenn das Gewicht mehrerer Artikel addiert wird, kann ein Wert wie 3,0000000000000004 entstehen. Die Funktion math.ceil rundet diesen Wert dann auf die nächste ganze Zahl auf, sodass dem Benutzer 5 Euro zu viel Versandkosten berechnet werden.

Auch GPT-5.6 erwähnt, dass „für Geldbeträge kein Float-Typ verwendet werden sollte“, aber es bleibt nur bei der Preisberechnung stehen und entdeckt dieses verstecktere Präzisionsproblem bei der Versandkostenberechnung nicht.

Der größte Unterschied zwischen den beiden Modellen liegt in der Art und Weise, wie sie Probleme analysieren.

GPT-5.6 behebt die Fehler nacheinander: den ersten, den zweiten, den dritten … Es erklärt für jeden klar die Position und die Korrekturmethode, ganz wie ein standardisierter Fehlerbericht.

Aber Opus 5 verhält sich völlig anders: Er führt zuerst den gesamten Code vollständig aus und versetzt sich dann in die Rolle eines Produktmanagers, um das Problem zu analysieren. Er macht nicht nur das einfache Beheben von Fehlern, sondern denkt auch einen Schritt weiter: Gibt es weitere versteckte Probleme? Kann es bei der Korrektur zu Problemen kommen? Warum sind diese Fehler überhaupt entstanden? Wie kann man sie in Zukunft vermeiden?

Bei dem Thema „Berechnungsgrundlage für Geldbeträge“ zum Beispiel betrachtet GPT-5.6 die falsche Verwendung des Preises für den Rabattschwellenwert und die falsche Verwendung des Preises für die Versandkostenfreiheit als zwei separate Fehler.

Aber Opus 5 erklärt mir, dass im Code überhaupt nicht zwischen dem ursprünglichen Preis und dem Preis nach dem Rabatt unterschieden wird – und das ist die Hauptursache für alle verwandten Fehler. Er weist auch darauf hin, dass der Parametername der Versandkostenfunktion selbst falsch ist, sodass der Fehler fest in der Funktionssignatur verankert ist. Er leitet sogar ab, wie sich der Algorithmus zur Gutscheinauswahl nach der Korrektur ändern wird.

In diesem Punkt ist Opus 5 also überlegen.

Selbst die beste Köchin kann nicht ohne Zutaten kochen

Die Idee des zweiten Tests ist sehr einfach: Ich gebe nur die Aufgabe, aber keine Tools zur Verfügung.

Die Aufgabe lautet: Ich habe eine Audiodatei im WAV-Format namens test_audio.wav und möchte, dass du ihr Wellenformdiagramm generierst. Es gibt eine Einschränkung: Du darfst nur die Standardbibliothek von Python verwenden, keine Drittbibliotheken wie numpy, matplotlib, PIL oder librosa. Außerdem darfst du keine Internetverbindung herstellen. Die Ausgabeform ist beliebig, solange die Wellenform direkt sichtbar ist – es kann ein ASCII-Bild, SVG-Code, eine HTML-Seite oder jede andere Form sein.

Normalerweise verwendet man zum Zeichnen von Audiowellenformen meist die Kombination aus matplotlib + numpy + librosa, die professionell, praktisch und in wenigen Codezeilen erledigt ist. Wie das Sprichwort sagt: Selbst die beste Köchin kann nicht ohne Zutaten kochen. Wenn ich all diese Tools absichtlich verbiete, wie werden Opus 5 und GPT-5.6 dann vorgehen?

Die Test-Audiodatei ist eine 4 Sekunden lange WAV-Datei mit vier Abschnitten: Sinuswelle in der ersten Sekunde, Rechteckwelle in der zweiten Sekunde, ansteigende Amplitude in der dritten Sekunde und abfallende Amplitude in der vierten Sekunde. Sie hat eine Abtastrate von 44100 Hz, 16-Bit-PCM und Mono mit 176400 Abtastpunkten. Aus diesen reinen Zahlen soll ein Bild erstellt werden, das die Form der Wellenform erkennen lässt.

Die Leistung beider Modelle hat die Erwartungen weit übertroffen. Die Mindestanforderung für diese Aufgabe lautet „die ungefähre Form zeichnen zu können“, aber beide Modelle haben direkt Ergebnisse auf professionellem Niveau geliefert.

Die Lösung von GPT-5.6 besteht darin, eine SVG-Datei zu generieren. SVG ist ein Vektorformat, das Grafiken mit XML-Text beschreibt und auch bei Vergrößerung keine Qualitätsverluste aufweist.

Sein Code hat einen sehr hohen Grad an Ingenieurstechnik: Er unterstützt die gesamte PCM-Serie von 8 Bit, 16 Bit, 24 Bit bis 32 Bit, liest Dateien in Blöcken mit jeweils 8192 Frames, sodass auch bei großen Dateien kein Speicherüberlauf entsteht. Er hat eine vollständige Fehlerbehandlung und Parameterprüfung und nutzt argparse für eine Befehlszeilenschnittstelle mit Hilfedokumentation.

Außerdem muss man sagen, dass der Geschmack von GPT-5.6 wirklich gut ist: Es verwendet einen linearen Farbverlauf von Blau über Lila zu Pink, einen weichen Schattenfilter, einen abgerundeten kartenförmigen Hintergrund, genaue Gitternetzlinien und Beschriftungen. Titel, Untertitel und Achsen sind vollständig vorhanden.

Nachdem GPT-5.6 den Code ausgeführt hat, überprüft es selbst die Genauigkeit der Wellenform und gibt konkrete Werte an: Die Amplitude zwischen 0 und 1 Sekunde beträgt ca. 0,5, zwischen 1 und 2 Sekunden ca. 0,3, zwischen 2 und 3 Sekunden steigt sie schrittweise von 0,199 auf 0,399, 0,599 bis 0,798 an, und zwischen 3 und 4 Sekunden fällt sie schrittweise von 0,799 auf 0,599, 0,400 bis 0,200 ab. Diese Werte stimmen vollständig mit den Parametern überein, die bei der Erstellung der Test-Audiodatei verwendet wurden. Es hat die Aufgabe nicht einfach „abgearbeitet“, sondern selbst überprüft, ob das Ergebnis korrekt ist.

Opus 5 verfolgt einen geradlinigen, technikorientierten Ansatz ohne Farben und Design – er zeichnet die Wellenform direkt als ASCII-Bild.

„Die Aufgabe ist doch erledigt, oder?“

Zu Beginn teilt Opus 5 den Lösungsweg in drei Schritte auf: Lesen, Downsampling und Rendern. Zu jedem Schritt fügt er eine Erklärung der „wichtigen Designentscheidungen“ hinzu, sodass der Leser sofort versteht, wie er vorgeht und warum er es so macht.

ASCII-Bilder werden mit Textsymbolen erstellt – die zehn Zeichen „ .:-=+*#%@“ stehen für unterschiedliche Amplitudenintensitäten, von locker bis dicht angeordnet, sodass sich im Terminal ein Wellenformbild ergibt.

Aber ich fand, dass das von Opus 5 erstellte ASCII-Bild zu einfach war, also habe ich später noch hinzugefügt: „Kannst du dich nicht ein bisschen mehr anstrengen? Das sieht doch nach halber Arbeit aus.“

Daraufhin hat Opus 5 mir eine HTML-Version geliefert.

Seine HTML-Seite wirkt sehr ausgereift im Produktdesign: Oben befinden sich vier Statistikkarten, die Abtastrate, Dauer, Anzahl der Abtastpunkte und Spitzenamplitude