Hur vi använde Codex för att lansera Sora för Android på 28 dagar

Från och med 2026-04-26 är Sora-produkten inte längre tillgänglig.

I november lanserade vi Sora Android-appen globalt, vilket ger alla med en Android-enhet möjligheten att förvandla en kort prompt till en levande video. På lanseringsdagen nådde appen förstaplatsen i Play Store. Android-användare genererade mer än en miljon videor under de första 24 timmarna.

Bakom lanseringen finns en berättelse: den första versionen av Soras Android-app utvecklades på 28 dagar tack vare samma agent som är tillgänglig för alla team och utvecklare: Codex.

Från den 8 oktober till den 5 november 2025 arbetade ett lean engineering-team tillsammans med Codex och förbrukade cirka 5 miljarder tokens för att ta Sora för Android från prototyp till global lansering. Trots sin storlek har appen en kraschfrihet på 99,9 procent och en arkitektur som vi är stolta över. Om du undrar om vi använde en hemlig modell, så använde vi en tidig version av GPT‑5.1‑Codex‑ modellen – samma version som alla utvecklare och företag kan använda idag via CLI, IDE-tillägg eller webbapp.

När Sora lanserades på iOS exploderade användningen. Folk började omedelbart producera en ström av videoklipp. På Android hade vi däremot bara en liten intern prototyp och ett växande antal förregistrerade användarere på Google Play.

Ett vanligt svar på en lansering med höga insatser och tidspress är att lägga på resurser och lägga till processer. En produktionsapp av denna omfattning och kvalitet skulle normalt sett kräva många ingenjörer som arbetar i flera månader, vilket skulle bromsas upp av samordningen. 

Den amerikanske datorarkitekten Fred Brooks varnade för att ”lägga till fler personer till ett försenat mjukvaruprojekt gör det ännu mer försenat”. Med andra ord, när man försöker leverera ett komplext projekt snabbt kan det ofta minska effektiviteten att lägga till fler ingenjörer, eftersom det ökar kommunikationskostnaderna, fragmenteringen av arbetsuppgifterna och integrationskostnaderna. Vi tog fasta på denna insikt istället för att ignorera den. Vi satte ihop ett starkt team bestående av fyra ingenjörer – alla utrustade med Codex för att drastiskt öka varje ingenjörs verkan. 

Genom att arbeta på detta sätt skickade vi en intern version av Sora för Android till våra anställda på 18 dagar och lanserade den offentligt 10 dagar senare. Vi höll en hög standard på Android-utvecklingsmetoderna, investerade i underhållsbarhet och höll appen på samma tillförlitlighetsnivå som vi skulle förvänta oss av ett mer traditionellt projekt. (Vi fortsätter också att använda Codex i stor utsträckning idag för att utveckla och lägga till nya funktioner i appen).

För att förstå hur vi arbetade med Codex är det bra att veta var det fungerar bra och var det behöver förbättras. Att behandla det som en nyanställd senioringenjör var en bra strategi. Codex förmåga innebar att vi kunde ägna mer tid åt att leda och granska kod än att skriva den själva.

Områden där Codex behöver vägledning

1. Codex är ännu inte bra på att dra slutsatser om det som den inte har fått veta (t.ex. dina föredragna arkitekturmönster, produktstrategi, verkligt användarbeteende och interna normer eller genvägar).
2. På samma sätt kunde Codex inte se appen köras: den kunde inte öppna Sora på en enhet, märka att en rullning kändes fel eller känna att flödet var förvirrande. Bara vårt team kunde hantera dessa upplevelsebaserade uppgifter.
3. Varje instans kräver onboarding. Att dela kontext med tydliga mål, begränsningar och vägledning om "hur vi gör saker" var avgörande för att Codex skulle fungera bra.
4. På samma sätt kämpade Codex med djupa arkitektoniska bedömningar: Om man lämnade det åt sitt öde kunde det införa en extra visningsmodell där vi egentligen ville utöka en befintlig eller flytta logik till UI-lagret som helt klart hörde hemma i ett arkiv. Dess instinkt är att få något att fungera, inte att prioritera långsiktig ordning.

Vi tyckte det var användbart att låta Codex skapa och underhålla ett stort antal AGENT.md-filer i hela kodbasen. Detta gjorde det enkelt att tillämpa samma riktlinjer och bästa praxis under sessionerna. För att säkerställa att Codex skrev kod enligt våra stilriktlinjer lade vi till följande i vår överordnade AGENTS.md:

Där Codex utmärker sig

1. Att läsa och förstå stora kodbaser snabbt: Codex känner till i princip alla större programmeringsspråk, vilket gör det enklare att använda samma koncept över många plattformar utan komplexa abstraktioner.
2. Testtäckning: Codex är (särskilt) entusiastisk över att skriva enhetstester för att täcka en bred variation av fall. Alla tester var inte djupgående, men bred täckning var till hjälp för att förhindra regressioner. 
3. Att tillämpa feedback: På liknande sätt är Codex bra på att reagera på feedback. När CI misslyckades kunde vi klistra in loggutdata i en prompt och be Codex föreslå lösningar.
4. Massivt parallellt, engångsutförande: De flesta kommer inte att utnyttja det maximala antalet sessioner som de faktiskt kan köra samtidigt. Det är mycket möjligt att testa flera idéer samtidigt och betrakta koden som förbrukningsvara.
5. Erbjuder nytt perspektiv: I designdiskussioner använde vi Codex som ett generativt verktyg för att utforska potentiella felpunkter och upptäcka nya sätt att lösa problem. Till exempel, medan vi designade minnesoptimeringar för videospelaren, granskade Codex flera SDK:er för att föreslå metoder som vi inte skulle ha haft tid att analysera. Insikterna från Codexs forskning visade sig vara ovärderliga för att minimera minnesanvändningen i den slutliga appen.
6. Möjliggöra arbete med högre hävstång: I praktiken slutade vi med att lägga mer tid på att granska och styra kod än att skriva den själva. Med det sagt är Codex också mycket bra på kodgranskning och fångar ofta buggar innan de sammanfogas, vilket förbättrar tillförlitligheten.

När vi väl erkände dessa egenskaper blev vår arbetsmodell mer okomplicerad. Vi förlitade oss på Codex för att utföra en stor mängd tungt arbete inom välförstådda mönster och välavgränsade områden, medan vårt Team fokuserade på arkitektur, användarupplevelse, systemiska förändringar och slutlig kvalitet.

Även den bästa nya, seniora medarbetaren har inte rätt perspektiv för att göra långsiktiga avvägningar direkt. För att dra nytta av Codex och säkerställa att dess arbete var robust och underhållbart var det avgörande att vi själva övervakade appens systemdesign och centrala avvägningar. Dessa inkluderade utformning av appens arkitektur, modularisering, beroendeinjektion och navigering. Vi implementerade även autentisering och grundläggande nätverksflöden. 

Från denna grund skrev vi några representativa funktioner från början till slut. Vi använde de regler vi ville att hela kodbasen skulle följa och dokumenterade projektomfattande mönster medan vi arbetade. Genom att peka Codex mot representativa funktioner kunde den arbeta mer självständigt inom våra standarder. För ett projekt som vi uppskattar var 85% skrivet av Codex, undveks kostsamma omvägar och omarbetningar tack vare en noggrant planerad grund. Det var ett av de viktigaste besluten vi tog. 

Tanken var inte att så snabbt som möjligt skapa ”något som fungerar”, utan snarare att skapa ”något som fungerar som vi vill att det ska fungera”. Det finns många ”korrekta” sätt att skriva kod. Vi behövde inte tala om för Codex exakt vad den skulle göra, utan vi behövde visa Codex vad som är ”rätt” i vårt team. När vi hade fastställt vår utgångspunkt och hur vi ville utvecklas, var Codex redo att sätta igång.

För att se vad som skulle hända försökte vi uppmana: ”Utveckla Sora Android-appen baserat på iOS-koden. Kör.” men avbröt snabbt den vägen. Även om det Codex skapade tekniskt sett fungerade, var produktupplevelsen undermålig. Och utan en tydlig förståelse för slutpunkter, data och användarflöden var Codex engångskod opålitlig (även utan att använda en agent är det riskabelt att slå samman tusentals rader kod). 

Vi antog att Codex skulle trivas i en sandlåda med välskrivna exempel; och vi hade rätt. Att be Codex att ”utveckla denna inställningsskärm” utan någon kontext var opålitligt. Att be Codex att ”utveckla denna inställningsskärmen med samma arkitektur och mönster som den andra skärmen du just såg” fungerade mycket bättre. Människor fattade de strukturella besluten och fastställde invarianten; Codex fyllde sedan i stora mängder kod inom den strukturen.

