Kaip mes panaudojome „Codex“, kad sukurtume „Sora“ „Android“ platformai per 28 dienas

Nuo 2026 m. balandžio 26 d. „Sora“ produktas nebeteikiamas.

Lapkritį pasauliui pristatėme „Android“ programėlę „Sora“, suteikdami visiems, turintiems „Android“ įrenginį, galimybę trumpą raginimą paversti ryškiu vaizdo įrašu. Paleidimo dieną programėlė pasiekė pirmąją vietą „Play“ parduotuvėje. „Android“ naudotojai sugeneravo daugiau nei milijoną vaizdo įrašų per pirmąsias 24 valandas.

Už paleidimo slypi istorija: pradinė „Sora“ gamybinės „Android“ programėlės versija buvo sukurta per 28 dienas, naudojant tą patį agentą, kuris prieinamas bet kuriai komandai ar kūrėjui: „Codex“.

Nuo 2025 m. spalio 8 d. iki lapkričio 5 d. kartu su „Codex“ dirbanti ir maždaug 5 milijardus žetonų panaudojusi inžinierių komanda įgyvendino „Sora for Android“ prototipo kūrimo procesą iki pasaulinio paleidimo. Nepaisant savo masto, progr. turi 99,9 procento stabilumo rodiklį ir architektūrą, kuria didžiuojamės. Jeigu svarstote, ar mes naudojome slaptą modelį, mes naudojome ankstyvąją „GPT‑5.1‑Codex“ versiją. modelis – ta pati versija, kurią šiandien gali naudoti bet kuris kūrėjas ar įmonė per CLI, IDE plėtinį arba žiniatinklio programą.

Kai „Sora“ buvo paleista „iOS“, naudojimas smarkiai išaugo. Žmonės iš karto pradėjo kurti vaizdo įrašų srautą. Priešingai, „Android“ turėjome tik nedidelį vidinį prototipą ir didėjantį iš anksto užsiregistravusių naudotojų skaičių „Google Play“.

Įprastas atsakas į didelių statymų ir laiko stokos reikalaujantį paleidimą yra išteklių kaupimas ir procesų keitimas. Tokios apimties ir kokybės gamybinė programa paprastai apimtų daug inžinierių, dirbančių mėnesius, o jų darbą sulėtintų koordinavimas. 

Amerikiečių kompiuterių architektas Fredas Brooksas garsiai įspėjo, kad „pridėjus daugiau žmonių prie vėluojančio programinės įrangos projekto, jis vėluos dar labiau.“ Kitaip tariant, bandant greitai įgyvendinti sudėtingą projektą, didesnio inžinierių skaičiaus įdarbinimas dažnai gali sulėtinti efektyvumą, nes padidėja komunikacijos išlaidos, užduočių suskaidymas ir integracijos išlaidos. Mes rėmėmės šia įžvalga, užuot ją ignoravę; subūrėme stiprią keturių inžinierių komandą – visi jie buvo aprūpinti „Codex“, kad ženkliai padidintų kiekvieno inžinieriaus įtaką. 

Tokiu būdu per 18 dienų darbuotojams išsiuntėme vidinės konstrukcijos „Sora for Android“ versiją, o po 10 dienų ją paleidome viešai. Mes išlaikėme aukštus „Android“ inžinerijos praktikos reikalavimus, investavome į programos priežiūrą ir laikėmės tokios pačios patikimumo ribos, kokios tikėtumėmės iš tradiciškesnio projekto. (Mes taip pat ir šiandien plačiai naudojame „Codex“, kad galėtume tobulėti ir pridėti naujų funkcijų programėlėje).

Norint suprasti, kaip mes dirbome su „Codex“, svarbu žinoti, kur jis puikiai veikia ir kur jam reikia nurodymų. Elgtis su juo kaip su ką tik įdarbintu vyresniuoju inžinieriumi buvo geras požiūris. „Codex“ gebėjimas reiškė, kad galėjome daugiau laiko skirti kodo nukreipimui ir peržiūrai, o ne rašyti jį patys.

Kur „Codex“ reikia vadovavimo

