Sådan brugte vi Codex til at bygge Sora til Android på 28 dage

Fra og med den 26. april 2026 vil Sora-produktet ikke længere være tilgængeligt.

I november lancerede vi Sora Android app globalt, hvilket gav alle med en Android-enhed mulighed for at forvandle en kort forespørgsel til en levende video. På lanceringsdagen nåede appen #1 i Play Butik. Android-brugere genererede mere end en million videoer i løbet af de første 24 timer.

Bag lanceringen er en historie: den første version af Soras produktions-Android-app blev bygget på 28 dage takket være den samme agent, der er tilgængelig for ethvert team eller enhver udvikler: Codex.

Fra 8. oktober til 5. november 2025 arbejdede et lean engineering-team sammen med Codex og brugte cirka 5 milliarder tokens på at bringe Sora til Android fra prototype til global lancering. På trods af sin størrelse har appen en nedbrudsfri rate på 99,9 procent og en arkitektur, vi er stolte af. Hvis du undrer dig over, om vi brugte en hemmelig model, så brugte vi en tidlig version af GPT‑5.1‑Codex‑ model – den samme version, som enhver udvikler eller virksomhed kan bruge i dag via CLI, IDE-udvidelse eller app.

Da Sora blev lanceret på iOS, eksploderede brugen. Folk begyndte straks at generere en strøm af videoer. På Android havde vi derimod kun en lille intern prototype og et stigende antal forhåndsregistrerede brugere på Google Play.

En almindelig reaktion på en lancering med høje indsatser og tidspres er at tilføre flere ressourcer og tilføje processer. En produktionsapp af denne størrelse og kvalitet ville typisk involvere mange ingeniører, der arbejder i flere måneder, forsinket af koordinering. 

Den amerikanske computerarkitekt Fred Brooks advarede berømt om, at "tilføjelse af flere personer til et forsinket softwareprojekt gør det endnu mere forsinket." Med andre ord, når man forsøger at aflevere et komplekst projekt hurtigt, kan det ofte sænke effektiviteten ved at øge kommunikationsomkostninger, opgavefragmentering og integrationsomkostninger. Vi lænede os op ad denne indsigt i stedet for at ignorere den; vi samlede et stærkt team af fire ingeniører – alle udstyret med Codex for drastisk at øge hver enkelt ingeniørs indflydelse. 

På denne måde sendte vi en intern version af Sora til Android til medarbejderne på 18 dage og lancerede den offentligt 10 dage senere. Vi opretholdt en høj standard for Android-ingeniørpraksis, investerede i vedligeholdelse og holdt appen til den samme pålidelighedsstandard, som vi ville forvente af et mere traditionelt projekt. (Vi fortsæt også med at bruge Codex i stor udstrækning i dag for at udvikle og bringe nye funktioner til appen).

For at forstå, hvordan vi arbejdede med Codex, er det nyttigt at vide, hvor det udmærker sig, og hvor det har brug for vejledning. Det var en god tilgang at behandle det som en nyansat senioringeniør. Codex' evne betød, at vi kunne bruge mere tid på at dirigere og gennemgå kode end på at skrive den selv.

Hvor Codex har brug for vejledning

1. Codex er endnu ikke god til at udlede det, den ikke er blevet fortalt (f.eks. dine foretrukne arkitekturmønstre, produktstrategi, reel brugeradfærd og interne normer eller genveje).
2. På samme måde kunne Codex ikke se appen rent faktisk køre: Den kunne ikke åbne Sora på en enhed, bemærke at en rulning føltes forkert eller fornemme at et flow var forvirrende. Kun vores team kunne dække disse erfaringsmæssige opgaver.
3. Hver instans kræver onboarding. Det var afgørende for, at Codex fungerede godt, at vi delte kontekst med klare mål, begrænsninger og vejledning i, "hvordan vi gør tingene".
4. På samme måde kæmpede Codex med dybe arkitektoniske vurderinger: Hvis det blev overladt til sig selv, kunne det introducere en ekstra visningsmodel, hvor vi egentlig ønskede at udvide en eksisterende model eller flytte logik til UI-laget, som klart hørte hjemme i et repository. Dets instinkt er at få noget til at fungere, ikke at prioritere langsigtet renlighed.

Vi fandt det nyttigt at lade Codex skabe og vedligeholde en generøs mængde agent.md-filer i hele kodebasen. Dette gjorde det nemt at anvende den samme vejledning og anbefalede fremgangsmåder på tværs af sessioner. For at sikre, at Codex skrev kode i overensstemmelse med vores stilretningslinjer, tilføjede vi for eksempel følgende til vores topniveau AGENTS.md:

