Kā mēs izmantojām Codex, lai 28 dienās izveidotu Sora Android ierīcēm

No 2026. gada 26. aprīļa Sora produkts vairs nav pieejams.

Novembrī mēs laidām klajā Sora Android lietotni, dodot ikvienam, kam ir Android ierīce, iespēju pārvērst īsu uzvedni spilgtā video. Palaišanas dienā lietotne sasniedza 1. vietu veikalā Play Store. Android lietotāji ģenerēja vairāk nekā miljonu video pirmajās 24 stundās.

Aiz šīs palaišanas ir stāsts: Sora Android lietotnes sākotnējā versija tika izveidota 28 dienās, pateicoties tam pašam aģentam, kas ir pieejams jebkurai komandai vai izstrādātājam: Codex.

No 2025. gada 8. oktobra līdz 5. novembrim neliela inženieru komanda, strādājot kopā ar Codex un patērējot aptuveni 5 miljardus tokenu, izstrādāja Sora Android ierīcēm – no prototipa līdz globālai palaišanai. Neskatoties uz tās mērogu, lietotnei ir 99,9% bezavāriju rādītājs un arhitektūra, ar kuru mēs lepojamies. Ja tu prāto, vai mēs izmantojām kādu slepenu modeli – mēs izmantojām agrīnu GPT‑5.1‑Codex modeļa versiju – to pašu versija, ko jebkurš izstrādātājs vai uzņēmums var izmantot šodien, lietojot CLI, IDE paplašinājumu vai tīmekļa lietotni.

Kad Sora tika palaista iOS platformā, lietojums pieauga ļoti strauji. Cilvēki nekavējoties sāka ģenerēt video plūsmu. Savukārt Android platformā mums bija tikai neliels iekšējais prototips un augošs iepriekšreģistrētu lietotāju skaits Google Play.

Izplatīta reakcija gadījumos, kad produkta palaišana ir saistīta ar augstām likmēm un laika trūkumu, ir resursu palielināšana un procesa papildināšana. Šāda apjoma un kvalitātes lietotnes izstrādē parasti ir iesaistīti daudzi inženieri, kas strādā mēnešiem ilgi un kuru darbu palēnina koordinācija. 

Amerikāņu datorarhitekts Freds Brūkss (Fred Brooks) savulaik brīdināja, ka "vairāk cilvēku pievienošana novēlotam programmatūras projektam padara to vēl novēlotāku". Citiem vārdiem sakot, mēģinot ātri piegādāt sarežģītu projektu, papildu inženieru pievienošana bieži var samazināt efektivitāti, palielinot komunikācijas slogu, uzdevumu sadrumstalotību un integrācijas izmaksas. Mēs izmantojām šo ieskatu, nevis ignorējām to; mēs izveidojām spēcīgu četru inženieru komandu – visi aprīkoti ar Codex –, lai ievērojami palielinātu katra inženiera ietekmi. 

Strādājot šādā veidā, mēs 18 dienu laikā nosūtījām iekšēju Sora Android versiju darbiniekiem un 10 dienas vēlāk to publiskojām. Mēs uzturējām augstu Android inženierijas līmeni, ieguldījām turpmākās uzturēšanas iespējās un nodrošinājām, lai lietotne būtu tikpat uzticama, kā tas būtu gaidāms no tradicionālāka projekta. (Mēs arī turpinām plaši izmantot Codex, lai attīstītu un ieviestu jaunas funkcijas lietotnē).

Lai saprastu, kā mēs strādājām ar Codex, ir svarīgi zināt, kur tas pozitīvi izceļas un kur tam nepieciešama cilvēka vadība. Uztvert to kā nesen darbā pieņemtu vecāko inženieri bija laba pieeja. Pateicoties Codex spējām, mēs varējām vairāk laika veltīt koda pārvaldīšanai un pārskatīšanai, nevis to rakstīt paši.

Kur Codex nepieciešama cilvēka vadība

