Genialer Neuling und erfahrener Senior
Meine Erfahrungen mit Codex und Claude Code
In diesen Tagen ist es nicht mehr besonders, wenn man sagt, dass man mit KI codiert.
Auch ich verwende verschiedene Modelle während der Entwicklung von Services, und insbesondere fühlen sich Codex(gpt-5-codex high) und Claude Code(Opus) wie zwei Kollegen an, die sehr unterschiedliche Eigenschaften haben.
Interessanterweise verpasst man die Essenz, wenn man sie einfach nur mit "Wer codiert besser?" vergleicht.
Es handelt sich weniger um eine Frage der Fähigkeiten als vielmehr um Unterschiede in der Persönlichkeit, die den Entwicklern ähnlich sind.
Codex: Genialer Neuling-Entwickler
Als ich Codex zum ersten Mal benutzte, war das Beeindruckendste die Geschwindigkeit.
Wenn man ein Problem wirft, kommt der Code sofort ohne Zögern heraus. Die Fähigkeit, Ideen in Strukturen umzuwandeln, ist hervorragend.
Es fühlt sich irgendwie so an.
"Könnte man das nicht so lösen?"
— Ein neuer Mitarbeiter, der gerade eingestellt wurde und besonders schnell denkt
Besonders in Situationen wie diesen ist Codex wirklich stark.
- Wenn man Ideen im Kopf schnell in Codeform sehen möchte
- Wenn man Prototypen, POCs oder experimentelle Strukturen erstellen möchte
- Wenn die grammatikalische Vollständigkeit einer Sprache oder eines Frameworks wichtig ist
Allerdings gibt es aus der Perspektive eines Entwicklers, der tatsächlich Rails-Services betreibt, auch klare Mängel.
Zum Beispiel, wenn man Migrationsdateien schreibt, gibt es manchmal Missverständnisse bezüglich der Absicht der up / down Methoden und der von Rails empfohlenen Änderungsmethoden (z. B. reversible Migration).
Auch bei Deploy-Tools wie Kamal kommt es manchmal vor, dass Antworten wie "Ich weiß, dass es existiert, aber ich kenne den Kontext nicht" gegeben werden.
Das liegt weniger an einem Mangel von Codex, sondern eher daran, dass es einem Entwickler ähnelt, der noch nicht viel Zeit mit dem Verwenden von Rails verbracht hat.
Claude Code(Opus): Erfahrener Senior, der lange mit Rails gearbeitet hat
Auf der anderen Seite ist Claude Code(Opus) von Anfang an anders.
Wenn man ein Problem wirft, beginnt er nicht sofort mit dem Schreiben des Codes. Er ordnet zuerst den Kontext.
"In Rails ist es natürlich, diesen Weg zu gehen."
Diese Art zu sprechen allein zeigt schon, dass es sich um einen Senior handelt.
Claude Codes Stärken sind klar.
- Verständnis des gesamten Rails-Ökosystems
- Der gesamte Ablauf von Migration über Deployment bis hin zum Betrieb
- Die Wahl von "Rails-intendiertem Code" anstelle von "möglichen Code"
Auch wenn man dieselbe Migration schreibt, schlägt er nicht einfach funktionierenden Code vor, sondern zuerst eine Form, die rückgängig gemacht werden kann und für das Team leicht zu warten ist.
Deshalb ist der von Claude Code vorgeschlagene Code nicht spektakulär.
Aber für jemanden, der tatsächlich Services betreibt, fühlt es sich an wie "Oh, das ist die Art und Weise, wie es in der Praxis gemacht wurde".
Ich halte diesen Punkt für sehr wichtig.
Letztendlich dauert es viel länger, einen Code zu betreiben als ihn zu schreiben.
So verwende ich beide Modelle
Deshalb trenne ich heutzutage die beiden Modelle absichtlich.
Anstatt dieselbe Frage zu stellen und die Antworten zu vergleichen, teile ich die Aufgaben auf und lasse sie zusammenarbeiten.
Normalerweise richte ich das so ein, wenn ich mit der Entwicklung beginne.
Ich öffne das Warp-Terminal und
erstelle zwei Panels nebeneinander.
- Linkes Panel: Claude Code(Opus)
- Rechtes Panel: Codex(gpt-5-codex high)
Auf der linken Seite ist immer Claude Code.
Hier wird der Code nicht sofort geschrieben.
Zuerst lasse ich Claude Code einen Plan erstellen.
- Wie sollte diese Funktion in Rails strukturiert sein?
- Wo sind die Grenzen zwischen Modellen, Controllern und Service-Objekten gut?
- In welcher Reihenfolge sollten Migrationen durchgeführt werden?
- Worauf muss man bei Deployment und Betrieb achten?
Claude Code verhält sich in diesem Stadium fast wie ein technischer Design-Reviewer.
"Das ist der Rails-typische Weg" kommt ganz natürlich.
Dann werfe ich denselben Plan Codex auf der rechten Seite zu.
"Kannst du prüfen, ob in diesem Plan etwas fehlt?"
"Gibt es hier Bereiche, die vereinfacht werden können?"
Codex spielt dabei eine wirklich gute Rolle.
Er zeigt schnell Schwachstellen in der Struktur auf oder bereinigt mutig überkomplizierte Teile.
Schreiben mit Claude, Überprüfen mit Codex
Wenn der Plan steht, schreibe ich den tatsächlichen Code wieder mit Claude Code.
Der Grund dafür ist einfach.
In Rails ist "Code, der überlebt" wichtiger als "Code, der funktioniert".
Der von Claude Code geschriebene Code mag zwar langsamer sein, aber
- er berücksichtigt das Zurücksetzen von Migrationen,
- verletzt nicht die Rails-Konventionen und
- ist in einer Form, die ich später verstehen kann.
Sobald der Code in gewisser Weise fertig ist, verwende ich Codex als Code-Reviewer.
- Kann dieser Logikteil einfacher geschrieben werden?
- Gibt es etwas in Abfragen oder Schleifen, das übersehen wurde?
- Gibt es Strukturen, die schwer zu testen sind?
Codex ist in diesem Stadium wirklich kompetent.
Es fühlt sich an, als würde ein aufgeweckter Neuling ohne Zögern Fragen zum Code des Seniors stellen.
Erkenntnisse aus der Verwendung beider KIs
Auf diese Weise wurde mir klar.
Es macht keinen großen Sinn, Codex und Claude Code zu vergleichen.
Wichtig ist, welche Rolle sie spielen.
- Codex ist stark in der Divergenz und Überprüfung
- Claude Code ist stark in der Akkumulation und Stabilität
Wenn man sie nebeneinander in den Panels von Warp hat,
fühlt es sich an, als ob man trotz des Alleinarbeitens zwei Entwickler mit unterschiedlichen Persönlichkeiten im Team hat.
Und ich bin nur der Entwickler, der die Entscheidungen trifft.