Hoe we Codex gebruikten om Sora voor Android in 28 dagen uit te brengen

Vanaf 26-4-2026 is het Sora-product niet langer beschikbaar.

In november hebben we de Sora Android-app wereldwijd gelanceerd. Hiermee kan iedereen met een Android-toestel een korte prompt omzetten in een levendige video. Op de dag van de lancering bereikte de app de eerste plaats in de Play Store. Android-gebruikers hebben in de eerste 24 uur meer dan een miljoen video's gegenereerd.

Achter deze lancering schuilt een verhaal: de eerste versie van de Sora-productieapp voor Android werd in 28 dagen gebouwd. Dit was mogelijk dankzij dezelfde agent die voor elk team en elke ontwikkelaar beschikbaar is: Codex.

Van 8 oktober tot 5 november 2025 bracht een klein, efficiënt engineeringteam (samen met Codex en met een verbruik van ongeveer 5 miljard tokens) Sora voor Android van prototype naar wereldwijde lancering. Ondanks de omvang heeft de app een crashvrij percentage van 99,9 procent en een architectuur waar we trots op zijn. Mocht je je afvragen of we een geheim model gebruikten: we werkten met een vroege versie van het GPT‑5.1‑Codex‑model. Dit is dezelfde versie die elke ontwikkelaar of elk bedrijf vandaag de dag kan gebruiken via de CLI, een IDE-extensie of de webapp.

Toen Sora op iOS werd gelanceerd, explodeerde het gebruik. Mensen begonnen onmiddellijk een stroom aan video's te genereren. Voor Android hadden we daarentegen slechts een klein intern prototype en een oplopend aantal voorregistraties in Google Play.

Een veelvoorkomende reactie op een belangrijke lancering met hoge tijdsdruk, is het toevoegen van extra middelen en processen. Een productieapp van deze omvang en kwaliteit zou normaal gesproken vele engineers vereisen die maandenlang werken, vertraagd door afstemming. 

De Amerikaanse computerarchitect Fred Brooks waarschuwde dat "het toevoegen van meer mensen aan een vertraagd softwareproject het alleen maar later maakt". Met andere woorden: als je een complex project snel wilt opleveren, kan het toevoegen van meer engineers de efficiëntie vaak verlagen door extra communicatie-overhead, taakfragmentatie en integratiekosten. We omarmden dit inzicht in plaats van het te negeren. We stelden een sterk team samen van vier engineers, allemaal uitgerust met Codex om de impact van elke engineer drastisch te vergroten. 

Door op deze manier te werken, leverden we in 18 dagen een interne build van Sora voor Android aan medewerkers en lanceerden we 10 dagen later voor het publiek. We hielden vast aan een hoge standaard voor Android-engineering, investeerden in onderhoudbaarheid en hanteerden dezelfde betrouwbaarheidsnorm als bij een traditioneler project. (We gebruiken Codex vandaag de dag nog steeds intensief om de app door te ontwikkelen en nieuwe functies toe te voegen.)

Om te begrijpen hoe we met Codex werkten, helpt het om te weten waar het in uitblinkt en waar het sturing nodig heeft. Het bleek een goede aanpak om het te behandelen als een pas aangenomen senior engineer. De capaciteiten van Codex zorgden ervoor dat we meer tijd konden besteden aan het aansturen en reviewen van code dan aan het zelf schrijven ervan.

Waar Codex sturing nodig heeft

1. Codex is nog niet geweldig in het afleiden van wat niet expliciet verteld is (bijv. voorkeursarchitectuur, productstrategie, werkelijk gebruikersgedrag en interne normen of shortcuts).
2. Evenzo kon Codex de app niet daadwerkelijk zien draaien: het kon Sora niet openen op een toestel, opmerken dat het scrollen niet goed aanvoelde of aanvoelen dat een flow verwarrend was. Alleen ons team kon deze ervaringsgerichte taken oppakken.
3. Elke instantie vereist onboarding. Het delen van context met duidelijke doelen, kaders en richtlijnen over 'hoe wij dingen doen' was essentieel om Codex goed te laten presteren.
4. In dezelfde lijn had Codex moeite met diepgaande architecturale beslissingen. Als we het zijn gang lieten gaan, introduceerde het misschien een extra view model waar we er eigenlijk een wilden uitbreiden, of stopte het logica in de UI-laag die duidelijk in een repository thuishoorde. Zijn instinct is om iets werkend te krijgen, niet om prioriteit te geven aan netheid op de lange termijn.

