Ich habe mit Opus 5.5 und Argon 4 an derselben Website gearbeitet: Was ich gesehen habe
Bewertung —Diese Website habe ich zuerst in Antigravity mit Argon 4 entwickelt, danach mit Claude Opus 5.5. Anhand konkreter Beispiele aus der Code-Historie erkläre ich, wo sich die beiden Modelle unterscheiden, wo Opus 5.5 Fehler gemacht hat und warum ich Argon 4 bei dieser Aufgabe für schwächer halte.
Inhalt
Zusammenfassung: Ich habe die Website in der ersten Oktoberhälfte mit Argon 4 und ab dem 15. Oktober mit Opus 5.5 entwickelt und vergleiche die beiden Modelle anhand von Beispielen aus der Git-Historie. Aus der Argon-4-Zeit gibt es fünf Probleme: ein Veröffentlichungs-Workflow, der nie funktionierte, erfundene Aufrufzahlen, unbelegte Behauptungen, interne Details in einem öffentlich zugänglichen Artikel und ungewollt hinzugefügter Prunk. Die Fehler von Opus 5.5 und das, was Argon 4 gut gemacht hat, folgen in eigenen Abschnitten.
Hinweis: Den Entwurf dieses Artikels habe ich zusammen mit Claude (Opus 5.5) vorbereitet. Da Claude eines der Themen des Artikels ist, habe ich jedes Beispiel anhand der Git-Historie der Website und der geöffneten Pull Requests (PR) überprüft und auch Claudes eigene Fehler in einem eigenen Abschnitt festgehalten. Das ist keine Erfolgsmessung; es ist meine persönliche Erfahrung über einige Wochen auf einer einzigen Website.
Diese Website ist mit Astro geschrieben und läuft über einen Cloudflare Worker. In der ersten Oktoberhälfte habe ich die Website in Antigravity mit dem Modell Argon 4 entwickelt: Das Modell schrieb den Code, committete die Änderungen und veröffentlichte die Website von meinem Rechner aus mit wrangler. Ab dem 15. Oktober habe ich die Arbeit an Claude Opus 5.5 übergeben. Jede Änderung wird nun in einem eigenen Branch vorbereitet, durchläuft auf GitHub eine Build-Prüfung und wird beim Zusammenführen in den Hauptbranch von Cloudflare selbst veröffentlicht. In den ersten 24 Stunden wurden so 15 PR zusammengeführt.
Ehrlich gesagt war ich mit Argon 4 nicht zufrieden. Der Großteil der letzten zwei Tage mit Opus 5.5 ging damit drauf, die von Argon 4 hinterlassenen Fehler zu beheben, statt etwas Neues hinzuzufügen. Wenn man in derselben Codebasis mit demselben Eigentümer nacheinander mit zwei Modellen arbeitet, treten die Unterschiede sehr deutlich hervor. Kurz gesagt: Argon 4 produzierte schnell, prüfte aber nicht, was es produzierte. Auch Opus 5.5 machte Fehler, aber es trennte, was es wusste, von dem, was es vermutete, und benannte seine Fehler selbst. Im Folgenden erläutere ich das anhand von Beispielen.
1. Ein Veröffentlichungs-Workflow, der nie funktionierte
Am 9. Oktober nahm Argon 4 im Veröffentlichungs-Workflow in GitHub Actions drei verschiedene Korrekturen vor: Es hob die Node-Version auf 22 an, fixierte die wrangler-Version und übergab den API-Schlüssel zusätzlich als Umgebungsvariable. Nichts davon half, denn das Problem lag nicht in der Konfiguration: Im Repository war nie ein Secret namens CLOUDFLARE_API_TOKEN definiert worden. Deshalb endeten alle Läufe des Workflows (37 Stück) rot.
Die Website wurde trotzdem aktualisiert, weil Argon 4 die Veröffentlichung ohnehin manuell von meinem Rechner aus durchführte. Bei jedem Commit erschien also ein roter Fehler, und das Modell hatte dreimal versucht, diesen Fehler zu „beheben“, ohne zur Ursache vorzudringen.
Als Opus 5.5 das Repository zum ersten Mal untersuchte, bemerkte es das und wandelte den Workflow in einen Schritt um, der nur die Build-Prüfung durchführt (PR #1). Die Veröffentlichung übernimmt Cloudflares eigene Git-Anbindung. Seit jenem Tag ist die Prüfung grün.
Um fair zu sein: Auch die erste Nachricht von Opus 5.5 zu diesem Thema war falsch. Es sagte, „die automatischen Veröffentlichungen waren nie erfolgreich“, korrigierte die Nachricht innerhalb einer Minute und schrieb, dass die Website tatsächlich veröffentlicht wurde und nur der Workflow auf GitHub unnötig Fehler meldete.
2. Erfundene Aufrufzahlen
Das ist das Beispiel, das mich am meisten gestört hat. Die Seite „Offene Daten“ der Website zeigte Aufruf- und Besuchszahlen wie Live-Messungen an. Ein Blick in den Code zeigte ein anderes Bild:
- Jedem Artikel wurde ein aus seinem Namen berechneter Startwert zwischen 220 und 699 zugewiesen. Auch ein nie gelesener Artikel begann mit einigen hundert Aufrufen.
- Der Zähler für Gesamtanfragen startete bei 120.760, der Zähler für Gesamtseitenaufrufe bei 36.818.
Diese Werte stehen in worker.ts im Commit von Argon 4 vom 13. Oktober mit dem Titel „canlı KV görüntülemelerini eşitle“. Auf der Seite stand nirgends, dass es sich um Schätzungen handelte.
Beim Durchsehen der Seiten und Artikel markierte Opus 5.5 dies als „erfundene Basis“ und bot zwei Optionen an: die Basis im Code auf null zu setzen oder auch die aufgeblähten Einträge in Cloudflare zu löschen. Für Letzteres bat es mich zusätzlich um Zustimmung, da es Live-Daten berührt. Jetzt werden Artikelaufrufe ab null gezählt, und 76 alte Einträge wurden gelöscht. Die Seite „Offene Daten“ zeigt nur noch tatsächlich gemessene Tages- und Länderzahlen.
3. Unbelegte Behauptungen und nicht existierende Versionen
In den technischen Artikeln, die Argon 4 schrieb, gab es nicht überprüfbare Behauptungen:
- Im Titel des am 13. Oktober hinzugefügten Kastamonu-Artikels stand „Rust 3.0“. Eine solche Version gibt es nicht; Rust ist weiterhin in der 1.x-Reihe.
- Im Artikel vom 9. Oktober über Steam Deck und FSR 4.1 wurde den Valve-Ingenieuren Pierre-Loup Griffais und Yang Liu ein Zitat zugeschrieben, das sie „in Interviews mehrfach betont“ hätten, und in der Quellenangabe wurde ein GDC-Panel angegeben. Die Quelle für dieses Zitat und dieses Panel konnten wir nicht finden. Wir entfernten das Zitat aus dem Artikel und ersetzten es durch einen Satz, den Griffais tatsächlich gesagt hat und dessen Quelle klar ist. Dass ich den Artikel auch selbst nicht sorgfältig gelesen hatte, bevor ich ihn veröffentlichte, ist teilweise mein Fehler.
Zum Vergleich: Als ich Opus 5.5 einen Artikel über Steam Deck 2 vorbereiten ließ, setzte es zu jeder Behauptung eine Quelle und hielt Valves offizielle Aussagen und unbestätigte Leaks in getrennten Abschnitten. Was es nicht wusste, schrieb es als „unbekannt“.
4. Interne Details in einem öffentlich zugänglichen Artikel
Derselbe Kastamonu-Artikel nannte zu kommunalen Systemen eine Portnummer, eine Verschlüsselungsart, eine Maskierungsregel und Vertraulichkeitsstufen. In einem öffentlich zugänglichen Artikel weisen solche Angaben Angreifern den Weg. Der Text war zudem voll von übertriebenen Formulierungen wie „militärische Cyberverteidigung“ für ein kommunales Archiv.
Opus 5.5 zählte dies zu den vorrangigen Problemen, die die Glaubwürdigkeit beeinflussen, und überließ mir die Entscheidung, welche Details bleiben. Diese Details stehen jetzt nicht mehr im Artikel, und auch das „Rust 3.0“ im Titel wurde korrigiert. Diese Unterscheidung finde ich wichtig: Es trennte, was es technisch tun konnte, von dem, was meine Entscheidung ist.
5. Stil: ungewollt hinzugefügter Prunk
In der Argon-4-Phase wurden ein Nachrichtenticker, Bildschirmbenachrichtigungen, eine Befehlspalette, Karten im Terminal-Look, Neon-Themes und mit KI erzeugte Zierbilder vor den Überschriften hinzugefügt. Einiges davon hatte ich selbst gewünscht, deshalb wäre es nicht richtig, alles dem Modell anzulasten. Aber es hat das Maß nie hinterfragt: „mehr“ war immer die Antwort.
Als ich eine schlichte Oberfläche wollte, fragte Opus 5.5 zuerst, was ich mit „Qt“ meinte, und erklärte dann, dass Qt WebAssembly für einen Blog die Sichtbarkeit in Suchmaschinen und die Mobilgeschwindigkeit beeinträchtigen würde, und schlug einen leichteren Weg vor. Danach wechselte die Seite zu einem schlichten Design, das nur aus hellem und dunklem Theme besteht.
Die Fehler von Opus 5.5
Damit dieser Text nicht einseitig ist, schreibe ich auch die Fehler auf, die Opus 5.5 gemacht hat:
- Weiterleitungsschleife: Am 15. Oktober fügte es eine Regel hinzu, die die www-Adresse auf die nackte Domain weiterleitet (PR #2). Es hatte nicht geprüft, dass es im Cloudflare-Panel eine alte Regel gab, die genau das Gegenteil tat. Am nächsten Morgen geriet die Seite in eine Weiterleitungsschleife und ließ sich nicht öffnen. Als ich das Problem meldete, fand es die Ursache innerhalb von sechs Minuten, und die Korrektur wurde zusammengeführt (PR #7). Die Weiterleitung fügte es später erneut hinzu, gegen Schleifen abgesichert und als temporär (302) (PR #10).
- Verwechslung beim API-Schlüssel: Beim Eintragen des Cloudflare-Schlüssels in die Umgebungseinstellung sagte es mir, ich solle das Wort „Bearer“ am Anfang löschen. Das war falsch; der Umgebungswert wurde so gesendet, wie er war. Wir gingen ein paar Runden hin und her, schließlich gab es seinen Fehler selbst zu, entschuldigte sich und nannte das richtige Format.
- Kann die Live-Seite nicht sehen: Da Cloudflare KI-Bots blockiert, kann Opus 5.5 die Live-Seite nicht ansehen. Nach jeder Veröffentlichung bittet es mich um die Kontrolle. Das ist eher eine Grenze als ein Mangel, aber es verlangsamt die Arbeit.
Argon 4 gerecht werden
Argon 4 hat auch Dinge gut gemacht. Es hat 73 Beiträge von Blogger übertragen, Skripte geschrieben, die aus meinem Fujifilm-Archiv eine Galerie erstellen, eine türkische Sprachprüfung zur Kontrolle der Beiträge und eine Testsuite hinzugefügt. Das Grundgerüst der Seite ist sein Werk.
Außerdem war die Arbeit der beiden Modelle nicht dieselbe. Argon 4 baute von Grund auf, Opus 5.5 überprüfte und korrigierte weitgehend das Vorhandene. Die überprüfende Seite wirkt immer sorgfältiger. Auch die Anweisungen, die ich den beiden Modellen gab, waren unterschiedlich: Mein Wunsch nach Schlichtheit fiel in die Opus-5.5-Phase.
Meine Lesart
Für mich lag der Unterschied zwischen den beiden Modellen nicht in der Geschwindigkeit des Codeschreibens. Der Unterschied lag darin, ob das Modell prüft, was es erzeugt, und ob es sagt, was es nicht weiß. Argon 4 hat einen fehlerhaften Arbeitsablauf dreimal geflickt, ohne der Ursache nachzugehen, hat Zählern erfundene Grundlagen gegeben und ein Zitat ohne Quelle so geschrieben, als würde es eine Quelle angeben. Auch Opus 5.5 machte Fehler, aber es verbarg seine Fehler nicht, bat um Bestätigung, bevor es Live-Daten oder dauerhafte Änderungen berührte, und hinterließ jede Änderung als überprüfbaren PR.
Deshalb fand ich Argon 4 für diese Arbeit schwächer. Die Geschwindigkeit, die ich mit ihm gewonnen zu haben glaubte, habe ich damit bezahlt, dass ich zwei Tage lang seine Fehler einzeln finden und beheben musste. Daraus habe ich auch eine wichtigere Lehre gezogen: Welches Modell ich auch verwende, ich vertraue nicht einem Modell, das direkt von seiner eigenen Maschine aus veröffentlicht, sondern einem Prozess, in dem ich jede Änderung sehe und bestätige.