Hvordan vi brukte Codex til å bygge Sora for Android på 28 dager

Fra og med 26. april 2026 er ikke Sora-produktet tilgjengelig lenger.

I november lanserte vi Sora Android-appen på verdensbasis, og ga alle med Android-enhet muligheten til å forvandle en kort melding til en levende video. På lanseringsdagen ble appen nr. 1 i Play-butikken. Android-brukere genererte mer enn en million videoer i løpet av de første 24 timene.

Bak lanseringen ligger en historie: den første versjonen av Soras produksjonsapp for Android ble utviklet på 28 dager, takket være den samme agenten som er tilgjengelig for hvert team eller hver utvikler: Codex.

Fra 8. oktober til 5. november 2025 jobbet et lite team sammen med Codex og brukte omtrent 5 milliarder tokens for å lansere Sora for Android fra prototype til global lansering. Til tross for størrelsen har appen en krasjfri rate på 99,9 prosent og en arkitektur vi er stolt av. Hvis du lurer på om vi brukte en hemmelig modell, brukte vi en tidlig versjon av GPT‑5.1‑Codex modell – den samme versjonen som enhver utvikler eller bedrift kan bruke i dag via CLI, IDE-utvidelse eller app.

Da Sora ble lansert på iOS, eksploderte bruken. Folk begynte umiddelbart å generere en strøm av videoer. På Android, derimot, hadde vi bare en liten intern prototype og et økende antall forhåndsregistrerte brukere på Google Play.

En vanlig reaksjon på en lansering med høye innsatser og tidspress er å øke ressursene og legge til prosesser. En produksjonsapp av dette omfanget og denne kvaliteten vil typisk involvere mange ingeniører som jobber i flere måneder, forsinket av koordinering. 

Den amerikanske dataarkitekten Fred Brooks advarte berømt om at «hvis flere personer legges til i et forsinket programvareprosjekt, gjøres det enda mer forsinket». Med andre ord, når du prøver å levere et komplekst prosjekt raskt, kan det å legge til flere ingeniører ofte redusere effektiviteten ved å øke kommunikasjonsbyrden, oppgavefragmentering og integrasjonskostnader. Vi utnyttet denne innsikten i stedet for å ignorere den. Vi satte sammen et sterkt team bestående av fire ingeniører – alle utstyrt med Codex for å drastisk øke innflytelsen den enkelte av dem hadde. 

Ved å jobbe på denne måten, sendte vi en intern versjon av Sora for Android til ansatte etter 18 dager og lanserte den offentlig 10 dager senere. Vi opprettholdt en høy standard for Android-ingeniørpraksis, investerte i vedlikeholdbarhet, og holdt appen til den samme pålitelighetsstandarden som vi ville forvente fra et mer tradisjonelt prosjekt. (Vi fortsetter også å bruke Codex i stor grad i dag for å utvikle og legge til nye funksjoner i appen).

For å forstå hvordan vi jobbet med Codex, er det nyttig å vite hvor det utmerker seg og hvor det trenger mer arbeid. En god tilnærming var å behandle det som en nyansatt senioringeniør. Codex sin kapasitet gjorde at vi kunne bruke mer tid på å dirigere og gjennomgå kode enn å skrive den selv.

Hvor Codex trenger mer arbeid

1. Codex er ennå ikke svært god på å utlede det den ikke har fått informasjon om (f.eks. dine foretrukne arkitekturmønstre, produktstrategi, faktisk brukeradferd og interne normer eller snarveier).
2. På samme måte kunne ikke Codex se appen faktisk kjøre: Den kunne ikke åpne Sora på en enhet, merke at en rulling føltes feil, eller oppfatte at en flyt var forvirrende. Bare teamet vårt kunne dekke disse erfaringsbaserte oppgavene.
3. Hver forekomst krever en introduksjon. Det var avgjørende å dele kontekst med klare mål, begrensninger og veiledning om «hvordan vi gjør ting» for at Codex skulle fungere godt.
4. I samme ånd, slet Codex med dyp arkitektonisk vurdering: Hvis det ble overlatt til seg selv, kunne det introdusere en ekstra visningsmodell der vi egentlig ønsket å utvide en som fantes fra før, eller flytte logikk inn i brukergrensesnittlaget som klart hørte hjemme i et repository. Instinktet er å få noe til å fungere, ikke å prioritere langsiktig orden.