1. „Codex“ dar neturi tvirtų įgūdžių daryti išvadas apie tai, kas jai nebuvo pasakyta (pvz., jūsų pageidaujamus architektūros modelius, produkto strategiją, realų vartotojo elgesį ir vidines normas ar nuorodas).
2. Panašiai ir „Codex“ negalėjo matyti, kaip progr. iš tikrųjų veikia: ji negalėjo atidaryti „Sora“ įrenginyje, pastebėti, kad slinkimas buvo netinkamas, ar pajusti, kad srautas buvo painus. Tik mūsų komanda galėjo atlikti šias praktines užduotis.
3. Kiekvienam atvejui reikalingas priėmimas. Dalijimasis kontekstu su aiškiais tikslais, apribojimais ir gairėmis apie tai, „kaip mes darome dalykus“, buvo esminis veiksnys, kad „Codex“ veiktų gerai.
4. Panašiai, „Codex“ susidūrė su giliu architektūriniu sprendimu: paliktas vienas, jis galėjo įvesti papildomą vaizdo modelį, kur mes iš tikrųjų norėjome išplėsti esamą arba perkelti logiką į UI sluoksnį, kuris aiškiai priklausė saugyklai. Jo instinktas yra siekti, kad kažkas veiktų, o ne teikti prioritetą ilgalaikei tvarkai.

Mes nustatėme, kad naudinga, jei „Codex“ sukurtų ir palaikytų didelį kiekį AGENT.md failų visoje kodų bazėje. Tai leido lengvai taikyti tas pačias gaires ir geriausias praktikas visiems seansams. Pavyzdžiui, norėdami užtikrinti, kad „Codex“ rašytų kodą pagal mūsų stiliaus gaires, į aukščiausio lygio AGENTS.md įtraukėme šiuos punktus:

Kuo „Codex“ išsiskiria

1. Greitas didelių kodų bazių skaitymas ir supratimas: „Codex“ moka iš esmės visas pagrindines programavimo kalbas, todėl lengviau naudoti tas pačias koncepcijas daugelyje platformų be sudėtingų abstrakcijų.
2. Testavimo aprėptis: „Codex“ yra (unikaliai) entuziastingas rašyti vienetinius testus, kad apimtų platų atvejų spektrą. Ne kiekvienas testas buvo gilus, tačiau plati aprėptis padėjo išvengti regresijų. 
3. Atsiliepimų taikymas: panašiai „Codex“ gerai reaguoja į atsiliepimus. Kai CI nepavyko, galėjome įklijuoti žurnalo išvestį į raginimą ir paprašyti „Codex“ pasiūlyti pataisymus.
4. Masiškai lygiagretus, vienkartinis vykdymas: dauguma neperžengs vienu metu galimų vykdyti sesijų skaičiaus ribų. Labai tikėtina, kad galima išbandyti kelias idėjas lygiagrečiai ir laikyti kodą kaip vienkartinį.
5. Siūlome naują perspektyvą: dizaino diskusijose mes naudojome „Codex“ kaip generatyvinį įrankį, kad tyrinėtume galimus gedimo taškus ir atrastume naujus problemos sprendimo būdus. Pavyzdžiui, kai kūrėme vaizdo leistuvo atminties optimizacijas, „Codex“ peržiūrėjo kelis SDK, kad pasiūlytų metodus, kurių neturėtume laiko išanalizuoti. „Codex“ tyrimų įžvalgos pasirodė neįkainojamos mažinant atminties naudojimą galutinėje progr.
6. Didesnio sverto darbo įgalinimas: praktiškai daugiau laiko skyrėme kodo peržiūrai ir valdymui, nei jį rašydami patys. Vis dėlto, „Codex“ taip pat labai gerai atlieka kodo peržiūrą, dažnai aptikdamas klaidas dar prieš jas suliejant, taip pagerindamas patikimumą.

Kai pripažinome šias savybes, mūsų darbo modelis tapo paprastesnis. Mes pasikliovėme „Codex“, kad ši atliktų didžiulį darbą gerai suprantamų šablonų ir aiškiai apribotų taikymo sričių kontekste, o mūsų komanda sutelkė dėmesį į architektūrą, naudotojo patirtį, sisteminius pokyčius ir galutinę kokybę.

Net ir geriausias naujas vyresnysis darbuotojas iš pradžių neturi tinkamo požiūrio ilgalaikiams kompromisams priimti. Norint pasinaudoti „Codex“ ir užtikrinti, kad jo darbas būtų patikimas ir lengvai prižiūrimas, buvo svarbu, kad patys prižiūrėtume progr. sistemų dizainą ir pagrindinius kompromisus. Tai apėmė progr. architektūros formavimą, moduliavimą, priklausomybių injekciją ir navigaciją; taip pat įgyvendinome autentifikavimą ir pagrindinius tinklo srautus. 

