Praxistest von OpenAI Codex

• OpenAI Codex ist ein multitaskingfähiger Code-Agent auf Basis der GitHub-Integration und bietet eine Oberfläche, über die sich per natürlicher Sprache mehrere Aufgaben parallel anweisen lassen
• Nutzer können die Arbeit eines ganzen Tages schnell hineingeben und automatisch Branches erstellen sowie PRs öffnen lassen; zudem ist die Nutzung auch mobil möglich, was letztlich einen Remote-first-Workflow unterstützen kann
• Derzeit ist es jedoch wegen Problemen wie unzureichender Fehlerbehandlung, schwankender Codequalität, schwierigen Updates bestehender Branches und blockiertem Netzwerkzugang in der Sandbox für größere Refactoring-Arbeiten ungeeignet
• Für die Automatisierung kleiner Wartungsaufgaben ist Codex hingegen nützlich und in der Praxis gut darin, wiederholbare Aufgaben schnell zu erledigen
• Wenn künftig Modellverbesserungen, Multi-Model-Mixing und erweiterte Integrationsfunktionen hinzukommen, könnte es sich zu einem High-Level-Orchestrierungstool entwickeln

---

Wie OpenAI Codex funktioniert

• OpenAI Codex verfügt über eine chatbasierte UI und ist per Einladung oder über ein Pro-Abo für 200 $/Monat zugänglich
• Nutzer müssen eine mehrstufige Authentifizierung durchlaufen und die Codex-GitHub-App für jede Organisation freigeben; Codex klont dann Repositories in seine eigene Sandbox und übernimmt das Ausführen von Befehlen sowie das Erstellen von Branches
• Wer Dutzende öffentliche und private Repositories verwaltet, profitiert stark von der Effizienz bei Projektwechseln und der Verwaltung vieler Aufgaben in der Warteschlange
• Wenn man nur 1–2 Repositories betreut, können ein bestehendes LLM oder ein Editor mit AI-Funktionen die leichtere Wahl sein

Stärken von Codex

• Parallele Verarbeitung mehrerer Aufgaben und Oberfläche

  • Für jede Aufgabe lassen sich Repository und Branch festlegen, wodurch es sich natürlich anfühlt, die Arbeit eines ganzen Tages parallel in natürlicher Sprache einzureichen
  • Codex empfiehlt ausdrücklich die gleichzeitige Bearbeitung vieler Aufgaben, was gut zum eigenen Arbeitsstil passt

• Flexibler Workflow und mobile Unterstützung

  • Codex funktioniert auch auf dem Smartphone mobilfreundlich, wodurch effizientes Arbeiten auch außerhalb des Büros gut möglich erscheint
  • Das ideale Nutzungsszenario ist, zu Arbeitsbeginn mehrere Aufgaben anzulegen und Planung sowie Fortschritt auch unterwegs weiter zu steuern

• Chatbasiertes Feedback und PR-Erstellung

  • Logs und Status laufender Aufgaben lassen sich bequem über die Chat-Oberfläche prüfen; zusätzliche Anweisungen sind ebenfalls möglich
  • Wenn die Änderungen zufriedenstellend sind, erstellt Codex einen Pull Request (im Folgenden PR) und vervollständigt die Beschreibung automatisch
  • Positiv ist auch, dass sich Ausführungslogs und Befehlsverlauf schrittweise nachvollziehen lassen

Punkte mit Verbesserungsbedarf

• Unzureichende Fehlerbehandlung

  • Wenn das Starten einer Aufgabe oder das Erstellen eines PR fehlschlägt, fehlt klares Feedback, was die Nutzbarkeit verschlechtert

• Codequalität und einmalige Aufgabenausführung

  • Das Codex-Modell gehört zur GPT-3-Familie und unterstützt mehr als 12 Sprachen, doch bei paralleler Ausführung liegt die Zufriedenheit nur bei etwa 40–60 %
  • Für kleinere Wartungsaufgaben ist es nützlich, aber bei groß angelegtem Refactoring sinkt die Effizienz durch wiederholte PR-Erstellung