1. Codex vēl ne visai labi spēj izsecināt to, kas tam nav skaidri pateikts (piemēram, tavi vēlamie arhitektūras modeļi, produktu stratēģija, reālo lietotāju uzvedība un iekšējās normas vai saīsnes).
2. Tāpat Codex nespēja redzēt, kā lietotne faktiski darbojas: tas nevarēja atvērt Sora ierīcē, pamanīt, ka ritināšana šķiet nepareiza, vai sajust, ka plūsma ir mulsinoša. Tikai mūsu komanda varēja veikt šos praktiskās pieredzes uzdevumus.
3. Katrs gadījums prasa pievienošanu. Lai Codex labi darbotos, bija svarīgi norādīt kontekstu ar skaidriem mērķiem, ierobežojumiem un vadlīnijām par to, "kā mēs darām lietas".
4. Tāpat arī Codex bija grūtības ar dziļu arhitektonisku spriestspēju – ļaujot tam rīkoties patstāvīgi, tas varētu ieviest papildu skata modeli tur, kur mēs patiesībā vēlējāmies paplašināt esošo, vai arī ievietot lietotāja saskarnes slānī loģiku, kas nepārprotami piederēja repozitorijam. Tā instinkts ir panākt, lai kaut kas darbotos, nevis par prioritāti noteikt ilgtermiņa tīrību.

Mēs secinājām, ka ir lietderīgi, ja Codex izveido un uztur lielu daudzumu AGENT.md failu visā koda bāzē. Tas atviegloja vienādu vadlīniju un paraugprakses piemērošanu visās sesijās. Piemēram, lai nodrošinātu, ka Codex raksta kodu saskaņā ar mūsu stila vadlīnijām, mēs pievienojām savam augstākā līmeņa AGENTS.md šādu tekstu:

Kur Codex izceļas

1. Lielu kodu bāzu ātra lasīšana un izpratne: Codex pārzina praktiski visas lielākās programmēšanas valodas, kas atvieglo to pašu koncepciju izmantošanu dažādās platformās bez sarežģītām abstrakcijām.
2. Testēšanas pārklājums: Codex ir (unikāli) aizrautīgs vienību testu rakstīšanā, lai aptvertu plašu gadījumu klāstu. Ne katrs tests bija dziļš, bet plašs pārklājums bija noderīgs, lai novērstu regresijas. 
3. Atsauksmju ieviešana: tāpat Codex labi reaģē uz atsauksmēm. Ja nepārtrauktā integrācija (CI) neizdevās, mēs varējām ielīmēt žurnāla izvades rezultātus uzvednē un prasīt Codex ierosināt labojumus.
4. Masveidīgi paralēla, vienreizēja izpilde: lielākā daļa lietotāju nemaz necentīsies sasniegt vienlaicīgi palaižamo sesiju skaita robežas. Ir ļoti iespējams paralēli testēt vairākas idejas un uzskatīt kodu par "vienreizlietojamu".
5. Jaunu perspektīvu piedāvāšana: projektēšanas diskusijās mēs izmantojām Codex kā ģenerējošu rīku, lai izpētītu iespējamos kļūmju punktus un atklātu jaunus problēmas risināšanas veidus. Piemēram, kamēr mēs projektējam video atskaņotāja atmiņas optimizācijas, Codex pārskatīja vairākus SDK, lai piedāvātu pieejas, kuras mums nebūtu bijis laika izskatīt. Codex pētījuma atziņas izrādījās nenovērtējamas, lai samazinātu atmiņas patēriņu galīgajā lietotnē.
6. Iespēja veikt darbu ar lielāku efektivitāti: praksē mēs pavadījām vairāk laika, pārskatot un pārvaldot kodu, nekā rakstot to paši. Tomēr Codex ir ļoti labs arī koda pārskatīšanā, bieži vien atklājot kļūdas, pirms tās tiek sapludinātas, tādējādi uzlabojot uzticamību.

Tiklīdz mēs apzinājāmies šīs īpašības, mūsu darba modelis kļuva vienkāršāks. Mēs paļāvāmies uz Codex, lai tas paveiktu lielu daļu smago darbu, izmantojot labi saprotamus modeļus un skaidri definētu darbības jomu, kamēr mūsu komanda koncentrējās uz arhitektūru, lietotāja pieredzi, sistēmiskām izmaiņām un galīgo kvalitāti.

Pat vislabākajam jaunpieņemtam augsta līmeņa darbiniekam nav pareizā skatupunkta, lai uzreiz izvēlētos ilgtermiņa kompromisus. Lai lietderīgi izmantotu Codex un nodrošinātu, ka tā darbs ir uzticams un ilgtermiņā uzturams, bija svarīgi, ka mēs paši pārraudzījām lietotnes sistēmu projektēšanu un galvenos kompromisus. Tas ietvēra lietotnes arhitektūras veidošanu, modularizāciju, atkarību injekciju un navigāciju; mēs arī ieviesām autentifikāciju un pamata tīkla plūsmas. 