We vonden het nuttig om Codex een flink aantal AGENT.md-bestanden te laten aanmaken en onderhouden in de codebase. Dit maakte het eenvoudig om dezelfde richtlijnen en best practices toe te passen in verschillende sessies. Om er bijvoorbeeld voor te zorgen dat Codex code schreef volgens onze stijlrichtlijnen, voegden we het volgende toe aan onze AGENTS.md op het hoogste niveau:

Waar Codex in uitblinkt

1. Snel lezen en begrijpen van grote codebases: Codex kent in wezen alle belangrijke programmeertalen. Dit maakt het makkelijker om dezelfde concepten op verschillende platforms toe te passen zonder complexe abstracties.
2. Testdekking: Codex is (uniek) enthousiast over het schrijven van unit-tests voor een grote verscheidenheid aan scenario's. Niet elke test was diepgaand, maar een brede dekking hielp wel om regressies te voorkomen. 
3. Feedback verwerken: Codex is ook goed in het reageren op feedback. Wanneer de CI faalde, konden we de loguitvoer in een prompt plakken en Codex vragen om oplossingen voor te stellen.
4. Massaal parallelle, wegwerpbare uitvoering: De meesten zullen de limiet van het aantal gelijktijdige sessies niet snel bereiken. Het is heel goed mogelijk om meerdere ideeën parallel te testen en code als wegwerpbaar te beschouwen.
5. Een nieuw perspectief bieden: In ontwerpsessies gebruikten we Codex als een generatieve tool om potentiële knelpunten te verkennen en nieuwe oplossingen te ontdekken. Toen we bijvoorbeeld geheugenoptimalisaties voor de videospeler ontwierpen, doorzocht Codex meerdere SDK's om benaderingen voor te stellen die wij zelf nooit zo snel hadden kunnen uitpluizen. De inzichten uit het onderzoek van Codex bleken van onschatbare waarde voor het minimaliseren van het geheugenverbruik in de uiteindelijke app.
6. Werk met meer impact mogelijk maken: In de praktijk besteedden we uiteindelijk meer tijd aan het reviewen en aansturen van code dan aan het zelf schrijven ervan. Dat gezegd hebbende, is Codex ook erg goed in code reviews; het spoort vaak bugs op voordat ze worden gemerged, wat de betrouwbaarheid verbetert.

Toen we deze eigenschappen eenmaal erkenden, werd onze werkwijze eenvoudiger. We lieten Codex het zware werk doen binnen duidelijke patronen en afgebakende kaders, terwijl ons team zich richtte op architectuur, gebruikerservaring, systemische veranderingen en de uiteindelijke kwaliteit.

Zelfs de beste nieuwe senior medewerker heeft niet direct het overzicht om langetermijnafwegingen te maken. Om Codex goed te benutten en te zorgen voor robuust en onderhoudbaar werk, was het cruciaal dat we zelf toezicht hielden op het systeemontwerp en de belangrijkste keuzes. Dit omvatte het vormgeven van de architectuur, modularisatie, dependency injection en navigatie; ook implementeerden we zelf de authenticatie en de basis netwerkflows. 

Vanuit deze basis schreven we enkele representatieve features van begin tot eind. We pasten de regels toe die we voor de hele codebase wilden laten gelden en documenteerden gaandeweg de projectbrede patronen. Door Codex naar deze voorbeelden te verwijzen, kon het zelfstandiger werken binnen onze standaarden. Voor een project dat naar schatting voor 85% door Codex is geschreven, voorkwam een zorgvuldig geplande basis kostbaar herstelwerk en refactoring. Het was een van de belangrijkste beslissingen die we hebben genomen. 

Het idee was niet om zo snel mogelijk 'iets te maken dat werkt', maar eerder om 'iets te maken dat begrijpt hoe wij willen dat dingen werken'. Er zijn veel 'juiste' manieren om code te schrijven. We hoefden Codex niet precies te vertellen wat het moest doen: we moesten laten zien wat 'juist' is binnen ons team. Toen we eenmaal ons startpunt en onze bouwwijze hadden vastgesteld, was Codex klaar om te beginnen.

Om te testen wat er zou gebeuren, probeerden we de prompt: 'Bouw de Sora Android-app op basis van de iOS-code. Start,' maar dat pad hebben we snel verlaten. Hoewel wat Codex creëerde technisch werkte, was de productervaring ondermaats. En zonder een duidelijk begrip van endpoints, data en user flows was de in één keer gegenereerde code onbetrouwbaar (zelfs zonder AI is het riskant om duizenden regels code te mergen). 