• Keine Unterstützung für fortlaufende Updates innerhalb eines Branches

  • Da sich fortlaufende Commits nur schwer mit bestehenden PRs und Branches verknüpfen lassen, sind mehrstufige Refactoring-Arbeiten ineffizient
  • Derzeit eignet sich Codex vor allem für einfache Aufgaben, die sich innerhalb eines einzelnen Auftrags direkt übergeben lassen

• Einschränkungen beim Netzwerkzugang der Ausführungs-Sandbox

  • Durch das beabsichtigte Design ist externer Netzwerkzugang nicht möglich, was verschiedene praktische Aufgaben wie Paketaktualisierungen oder Dependency-Verarbeitung einschränkt
  • Beispiel: Eine Anforderung zur Installation externer Pakete funktioniert nicht
  • Solche Aufgaben müssen weiterhin lokal direkt erledigt werden oder auf bestehende Bot-Funktionen wie Dependabot zurückgreifen

Did it unlock insane productivity gains for me?

• Bisher habe ich keinen explosionsartigen Produktivitätsschub gespürt
• Damit Codex wirklich zu einer Produktivitätsrevolution wird, braucht es
  • Verbesserungen bei Design und Algorithmen, damit mehr Aufgaben in einem Durchlauf lösbar werden
  • einen besseren Ablauf für das Aktualisieren bestehender Branch-PRs
  • stärkere Fähigkeiten bei Delegation und integrierter Verwaltung sowie eine breitere Integration mit verschiedenen OpenAI-APIs
  • eine Weiterentwicklung von Codex zum High-Level-Orchestrator
• Derzeit ist Codex besonders nützlich für die Automatisierung von routinemäßiger Wartung und kleineren Updates
• Für große Feature-Entwicklung und Refactoring ist die Zusammenarbeit mit IDE und LLM-Unterstützung besser geeignet

Abschließende Gedanken

• Codex ist ein stilles, aber vielversprechendes Tool
• Mit Blick auf die Funktionen, die künftig noch verfeinert werden, ist das Potenzial groß, sich als Einstiegspunkt und Koordinationswerkzeug für die Arbeit zu etablieren
• Jetzt ist der Zeitpunkt, sich auf leichte, wiederkehrende Aufgaben zu konzentrieren und auf weitere Verbesserungen zu warten

[yangeok]

Anscheinend ist es noch nicht die Stimmung, dafür 200 Dollar zu verbrennen.

[GN⁺]

Hacker-News-Meinungen

• Ich war Plus-Abonnent und habe auf Pro upgegradet, weil ich Codex testen wollte, aber ehrlich gesagt war das Ergebnis meiner Erfahrung nach eher enttäuschend
  Auch die UX wirkt noch nicht wirklich ausgereift, und es ist frustrierend, dass man nicht weiß, wie lange es dauert, bis ein Ergebnis kommt
  Dank der asynchronen Natur von Codex kann man immerhin mehrere Aufgaben gleichzeitig laufen lassen, das ist noch der bessere Teil
  Ein weiterer Kritikpunkt ist, dass man die Umgebung separat festlegen muss, damit das Tool sinnvoll nutzbar ist
  Da man die für Tests nötigen Container nicht starten kann, ist der praktische Nutzen stark eingeschränkt
  Die Umgebung ist vollständig vom Internet isoliert, was die Einsatzmöglichkeiten begrenzt
  Der Grund, warum ChatGPTs o3 so stark ist, liegt darin, dass es auch das Web zur Informationssuche nutzen kann, und genau das fehlt Codex
  Zum Vergleich: Ich nutze auch oft Claude; wenn man ein Projekt aus einem GitHub-Repo als Quelle erstellt, findet es selbst unbekannte Bugs in komplexen React-Apps gut
  Gemini unterstützt solche Funktionen ebenfalls gut, weil das Kontextfenster groß ist
  Natürlich verstehe ich auch, worauf OpenAI hinauswill
  Ich wünsche mir, dass Codex wie ein echter Kollege mehrere Aufgaben übernimmt und löst, aber im aktuellen Stand wirkt es zu stark auf Pull Requests fokussiert
  Deshalb downgrade ich wieder auf Plus und beobachte das Ganze noch etwas weiter

  • Ich finde, Container-Support ist absolut notwendig

