Ein Monat OpenAI Codex 5.2 – und wie Opus 4.6 danach aufgeräumt hat

Ich bin jemand, der neue Tools ernsthaft ausprobiert. Nicht für einen Nachmittag, sondern wirklich – mit echten Projekten, echtem Code, echtem Druck.

Als OpenAI im Dezember 2025 Codex 5.2 veröffentlichte, war klar: Das ist einen richtigen Test wert. Also habe ich es gemacht.

Was dabei herauskam, war interessanter als ich erwartet hatte – und die grösste Erkenntnis kam nicht aus dem Experiment selbst, sondern aus dem, was danach passierte.

Codex 5.2: Was es gut macht

Ich beginne dort, wo Codex 5.2 wirklich glänzt – denn das tut es.

Liefergeschwindigkeit. Wenn ich ein klares Feature beschreibe, liefert Codex schnell. Nicht immer perfekt, aber schnell. Für einen ersten Entwurf, für einen Proof of Concept, für das Ausformulieren einer Idee in Code – da ist Codex agil und direkt.

Grosse Repositories. Die Arbeit in grossen Codebasen, das Navigieren über Modulgrenzen hinweg – da hat Codex tatsächlich Stärken. Context Compaction funktioniert gut für lange Sessions in grossen Projekten, und die Resultate sind solide.

Refactoring und Migrationen. Für grössere Code-Änderungen, Umstrukturierungen, das Portieren von altem Code – da zeigt Codex, was es kann. Besonders bei grossen, klar definierten Umbauten liefert es zuverlässig.

Visuelle Verarbeitung. Screenshots, UI-Diagramme, technische Zeichnungen – Codex versteht visuelle Inputs gut und kann daraus funktionierenden Code generieren. Das hat mir beim Umsetzen von Design-Mockups wirklich Zeit gespart.

Das ist nicht wenig. Und in den ersten Wochen war ich begeistert von der Geschwindigkeit.

Was sich im Laufe der Zeit zeigte

Dann kam, was immer kommt, wenn man wirklich tief mit einem Werkzeug arbeitet: Die Muster werden sichtbar.

Komplexität als Standard-Lösung. Codex neigt dazu, komplexere Lösungen zu bauen als notwendig. Nicht falsch, nicht kaputt – aber aufwändiger als es sein müsste. Abstraktionsschichten, die niemand angefragt hat. Hilfsmethoden, die genau einmal verwendet werden. Konfigurationsoptionen ohne konkrete Aufgabe.

Abhängigkeiten, die sich summieren. Über Wochen hinweg sammelten sich Abhängigkeiten an, die teils unnötig waren, teils miteinander in Spannung standen. Einzeln betrachtet harmlos, zusammen ein wachsendes Problem.

Absicht und Beschreibung. Codex ist gut darin, technisch korrekte Lösungen zu bauen. Manchmal hat es meine Absicht aber nicht ganz getroffen – der Code tat das Beschriebene, nicht das Gemeinte. Das ist ein feiner, aber wichtiger Unterschied, der sich mit der Zeit akkumuliert.

Lange autonome Sessions. Bei wirklich langen, autonomen Sessions hatte Codex manchmal Mühe, den Faden zu halten. Es hörte auf, fragte nach, oder lieferte unvollständige Ergebnisse, die ich dann fertigstellen musste.

Nichts davon ist katastrophal. Der Code lief. Aber er hatte mir etwas zu zahlen.

Opus 4.6 kommt ins Spiel

Nach etwa einem Monat mit Codex 5.2 – nicht einem zusammenhängenden Monat, sondern über Wochen verteilt, immer wieder – war klar, dass es Zeit für eine andere Perspektive war.

Ich habe angefangen, einzelne Module mit Opus 4.6 zu reviewen. Nicht mit dem Ziel, alles niederzureissen, sondern um zu verstehen, was da ist – und was besser sein könnte.

Was dann folgte, war ein schrittweiser, iterativer Prozess:

Das war keine schnelle Sache. Es war Arbeit über mehrere Wochen – aber es hat sich gelohnt.

Was der Prozess mir gezeigt hat

Hier ist das Interessante: Ich glaube nicht, dass das Codex-Experiment ein Fehler war.

Der Code, den Codex produziert hat, hat funktioniert. Das Projekt hat sich vorwärtsbewegt. Und der Kontakt mit einem anderen Modell hat mir Dinge über meinen eigenen Stil gezeigt, die ich so nicht gesehen hätte.

Die eigentliche Erkenntnis kam beim Aufräumen mit Opus 4.6.

Code-Qualität ist keine unmittelbare Eigenschaft. Sie zeigt sich über Zeit. Ein Feature, das heute funktioniert, kann in drei Monaten zur Quelle von Problemen werden – nicht weil es kaputt ist, sondern weil es zu komplex ist, zu eng gekoppelt, zu schwer zu ändern.

Opus 4.6 denkt in Systemen. Was mir beim Cleanup aufgefallen ist: Opus sieht nicht nur den Code vor sich, sondern das System, das er beschreibt. Es fragt nicht nur "Funktioniert das?", sondern "Ist das das Richtige?"

Die Fähigkeit aufzuräumen ist genauso wichtig wie die Fähigkeit zu bauen. Das klingt trivial, ist es aber nicht. Nicht jedes Tool – nicht jeder Entwickler – ist gut in beidem. Zu wissen, welches Werkzeug man wann braucht, ist die eigentliche Kompetenz.

Was ich anders machen würde

Wenn ich das Experiment heute noch einmal starten würde, würde ich es mit klaren Checkpoints starten.

Nicht "teste Codex 5.2 für einen Monat" – sondern "teste Codex 5.2 für konkrete Aufgaben, und überprüfe wöchentlich die Code-Qualität."

Der Unterschied: Ich hätte früher gesehen, wo sich technische Schulden aufbauen – und hätte sie kontinuierlich adressiert, statt am Ende aufzuräumen.

Das ist übrigens eine Lektion, die unabhängig von jedem AI-Tool gilt.

Verschiedene Tools, verschiedene Stärken

Was bleibt nach diesem Experiment?

Codex 5.2 ist ein ernstzunehmendes Werkzeug. Für schnelle Lieferung, für grosse Refactorings, für Prototypen – es hat seinen Platz. Wer weiss, wann er es einsetzen soll, kann damit produktiv sein.

Opus 4.6 ist mein Werkzeug für alles, was über die nächsten Wochen und Monate hinaus leben muss. Wo Code nicht nur funktionieren, sondern auch lesbar, wartbar und erweiterbar sein muss.

Das sind nicht nur zwei verschiedene Modelle. Das sind zwei verschiedene Philosophien beim Code-Schreiben – und zu wissen, wann man welche braucht, ist die eigentliche Kompetenz.

Fazit: Das Experiment hat sich gelohnt

Ich würde das Experiment wieder machen. Weil ich mit jedem Test lerne – über die Tools, über meinen eigenen Stil, und über das, was ich wirklich von einem Coding-Partner erwarte.

Und was ich jetzt weiss: Für meine Art zu arbeiten, für Projekte mit langem Atem, für Code, der in einem Jahr noch gut aussehen soll – da ist Claude Opus 4.6 das Richtige.

Codex 5.2 hat mir das auf seine Weise bestätigt.

Patrik Germann

Solo-Developer, AIpuna App