Uz šī pamata mēs izveidojām dažas reprezentatīvas funkcijas no sākuma līdz beigām. Mēs izmantojām noteikumus, kurus vēlējāmies lietot visai koda bāzei, un darba gaitā dokumentējām projekta mēroga principus. Norādot Codex uz reprezentatīvām funkcijām, tas varēja strādāt patstāvīgāk saskaņā ar mūsu standartiem. Projektam, kurā, pēc mūsu aplēsēm, 85% bija uzrakstījis Codex, rūpīgi plānots pamats ļāva izvairīties no dārgas atpakaļiešanas un refaktorēšanas. Tas bija viens no svarīgākajiem mūsu pieņemtajiem lēmumiem. 

Doma nebija pēc iespējas ātrāk izveidot "kaut ko, kas darbojas", bet gan "kaut ko, kas saprot mūsu vēlamos darbības principus". Ir daudz “pareizu” veidu, kā rakstīt kodu. Mums nevajadzēja tieši pateikt Codex, ko darīt; mums vajadzēja parādīt Codex, kas mūsu komandā ir “pareizi”. Kad mēs bijām noteikuši savu sākumpunktu un to, kā mums patīk izstrādāt, Codex bija gatavs sākt.

Lai redzētu, kas notiktu, mēs mēģinājām uzdot: "Izveido Sora Android lietotni, balstoties uz iOS kodu. Aiziet,” taču ātri atteicāmies no šī ceļa. Lai gan Codex izveidotais produkts tehniski darbojās, lietošanas pieredze bija neapmierinoša. Un bez skaidras izpratnes par galapunktiem, datiem un lietotāju plūsmām Codex vienreizējais kods bija neuzticams (pat neizmantojot aģentu, ir riskanti sapludināt tūkstošiem koda rindu.) 

Mēs izvirzījām hipotēzi, ka Codex varētu uzplaukt labi uzrakstītu piemēru smilšu kastē, un mums bija taisnība. Pieprasījums Codex "izveidot šo iestatījumu ekrānu" bez gandrīz nekāda konteksta bija neuzticams. Prasīt Codex "izveidot šo iestatījumu ekrānu, izmantojot to pašu arhitektūru un modeļus, ko otrs ekrāns, ko tikko redzēji" darbojās daudz labāk. Cilvēki pieņēma strukturālos lēmumus un noteica invariantus, bet Codex pēc tam šīs struktūras iekšienē iestrādāja lielu daudzumu koda.

Mūsu nākamais solis, lai maksimāli izmantotu Codex potenciālu, bija saprast, kā nodrošināt ilgstošu Codex strādāšanu (jaunākais sasniegums – vairāk nekā 24 stundas⁠) bez uzraudzības.

Sākotnējā Codex lietošanas posmā mēs izmantojām tādas uzvednes kā "Šeit ir funkcija. Šeit ir daži faili. Lūdzu, uzbūvē to." Dažreiz tas izdevās, bet lielākoties tika radīts tehniski kompilējams kods, kas tomēr novirzījās no mūsu arhitektūras un mērķiem.

Tāpēc mēs mainījām darbplūsmu. Attiecībā uz visām izmaiņām, kas nav triviālas, mēs vispirms prasījām Codex palīdzēt mums saprast, kā darbojas sistēma un kods. Piemēram, mēs prasījām nolasīt saistītu failu kopumu un dot kopsavilkumu par to, kā šī funkcija darbojas – piemēram, kā dati plūst no API caur repozitorija slāni, skata modeli un lietotāja saskarnē. Tad mēs labojām vai precizējām tā izpratni. (Piemēram, mēs norādījām, ka konkrēta abstrakcija patiesībā pieder citam slānim vai ka noteikta klase pastāv tikai bezsaistes režīmam un nav jāpaplašina.)

Līdzīgi tam, kā varētu sākt sadarbību ar jaunu, ļoti spējīgu kolēģi, mēs strādājām ar Codex, lai izveidotu stabilu ieviešanas plānu. Šis plāns bieži vien atgādināja miniatūru projektēšanas dokumentu, kurā norādīts, kuri faili jāmaina, kādi jauni stāvokļi jāievieš un kā jāplūst loģikai. Tikai tad mēs prasījām Codex sākt plānu īstenot, soli pa solim. Viens noderīgs padoms: ļoti gariem uzdevumiem, kad mēs sasniedzam konteksta loga robežas, mēs prasījām Codex saglabāt savu plānu failā, tādējādi ļaujot mums piemērot vienu un to pašu virzienu dažādās instancēs.