• Ich arbeite bei OpenAI, aber nicht im Codex-Team, und habe Codex in mehreren Projekten erfolgreich eingesetzt
  So arbeite ich damit
  Ich führe immer denselben Prompt mehrfach aus, damit jeweils unterschiedliche Ergebnisse entstehen
  Ich vergleiche mehrere Implementierungen, finde die beste und überlege, wie ich den Prompt hätte ändern können, um ein besseres Ergebnis zu erzielen
  Die Stellen, an denen das Modell falsch lag, korrigiere ich im Prompt und wende das dann iterativ an
  Wenn man die Arbeit so in kleine Einheiten zerlegt und parallele Experimente wiederholt, kann man selbst riesige Projekte in wenigen Stunden abschließen, im Wesentlichen nur mit Prompt-Abstimmung und Code-Review
  Diese Methode ist nicht nur für API-Migrationsarbeiten nützlich, sondern auch für tieferen Code wie Triton-Kernel sehr hilfreich

  • „Ich wähle unter mehreren Implementierungen die beste aus und überlege, was ich im Prompt zusätzlich hätte tun müssen, damit bessere Ergebnisse herauskommen.“
    Als Nichtfachmann frage ich mich, wie man überhaupt erkennt, was das „Beste“ ist
    Um am Ende die richtige Richtung zu finden, braucht man doch Fachwissen in dem Bereich, und genau das ist für mich ein Argument dafür, dass LLMs Software-Engineering-Jobs nicht verdrängen werden

  • Ich denke, diese manuelle Arbeitsweise könnte tatsächlich die Grundlage für Reinforcement Learning (RL) sein
    Wenn man die UI-Erfahrung ein wenig anpasst und die realen Daten dafür nutzt, könnte daraus ein gutes Trainingsdatenset entstehen

  • Ich frage mich, wie viel schneller diese Methode in der Praxis wirklich ist als das direkte Schreiben von Code

  • Ich frage mich, ob du bisherige Arbeit manchmal verwirfst, wenn sich durch einen neuen Prompt etwas Wichtiges ändert
    Kleine Änderungen können große Auswirkungen auf das Ergebnis haben, und bei Problemen ohne vorhandene Beispiele scheint das noch schwieriger zu sein
    Wenn sich diese Arbeitsweise ständig wiederholt, könnte sie einen eher ermüden oder vom Wesentlichen wegführen
    Für mich könnte sich das ineffizient anfühlen, daher frage ich mich, ob andere einfach mehr Geduld für solche Wiederholungsarbeit haben

