Wie wir Codex genutzt haben, um Sora für Android in 28 Tagen zu entwickeln

Im November 2025 wurde die Sora Android-App weltweit eingeführt, die es jedem mit einem Android-Gerät ermöglicht, aus einem kurzen Prompt ein lebendiges Video zu erstellen. Am Tag der Einführung erreichte die App den ersten Platz im Play Store, und Android-Nutzer generierten in den ersten 24 Stunden über eine Million Videos. Hinter diesem Erfolg steht eine bemerkenswerte Geschichte: Die erste Version der Produktions-App von Sora wurde in nur 28 Tagen mit Hilfe von OpenAI Codex entwickelt. Ein schlankes Ingenieurteam arbeitete vom 8. Oktober bis zum 5. November 2025 und nutzte dabei rund 5 Milliarden Tokens, um Sora für Android von der Prototyp-Phase bis zur globalen Einführung zu bringen.

Die Herausforderung: Schnelligkeit und Effizienz

Bei der Einführung von Sora auf iOS explodierte die Nutzung sofort. Im Gegensatz dazu hatten wir für Android nur einen kleinen internen Prototyp und eine wachsende Anzahl von vorregistrierten Nutzern im Google Play Store. Eine gängige Reaktion auf einen zeitlich drängenden Launch ist es, Ressourcen zu bündeln und Prozesse zu erweitern. Fred Brooks, ein amerikanischer Computerarchitekt, warnte jedoch: “Das Hinzufügen von mehr Personen zu einem späten Softwareprojekt macht es später.” Das bedeutet, dass das Hinzufügen von Ingenieuren oft die Effizienz verringert, indem es Kommunikationsaufwand, Aufgabenfragmentierung und Integrationskosten erhöht.

Ein agiler Ansatz

Wir haben diese Einsicht angenommen und ein starkes Team von vier Ingenieuren zusammengestellt, die alle mit Codex ausgestattet waren, um die Auswirkungen jedes Ingenieurs drastisch zu erhöhen. Auf diese Weise konnten wir einen internen Build von Sora für Android in 18 Tagen an unsere Mitarbeiter ausliefern und 10 Tage später öffentlich launchen. Wir hielten hohe Standards für die Android-Engineering-Praktiken ein, investierten in die Wartbarkeit und hielten die App an denselben Zuverlässigkeitsstandards fest, die wir von einem traditionelleren Projekt erwarten würden.

Onboarding eines neuen Senior Engineers

Um zu verstehen, wie wir mit Codex arbeiteten, ist es hilfreich zu wissen, wo Codex glänzt und wo es Anleitung benötigt. Die Behandlung von Codex wie eines neu eingestellten Senior Engineers war ein guter Ansatz. Codex ermöglichte es uns, mehr Zeit mit der Anleitung und Überprüfung von Code zu verbringen, als mit dem Schreiben von Code selbst.

Wo Codex Anleitung benötigt

• Codex ist noch nicht gut darin, zu inferieren, was ihm nicht gesagt wurde (z.B. bevorzugte Architektur-Muster, Produktstrategie, echtes Nutzerverhalten und interne Normen).
• Codex kann die App nicht tatsächlich ausführen: Es kann Sora auf einem Gerät nicht öffnen, bemerken, dass ein Scrollen seltsam ist, oder erkennen, dass ein Flow verwirrend ist.
• Jede Instanz benötigt ein Onboarding. Das Teilen von Kontext mit klaren Zielen, Einschränkungen und Anleitungen war entscheidend für die erfolgreiche Ausführung von Codex.
• Codex hatte Schwierigkeiten mit tiefem architektonischen Urteilsvermögen.

Wo Codex glänzt

• Schnelles Lesen und Verstehen großer Codebasen.
• Testabdeckung: Codex ist besonders begeistert davon, Unit-Tests zu schreiben.
• Reaktion auf Feedback: Codex kann auf CI-Fehler reagieren und Vorschläge zur Behebung machen.
• Massiv parallele, disposable Ausführung: Codex kann mehrere Ideen gleichzeitig testen.
• Anbieten neuer Perspektiven: Codex half uns, potenzielle Fehlerquellen zu erkunden und neue Lösungsansätze zu finden.

Die Grundlagen legen

Um Codex effektiv zu nutzen, war es entscheidend, dass wir das Systemdesign und die Schlüsselentscheidungen selbst überwachten. Dazu gehörten die Gestaltung der Architektur der App, Modularisierung, Abhängigkeitsinjektion und Navigation. Wir schrieben einige repräsentative Funktionen von Ende zu Ende und verwendeten die Regeln, die wir für den gesamten Code einhalten wollten. Durch das Zeigen von repräsentativen Funktionen konnte Codex unabhängiger innerhalb unserer Standards arbeiten.

Planung mit Codex vor dem Codieren

Ein weiterer Schritt zur Maximierung des Potenzials von Codex war die Entwicklung eines Implementierungsplans. Für jede nicht triviale Änderung baten wir Codex, uns zu helfen, das System und den Code zu verstehen. Diese zusätzliche Planungsschleife stellte sich als wertvoll heraus, da sie es uns ermöglichte, Codex über längere Zeiträume unbeaufsichtigt arbeiten zu lassen.

Verteilte Ingenieurskunst

Zu Spitzenzeiten des Projekts führten wir oft mehrere Codex-Sitzungen parallel aus. Jede Sitzung berichtete regelmäßig über Fortschritte und benötigte Feedback. Das Ergebnis war ein kollaborativer Fluss, der es uns ermöglichte, uns auf Architektur, das Testen der App und die Überprüfung von Pull-Requests zu konzentrieren.

Codex als plattformübergreifende Superkraft

Wir begannen unser Projekt mit einem großen Vorteil: Sora war bereits auf iOS veröffentlicht worden. Wir gaben Codex Zugriff auf die iOS- und Backend-Codebasen, um die Anforderungen und Einschränkungen zu verstehen. Wir haben Codex gebeten, die Modelle und Endpunkte im iOS-Code zu lesen und einen Plan zur Implementierung des entsprechenden Verhaltens auf Android vorzuschlagen.

Die Softwareentwicklung der Zukunft, heute

Am Ende unseres vierwöchigen Sprints wurde die Nutzung von Codex zu unserem Standardentwicklungsprozess. Wir verwendeten es, um bestehenden Code zu verstehen, Änderungen zu planen und Funktionen zu implementieren. Es wurde klar, dass KI-unterstützte Entwicklung nicht den Bedarf an Rigor verringert, sondern erhöht. Die Superkräfte der Softwareentwickler von morgen werden ein tiefes Systemverständnis und die Fähigkeit sein, über lange Zeiträume hinweg mit KI zusammenzuarbeiten.

Quellenliste:

• Quelle: HOW WE USED CODEX TO BUILD SORA FOR ANDROID IN 28 DAYS
• Engineering News
• OpenAI Research