Mit Codex dauerte es nur 28 Tage, bis Sora auf Android lief

Ab dem 26. April 2026 ist das Sora-Produkt nicht mehr verfügbar.

Im November haben wir die Sora Android-App weltweit eingeführt, mit der jeder Android-Nutzer aus einem kurzen Prompt ein lebendiges Video erstellen kann. Am Einführungstag erreichte die App Platz 1 im Play Store. Mehr als eine Million Videos wurden in den ersten 24 Stunden auf Android generiert.

Hinter dem Start steckt eine Story: Die erste Version der Sora-App für Videoproduktion auf Android wurde in 28 Tagen entwickelt, dank des gleichen Agenten, den auch jedes andere Team oder jeder andere Entwickler verwenden kann: Codex.

Vom 8. Oktober bis 5. November 2025 arbeitete ein schlankes Ingenieurteam zusammen mit Codex, verbrauchte etwa 5 Milliarden Tokens und brachte Sora für Android vom Prototyp bis zur weltweiten Markteinführung. Trotz des Umfangs besitzt die App eine absturzfreie Rate von 99,9 % und eine Architektur, auf die wir stolz sein können. Tatsächlich haben wir kein geheimes Modell verwendet, stattdessen kam eine frühe Version des Modells GPT‑5.1-Codex zum Einsatz – die gleiche Version, die jeder Entwickler oder jedes Unternehmen heute über CLI, IDE-Erweiterungen oder Web-App nutzen kann.

Als Sora auf iOS veröffentlicht wurde, stieg die Nutzungsrate explosionsartig. Die Leute begannen sofort, eine Flut von Videos zu generieren. Im Gegensatz dazu hatten wir auf Android nur einen kleinen internen Prototyp und eine steigende Anzahl vorab registrierter Benutzer auf Google Play.

Ein zeitkritischer Starttermin, bei dem viel auf dem Spiel steht – oft wird damit reagiert, zusätzliche Ressourcen bereitzustellen und Prozesse zu erweitern. Eine Produktions-App dieses Umfangs und dieser Qualität würde typischerweise viele Softwareingenieure erfordern, die monatelang arbeiten, verlangsamt durch die notwendige Koordination. 

Der amerikanische Computerarchitekt Fred Brooks warnte bekanntlich: „Wenn man mehr Leute in ein verspätetes Softwareprojekt einbringt, wird es noch weiter verzögert.“ Mit anderen Worten, wenn man versucht, ein komplexes Projekt schnell abzuschließen, kann das Hinzufügen weiterer Softwareingenieure oft die Effizienz verringern, indem es den Kommunikationsaufwand, die Aufgabenfragmentierung und die Integrationskosten erhöht. Wir haben uns an dieser Weisheit orientiert, anstatt sie zu ignorieren. Wir haben ein starkes Team von vier Softwareingenieuren zusammengestellt – alle mit Codex ausgestattet, um die Leistungsfähigkeit jedes Softwareingenieurs drastisch zu erhöhen. 

Auf diese Weise konnten wir binnen 18 Tagen einen internen Build von Sora für Android an die Mitarbeiter bereitstellen und ihn 10 Tage später öffentlich veröffentlichen. Wir haben hohe Maßstäbe für die Android-Entwicklungspraktiken gesetzt, in die Wartbarkeit investiert und die App auf demselben Zuverlässigkeitsniveau gehalten, das wir von einem traditionelleren Projekt erwarten würden. (Wir verwenden Codex auch heute noch intensiv, um die App weiterzuentwickeln und neue Funktionen hinzuzufügen.)

Um zu verstehen, wie wir mit Codex gearbeitet haben, ist es hilfreich zu wissen, in welchen Bereichen die Stärken liegen und wann weitere Anweisungen benötigt werden. Unsere Herangehensweise, Codex als neuen „Senior Engineer“ zu behandeln, hat gut geklappt. Dank der Fähigkeiten von Codex konnten wir mehr Zeit damit verbringen, Programmieranweisungen zu geben und Code zu überprüfen, anstatt ihn selbst zu tippen.

Wann Codex Unterstützung benötigt