• Ich habe in meinem Team einen Review zu Codex im pod geteilt (https://latent.space/p/codex)
  Es ist ein sehr starkes Modell dafür, in einem Durchgang Code zu erzeugen (im pod wurde bestätigt, dass es dafür besonders als One-Shot auf OpenAI-SWE-Aufgaben feinabgestimmt wurde)
  Relativ schwach ist es bei Integrationen (z. B. keine Browser-Integration und unzureichende GitHub-Anbindung — wenn bei jeder Iteration ein neuer Pull Request geöffnet werden soll, ist es lästig, Folge-Commits in denselben Branch zu legen)
  Trotzdem erwarte ich, dass sich solche Integrationsfunktionen mit der Zeit verbessern
  Dass man pro Stunde 60 gleichzeitige Codex-Instanzen ausführen kann, ist meiner Meinung nach ein qualitativer Unterschied zu Devin (5 gleichzeitig) oder Cursor (vor Hintergrund-Agenten nur 1 gleichzeitig)
  Ich habe keinen klaren Leistungsunterschied beim Codex-Modell bemerkt, und obwohl OpenAI erklärt, Codex sei von GPT-3 abgeleitet, ist es in Wirklichkeit ein Fine-Tuning von o3

  • Schon die Behauptung „Fine-Tuning von o3“ wirkt verwirrend
    Auch OpenAIs Namenskonventionen stiften Verwirrung, und dieses Problem haben die meisten AI-Unternehmen
    Codex war ursprünglich ein altes Modell auf Basis von GPT-3, und inzwischen wird derselbe Name für CLI, Tools und andere Dinge wiederverwendet
    Google sorgt mit „Gemini Ultra“ für dieselbe Verwirrung, weil es sowohl als Modellname als auch als Name eines Abos verwendet wird

  • Für mich ist die Netzwerkeinschränkung am störendsten

    1. git fetch, Upstream-Sync und das Beheben von Integrationsbugs sind nicht möglich
    2. Externe Bibliotheken neu herunterladen und Integrationen testen geht nicht
       Offenbar sind sogar Domains blockiert, sodass im Setup-Script nicht einmal apt install funktioniert
       Außerdem scheint der Agent eher dazu zu neigen, erst einmal einfach git grep zu machen, statt den Gesamtkontext des Codes zu erfassen (das sieht man in der UI), deshalb finde ich das eher mittelmäßig

  • Mich würde interessieren, worin genau der Unterschied zu Claude Code liegt

• Ich finde die Funktion wirklich großartig, mit der man mehrere Repos schnell ändern kann
  Wenn man viele Beispiel-Apps gleichzeitig pflegt, wird es extrem langweilig, README-Formate oder Links an mehr als 20 Stellen immer wieder anzupassen
  Wenn ich solche Nebenarbeiten an Codex abgeben und später nur noch auf den Merge-Button drücken könnte, wäre ich sehr glücklich

  • Mir geht es genauso
    Ich erwarte, dass es sich bald in diese Richtung entwickelt
    Vorerst wird man wahrscheinlich kleinere Wartungsaufgaben mit Codex verteilen, während man große Refactorings oder wichtige Entwicklung weiter in der IDE erledigt

• Ich frage mich, ob Nichtentwickler solche Werkzeuge nutzen könnten, um Codeänderungen vorzunehmen
  Inhaltliche Änderungen oder einfache CSS-Anpassungen möchte ich wirklich nicht selbst machen, und da man Tests visuell prüfen kann, würde es reichen, wenn ich nur das Code-Review mache
  Ein Nichtentwickler könnte sich ein Ticket ansehen, die Arbeit starten und am Ende einfach sagen „Das sieht gut aus“, und ich prüfe es dann
  Ich halte das für einen idealen Workflow für kleinere Bugs oder Feature-Verbesserungen im Backlog

  • Ich denke, Tools wie AI Assist könnten am Ende die beste Low-Code-Plattform werden
    Vielleicht kommt damit tatsächlich der Tag, an dem Software Engineers ersetzt werden

  • Aber selbst Inhaltsänderungen verlangen oft gründliches Nachdenken
    Schon bei etwas mehr Größe gibt es Upstream- und Downstream-Abhängigkeiten, und selbst das Hinzufügen nur eines Felds kann Auswirkungen auf das ganze System haben
    Auch kleine Änderungen wie CSS wirken trivial, aber wie klein sie tatsächlich sind, ist für Nutzer schwer zu beurteilen

  • Themen wie Barrierefreiheit, Multiplattform (Mobile/Desktop) und viele andere Probleme wird man ebenfalls schnell kennenlernen
    Das Ganze wirkt fast wie ein Funnel, durch den Menschen „inbound“ in den Software-Engineering-Bereich kommen

• Bei kleinen Aufgaben finde ich eine Erfolgsquote von 40–60 % ziemlich ordentlich
  Hilfreich zu wissen ist, dass es bei komplexeren Aufgaben mit tieferer Logik Schwierigkeiten gibt

  • Nach meinen Tests scheitert Codex komplett schon bei Aufgaben, die nur ein wenig kritisches Denken erfordern
    Die aktuelle Leistung liegt auf dem Niveau eines miserablen Junior Engineers
    Wenn man es etwa anweist, eine Änderung vorzunehmen, macht es einfach pauschal alle Klassenwerte nullable, nur um Compiler-Warnungen loszuwerden
    Oberflächlich funktioniert es dann und kompiliert auch, aber die Datenintegrität ist damit komplett zerstört — also ein völlig falsches Ergebnis
    Solche Fälle gibt es ziemlich oft
    Wenn man eine ganze Codebasis unbeaufsichtigt Codex überlässt, sammelt sich schnell Technical Debt an

• Die Erwartung, dass Codex uns helfen wird, während unserer Abwesenheit gut zu arbeiten, wirkt zu optimistisch
  Für viele hängt „funktioniert effektiv, obwohl wir nicht da sind“ eng mit „der Schlange der Arbeitslosen“ zusammen

  • Ich finde schon erstaunlich, dass Entwickler sich über solche Veränderungen freuen
    Mich überrascht diese Stimmung, als würden wir eines Tages einfach nur dasitzen, zusehen, wie Agenten alles erledigen, und trotzdem dafür bezahlt werden
    Selbst wenn die Arbeit leichter wird, kann sie am Ende trotzdem in Richtung Arbeitsplatzabbau führen

  • In der Geschichte von Produktivitätssteigerungen gibt es kaum Präzedenzfälle dafür, dass Beschäftigte dadurch mehr Freizeit bekommen
    Meist läuft es auf mehr Gewinn für Aktionäre und Management hinaus, auf doppelte Arbeit für die Hälfte der verbleibenden Mitarbeiter und auf Arbeitslosigkeit für den Rest

  • Ich denke, bis zu echter Arbeitslosigkeit dauert es noch eine Weile
    Damit solche Modelle in einer breiten Palette von Aufgaben zuverlässig auf 90–95 % kommen, ist wohl enorm viel Aufwand nötig
    Die ersten 60–70 % sind bei fast allem leicht, aber die letzten 5–10 % sind wirklich schwer
    Wie oben erwähnt, ist es derzeit deutlich teurer, viele Durchläufe zu starten, unterschiedliche Ergebnisse zu erzeugen und diese auszuwählen, und wenn man das pauschal auf alle Aufgaben anwenden will, kommen noch hohe Inferenzkosten hinzu
    Ab einem gewissen Punkt wird Code-Review gerade bei von Maschinen geschriebenem Code unverzichtbar werden
    Bei kleinen Projekten oder kleineren Features mag man maschineller Arbeit vertrauen können, aber bei Codebasen, die lange gepflegt werden, werden Menschen Architektur und Review weiter übernehmen müssen
    AI kann helfen, verschiedene Wege schneller zu erkunden, aber die letzte Entscheidung liegt weiterhin beim Menschen, der Qualität auch selbst durch Design oder Review sichern muss
    In naher Zukunft werden Engineering-Teams vermutlich aktiv nach Wegen suchen, Hintergrund-Agenten sinnvoll einzusetzen
    Ich bin skeptisch gegenüber dem heutigen Ansatz, einfach alles an ein starkes Modell auszulagern
    Das derzeitige AI-Code-Review ist ziemlich frustrierend, daher braucht es bessere Workflows
    Für einige Jahre werden „Hintergrund-Agenten“ selbst zu einer unverzichtbaren Infra je Unternehmen werden
    Die meisten Unternehmen werden eine solche Agenten-Infrastruktur vermutlich eher per API nutzen als selbst hosten
    Agentenbasierte Engineering-Infrastruktur steht noch ganz am Anfang, daher dürften in den nächsten 3–5 Jahren auch viele neue Arbeitsmöglichkeiten entstehen

  • Optimistisch betrachtet steigt die Nachfrage nach etwas oft gerade dann, wenn es billiger wird, es herzustellen (zum Beispiel Code)
    Nichtentwickler könnten zwar als Manager agieren, aber meiner Erfahrung nach wollen Menschen wichtige Aufgaben umso lieber vertrauenswürdigen Personen — also Menschen — überlassen

  • Man könnte Softwareentwickler mit Pferden und neue Modell-Agenten wie Codex oder Claude Code mit Autos vergleichen
    Ich frage mich, ob der Rahmen stimmt, dass einige Pferde zu Autofahrern werden, während andere arbeitslos werden, weil sie keine Wagen mehr ziehen müssen

• Ich konnte keinen Ort finden, an dem die Liste der unterstützten Sprachen sauber aufbereitet ist
  Weder in der offiziellen Einführung noch in Reviews wird das ordentlich erklärt; meistens wird es nur an Beispielen wie Tippfehlerkorrekturen auf Webseiten demonstriert

• Es wirkt wie etwas, das man in einer Woche mit gptel-tool schnell zusammenbauen könnte

[horace]

Wenn man es wie einen Diener einsetzt, ist es ziemlich nützlich!