Vi fant det nyttig å la Codex opprette og vedlikeholde et stort antall AGENT.md-filer i hele kodebasen. Dette gjorde det enkelt å anvende den samme veiledningen og best praksis på tvers av økter. For å sikre at Codex skrev kode i henhold til våre stilretningslinjer, la vi for eksempel til følgende i vår AGENTS.md på toppnivå:

Der Codex utmerker seg

1. Lese og forstå store kodebaser raskt: Codex kjenner til alle større programmeringsspråk, noe som gjør det lettere å bruke de samme konseptene på tvers av mange plattformer uten komplekse abstraksjoner.
2. Testdekning: Codex er (unikt) entusiastisk for å skrive enhetstester for å dekke et bredt spekter av tilfeller. Ikke alle tester var dyptgående, men å ha bred dekning var nyttig for å forhindre regresjoner. 
3. Anvendelse av tilbakemelding: På en lignende måte er Codex flink til å reagere på tilbakemeldinger. Når CI feilet, kunne vi lime inn logg-utdata i en melding og be Codex om å foreslå rettelser.
4. Massivt parallell éngangsutførelse: De fleste vil ikke presse grensene for antall økter de faktisk kunne kjøre på én gang. Det er svært gjennomførbart å teste flere ideer parallelt og betrakte kode som forbruksvare.
5. Tilbyr nytt perspektiv: I design-diskusjoner brukte vi Codex som et generativt verktøy for å utforske potensielle feilkilder og oppdage nye måter å løse et problem på. Mens vi designet minneoptimaliseringer for videospilleren, gikk Codex for eksempel gjennom flere SDK-er for å foreslå tilnærminger vi ikke ville hatt tid til å analysere. Innsikten fra Codex sin forskning viste seg å være uvurderlig for å minimere minnefotavtrykket i den endelige appen.
6. Muliggjøre arbeid med større innflytelse: I praksis brukte vi mer tid på å gjennomgå og veilede kode enn å skrive den selv. Når det er sagt, er Codex også veldig god på kodegjennomgang, og oppdager ofte feil før de blir slått sammen, noe som forbedrer påliteligheten.

Når vi først erkjente disse egenskapene, ble arbeidsmodellen vår enklere. Vi støttet oss på Codex for å utføre en stor mengde tungt arbeid innenfor godt forståtte mønstre og velavgrensede områder, mens Teamet vårt fokuserte på arkitektur, brukeropplevelse, systemiske endringer og endelig kvalitet.

Selv den beste nye senioransatte har ikke det rette perspektivet for å gjøre langsiktige avveininger med én gang. For å utnytte Codex og sikre at arbeidet var robust og vedlikeholdbart, var det viktig at vi selv overvåket appens systemdesign og sentrale avveininger. Disse inkluderte utformingen av appens arkitektur, modularisering, avhengighetsinjeksjon og navigasjon; vi implementerte også autentisering og grunnleggende nettverksflyter. 

Basert på dette grunnlaget skrev vi noen representative funksjoner fra start til slutt. Vi brukte reglene vi ønsket at hele kodebasen skulle følge, og dokumenterte prosjektomfattende mønstre underveis. Ved å peke Codex mot representative funksjoner, kunne det arbeide mer selvstendig innenfor våre standarder. For et prosjekt som vi anslår var 85 % skrevet av Codex, unngikk en nøye planlagt grunnstruktur kostbar tilbakesporing og refaktorisering. Det var en av de viktigste avgjørelsene vi tok. 

Tanken var ikke å lage «noe som fungerer» så raskt som mulig, men heller å lage «noe som forstår hvordan vi vil at ting skal fungere.» Det finnes mange «korrekte» måter å skrive kode på. Vi trengte ikke å fortelle Codex nøyaktig hva den skulle gjøre; vi trengte å vise Codex hva som er "korrekt" på vårt team. Når vi først hadde etablert vårt utgangspunkt og hvordan vi likte å bygge, var Codex klar til å starte.

For å se hva som ville skje, prøvde vi å be om følgende: «Bygg Sora Android-appen basert på iOS-koden. Gå», men avbrøt raskt den veien. Selv om det som Codex opprettet teknisk sett fungerte, var produktopplevelsen under pari. Uten en klar forståelse av endepunkter, data og brukerflyter, var Codex sin enkeltutførte kode også upålitelig (Selv uten å bruke en agent, er det risikabelt å slå sammen tusenvis av linjer med kode.) 

Vi antok at Codex ville blomstre i en sandkasse med godt skrevne eksempler; og vi hadde rett. Å be Codex om å «bygge denne innstillingsskjermen» med nesten ingen kontekst var upålitelig. Det fungerte langt bedre å be Codex om å «bygge denne innstillingsskjermen ved å bruke samme arkitektur og mønstre som denne andre skjermen du nettopp så». Mennesker tok de strukturelle beslutningene og satte invariantene; Codex fylte deretter inn store mengder kode i den strukturen.