1. Codex ist noch nicht gut darin, Dinge zu erschließen, die ihm nicht mitgeteilt wurden (z. B. bevorzugte Architekturmuster, Produktstrategie, das tatsächliche Benutzerverhalten und interne Normen oder Workarounds).
2. Ebenso konnte Codex die App nicht selbst ausführen: Es konnte Sora nicht auf einem Gerät starten, nicht bemerken wenn sich etwas beim Scrollen komisch anfühlte oder dass ein Ablauf verwirrend war. Nur unser Team konnte diese erlebnisorientierten Aufgaben übernehmen.
3. Jede Instanz erfordert ein Onboarding. Das Teilen von Kontext mit klaren Zielen, Einschränkungen und Anleitungen dazu, „wie man es richtig macht“, war entscheidend dafür, dass Codex gut funktionierte.
4. In ähnlicher Weise hatte Codex Schwierigkeiten mit tiefgreifenden Entscheidungen zur Softwarearchitektur: Ohne Aufsicht hätte es ein zusätzliches ViewModel eingeführt, wo wir eigentlich ein bestehendes erweitern wollten, oder Logik in die UI-Ebene verschoben, die eindeutig in ein Repository gehörte. Der Instinkt von Codex ist es, etwas zum Laufen zu bringen, nicht die langfristige Sauberkeit zu priorisieren.

Wir fanden es nützlich, Codex eine großzügige Anzahl von in der Codebasis verteilten AGENTS.md-Dateien erstellen und pflegen zu lassen. Auf diese Weise wurde es einfach, dieselben Anleitungen und bewährten Verfahren über Sitzungen hinweg anzuwenden. Zum Beispiel haben wir, um sicherzustellen, dass Codex gemäß unseren Stilrichtlinien programmiert, Folgendes zu unserer AGENTS.md-Datei auf der obersten Ebene hinzugefügt:

Stärken von Codex

1. Große Codebasen schnell lesen und verstehen: Codex kennt im Wesentlichen alle wichtigen Programmiersprachen, womit es einfacher wird, dieselben Konzepte über viele Plattformen hinweg ohne komplexe Abstraktionen anzuwenden.
2. Testabdeckung: Codex ist (auf einzigartige Weise) sehr motiviert, Unit-Tests zu schreiben, die eine große Bandbreite an Fällen abdecken. Nicht jeder Test ging in die Tiefe, aber die breite Abdeckung war hilfreich, um Regressionen zu verhindern. 
3. Feedback umsetzen: In ähnlicher Weise reagiert Codex gut auf Feedback. Wenn CI fehlschlug, konnten wir die Protokollausgabe in einen Prompt einfügen und Vorschläge zur Fehlerbehebung von Codex anfragen.
4. Massiv parallele, kurzlebige Ausführung: Da die meisten Benutzer die maximale Zahl gleichzeitiger Sessions nicht ausschöpfen, lassen sich mehrere Ideen problemlos parallel testen und Code bewusst als ersetzbar behandeln.
5. Neue Perspektiven eröffnen: In Design-Diskussionen nutzten wir Codex als generatives Werkzeug, um potenzielle Fehlerquellen zu untersuchen und neue Lösungsansätze zu entdecken. So durchforstete Codex beispielsweise bei der Entwicklung von Speicheroptimierungen für einen Videoplayer mehrere SDKs und schlug Ansätze vor, für deren Analyse uns sonst die Zeit gefehlt hätte. Die aus der Recherche von Codex gewonnenen Erkenntnisse erwiesen sich als äußerst wertvoll, um den Speicherbedarf in der finalen App zu minimieren.
6. Höherwertige Arbeit ermöglichen: In der Praxis verbrachten wir letztlich mehr Zeit damit, die Programmierung anzuleiten und den Code zu überprüfen, als diesen selbst zu schreiben. Allerdings schlägt sich Codex ebenfalls sehr gut im Code-Review und entdeckt häufig Fehler vor der Zusammenführung, was die Zuverlässigkeit verbessert.

Sobald wir diese Eigenschaften erkannt hatten, wurde unser Arbeitsmodell deutlich einfacher. Wir verließen uns darauf, dass Codex innerhalb gut verstandener Muster und klar abgegrenzter Bereiche einen Großteil der schweren Arbeit übernahm, während sich unser Team auf Architektur, Nutzererlebnis, systemische Änderungen und die Qualität des Endprodukts konzentrierte.

Selbst die besten neuen, erfahrenen Mitarbeitenden verfügen anfangs nicht über die richtige Perspektive, um langfristige Abwägungen sofort treffen zu können. Um Codex effektiv zu nutzen und sicherzustellen, dass seine Arbeit robust und wartbar ist, war es entscheidend, dass wir das Systemdesign der App und die zentralen Trade-offs selbst überwachten. Dazu gehörten die Ausgestaltung der App-Architektur, Modularisierung, Dependency Injection und Navigation; außerdem implementierten wir die Authentifizierung sowie die grundlegenden Netzwerkabläufe selbst. 