Onze hypothese was dat Codex zou gedijen in een omgeving vol goed geschreven voorbeelden, en we hadden gelijk. Codex vragen om 'dit instellingenscherm te bouwen' met vrijwel geen context, bleek onbetrouwbaar. Vragen om 'dit instellingenscherm te bouwen met dezelfde architectuur en patronen als dit andere scherm dat je net zag' werkte veel beter. Mensen namen de structurele beslissingen en bepaalden de kaders, Codex vulde vervolgens grote hoeveelheden code in binnen die structuur.

Onze volgende stap om het potentieel van Codex te maximaliseren, was uitzoeken hoe we Codex gedurende lange perioden (recentelijk meer dan 24 uur⁠) onbeheerd konden laten werken.

In het begin grepen we snel naar prompts als: 'Hier is de feature. Hier zijn wat bestanden. Bouw het alsjeblieft.' Dat werkte soms, maar leverde meestal code op die technisch gezien wel compileerde, maar afweek van onze architectuur en doelen.

Dus pasten we de workflow aan. Voor elke substantiële wijziging vroegen we Codex eerst om ons te helpen begrijpen hoe het systeem en de code werken. We vroegen het bijvoorbeeld om een set gerelateerde bestanden te lezen en samen te vatten hoe die feature werkt; bijvoorbeeld hoe data van de API via de repository-laag en het view model naar de UI stroomt. Vervolgens corrigeerden of verfijnden we dat begrip. (We wezen er bijvoorbeeld op dat een bepaalde abstractie eigenlijk in een andere laag thuishoorde, of dat een bepaalde klasse alleen voor de offline-modus bestaat en niet uitgebreid moet worden.)

Net zoals je een nieuwe, zeer bekwame collega zou inschakelen, werkten we samen met Codex aan een gedegen implementatieplan. Dat plan leek vaak op een beknopt ontwerpdocument dat aangaf welke bestanden gewijzigd moesten worden, welke nieuwe statussen er nodig waren en hoe de logica moest lopen. Pas daarna vroegen we Codex om het plan uit te voeren, stap voor stap. Een handige tip: bij erg lange taken, waarbij we tegen de limiet van het contextvenster aanliepen, vroegen we Codex om het plan in een bestand op te slaan, zodat we dezelfde instructies in verschillende sessies konden blijven gebruiken.

Deze extra planningsronde bleek de tijd meer dan waard. Hierdoor konden we Codex langere tijd 'onbeheerd' laten werken, omdat we wisten wat de plannen waren. Het maakte de code review eenvoudiger, omdat we de implementatie konden toetsen aan ons plan in plaats van een diff te lezen zonder context. En als er iets misging, konden we eerst het plan debuggen en daarna pas de code. 

Deze dynamiek voelde vergelijkbaar met hoe een goed ontwerpdocument een tech lead vertrouwen geeft in een project. We genereerden niet zomaar code: we produceerden code die een gezamenlijke roadmap ondersteunde.

Op het hoogtepunt van het project lieten we vaak meerdere Codex-sessies parallel draaien. De ene werkte aan het afspelen, de andere aan de zoekfunctie, weer een andere aan foutafhandeling, en soms nog een aan tests of refactors. Het voelde minder als het gebruik van een tool en meer als het aansturen van een team.

Elke sessie koppelde periodiek de voortgang aan ons terug. De ene zou kunnen zeggen: "Ik ben klaar met het plannen van deze module: dit is mijn voorstel," terwijl de andere een grote diff voor een nieuwe feature aanbood. Elk vereiste aandacht, feedback en review. Het leek griezelig veel op de rol van een tech lead met meerdere nieuwe engineers, die allemaal vooruitgang boeken en allemaal sturing nodig hebben.

Het resultaat was een soepele flow van samenwerking. De pure codeercapaciteit van Codex bevrijdde ons van veel handmatig typwerk. We hadden meer tijd om na te denken over architectuur, pull requests zorgvuldig te lezen en de app te testen. 

Tegelijkertijd betekende die extra snelheid dat er altijd iets in onze review-wachtrij stond. Codex liep niet vast door het wisselen van context, maar wij wel. Onze bottleneck in de ontwikkeling verschoof van het schrijven van code naar het nemen van beslissingen, het geven van feedback en het integreren van wijzigingen.

Dit is waar de inzichten van Brooks op een nieuwe manier relevant worden. Je kunt niet simpelweg Codex-sessies toevoegen en een lineaire versnelling verwachten, net zo min als dat je engineers aan een project kunt blijven toevoegen en verwachten dat de planning lineair krimpt. Elk extra 'paar handen', zelfs virtuele, voegt coördinatie-overhead toe. We waren de dirigent van een orkest geworden in plaats van simpelweg snellere solisten.