For å utnytte det fulle potensialet til Codex, ville vi få Codex til å funksjonere i lange perioder (nylig over 24 timer⁠) uten oppsyn.

Tidlig i bruken av Codex gikk vi rett til meldinger som, «Her er funksjonen. Her er noen filer. Sett det sammen for oss.» Det fungerte noen ganger, men produserte for det meste kode som teknisk sett kompilert, mens den avvek fra vår arkitektur og mål.

Derfor endret vi arbeidsflyten. For enhver ikke-triviell endring, ba vi først Codex om å hjelpe oss med å forstå hvordan systemet og koden fungerer. Vi ville for eksempel be den lese et sett med relaterte filer og oppsummere hvordan funksjonen fungerer; for eksempel, hvordan data flyter fra API-et gjennom repositorielaget, visningsmodell og inn i brukergrensesnittet. Deretter korrigertee eller forbedret vi forståelsen. (Vi ville for eksempel påpeke at en bestemt abstraksjon egentlig hører hjemme i et annet lag, eller at en gitt klasse kun eksisterer for offline-modus og ikke bør utvides.)

På lignende måte som du kanskje ville samarbeidet med en ny, svært dyktig kollega, jobbet vi med Codex for å opprette en solid implementeringsplan. Den planen så ofte ut som et miniatyrdesigndokument som angir hvilke filer som bør endres, hvilke nye tilstander som bør introduseres, og hvordan logikken bør flyte. Først da ba vi Codex om å begynne å iverksette planen, ett steg av gangen. Et nyttig tips: For svært lange oppgaver, der vi når grensen for kontekstvinduet vårt, ber vi Codex om å lagre planen sin til en fil, slik at vi kan anvende samme retning på tvers av tilfeller.

Denne ekstra planleggingssløyfen viste seg å være verdt tiden. Det gjorde at vi kunne la Codex kjøre «uten tilsyn» i lange perioder, fordi vi kjente til planene den hadde. Det gjorde det enklere å gå gjennom koden, fordi vi kunne sjekke implementeringen mot planen vår i stedet for å lese en diff uten kontekst. Og når noe gikk galt, kunne vi utføre feilsøking på planen først og deretter koden. 

Dynamikken lignet på måten et godt designdokument gir en teknisk leder selvtillit i et prosjekt. Vi genererte ikke bare kode: vi produserte kode som støttet en felles plan.

Midt uti prosjektet kjørte vi ofte flere Codex-økter samtidig. Én jobbet med avspilling, en annen med søk, en annen med feilhåndtering, og noen ganger en annen med tester eller refaktorering. Det føltes mindre som å bruke et verktøy og mer som å administrere et team.

Hver økt rapporterte med jevne mellomrom tilbake til oss om fremdriften. Én kunne si, «Jeg er ferdig med å planlegge denne modulen; her er hva jeg foreslår,» mens en annen ville tilby en stor diff for en ny funksjon. Hver enkelt krevde oppmerksomhet, tilbakemelding og gjennomgang. Det var påfallende likt å være en teknisk leder med flere nye ingeniører. Alle gjorde fremgang, alle trengte veiledning.

Resultatet var et samarbeidende flyt. Codex’ rå kodingsevne frigjorde oss fra mye manuell skriving. Vi hadde mer tid til å tenke på arkitektur, lese pull requests nøye og teste ut appen. 

Samtidig betydde den ekstra hastigheten at vi alltid hadde noe som ventet i køen vår for gjennomgang. Codex ble ikke blokkert av kontekstbytte, men vi ble det. Flaskehalsen vår i utviklingen har flyttet seg fra å skrive kode til å ta beslutninger, gi tilbakemeldinger og integrere endringer.

Det er her Brooks' innsikt lander på en ny måte. Du kan ikke bare legge til Codex-økter og forvente lineære hastighetsøkninger, like lite som du kan fortsette å legge til ingeniører til et prosjekt og forvente at tidsplanen skal krympe lineært. Hver ekstra «hjelpende hånd,» selv virtuelle, legger til koordinasjonsbelastning. Vi hadde blitt dirigenten for et orkester i stedet for bare raskere solospillere.