Her udmærker Codex sig

1. Hurtig læsning og forståelse af store kodebaser: Codex kender stort set alle større programmeringssprog, hvilket gør det lettere at anvende de samme koncepter på tværs af mange platforme uden komplekse abstraktioner.
2. Testdækning: Codex er (særligt) entusiastisk med hensyn til at skrive enhedstests for at dække en bred vifte af tilfælde. Ikke alle tests var dybdegående, men det var nyttigt at have en bred dækning for at forhindre regressioner. 
3. Anvendelse af feedback: På samme måde er Codex god til at reagere på feedback. Når CI fejlede, kunne vi indsætte logoutput i en forespørgsel og bede Codex om at foreslå rettelser.
4. Massivt parallel, engangsudførelse: De fleste vil ikke presse grænserne for antallet af sessioner, de faktisk kunne køre på én gang. Det er meget muligt at teste flere idéer parallelt og betragte kode som værende midlertidig.
5. Tilbyder nyt perspektiv: I designdiskussioner brugte vi Codex som et generativt værktøj til at udforske potentielle fejlpunkter og finde nye måder at løse et problem på. Mens vi designede hukommelsesoptimeringer til videospillere, gennemgik Codex for eksempel flere SDK'er for at foreslå tilgange, som vi ikke ville have haft tid til at gennemgå. Indsigterne fra Codex's forskning viste sig at være uvurderlige til at minimere hukommelsesforbruget i den endelige app.
6. Muliggør arbejde med større indflydelse: I praksis endte vi med at bruge mere tid på at gennemgå og lede kode end på at skrive det selv. Når det er sagt, er Codex også meget god til kodegennemgang og fanger ofte fejl, før de bliver fusioneret, hvilket forbedrer pålideligheden.

Da vi først anerkendte disse karakteristika, blev vores model mere ligetil. Vi lænede os op ad Codex for at udføre en stor mængde tungt arbejde inden for velkendte mønstre og velafgrænsede områder, mens vores team fokuserede på arkitektur, brugeroplevelse, systemiske ændringer og den endelige kvalitet.

Selv den bedste nyansatte, erfarne medarbejder har ikke det rette udgangspunkt for at foretage langsigtede kompromiser med det samme. For at udnytte Codex og sikre, at dets arbejde var robust og vedligeholdelsesvenligt, var det afgørende, at vi selv overvågede appens systemdesign og centrale kompromiser. Disse omfattede udformning af appens arkitektur, modularisering, dependency injection og navigation; vi implementerede også autentificering og grundlæggende netværksstrømme. 

Fra dette fundament skrev vi nogle repræsentative funktioner fra start til slut. Vi brugte de regler, vi ønskede, at hele kodebasen skulle følge, og dokumenterede projektomfattende mønstre, mens vi gik frem. Ved at pege Codex mod repræsentative funktioner, kunne det arbejde mere selvstændigt inden for vores standarder. For et projekt, som vi anslår, at Codex har skrevet 85% af, undgik et omhyggeligt planlagt fundament dyre tilbageskridt og refaktorering. Det var en af de vigtigste beslutninger, vi tog. 

Ideen var ikke at lave "noget, der virker" så hurtigt som muligt, men snarere at lave "noget, der forstår, hvordan vi ønsker, at tingene skal fungere." Der er mange "korrekte" måder at skrive kode på. Vi behøvede ikke at fortælle Codex præcis, hvad der skulle gøres; vi skulle vise Codex, hvad der er "korrekt" på vores team. Når vi først havde fastlagt vores udgangspunkt, og hvordan vi gerne ville bygge, var Codex klar til at begynde.

For at se, hvad der ville ske, prøvede vi at spørge: "Byg Sora Android-appen baseret på iOS-koden." Go,” men gik hurtigt væk fra den fremgangsmåde.. Selvom det, Codex skabte, teknisk set fungerede, var produktoplevelsen under standard. Og uden en klar forståelse af endepunkter, data og brugerflows var Codexs single-shot-kode upålidelig (selv uden at bruge en agent er det risikabelt at fusionere tusindvis af kodelinjer). 

Vi antog, at Codex ville trives i en sandkasse med velskrevne eksempler; og vi havde ret. At bede Codex om at "bygge denne indstillingsskærm" med næsten ingen kontekst var upålideligt. At bede Codex om at "bygge denne indstillingsskærm ved hjælp af den samme arkitektur og de samme mønstre som denne anden skærm, du lige har set" fungerede meget bedre. Mennesker traf de strukturelle beslutninger og fastsatte invarianterne; Codex udfyldte derefter store mængder kode inden for den struktur.