We begonnen ons project met een enorme voorsprong: Sora was al uitgebracht op iOS. We verwezen Codex regelmatig naar de iOS- en backend-codebases om het te helpen de belangrijkste vereisten en beperkingen te begrijpen. Tijdens het project grapten we dat we het idee van een cross-platform framework opnieuw hadden uitgevonden. Vergeet React Native of Flutter; de toekomst van cross-platform is gewoon Codex.

Onder die grap liggen twee principes:

1. Logica is overdraagbaar. Of de code nu in Swift of Kotlin is geschreven, de onderliggende applicatielogica (datamodellen, netwerkcalls, validatieregels, bedrijfslogica) is hetzelfde. Codex is erg goed in het lezen van een Swift-implementatie en het produceren van een equivalent in Kotlin waarbij de semantiek behouden blijft.
2. Concrete voorbeelden bieden krachtige context. Een nieuwe Codex-sessie die kan zien 'hier is precies hoe dit werkt op iOS' en 'hier is de Android-architectuur', is veel effectiever dan een sessie die alleen werkt op basis van beschrijvingen in natuurlijke taal.

Om deze principes toe te passen, maakten we de iOS-, backend- en Android-repository's beschikbaar in dezelfde omgeving. We gaven Codex prompts zoals:

"Lees deze modellen en endpoints in de iOS-code en stel vervolgens een plan voor om het equivalente gedrag op Android te implementeren met behulp van onze bestaande API-client en modelklassen."

Een kleine maar handige truc was om in ~/.codex/AGENTS.md in detail aan te geven waar lokale repository's zich bevonden en wat ze bevatten. Dat maakte het voor Codex makkelijker om relevante code te ontdekken en te doorzoeken.

We deden in feite aan cross-platform ontwikkeling door middel van vertaling in plaats van gedeelde abstractie. Omdat Codex het grootste deel van de vertaling voor zijn rekening nam, vermeden we een verdubbeling van de implementatiekosten.

De bredere les is dat voor Codex context allesbepalend is. Codex leverde het beste werk wanneer het begreep hoe de feature al werkte in iOS, gecombineerd met inzicht in de structuur van onze Android-app. Wanneer Codex die context miste, was het niet aan het 'weigeren mee te werken', het was aan het gokken. Hoe meer we het behandelden als een nieuwe teamgenoot en investeerden in het geven van de juiste input, hoe beter het presteerde.

Tegen het einde van onze sprint van vier weken voelde het gebruik van Codex niet meer als een experiment, maar werd het onze standaard ontwikkelcyclus. We gebruikten het om bestaande code te begrijpen, wijzigingen te plannen en features te implementeren. We reviewden de output op dezelfde manier als we dat bij een teamgenoot zouden doen. Het was gewoon de manier waarop we software opleverden.

Het werd duidelijk dat AI-ondersteunde ontwikkeling de behoefte aan discipline niet vermindert, maar juist vergroot. Hoe capabel Codex ook is, het doel ervan is om van A naar B te komen, en wel nu. Daarom werkt AI-ondersteund coderen niet zonder mensen. Software-engineers kunnen de real-world beperkingen van systemen begrijpen en toepassen, bepalen hoe software het beste kan worden opgezet en bouwen met toekomstige ontwikkeling en productplannen in het achterhoofd. De superkrachten van de software-engineer van morgen zullen bestaan uit een diepgaand systeembegrip en het vermogen om over langere perioden samen te werken met AI. 

De interessantste onderdelen van software-engineering zijn het bouwen van boeiende producten, het ontwerpen van schaalbare systemen, het schrijven van complexe algoritmen en het experimenteren met data, patronen en code. De realiteit van software-engineering in het verleden en heden neigt echter vaak naar het alledaagse: knoppen centreren, endpoints koppelen en boilerplate schrijven. Codex maakt het nu mogelijk om te focussen op de meest betekenisvolle delen van software-engineering en de redenen waarom we van ons vak houden.

Zodra Codex is opgezet in een contextrijke omgeving waarin het je doelen begrijpt en weet hoe je wilt bouwen, kan elk team zijn capaciteiten vermenigvuldigen. Onze terugblik op de lancering is geen kant-en-klaar recept, en we beweren niet dat we AI-ondersteunde ontwikkeling hebben 'opgelost'. Maar we hopen dat onze ervaring het makkelijker maakt om de beste manieren te vinden om Codex jou te laten versterken. 

Toen Codex zeven maanden geleden in een research preview werd gelanceerd, zag software-engineering er heel anders uit. Via Sora hebben we het volgende hoofdstuk van engineering kunnen verkennen. Naarmate onze modellen en tools blijven verbeteren, zal AI een steeds onmisbaarder onderdeel worden van het bouwproces. 

Wat ga jij maken met je eigen team van Codex?