|
06.02.2026
11:31 Uhr
|
Programmierassistenten sind allgegenwärtig. iX hat bei OpenAI nachgefragt, wie man den Überblick behält und mit großen Code-Mengen umgeht.
Für viele Entwickler sind Programmierassistenten auf Basis großer Sprachmodelle (LLMs) nicht mehr wegzudenken. Da Kompetenz in diesem Feld für neue Modelle besonders relevant ist, nennen Entwickler Coding-Kapazitäten oft neben Mathe-Fähigkeiten, wenn sie die nächste Generation ihrer Produkte hypen wollen. Derzeit nutzen Entwickler oft nicht das Eine Modell, sondern greifen für verschiedene Anforderungen auf die Klassenbesten verschiedener Anbieter zu - wenn nicht sogar kleinere Modelle simplere Aufgaben abwickeln.
Unter dem Namen Codex bündelt OpenAI die Programmierfähigkeiten seines Angebots, auf die sich über eine CLI-Variante, als IDE-Extension oder auf dem Mac neuerdings per App zugreifen lässt. Im Gespräch mit iX erzählt Dominik Kundel, Developer Experience Lead bei OpenAI, über Softwareentwicklung mit Codex bei OpenAI und den Zielen, die das Unternehmen mit dem Tool verfolgt.
Mich überrascht häufig, wenn Codex Sachen findet, die ich selbst nicht gefunden hätte. Vor allem, da ich zum Teil an Dokumentation arbeite und dann etwa einen Pull Request hochschicke und auf einmal dann ein Kommentar kommt, dass auf der aktuellen Seite die Dokumentation und der Source Code nicht übereinstimmen. Etwa, weil es eine Logikproblem gibt. Trotzdem wird jeder PR noch von Menschen durchschaut. Häufig ist es so, dass die Leute als Erstes Codex benutzen, um den PR zu reviewen und dann eventuell irgendwelche CI/CD Probleme von Codex reparieren lassen, bevor ein Kollege den Pull Request dann durchschaut.
Was wir generell vorschlagen ist, die gleichen Systeme aufzusetzen, wie wenn man mit einem großen Team an denselben Sachen arbeitet. Das heißt, CI ist eine der ersten Sachen, die ich normalerweise aufsetze, um sicherzustellen, dass ich dann auch Test Coverage habe. Das hilft dann auch Codex. Codex ist generell darauf trainiert, zu verifizieren, ob die Aufgaben fertig sind. Wenn man also nach einem neuen Feature fragt und bereits Tests hat, schreibt Codex automatisch neue Tests. Sowas hilft dann bei der Maintenance. Genauso wie weiterhin Code Reviews zu machen und Dokumentation zu behalten. Ich habe das Gefühl, dass die Codebases besser aussehen, weil Codex hilft Features zu dokumentieren und auch bei anderen Aufgaben hilft, die in der Realität oft hinten anstehen.
Anders als bei Claude Code, wo man sich dran gewöhnt hat, hin und her zu schreiben, ist Codex gut darin, ein Problem zu nehmen und wenn es das Ziel verstanden hat, einfach für mehrere Stunden an diesem Problem arbeiten. Peter Steinberger, der im Moment auf X und LinkedIn sehr viral geht, schreibt darüber, dass er Codex bevorzugt und wie er das meiste aus Codex rausholt.
Außerdem schlagen wir vor, CI/CD zu haben und generell Validation Tools. Wenn man also Frontend-Produkte baut, auch die Tools zu haben, die sicherstellen, dass die Frontend-Komponenten richtig gerendert werden. Man kann dann die Screenshots wieder als Image-Input in Codex reingeben und Codex kann sich dann quasi selbst validieren. Ein weiterer Punkt ist Naming. Wir empfehlen, Namen zu benutzen, die sehr einfach zu finden sind. Codex benutzt nämlich Tools wie grep und ripgrep, um sich in der Codebase zurechtzufinden. Wenn es die Sachen schnell finden kann, ist Codex wesentlich schneller.
Einer der Gründe, warum Codex den Leuten langsam vorkommt, ist, dass es häufig erstmal auf eine Tour geht, um sich zurechtzufinden. Codex springt nicht direkt rein und schreibt irgendeinen Code, sondern es geht erstmal rum und versucht, zu verstehen. Genauso wie das ein Software-Entwickler machen würde: Wie sieht die Codebase hier aus, wo sind die Daten oder die Dateien, mit denen ich umgehen möchte. Das Modell versucht zu verstehen, wie das Ganze aufgebaut ist, bevor es dann anfängt. Naming Conventions, die dem Modell erlauben einfacher herumzuspringen, helfen.
Man kann in diese Skills Prozesse einarbeiten und dann mit dem kombinieren, was wir Automations nennen. Automations sind dann Aufgaben, die entweder jede Stunde oder zu einer bestimmten Uhrzeit am Tag laufen. Die Automations laufen im Hintergrund auf einem Worktree. Wenn sie irgendein Problem finden, können sie das Ganze an dich weiterleiten. Ein Kollege hat beispielsweise jede Stunde eine Automation laufen, die alle seine Pull Requests durchgeht und guckt, ob CI bei denen grün ist oder ob es irgendwelche Probleme gibt und fixt die dann automatisch selber. Oder die Automation läuft einmal am Tag durch Sentry durch und guckt sich die Error-Logs an. Dann sucht sich das Programm ein besonders großes Problem aus und versucht es selber zu fixen und öffnet einen PR.
Mit Codex und den Automations in der App kann man als Entwickler dann auch die Aufgaben neben der Feature-Entwicklung im Blick behalten. Also die Aufgaben, die so an der Seite hängen oder nicht-technische Aufgaben sind, wie etwa bei der Codebase auf dem Laufenden zu bleiben. Da kann man sich zum Beispiel einmal am Tag ein automatisiertes Update mit den Änderungen an der Codebase schicken lassen und dazu, was in dem Fall an der Dokumentation aktualisiert werden muss.
Dominik, vielen Dank für das Interview.
(pst)