Auf dieser Grundlage implementierten wir einige repräsentative Features von Anfang bis Ende. Dabei wendeten wir die Regeln an, denen die gesamte Codebasis folgen sollte, und dokumentierten projektweite Muster fortlaufend. Indem wir Codex auf diese repräsentativen Features verwiesen, konnte es deutlich selbstständiger innerhalb unserer Standards arbeiten. Für ein Projekt, das wir zu etwa 85 % von Codex schreiben ließen, verhinderte diese sorgfältig geplante Basis kostspieliges Zurückrudern und aufwendige Refactorings. Es war eine der wichtigsten Entscheidungen, die wir getroffen haben. 

Die Idee war nicht, so schnell wie möglich „etwas zum Laufen zu bringen“, sondern vielmehr „etwas zu schaffen, das versteht, wie wir wollen, dass die Dinge funktionieren“. Es gibt viele „richtige“ Wege, Code zu schreiben. Wir mussten Codex nicht genau sagen, was zu tun ist; wir mussten Codex zeigen, was in unserem Team als „richtig“ gilt. Sobald wir unseren Ausgangspunkt festgelegt hatten und unsere Präferenzen in der Entwicklung klar waren, war Codex bereit, loszulegen.

Um zu sehen, was passieren würde, haben wir tatsächlich folgenden Prompt ausprobiert: „Erstelle die Sora-App für Android auf Basis des iOS-Codes. Los.“ Diesen Ansatz haben wir jedoch schnell verworfen. Obwohl das, was Codex erstellt hat, technisch funktionierte, war die Produkterfahrung nicht zufriedenstellend. Ohne ein klares Verständnis der Endpunkte, der Daten und der User-Flows war der in einem einzigen Durchlauf erzeugte Code von Codex unzuverlässig. (Selbst ohne den Einsatz eines Agenten ist es riskant, Tausende von Codezeilen zusammenzuführen.)

Wir stellten die Hypothese auf, dass Codex in einer Sandbox mit gut geschriebenen Beispielen besonders gut funktionieren würde – und wir hatten recht. Mit der Anweisung „programmiere diesen Einstellungsbildschirm“ konnte Codex nur unzuverlässig arbeiten, solange so gut wie kein Kontext vorhanden war. Mit der Anweisung „programmiere diesen Einstellungsbildschirm mit derselben Architektur und denselben Mustern, wie der andere Bildschirm, den du gerade gesehen hast“ konnte Codex deutlich besser arbeiten. Die Menschen trafen die strukturellen Entscheidungen und legten die Invarianten fest; Codex füllte anschließend diese Struktur mit großen Mengen an Code aus.

Unser nächster Schritt, um das Potenzial von Codex maximal auszuschöpfen, bestand darin, herauszufinden, wie wir Codex ermöglichen können, über lange Zeiträume hinweg unbeaufsichtigt zu arbeiten. (Vor kurzem sogar mehr als 24 Stunden lang⁠.)

Als wir erst anfingen, Codex zu nutzen, versuchten wir es mit Prompts wie „Hier ist das Feature. Hier sind einige Dateien. Bitte programmieren.“ Das funktionierte manchmal, führte aber meist zu Code, der auf der technischen Seite zwar kompiliert wurde, jedoch von unserer Architektur und unseren Zielen abwich.

Also haben wir den Workflow geändert. Bei jeder nicht-trivialen Änderung haben wir Codex zunächst gebeten, uns dabei zu helfen, zu verstehen, wie das System und der Code funktionieren. Zum Beispiel gaben wir die Anweisung, eine Reihe zusammengehöriger Dateien zu lesen und zusammenzufassen, wie das entsprechende Feature funktioniert – etwa wie Daten von der API durch die Repository-Ebene und das ViewModel bis in die UI fließen. Anschließend haben wir das Verständnis korrigiert oder verfeinert. (Zum Beispiel haben wir darauf hingewiesen, dass eine bestimmte Abstraktion eigentlich in eine andere Ebene gehört oder dass eine bestimmte Klasse nur für den Offlinemodus existiert und nicht erweitert werden sollte.)

Ähnlich wie man mit einem neuen, hochkompetenten Teammitglied zusammenarbeiten würde, haben wir mit Codex einen soliden Implementierungsplan erstellt. Dieser Plan sah häufig wie ein kleines Design-Dokument aus, das festlegte, welche Dateien geändert werden sollten, welche neuen Zustände eingeführt werden mussten und wie die Logik fließen sollte. Erst danach haben wir Codex gebeten, den Plan Schritt für Schritt umzusetzen. Ein hilfreicher Tipp: Bei sehr umfangreichen Aufgaben, bei denen wir an die Grenzen unseres Kontextfensters gestoßen sind, haben wir Codex gebeten, seinen Plan in einer Datei zu speichern, sodass wir dieselbe Richtung über mehrere Instanzen hinweg beibehalten konnten.