Vårt nästa steg för att maximera Codex potential var att lista ut hur vi kan aktivera Codex att arbeta under långa perioder (nyligen, mer än 24 timmar⁠), utan tillsyn.

När vi började använda Codex hoppade vi direkt till promptar som ”Här är funktionen. Här är några filer. Utveckla det, tack.” Det fungerade ibland, men oftast resulterade det i kod som tekniskt sett kompilerades, men som avvek från vår arkitektur och mål.

Så vi ändrade arbetsflödet. För varje icke-trivial förändring bad vi först Codex att hjälpa oss förstå hur systemet och koden fungerar. Till exempel kunde vi be den att läsa en uppsättning relaterade filer och sammanfatta hur den funktionen fungerar, till exempel hur data flödar från API:et genom lagringslagret, visningsmodellen och in i användargränssnittet. Sedan skulle vi korrigera eller förfina dess förståelse. (Vi skulle till exempel påpeka att en viss abstraktion egentligen hör hemma i ett annat lager eller att en viss klass endast finns för offline-läge och inte bör utökas.)

På samma sätt som man skulle göra när man anställer en ny, mycket kompetent medarbetare, arbetade vi tillsammans med Codex för att ta fram en gedigen implementeringsplan. Den planen såg ofta ut som ett miniatyrdesign-dokument som angav vilka filer som skulle ändras, vilka nya tillstånd som skulle införas och hur logiken skulle flöda. Först då bad vi Codex att börja genomföra planen, ett steg i taget. Ett användbart tips: för mycket långa uppgifter, där vi når gränsen för vårt kontextfönster, skulle vi be Codex att spara sitt abonnemang till en fil, vilket gör att vi kan tillämpa samma riktning över instanser.

Denna extra planeringsrunda visade sig vara väl värd tiden. Det gjorde att vi kunde låta Codex köras ”utan övervakning” under långa perioder, eftersom vi kände till dess planer. Det gjorde kodgranskningen enklare, eftersom vi kunde kontrollera implementeringen mot vårt abonnemang snarare än att läsa en diff utan kontext. Och när något gick fel kunde vi avlusa planen först och koden sedan. 

Dynamiken kändes liknande som när ett bra designdokument ger en teknisk ledare förtroende i ett projekt. Vi genererade inte bara kod: vi skapade kod som stödde en gemensam färdplan.

Vid projektets höjdpunkt körde vi ofta flera Codex-sessioner parallellt. En person arbetade med uppspelning, en annan med sökning, en annan med felhantering, och ibland en annan med tester eller omstruktureringar. Det kändes mindre som att använda ett verktyg och mer som att hantera ett team.

Varje session återrapporterade regelbundet till oss om framstegen. En kunde säga: ”Jag är klar med planeringen av den här modulen; här är mitt förslag”, medan en annan skulle föreslå en stor diff för en ny funktion. Var och en behövde uppmärksamhet, feedback och granskning. Det var kusligt likt att vara en teknisk ledare med flera nya ingenjörer, alla gjorde framsteg, alla behövde vägledning.

Resultatet blev ett samarbetsflöde. Codex råa kodningskapacitet befriade oss från mycket manuellt skrivande. Vi hade mer tid för tänk kring arkitektur, läsa pull requests noggrant och att testa appen. 

Samtidigt innebar den extra hastigheten att vi alltid hade något som väntade i vår granskningskö. Codex blockerades inte av kontextväxling, men vi blev det. Vår flaskhals i utvecklingen har förskjutits från att skriva kod till att fatta beslut, ge feedback och integrera förändringar.

Det är här Brooks insikter landar på ett nytt sätt. Du kan inte bara lägga till Codex-sessioner och förvänta dig linjära hastighetsökningar, lika lite som du kan fortsätta att lägga till ingenjörer till ett projekt och förvänta dig att tidsplanen krymper linjärt. Varje extra "par händer," även virtuella, ökar samordningsbördan. Vi hade blivit dirigenten för en orkester snarare än bara snabbare solospelare.