Izrādījās, ka šīs papildu plānošanas cikls ir ieguldītā laika vērts. Tas ļāva mums atļaut Codex ilgstoši darboties "bez uzraudzības", jo mēs zinājām tā plānus. Tas atviegloja koda pārskatīšanu, jo mēs varējām pārbaudīt ieviešanu atbilstoši savam plānam, nevis lasīt atšķirības bez konteksta. Un, kad kaut kas nogāja greizi, mēs vispirms varējām atkļūdot plānu un tikai pēc tam kodu. 

Dinamika bija līdzīga tam, kā labs projektēšanas dokuments dod tehniskajam vadītājam pārliecību par projektu. Mēs ne tikai ģenerējām kodu – mēs radījām tādu kodu, kas bija daļa no kopīga plāna.

Projekta kulminācijas laikā mēs bieži vien paralēli darbinājām vairākās Codex sesijas. Viena strādāja pie atskaņošanas, otra pie meklēšanas, vēl viena pie kļūdu apstrādes, un reizēm vēl viena pie testiem vai refaktoriem. Tas mazāk atgādināja rīka lietošanu, bet vairāk komandas vadīšanu.

Katrā sesijā mums periodiski ziņoja par progresu. Viena varētu teikt: "Es pabeidzu šī moduļa plānošanu; lūk, ko es ierosinu," bet cita varētu piedāvāt lielas izmaiņas kādai jaunai funkcijai. Katrai bija nepieciešama uzmanība, atsauksmes un pārskatīšana. Tas bija ļoti līdzīgi tam, kā būt tehnoloģiskajam vadītājam ar vairākiem jauniem inženieriem, kuri visi darbos iet uz priekšu un kuriem visiem ir vajadzīgi norādījumi.

Rezultātā izveidojās sadarbības plūsma. Codex tīrās programmēšanas spējas atbrīvoja mūs no vajadzības daudz manuāli rakstīt. Mums bija vairāk laika domāt par arhitektūru, rūpīgi izlasīt izmaiņu pieprasījumus un testēt lietotni. 

Tajā pašā laikā šis papildu ātrums nozīmēja, ka mūsu pārskatīšanas rindā vienmēr kaut kas gaidīja. Codex netika bloķēts konteksta maiņas dēļ, bet mēs gan. Mūsu izstrādes šaurā vieta pārgāja no koda rakstīšanas uz lēmumu pieņemšanu, atsauksmju sniegšanu un izmaiņu integrēšanu.

Šeit Bruksa ieskati atklājas jaunā veidā. Tu nevari vienkārši pievienot Codex sesijas un gaidīt lineāru ātruma pieaugumu, tāpat kā nevari turpināt pievienot inženierus projektam un cerēt, ka grafiks lineāri saīsināsies. Katrs papildu "roku pāris", pat ja tas ir virtuāls, palielina koordinācijas slogu. Mēs bijām kļuvuši par orķestra diriģentiem, nevis vienkārši ātrākiem solo izpildītājiem.

Mēs sākām savu projektu ar milzīgu atspēriena punktu: Sora jau bija piegādāta iOS operētājsistēmā. Mēs bieži norādījām Codex uz iOS un backend datubāzēm, lai palīdzētu tam saprast galvenās prasības un ierobežojumus. Projekta laikā mēs bieži jokojām, ka esam no jauna radījuši starpplatformu ietvara ideju. Aizmirsti par React Native vai Flutter; starpplatformu izstrādes nākotne ir tikai Codex.

Zem šī joka slēpjas divi principi:

1. Loģika ir pārnesama. Neatkarīgi no tā, vai kods ir rakstīts Swift vai Kotlin, pamatā esošā lietojumprogrammas loģika – datu modeļi, tīkla izsaukumi, validācijas noteikumi, biznesa loģika – ir vienāda. Codex ir ļoti spējīgs Swift ieviešanas lasīšanā un ekvivalenta Kotlin koda izveidē, saglabājot semantiku.
2. Konkrēti piemēri sniedz spēcīgu kontekstu. Svaiga Codex sesija, kura spēj redzēt "šeit ir norādīts, precīzi kā tas darbojas iOS" un "šeit ir Android arhitektūra", ir daudz efektīvāka nekā sesija, kas darbojas tikai no dabiskās valodas aprakstiem.