Vi startet prosjektet vårt med et stort springbrett: Sora hadde allerede blitt lansert på iOS. Vi pekte ofte Codex i retning av iOS- og backend-kodebasene for å hjelpe den med å forstå viktige krav og begrensninger. Gjennom hele prosjektet spøkte vi med at vi hadde gjenoppfunnet ideen om et plattformuavhengig rammeverk. Glem React Native eller Flutter; fremtiden for plattformuavhengighet er bare Codex.

Bak vittigheten ligger det to prinsipper:

1. Logikk er bærbar. Enten koden er skrevet i Swift eller Kotlin, er den underliggende applikasjonslogikken – datamodeller, nettverksanrop, valideringsregler, bedriftslogikk – den samme. Codex er veldig god til å lese en Swift-implementering og produsere en tilsvarende i Kotlin som bevarer semantikken.
2. Konkrete eksempler gir en betydningsfull kontekst. En ny Codex-økt som kan se «slik fungerer dette på iOS» og «her er Android-arkitekturen» er langt mer effektiv enn en som bare arbeider ut fra naturlige språkbeskrivelser.

Ved å anvende disse prinsippene, gjorde vi iOS-, backend- og Android-repoene tilgjengelige i det samme miljøet. Vi ga Codex oppfordringer som:

Les disse modellene og endepunktene i iOS-koden og foreslå deretter en plan for å implementere tilsvarende oppførsel på Android ved å bruke vår eksisterende API-klient og modellklasser.

Et lite, men nyttig triks var å spesifisere i ~/.codex/AGENTS.md hvor lokale kodearkiver befant seg og hva de inneholdt. Det gjorde det enklere for Codex å oppdage og navigere i relevant kode.

Vi drev effektivt med plattformuavhengig utvikling gjennom oversettelse i stedet for delt abstraksjon. Fordi Codex håndterte mesteparten av oversettelsen, unngikk vi å doble implementeringskostnadene.

Den bredere lærdommen er at for Codex er kontekst alt. Codex gjorde sitt beste arbeid når det forsto hvordan funksjonen allerede fungerte i iOS, sammen med en forståelse av hvordan Android-appen vår var strukturert. Når Codex manglet den konteksten, var det ikke «nektet å samarbeide»; det gjettet. Jo mer vi behandlet det som en ny lagkamerat og investerte i å gi det de riktige inndataene, desto bedre presterte det.

Ved slutten av vår fire-ukers sprint, sluttet bruken av Codex å føles som et eksperiment og ble vår standard utviklingssløyfe. Vi brukte det til å forstå eksisterende kode, lage en plan for endringer og implementere funksjoner. Vi gjennomgikk resultatet på samme måte som vi ville ha gjennomgått en kollega sitt. Det var rett og slett slik vi leverte programvare.

Det ble tydelig at KI‑assistert utvikling ikke reduserer behovet for grundighet; det øker det. Så kapabel som Codex er, er målet å komme fra A til B, nå. Dette er grunnen til at KI-assistert koding ikke fungerer uten mennesker. Programvareingeniører kan forstå og anvende de virkelige begrensningene i systemer, de beste måtene å designe programvare på, og hvordan man bygger med fremtidige utviklings- og produktplaner i tankene. Morgendagens superkrefter for en programvareingeniør vil være dyp systemforståelse og evnen til å samarbeide med KI over lange tidshorisonter. 

De mest interessante delene av programvareutvikling er å bygge engasjerende produkter, designe skalerbare systemer, skrive komplekse algoritmer og eksperimentere med data, mønstre og kode. Realitetene i programvareutvikling fra fortid og nåtid er imidlertid ofte mer hverdagslige: sentrering av knapper, kobling av endepunkter og skriving av boilerplate-kode. Nå gjør Codex det mulig å fokusere på de mest meningsfulle delene av programvareutvikling og årsakene til hvorfor vi elsker håndverket vårt.

Når Codex er satt opp i et kontekstrikt miljø der det forstår målene dine og hvordan du liker å bygge, kan ethvert team multiplisere sine evner. Vår lanseringsretro er ikke en oppskrift som passer for alle, og vi påstår ikke å ha løst KI-assistert utvikling. Vi håper derimot at vår erfaring gjør det lettere å finne de beste måtene å styrke Codex for å styrke deg. 

Da Codex ble lansert i en forskningsforhåndsvisning for syv måneder siden, så programvareutvikling svært annerledes ut. Gjennom Sora fikk vi utforske neste kapittel i ingeniørfaget. Etter hvert som våre modeller og verktøy stadig forbedres, blir KI en stadig mer uunnværlig del av byggeprosessen. 

Hva vil du lage med ditt eget Codex-team?