Vores næste skridt i at maksimere Codex's potentiale var at finde ud af, hvordan vi kunne aktivere Codex til at arbejde i lange perioder (for nylig, mere end 24 timer⁠), uden opsyn.

Tidligt i brugen af Codex sprang vi til forespørgsler som: "Her er funktionen." Her er nogle filer. Byg det, tak. Det virkede nogle gange, men for det meste blev der produceret kode, der teknisk set kunne kompileres, men som afveg fra vores arkitektur og mål.

Så vi ændrede arbejdsgangen. For enhver ikke-triviel ændring bad vi først Codex om at hjælpe os med at forstå, hvordan systemet og koden fungerer. For eksempel ville vi bede den om at læse et sæt relaterede filer og opsummere, hvordan den funktion fungerer; for eksempel, hvordan data flyder fra API'en gennem repository-laget, viewmodellen og ind i UI'en. Så ville vi rette eller finjustere dens forståelse. (For eksempel ville vi påpege, at en bestemt abstraktion faktisk hører hjemme i et andet lag, eller at en given klasse kun findes til offline-tilstand og ikke bør udvides).

På samme måde som du måske engagerer en ny, yderst kompetent kollega, arbejdede vi sammen med Codex for at skabe en solid implementeringsplan. Den plan lignede ofte et miniaturedesigndokument, der beskrev, hvilke filer der skulle ændres, hvilke nye tilstande der skulle introduceres, og hvordan logikken skulle forløbe. Først da bad vi Codex om at begynde at anvende planen, et skridt ad gangen. Et nyttigt tip: Ved meget lange opgaver, hvor vi rammer grænsen for vores kontekstvindue, ville vi bede Codex om at gemme sin plan i en fil, så vi kan anvende den samme retning på tværs af instanser.

Dette ekstra planlægningsloop viste sig at være tiden værd. Det gjorde det muligt for os at lade Codex køre "uden opsyn" i lange perioder, fordi vi kendte dens planer. Det gjorde kodegennemgang lettere, fordi vi kunne kontrollere implementeringen mod vores plan i stedet for at læse en diff uden kontekst. Og når noget gik galt, kunne vi først fejlsøge planen og derefter koden. 

Den dynamik føltes på samme måde som et godt designdokument giver en teknologileder tillid til et projekt. Vi genererede ikke bare kode: Vi producerede kode, der understøttede en fælles køreplan.

På projektets højdepunkt kørte vi ofte flere Codex-sessioner parallelt. En arbejdede på afspilning, en anden på søgning, en anden på fejlhåndtering, og nogle gange en anden på tests eller refaktorering. Det føltes mindre som at bruge et værktøj og mere som at lede et team.

Hver session rapporterer periodisk tilbage til os om fremskridt. Én kunne sige: "Jeg er færdig med at planlægge dette modul; her er, hvad jeg foreslår," mens en anden ville tilbyde en stor diff til en ny funktion. Hver enkelt krævede opmærksomhed, feedback og gennemgang. Det var uhyggeligt meget lig at være teknisk ledende med adskillige nye ingeniører, der alle gjorde fremskridt, og som alle havde brug for vejledning.

Resultatet var et samarbejdsforløb. Codexs rå kodningsfunktion frigjorde os fra en masse manuel indtastning. Vi havde mere tid til at tænke over arkitektur, læse pull requests grundigt og teste appen. 

Samtidig betød den ekstra hastighed, at vi altid havde noget ventende i vores anmeldelseskø. Codex blev ikke blokeret af kontekstskift, men det blev vi. Vores flaskehals i udviklingen skiftede fra at skrive kode til at træffe beslutninger, give feedback og integrere ændringer.

Det er her, Brooks' indsigter lander på en ny måde. Du kan ikke bare tilføje Codex-sessioner og forvente lineære hastighedsforøgelser, lige så lidt som du kan blive ved med at tilføje ingeniører til et projekt og forvente, at tidsplanen skrumper lineært. Hvert ekstra "par hænder", selv virtuelle hænder, øger koordinationsomkostningerne. Vi var blevet dirigenten for et orkester frem for blot hurtigere solospillere.