Diese zusätzliche Planungsschleife erwies sich als positive Zeitinvestition. Sie ermöglichte es uns, Codex über längere Zeiträume „unbeaufsichtigt“ arbeiten zu lassen, weil wir seine Pläne kannten. Sie erleichterte außerdem das Code-Review, da wir die Implementierung mit unserem Plan abgleichen konnten, anstatt eine Diff-Ansicht ohne Kontext zu lesen. Und wenn etwas schiefging, konnten wir zuerst den Plan debuggen und erst danach den Code. 

Die Dynamik war vergleichbar damit, wie ein gutes Design-Dokument einer technischen Leitung Vertrauen in ein Projekt vermittelt. Wir haben nicht nur Code generiert: Wir haben Code generiert, der für eine gemeinsame Roadmap gemacht war.

Auf dem Höhepunkt des Projekts führten wir oft mehrere Codex-Sitzungen parallel aus. Eine arbeitete an der Videowiedergabe, eine andere an der Suche, eine weitere an der Fehlerbehandlung und manchmal noch eine an Tests oder Refactorings. Es fühlte sich weniger an wie die Nutzung eines Tools und eher wie das Managen eines Teams.

Jede Sitzung meldete sich regelmäßig mit Fortschrittsberichten bei uns zurück. Eine sagte zum Beispiel: „Ich bin mit der Planung dieses Moduls fertig; hier ist mein Vorschlag“, während eine andere eine große Diff-Datei für ein neues Feature präsentierte. Jede erforderte Aufmerksamkeit, Feedback und Review. Es war verblüffend ähnlich zur Arbeit in der technischen Leitung mit einem neuen Team an Softwareingenieuren – alle machten Fortschritte, alle benötigten Anweisungen.

Das Ergebnis war ein kollaborativer Ablauf. Die rohe Programmierfähigkeit von Codex befreite uns von einem Großteil der manuellen Tipparbeit. Wir hatten mehr Zeit, über die Architektur nachzudenken, Pull Requests sorgfältig zu lesen und die App zu testen.

Gleichzeitig bedeutete diese erhöhte Geschwindigkeit, dass stetig neuer Code auf ein Review wartete. Codex wurde nicht durch Kontextwechsel ausgebremst – wir schon. Unser Engpass in der Entwicklung verlagerte sich vom Schreiben von Code hin zum Treffen von Entscheidungen, zum Geben von Feedback und zum Integrieren von Änderungen.

Hier kommen Brooks’ Erkenntnisse auf eine neue Art zum Tragen. Man kann nicht einfach weitere Codex-Sitzungen hinzufügen und lineare Geschwindigkeitssteigerungen erwarten – genauso wenig, wie man fortlaufend Softwareingenieure zu einem Projekt hinzufügen und darauf hoffen kann, dass sich der Zeitplan linear verkürzt. Jedes zusätzliche „Paar Hände“, selbst virtuelle, erhöht den Koordinationsaufwand. Wir waren eher zum Dirigenten eines Orchesters geworden als einfach zu schnelleren Solospielern.

Beim Start unseres Projekts hatten wir einen großen Vorteil: Sora lief bereits auf iOS. Häufig verwiesen wir Codex auf die iOS- und Backend-Codebasen, um zu helfen, die zentralen Anforderungen und Einschränkungen zu verstehen. Während des gesamten Projekts scherzten wir darüber, dass wir die Idee eines Cross-Platform-Frameworks neu erfunden hätten. React Native oder Flutter, ade, die Zukunft von Cross-Platform ist einfach nur Codex.

Dieser Spruch basiert auf zwei Prinzipien:

1. Logik ist portabel. Egal, ob der Code in Swift oder Kotlin geschrieben ist – die zugrunde liegende Anwendungslogik – Datenmodelle, Netzwerkaufrufe, Validierungsregeln, Geschäftslogik – ist dieselbe. Codex ist sehr gut darin, eine Swift-Implementierung zu lesen und ein semantisch gleichwertiges Äquivalent in Kotlin zu erzeugen.
2. Konkrete Beispiele schaffen einen wirkungsvollen Kontext. Eine neue Codex-Session, die erkennen kann: „So funktioniert das also exakt unter iOS“ und „so ist die Android-Architektur also aufgebaut“, ist wesentlich effektiver als eine, die ausschließlich auf Beschreibungen in natürlicher Sprache basiert.