Ieviešot šos principus praksē, mēs padarījām iOS, backend un Android repozitorijus pieejamus vienā vidē. Mēs devām Codex uzvednes, piemēram:

“Izlasi šos modeļus un mērķparametrus iOS kodā un tad piedāvā plānu, kā ieviest līdzvērtīgu uzvedību Android, izmantojot mūsu esošo API klientu un modeļu klases.”

Viens neliels, bet noderīgs triks bija ~/.codex/AGENTS.md detalizēti aprakstīt, kur atrodas vietējie repozitoriji un ko tie satur. Tas ļāva Codex vieglāk atklāt un pārlūkot atbilstošo kodu.

Mēs faktiski veicām starpplatformu izstrādi, izmantojot tulkošanu, nevis kopīgu abstrakciju. Tā kā lielāko daļu tulkošanas veica Codex, mēs izvairījāmies no dubultām ieviešanas izmaksām.

Plašākā mācība ir tāda, ka Codex gadījumā konteksts ir galvenais. Codex veica darbu vislabāk tad, kad saprata, kā šī funkcija jau darbojas iOS operētājsistēmā, un saprata, kā ir strukturēta mūsu Android lietotne. Kad Codex trūka šī konteksta, tas "neatteicās sadarboties", taču tikai minēja. Jo vairāk mēs izturējāmies pret to kā pret jaunu kolēģi un ieguldījām laiku, lai nodrošinātu tam pareizos ievades datus, jo labāk tas darbojās.

Mūsu četru nedēļu sprinta beigās Codex vairs nelikās kā eksperiments un bija kļuvis par mūsu standarta izstrādes ciklu. Mēs to izmantojām, lai izprastu esošo kodu, plānotu izmaiņas un ieviestu funkcijas. Mēs pārskatījām tā izvadi tāpat kā pārskatām kolēģu darbu. Tas vienkārši bija veids, kā mēs piegādājām programmatūru.

Kļuva skaidrs, ka mākslīgā intelekta atbalstīta izstrāde nesamazina vajadzību pēc stingrības, bet gan to palielina. Lai cik spējīgs būtu Codex, tā mērķis ir ātri nokļūt no A līdz B. Tāpēc MI atbalstīta programmēšana nedarbojas bez cilvēkiem. Programmatūras inženieri var izprast un piemērot reālās pasaules sistēmu ierobežojumus, labākos veidus, kā veidot programmatūru, un kā veikt izstrādi, ņemot vērā nākotnes attīstības un produktu plānus. Rītdienas programmatūras inženiera superspējas būs dziļa sistēmu izpratne un spēja sadarboties ar mākslīgo intelektu ilgtermiņā. 

Visinteresantākās programmatūras inženierijas daļas ir saistošu produktu veidošana, mērogojamu sistēmu projektēšana, sarežģītu algoritmu rakstīšana un eksperimentēšana ar datiem, modeļiem un kodu. Tomēr pagātnes un tagadnes programmatūras inženierijas reālijas bieži vien ir vairāk ikdienišķas: pogu centrēšana, mērķparametru savienošana un šablona koda rakstīšana. Tagad Codex ļauj vairāk koncentrēties uz nozīmīgākajām programmatūras izstrādes jomām un iemesliem, kāpēc mēs mīlam savu darbu.

Kad Codex ir iestatīts ar kontekstu bagātā vidē, kurā tas saprot tavus mērķus un to, kā tev patīk veikt izstrādi, jebkura komanda var daudzkāršot savas iespējas. Mūsu palaišanas retrospektīva nav universāla recepte, un mēs neapgalvojam, ka esam pilnībā atrisinājuši MI atbalstītas izstrādes jautājumu. Taču mēs ceram, ka mūsu pieredze palīdzēs atrast labākos veidus, kā likt Codex palīdzēt jums. 

Kad pirms septiņiem mēnešiem Codex tika laists klajā kā pētnieciskais priekšskatījums, programmatūras inženierija izskatījās pavisam citādi. Ar Sora mums bija iespēja iepazīt nākamo inženierijas etapu. Tā kā mūsu modeļi un aprīkojums arvien pilnveidojas, mākslīgais intelekts kļūs par aizvien būtiskāku izstrādes sastāvdaļu. 

Ko tu izveidosi ar savu Codex komandu?