Vi startede vores projekt med en stor milepæl: Sora var allerede lanceret på iOS. Vi pegede ofte Codex mod iOS- og backend-kodebaserne for at hjælpe det med at forstå nøglekrav og begrænsninger. Gennem hele projektet jokede vi med, at vi havde genopfundet ideen om en platformuafhængig ramme. Glem React Native eller Flutter; fremtiden for cross-platform er kun Codex.

Under vittigheden er der to principper:

1. Logik er transportabel. Uanset om koden er skrevet i Swift eller Kotlin, er den underliggende applikationslogik – datamodeller, netværkskald, valideringsregler, forretningslogik – den samme. Codex er meget dygtig til at læse en Swift-implementering og skabe en tilsvarende i Kotlin, der bevarer betydningen.
2. Konkrete eksempler giver en stærk kontekst. En ny Codex-session, der kan se "her er præcis, hvordan dette fungerer på iOS" og "her er Android-arkitekturen", er langt mere effektiv end en, der kun arbejder ud fra naturlige sprog beskrivelser.

Ved at anvende disse principper gjorde vi iOS-, backend- og Android-repos tilgængelige i det samme miljø. Vi gav Codex forespørgsler som:

Læs disse modeller og endepunkter i iOS-koden, og foreslå derefter en plan for at implementere den tilsvarende adfærd på Android ved hjælp af vores eksisterende API-klient og modelklasser.

Et lille, men nyttigt trick var at beskrive i ~/.codex/AGENTS.md, hvor de lokale repositorier lå, og hvad de indeholdt. Det gjorde det lettere for Codex at opdage og navigere i relevant kode.

Vi udførte effektivt udvikling på tværs af platforme gennem oversættelse frem for fælles abstraktion. Fordi Codex håndterede det meste af oversættelsen, undgik vi at fordoble implementeringsomkostningerne.

Den bredere lektie er, at for Codex er kontekst alt. Codex gjorde sit bedste arbejde, når den forstod, hvordan funktionen allerede fungerede i iOS, kombineret med en forståelse af, hvordan vores Android-app var struktureret. Når Codex manglede den kontekst, var det ikke fordi det "nægtede at samarbejde"; den gættede. Jo mere vi behandlede det som en ny holdkammerat og investerede i at give det de rette inputs, desto bedre præsterede det.

Ved slutningen af vores fire ugers sprint føltes brugen af Codex ikke længere som et eksperiment og blev vores standardudviklingsloop. Vi brugte det til at forstå eksisterende kode, lave en plan for ændringer og implementere funktioner. Vi gennemgik dets output på samme måde, som vi ville gennemgå en kollegas. Det var simpelthen sådan, vi leverede software.

Det blev tydeligt, at AI-assisteret udvikling ikke mindsker behovet for grundighed; det øger det. Så dygtig som Codex er, er dens mål at komme fra A til B nu. Dette er grunden til, at AI-assisteret kodning ikke fungerer uden mennesker. Softwareingeniører kan forstå og anvende de virkelige begrænsninger i systemer, de bedste måder at designe software på, og hvordan man bygger med fremtidige udviklings- og produktplaner i tankerne. Morgendagens softwareingeniørs superkræfter vil være en dyb forståelse af systemer og evnen til at samarbejde med AI over lange tidshorisonter. 

De mest interessante dele af softwareudvikling er at bygge fængslende produkter, designe skalerbare systemer, skrive komplekse algoritmer og eksperimentere med data, mønstre og kode. Men virkeligheden inden for software engineering, både tidligere og nu, er ofte mere jordnær: centrering af knapper, tilslutning af endepunkter og skrivning af standardkode. Nu gør Codex det muligt at fokusere på de mest meningsfulde dele af softwareudvikling og avanceret tænkning, der gør, at vi elsker vores håndværk.

Når Codex er sat op i et kontekstrigt miljø, hvor det forstår dine mål, og hvordan du kan lide at bygge, kan ethvert team multiplicere sine evner. Vores lanceringsevaluering er ikke en universalløsning, og vi påstår ikke at have løst AI-assisteret udvikling. Men vi håber, at vores erfaring gør det lettere at finde de bedste måder at styrke Codex til at styrke dig. 

Da Codex blev lanceret i en forskningsmæssig forhåndsvisning for syv måneder siden, så softwareudvikling meget anderledes ud. Gennem Sora fik vi mulighed for at udforske det næste kapitel inden for ingeniørvidenskab. Efterhånden som vores modeller og ledningsnet bliver bedre, vil AI blive en stadig mere uundværlig del af bygningen. 

Hvad vil du lave med dit eget team af Codex?