Vi började vårt projekt med en stor milstolpe: Sora hade redan släppts på iOS. Vi riktade ofta Codex mot iOS- och backend-kodbaserna för att hjälpa den att förstå viktiga krav och begränsningar. Under hela projektet skämtade vi om att vi hade återuppfunnit idén om ett plattformsoberoende ramverk. Glöm React Native eller Flutter; framtiden för plattformsoberoende är bara Codex.

Under skämtet finns två principer:

1. Logik är portabel. Oavsett om koden är skriven i Swift eller Kotlin är den underliggande applikationslogiken – datamodeller, nätverksanrop, valideringsregler, affärslogik – densamma. Codex är mycket bra på att läsa en Swift-implementation och skapa en motsvarighet i Kotlin som bevarar semantiken.
2. Konkreta exempel ger en stark kontext. En ny Codex-session där man kan se ”så här fungerar det på iOS” och ”så här ser Android-arkitekturen ut” är mycket effektivare än en session som endast bygger på beskrivningar i naturligt språk.

Genom att tillämpa dessa principer gjorde vi iOS-, backend- och Android-repon tillgängliga i samma miljö. Vi gav Codex promptar som:

”Läs dessa modeller och slutpunkter i iOS-koden och föreslå sedan en plan för att implementera motsvarande beteende på Android med hjälp av våra befintliga API-klient- och modellklasser.”

Ett litet men användbart knep var att i ~/.codex/AGENTS.md ange var lokala repositorier fanns och vad de innehöll. Det gjorde det enklare för Codex att upptäcka och navigera relevant kod.

Vi bedrev effektivt plattformsoberoende utveckling genom översättning istället för genom delad abstraktion. Eftersom Codex hanterade det mesta av översättningen, undvek vi att fördubbla implementeringskostnaderna.

Den bredare lärdomen är att för Codex är kontexten allt. Codex gjorde sitt bästa arbete när man förstod hur funktionen redan fungerade i iOS, i kombination med en förståelse för hur vår Android-app var uppbyggd. När Codex saknade den kontexten var det inte fråga om att ”vägra att samarbeta”, utan om att gissa. Ju mer vi behandlade det som en ny lagkamrat och investerade i att ge det rätt input, desto bättre presterade det.

I slutet av vår fyra veckor långa sprint kändes det inte längre som ett experiment att använda Codex, utan det hade blivit vår standardutvecklingscykel. Vi använde det för att förstå befintlig kod, planera ändringar och implementera funktioner. Vi granskade resultatet på samma sätt som vi skulle granska en teammedlems resultat. Det var helt enkelt så vi levererade programvaran.

Det blev tydligt att AI-assisterad utveckling inte minskar behovet av noggrannhet, utan tvärtom ökar det. Hur kapabel Codex än är, så är dess mål att ta sig från A till B, nu. Det är därför AI-assisterad kodning inte fungerar utan människor. Programvaruingenjörer kan förstå och tillämpa de verkliga begränsningarna i system, de bästa sätten att utforma programvara och hur man bygger med framtida utveckling och produktplaner i åtanke. Morgondagens mjukvaruutvecklare kommer att ha superkrafter i form av djupgående systemförståelse och förmåga att samarbeta med AI över långa tidsperioder. 

De mest intressanta delarna av mjukvaruutveckling är att skapa attraktiva produkter, utforma skalbara system, skriva komplexa algoritmer och experimentera med data, mönster och kod. Men verkligheten inom mjukvaruutveckling, både förr och nu, är ofta mer vardaglig: centrera knappar, koppla ihop ändpunkter och skriva standardkod. Nu gör Codex det möjligt att fokusera på de mest meningsfulla delarna av mjukvaruutveckling och anledningarna till att vi älskar vårt yrke.

När Codex har installerats i en kontextrik miljö där det förstår dina mål och hur du vill bygga, kan vilket team som helst mångdubbla sina möjligheter. Vår lanseringsretro är inte en universallösning, och vi påstår inte att vi har löst AI-stödd utveckling. Men vi hoppas att vår erfarenhet gör det lättare att hitta de bästa sätten att stärka Codex så att de kan stärka dig. 

När Codex lanserades i en forskningsförhandsvisning för sju månader sedan såg mjukvaruutvecklingen helt annorlunda ut. Genom Sora fick vi utforska nästa kapitel av ingenjörskonsten. I takt med att våra modeller och verktyg blir allt bättre kommer AI att bli en allt mer oumbärlig del av utvecklingen. 

Vad kommer du att skapa med ditt eget team av Codex?