Ein Vizepräsident fliegt aus Kalifornien ein, setzt sich in London in einen Besprechungsraum und sagt einem Team, dass sein Projekt eingestellt wird. Tibo Sottiaux sitzt mit am Tisch. Zwei Jahre hatte er in der Ads-Organisation von Google an diesem Produkt gearbeitet. Hunderte Menschen nutzten es, und die technischen Fragen waren genau die, für die er den Job mochte. An einem Nachmittag ist die Sache vorbei.
Rückblickend war die Absage für Sottiaux lehrreich. Das Produkt hatte keinen tragfähigen Markt, die Nutzerresonanz blieb dünn, und im Team wollte das niemand sehen. Am meisten störte ihn damals, dass der Produktmanager die Lage bis zuletzt gut dargestellt hatte. Seitdem prüft er bei jeder Aufgabe zuerst die Wirkung, nicht den Aufwand.
Heute leitet Sottiaux bei OpenAI den Bereich Core Products & Platform, zu dem auch Codex gehört. Im Pragmatic Engineer Podcast hat er mit Gergely Orosz über den Bau von Codex gesprochen: warum die Codex CLI in Rust entwickelt ist, weshalb das Werkzeug quelloffen ist und wie das Team es im eigenen Softwareentwicklungszyklus einsetzt.
Googles Chatbot, ein Jahr vor ChatGPT
Anfang des Jahrzehnts war DeepMind stark auf Spiele und Reinforcement Learning ausgerichtet. Einige Mitarbeiter, darunter Sottiaux, hielten es für möglich, dass sich Sprachmodelle bis zu allgemeiner Intelligenz skalieren lassen. Daraus entstand ein internes Projekt zum Chatten mit einem Sprachmodell. Es verbreitete sich im Unternehmen schnell. Veröffentlicht wurde es nie.
Sottiaux schrieb auf X, er sei damals im Team gewesen und denke oft daran. Das Produkt sei ein ChatGPT gewesen, ein Jahr bevor ChatGPT erschien. Google habe sich nicht getraut, es zu veröffentlichen; DeepMind sei daran gehindert worden, Produkte auszuliefern, die das Kerngeschäft hätten stören können. Ob die Geschichte anders verlaufen wäre, lässt sich nicht beantworten. Sottiaux spekuliert im Gespräch auch nicht lange darüber.
2023 brachte ihn eine andere Beobachtung zu OpenAI. ChatGPT war schon sehr populär und wurde von etwa zwanzig Ingenieuren gebaut und betrieben. Die Zahl überraschte ihn so, dass er wechseln wollte. Bei Google hatte er die Trennung von Forschung und Produkt als Bremse erlebt. Bei OpenAI arbeiteten beide Seiten eng genug zusammen, dass Forschungsergebnisse schnell in einem Produkt landeten.
Warum die Codex CLI in Rust geschrieben ist
Als das Codex-Team die CLI entwarf, stand am Anfang eine Vorstellung, nicht die Vorliebe für eine Sprache: Codex-Instanzen sollten irgendwann auf Millionen von Cloud-Maschinen laufen. Daraus folgten drei Designprinzipien: Leistung, Sicherheit und sparsamer Umgang mit Ressourcen. Die Wahl fiel auf Rust, obwohl Modelle damals nachweislich besser in Python und TypeScript waren.
Eigentlich sollte ein Werkzeug, das KI-Agenten lesen und verändern, in der Sprache geschrieben sein, in der die Modelle am sichersten arbeiten. Das Team entschied sich bewusst dagegen, weil ein späterer Sprachwechsel teurer gewesen wäre als die anfängliche Reibung. Für Sottiaux ist das eine Entscheidung mit Blick auf später: lieber einmal eine unbequeme Entscheidung treffen als nach zwei Jahren den Unterbau austauschen.
Das hat Folgen. Wer Codex als offenes Projekt ansieht, findet Code, der nicht der statistisch wahrscheinlichste ist, den ein Modell erzeugen würde. Das ist der Unterschied zwischen einem Prototyp und einem Werkzeug, das auf fremden Maschinen läuft, ohne dass jemand danebensteht. Für die Entwicklung mit KI heißt das: Die Architekturentscheidung geht vor die Bequemlichkeit der Generierung.
Warum Codex quelloffen ist
Der größte Wettbewerber von Codex, Claude Code, ist geschlossen. Sottiaux‘ Team hat den entgegengesetzten Weg gewählt, aus zwei Gründen. Erstens Vertrauen: Wer ein Werkzeug auf seine Codebasis loslässt, will nachlesen können, was es tut. Zweitens die Community, die Beiträge liefert und das Team nach eigener Aussage antreibt.
Weil der Code öffentlich liegt, erscheint Arbeit des Codex-Teams manchmal in anderen Werkzeugen, bevor sie in Codex selbst veröffentlicht ist. Sottiaux sagt, das schmerze, sei aber der Preis für offene Entwicklung. Wer quelloffen entwickelt, verliert das Vorfeld, das ein geschlossenes Produkt für sich behalten kann.
Dieselbe Offenheit erklärt, warum Codex Modelle mehrerer Anbieter unterstützt. Technisch wäre eine Sperre ohnehin wirkungslos: Jeder könnte den Code forken und ein paar Zeilen ändern. Statt das zu bekämpfen, setzt das Team darauf, mit der besten Auswahl zu gewinnen. Die Entwickler probieren laut Sottiaux selbst andere Modelle im selben Harness aus, auch aus Eigeninteresse.
Was der Harness macht
Der Begriff Harness meint alles, was um das Sprachmodell herum gebaut ist: Leitplanken, Sicherheitsprüfungen, Vorgaben zur Steuerbarkeit und eine Entwicklernachricht, die zu Beginn jeder Runde in den Kontext kommt. Man kann sich das wie ein Baugerüst vorstellen, das eine Fassade stützt, solange sie noch nicht selbst steht. Ohne dieses Gerüst wäre das Modell in einem echten Projekt kaum kontrollierbar.
Mit jedem stärkeren Modell fällt ein Teil des Gerüsts weg. Was das vorherige Modell noch nicht zuverlässig konnte, erledigt das nächste selbst, und die entsprechenden Stützen werden abgebaut. Sottiaux beschreibt das als fortlaufenden Zyklus: Der Harness ist immer ein Stück weiter als das neueste Modell von OpenAI, und die Modelle holen ihn anschließend ein.
Codex reicht tief in die internen Systeme. Auf die Frage, was neuen Teammitgliedern geholfen hat, sagt Sottiaux: „Frag Codex.“ Das Werkzeug ist standardmäßig an Slack, alle Dokumente und den gesamten Code angebunden. Neue Kollegen sind überrascht, dass sie fragen können, wer an welchem Thema sitzt oder warum eine Entscheidung gefallen ist. Damit das funktioniert, arbeitet das Team bewusst in öffentlichen Kanälen und in Dokumenten mit weiten Berechtigungen. Die Antwortqualität folgt aus dieser Offenheit.
Codex im Entwicklungsalltag
Code-Reviews verändern sich durch KI. Sottiaux hat dazu eine klare Position. Ein Review dient der Korrektheit, dem Informationsaustausch und als Zwangspunkt für Gespräche, die früher hätten stattfinden sollen. Diskussionen über die Absicht hinter einem Codeabschnitt gehören für ihn nicht ins Review, sondern davor. Was ein System leisten soll, klärt man besser, bevor jemand Code schreibt, den andere später interpretieren müssen.
Für Wartung und Umbau nennt er Effekte, die sich in Zahlen fassen lassen. Ein Abhängigkeitsupdate, das früher einen halben Tag oder länger gebunden hat, erledigt ein Modell in ein paar Stunden über die ganze Codebasis hinweg. Ein Architekturumbau, an dem Teams früher Jahre saßen, ist in Tagen machbar. Die Kosten für Codeänderungen sinken so weit, dass Entscheidungen möglich werden, die vorher am Aufwand gescheitert sind.
Die Einschränkung nennt er selbst. Wie leicht eine Änderung fällt, hängt davon ab, wie gut der Code ist, wie klar die Abstraktionen sind und wie verlässlich die Tests. Ein unordentliches Projekt wird auch mit einem geduldigen Agenten nicht plötzlich beweglich. KI senkt die Kosten für Codeänderungen, nicht die Kosten für schlecht geschnittene Software. Der Unterschied wird nur sichtbarer, weil jetzt schneller klar wird, wo man hängen bleibt.
Was das für die Arbeit heißt
Stundenlang im Flow an einem Problem zu sitzen, beschreibt Sottiaux als Vergangenheit, zumindest für sich. Code ist für ihn ein Werkzeug zum Lösen von Problemen, kein Selbstzweck. Er öffnet noch einen Editor und schreibt ein wenig Code, weil es sich gut anfühlt. Die langen Sitzungen braucht er kaum noch. Statt aus dem Bauch heraus zu entscheiden, schickt er einen Agenten los und hat nach einer Minute die Daten für eine bessere Entscheidung.
Dazu passt seine Prognose zu Cloud-Entwicklungsumgebungen. Außerhalb der großen Konzerne haben die sich nie durchgesetzt, weil die Einrichtung zu aufwendig war. Agenten könnten das ändern, weil sie eine Maschine selbst konfigurieren und mit der lokalen Umgebung abgleichen können. Wenn ein Agent die Einrichtung übernimmt, fällt der Grund weg, aus dem Entwickler bei ihrem eigenen Rechner geblieben sind.
Für Teams heißt das weniger eine neue Werkzeugliste als eine Verschiebung der Arbeit. Der Aufwand verlagert sich vom Tippen zum Entscheiden: Was soll gebaut werden, welche Grenze ziehen wir, welcher Test beschreibt das Verhalten. Das Gerüst um das Modell wird kleiner, die Verantwortung der Menschen nicht. Wer Codex als Abkürzung versteht, wird enttäuscht. Wer klare Absichten mitbringt, bekommt das, was Sottiaux beschreibt.
Quelle: newsletter.pragmaticengineer.com