Remdamiesi šiuo pagrindu, parašėme keletą reprezentatyvių funkcijų nuo pradžios iki pabaigos. Naudojome taisykles, kurių norėjome, kad laikytųsi visa kodų bazė, ir dokumentavome projekto masto šablonus, kai dirbome. Nukreipus „Codex“ į reprezentatyvias ypatybes, jis galėjo dirbti savarankiškiau pagal mūsų standartus. Projekte, kurį, mūsų skaičiavimais, 85 % parašė „Codex“, kruopščiai suplanuotas pagrindas padėjo išvengti brangaus atgalinio taikymo ir pertvarkymo. Tai buvo vienas iš svarbiausių sprendimų, kuriuos mes priėmėme. 

Idėja buvo ne kuo greičiau sukurti „kažką, kas veikia“, o sukurti „kažką, kas supranta, kaip norime, kad viskas veiktų.“ Yra daug „teisingų“ būdų rašyti kodą. Mums nereikėjo tiksliai sakyti „Codex“, ką daryti; turėjome parodyti „Codex“, kas mūsų komandoje yra „teisinga“. Kai tik nustatėme savo pradžios tašką ir kaip mums patinka kurti, „Codex“ buvo pasirengęs pradėti.

Norėdami pamatyti, kas nutiks, pabandėme užduoti klausimą: „Sukurkite „Sora“ „Android“ programėlę pagal „iOS“ kodą.“ „Go“, bet greitai atsisakė to kelio. Nors tai, ką „Codex“ sukūrė, techniškai veikė, produkto naudojimo patirtis buvo prastesė. Be aiškaus galinių taškų, duomenų ir vartotojų srautų supratimo, „Codex“ vienkartinis kodas buvo nepatikimas (net ir nenaudojant agento, rizikinga sujungti tūkstančius kodo eilučių). 

Mes iškėlėme hipotezę, kad „Codex“ klestės gerai parašytų pavyzdžių kruopščiai parinktoje aplinkoje, sudarytoje iš gerų pavyzdžių; ir buvome teisūs. Prašyti „Codex“ „sukurti šį nustatymų ekraną“ beveik be jokio konteksto buvo nepatikima. Prašymas „Codex“ „sukurti šį nustatymų ekraną naudojant tą pačią architektūrą ir modelius kaip ir šis kitas ekranas, kurį ką tik matėte“ veikė daug geriau. Žmonės priėmė struktūrinius sprendimus ir nustatė invariantus; tada „Codex“ užpildė didelius kiekius kodo toje struktūroje.

Toliau mūsų žingsnis, siekiant maksimaliai išnaudoti „Codex“ potencialą, buvo išsiaiškinti, kaip įjungti „Codex“ dirbti ilgą laiką (neseniai, daugiau nei 24 valandas⁠), be priežiūros.

Ankstyvame „Codex“ naudojimo etape mes perėjome prie raginimų, tokių kaip: „Štai funkcija. Štai keletas failų. Prašome sukurti.“ Kartais tai pavykdavo, bet dažniausiai kodas techniškai kompiliuodavosi, nors ir nukrypdavo nuo mūsų architektūros bei tikslų.

Taigi, pakeitėme darbo eigą. Dėl bet kokio ne trivialaus pakeitimo pirmiausia paprašėme „Codex“ padėti mums suprasti, kaip veikia sistema ir kodas. Pavyzdžiui, mes paprašytume jo perskaityti susijusių failų rinkinį ir apibendrinti, kaip veikia ta funkcija; pavyzdžiui, kaip duomenys teka iš API per saugyklos sluoksnį, vaizdo modelį ir į vartotojo sąsają. Tada mes patikslintume arba patobulintume jo supratimą. (Pavyzdžiui, atkreiptume dėmesį, kad konkreti abstrakcija iš tikrųjų priklauso kitam sluoksniui arba kad tam tikra klasė egzistuoja tik neprisijungus veikiančiam režimui ir neturėtų būti išplėsta.)