Unter Anwendung dieser Prinzipien stellten wir die iOS-, Backend- und Android-Repos in derselben Umgebung bereit. Wir versorgten Codex mit Prompts wie z. B.:

„Lies diese Modelle und Endpunkte im iOS-Code und schlage dann einen Plan vor, um das entsprechende Verhalten auf Android mit unserem bestehenden API-Client und den Modellklassen zu implementieren.“

Ein kleiner, aber hilfreicher Trick bestand darin, in  ~/.codex/AGENTS.md zu dokumentieren, wo sich die lokalen Repos befanden und was sie enthielten. Das erleichterte es Codex, relevanten Code zu finden und darin zu navigieren.

Wir betrieben im Grunde plattformübergreifende Entwicklung durch Übersetzung statt durch gemeinsame Abstraktionen. Da Codex den Großteil der Übersetzungsarbeit übernahm, konnten wir vermeiden, die Implementierungskosten zu verdoppeln.

Die übergeordnete Erkenntnis ist, dass für Codex der Kontext entscheidend ist. Codex lieferte die besten Ergebnisse, wenn es verstand, wie das Feature bereits unter iOS funktionierte, und zugleich wusste, wie unsere Android-App aufgebaut war. Fehlte dieser Kontext, „verweigerte“ Codex zwar nicht die Zusammenarbeit, musste jedoch raten. Je mehr wir es wie ein neues Teammitglied behandelten und in die richtigen Eingaben investierten, desto besser war die Leistung.

Am Ende unseres vierwöchigen Sprints fühlte sich die Nutzung von Codex nicht mehr wie ein Experiment an, sondern wurde zu unserem standardmäßigen Entwicklungsablauf. Wir nutzten Codex, um bestehenden Code zu verstehen, Änderungen zu planen und Features zu implementieren. Die Ergebnisse überprüften wir auf die gleiche Weise, wie wir die Arbeit eines Teamkollegen geprüft hätten. Es wurde zum normalen Ablauf der Softwareentwicklung.

Es wurde deutlich, dass KI-gestützte Entwicklung den Bedarf an Sorgfalt nicht verringert, sondern erhöht. So leistungsfähig Codex auch ist, sein Ziel ist es, möglichst schnell von A nach B zu gelangen. Deshalb funktioniert KI-gestütztes Programmieren nicht ohne den Menschen. Softwareingenieure können die realen Randbedingungen von Systemen verstehen und anwenden, kennen die besten Methoden der Softwarearchitektur und entwickeln mit Blick auf zukünftige Weiterentwicklung und Produktpläne. Die Superkräfte der Softwareingenieure von morgen werden ein tiefes Systemverständnis und die Fähigkeit sein, über lange Zeiträume hinweg kollaborativ mit KI zu arbeiten. 

Die interessantesten Aspekte der Softwareentwicklung sind das Erstellen überzeugender Produkte, das Entwerfen skalierbarer Systeme, das Schreiben komplexer Algorithmen sowie das Experimentieren mit Daten, Mustern und Code. Die Realität der Softwareentwicklung in Vergangenheit und Gegenwart ist jedoch oft deutlich banaler: Buttons zentrieren, Endpunkte verdrahten und Boilerplate-Code schreiben. Codex macht es nun möglich, sich auf die bedeutungsvollsten Teile der Softwareentwicklung zu konzentrieren – und auf die Gründe, warum wir unser Handwerk lieben.

Sobald Codex in einer kontextreichen Umgebung eingerichtet ist, in der es die Ziele und Arbeitsweisen versteht, kann jedes Team seine Fähigkeiten vervielfachen. Unser Rückblick auf den Launch ist kein Patentrezept, und wir behaupten nicht, die ultimative Lösung für KI-gestützte Entwicklung gefunden zu haben. Aber wir hoffen, dass unsere Erfahrungen es erleichtern, die besten Ansätze zu identifizieren, um Codex wirksam einzusetzen. 

Als Codex vor sieben Monaten als Research-Preview veröffentlicht wurde, sah Softwareentwicklung noch ganz anders aus. Durch Sora konnten wir das nächste Kapitel der Softwareentwicklung erkunden. Während sich unsere Modelle und die zugrunde liegende Infrastruktur kontinuierlich verbessern, wird KI zu einem zunehmend unverzichtbaren Bestandteil der Erschaffung von Software. 

Mit welchem Projekt wird sich dein Team Codex beschäftigen?