Panašiai kaip įtraukiant naują, labai pajėgų komandos narį, mes dirbome su „Codex“, kad sukurtume tvirtą įgyvendinimo planą. Tas planas dažnai atrodė kaip miniatiūrinis dizaino dokumentas, nurodantis, kurie failai turėtų būti pakeisti, kokios naujos būsenos turėtų būti įvestos ir kaip turėtų vykti logika. Tik tada paprašėme „Codex“ pradėti taikyti planą, po vieną žingsnį vienu metu. Vienas naudingas patarimas: labai ilgoms užduotims, kai pasiekiame savo konteksto lango ribą, paprašytume „Codex“ įrašyti savo planą į failą, kad galėtume taikyti tą pačią kryptį skirtingose situacijose.

Šis papildomas planavimo ciklas pasirodė esąs vertas laiko. Tai leido mums leisti „Codex“ veikti „be priežiūros“ ilgą laiką, nes žinojome jo planus. Tai palengvino kodo peržiūrą, nes galėjome patikrinti įgyvendinimą pagal mūsų planą, o ne skaityti skirtumą be konteksto. Ir kai kažkas nepavykdavo, pirmiausia galėjome taisyti riktus plane, o tik tada – kodo. 

Dinamiškumas buvo panašus į tai, kaip geras dizaino dokumentas suteikia technikos vadovui pasitikėjimo projektu. Mes ne tik generavome kodą: mes kūrėme kodą, kuris palaikė bendrą veiksmų planą.

Projekto piko metu dažnai vykdėme kelis „Codex“ seansus lygiagrečiai. Vienas dirbo su atkūrimu, kitas su paieška, dar kitas su klaidų tvarkymu, o kartais dar kitas su testavimu ar pertvarkymais. Tai labiau priminė komandos valdymą, o mažiau įrankio naudojimą.

Kiekvienas seansas periodiškai pranešdavo mums atgal apie pažangą. Vienas gali pasakyti: „Baigiau planuoti šį modulį; štai ką siūlau“, o kitas pasiūlytų didelį skirtumą naujai funkcijai. Kiekvienam reikėjo dėmesio, atsiliepimų ir peržiūros. Tai buvo nepaprastai panašu į tai, kai esate technikos vadovas su keliais naujais inžinieriais, visi daro pažangą, visiems reikia vadovavimo.

Rezultatas buvo bendradarbiavimo procesas. „Codex“ pradinės programavimo galimybės išlaisvino mus nuo daugybės rankinio rašymo. Turėjome daugiau laiko apgalvoti architektūrą, atidžiai perskaityti užklausas ir išbandyti programėlę. 

Tuo pačiu metu tas papildomas greitis reiškė, kad visada turėjome kažką laukiančio mūsų peržiūros eilėje. „Codex“ nesutriko dėl konteksto perjungimo, bet mes sutrikome. Mūsų vystymo proceso kliūtis pasikeitė nuo kodo rašymo prie sprendimų priėmimo, atsiliepimų teikimo ir pokyčių integravimo.

Čia Brooks'o įžvalgos atsiskleidžia naujai. Negalite tiesiog pridėti „Codex“ sesijų ir tikėtis linijinio spartėjimo, lygiai taip pat, kaip negalite pridėti inžinierių prie projekto ir tikėtis, kad grafikas tiesiškai trumpės. Kiekviena papildoma „rankų pora“, net ir virtuali, padidina koordinavimo išlaidas. Mes tapome orkestro dirigentu, o ne tik greitesniais solo atlikėjais.

Savo projektą pradėjome nuo didžiulio žingsnio: „Sora“ jau buvo išleista „iOS“ sistemoje. Mes dažnai atkreipdavome „Codex“ dėmesį į „iOS“ ir vidines kodų bazes, kad padėtume suprasti pagrindinius reikalavimus ir apribojimus. Viso projekto metu juokavome, kad iš naujo išradome tarpplatforminio karkaso idėją. Pamirškite „React Native“ ar „Flutter“; kryžminių platformų ateitis yra tiesiog „Codex“.

Po šiuo pokštu slypi du principai:

1. Logika yra perkeliama. Nesvarbu, ar kodas parašytas „Swift“ ar „Kotlin“, pagrindinė programos logika – duomenų modeliai, tinklo skambučiai, tikrinimo taisyklės, Business logika – yra tokia pati. „Codex“ labai gerai skaito „Swift“ diegimą ir sukuria atitikmenį Kotlin kalba, išsaugodamas semantiką.
2. Konkretūs pavyzdžiai suteikia galingą kontekstą. Nauja „Codex“ sesija, kuri gali matyti „štai kaip tai veikia „iOS“ sistemoje“ ir „štai „Android“ architektūra“, yra daug efektyvesnė nei ta, kuri veikia tik pagal natūralios kalbos aprašymus.

Taikydami šiuos principus, „iOS“, vidines ir „Android“ saugyklas padarėme prieinamas toje pačioje aplinkoje. Mes pateikėme „Codex“ tokius raginimus kaip:

„Perskaitykite šiuos modelius ir galutinius taškus iOS kode, tada pasiūlykite planą, kaip įgyvendinti lygiavertį elgesį „Android“ platformoje, naudojant mūsų esamą API klientą ir modelio klases.“

Vienas mažas, bet naudingas triukas buvo detalizuoti ~/.codex/AGENTS.md, kur yra vietinės saugyklos ir ką jos turi. Tai palengvino „Codex“ lengviau atrasti ir naršyti atitinkamą kodą.

Mes iš esmės vykdėme kelių platformų kūrimą naudodami vertimą, o ne bendrą abstrakciją. Kadangi „Codex“ atliko didžiąją dalį vertimo, išvengėme dvigubų įgyvendinimo išlaidų.

Svarbiausia pamoka yra ta, kad „Codex“ kontekstas yra viskas. „Codex“ geriausiai veikė, kai suprato, kaip funkcija jau veikė „iOS“, kartu su supratimu, kaip buvo struktūrizuota mūsų „Android“ progr. Kai „Codex“ trūko to konteksto, jis ne „atsisakė bendradarbiauti“; jis spėliojo. Kuo labiau mes jį traktavome kaip naują komandos narį ir investavome į tinkamų įvesties duomenų suteikimą, tuo geriau jis veikė.

Iki mūsų keturių savaičių sprinto pabaigos „Codex“ naudojimas nustojo būti eksperimentu ir tapo mūsų numatytąja reikšme kūrimo cikle. Mes jį naudojome suprasti esamą kodą, parengti pakeitimų planą ir įgyvendinti funkcijas. Mes peržiūrėjome jo išvestį taip pat, kaip peržiūrėtume komandos nario. Tai buvo tiesiog kaip mes pristatydavome programinę įrangą.

Paaiškėjo, kad DI padedama plėtra nesumažina griežtumo poreikio; ji jį padidina. Nors „Codex“ yra pajėgus, jo tikslas dabar yra pasiekti nuo A iki B. Štai kodėl DI padedamas programavimas neveikia be žmonių. Programinės įrangos inžinieriai gali suprasti ir taikyti realaus pasaulio sistemų apribojimus, geriausius būdus, kaip architektūriškai sukurti programinę įrangą, ir kaip kurti, atsižvelgiant į būsimus kūrimo ir produkto planus. Rytojaus programinės įrangos inžinieriaus supergalios bus gilus sistemų supratimas ir gebėjimas ilgą laiką bendradarbiauti su dirbtiniu intelektu. 

Įdomiausios programinės įrangos inžinerijos dalys yra patrauklių produktų kūrimas, mastelio keičiamų sistemų projektavimas, sudėtingų algoritmų rašymas ir eksperimentavimas su duomenimis, modeliais ir kodu. Tačiau praeities ir dabarties programinės įrangos inžinerijos realijos dažnai yra labiau kasdieniškos: mygtukų centravimas, galutinių taškų sujungimas ir šabloninio kodo rašymas. Dabar „Codex“ leidžia susitelkti į pačias reikšmingiausias programinės įrangos inžinerijos dalis ir priežastis, dėl kurių mylime savo amatą.

Kai „Codex“ sistema bus sukurta kontekstualioje aplinkoje, kurioje ji supras jūsų tikslus ir kaip jums patinka kurti, bet kuri komanda galės padidinti savo galimybes. Mūsų paleidimo retrospektyva nėra vienas visiems tinkantis receptas, ir mes neteigiame, kad išsprendėme DI pagalba vykdomą kūrimą. Tačiau tikimės, kad mūsų patirtis padės lengviau rasti geriausius būdus, kaip įgalinti „Codex“, kad jis įgalintų Jus. 

Kai prieš septynis mėnesius „Codex“ buvo pristatytas kaip tyrimų peržiūros versija, programinės įrangos inžinerija atrodė labai skirtingai. Per „Sora“ mes galėjome tyrinėti toliau inžinerijos etapą. Tobulėjant mūsų modeliams ir įrangai, DI taps vis nepakeičiama statybos dalimi. 

Ką veiksite su savo „Codex“ komanda?