Kuidas me kasutasime Codexit Sora Androidile ehitamiseks 28 päevaga

Alates 26.04.2026 ei ole Sora toode enam saadaval.

Novembris tõime turule Sora Androidi rakenduse, mis annab kõigile Androidi seadme omanikele võimaluse muuta lühike viip elavaks videoks. Käivitamise päeval jõudis rakendus Play Store'is esikohale. Androidi kasutajad koostasid esimese 24 tunni jooksul üle miljoni video.

Lansseerimise taga on lugu: Sora tootmisrakenduse Androidi esialgne versioon loodi 28 päevaga, tänu samale agendile, mis on saadaval igale meeskonna liikmele või arendajale: Codex.

8. oktoobrist kuni 5. novembrini 2025 töötas väike inseneride meeskond koos Codexiga ja tarbis ligikaudu 5 miljardit tokenit, et viia Sora Androidi jaoks prototüübist ülemaailmse käivitamiseni. Vaatamata oma mastaabile on rakendusel 99,9-protsendiline tõrkevaba määr ja arhitektuur, mille üle oleme uhked. Kui sa mõtled, kas me kasutasime salajast mudelit, siis kasutasime GPT‑5.1‑Codexi varajast versiooni. mudel – sama versioon, mida iga arendaja või Business saab täna kasutada CLI, IDE laienduse või veebirakenduse kaudu.

Kui Sora iOS-is käivitati, kasvas kasutus plahvatuslikult. Inimesed hakkasid kohe koostama videote voogu. Androidil oli seevastu ainult väike sisemine prototüüp ja Google Plays eelregistreeritud kasutajate arv suurenes.

Tavaline vastus suure riskiga ja ajasurvega käivitamisele on ressursside kuhjamine ja protsesside lisamine. Sellise ulatuse ja kvaliteediga tootmisrakendus hõlmaks tavaliselt paljusid insenere, kes töötaksid kuid, koordineerimine aeglustaks neid. 

Ameerika arvutiarhitekt Fred Brooks hoiatas kuulsalt, et „rohkemate inimeste lisamine hilinenud tarkvaraprojektile muudab selle veelgi hilisemaks“. Teisisõnu, kui püüad keerukat projekti kiiresti tarnida, võib rohkemate inseneride lisamine sageli vähendada tõhusust, suurendades suhtluse koormust, ülesannete killustatust ja integreerimiskulusid. Selle teadmise omaksvõtmise asemel, et seda ignoreerida, panime kokku tugeva nelja inseneri meeskonna – kõik varustatud Codexiga, et iga inseneri mõju oluliselt suurendada. 

Töötades sel viisil, saatsime Androidi jaoks Sora sisemise versiooni töötajatele 18 päevaga ja avalikustasime selle 10 päeva hiljem. Me säilitasime kõrged standardid Androidi inseneritavades, investeerisime hooldatavusse ja hoidsime rakendust samal usaldusväärsuse tasemel, mida ootaksime traditsioonilisemalt projektilt. (Me jätkame Codexit ka täna laialdaselt, et rakendust arendada ja uusi funktsioone lisada.)

Et mõista, kuidas me Codexiga töötasime, on kasulik teada, kus see paistab silma ja kus vajab suunamist. Seda käsitledes nagu äsja palgatud vaneminseneri, oli see hea lähenemine. Codexi võimekus tähendas, et saime veeta rohkem aega koodi suunamisele ja ülevaatamisele kui ise selle kirjutamisele.

Kus Codex vajab juhendamist

1. Codex ei ole veel suurepärane järeldamises, mida talle pole öeldud (nt sinu eelistatud arhitektuurimustrid, tootestrateegia, tegelik kasutajakäitumine ja sisemised normid või otseteed).
2. Samamoodi ei saanud Codex rakendust tegelikult käivitada: see ei saanud Sora rakendust seadmes avada, märgata, et kerimine tundus vale, või tajuda, et voog oli segane. Ainult meie meeskond suudab katta need kogemuslikud ülesanded.
3. Iga eksemplar vajab alustamist. Konteksti jagamine selgete eesmärkide, piirangute ja juhistega selle kohta, kuidas me asju teeme, oli oluline, et Codex hästi toimiks.
4. Samamoodi oli Codexil raskusi sügava arhitektuurilise otsustusvõimega: Kui see jäeti omapäi, võis see lisada täiendava vaatemudeli, kui tegelikult soovisime olemasolevat laiendada, või viia loogika kasutajaliidese kihti, mis selgelt kuulus varamusse. Selle instinkt on saada midagi tööle, mitte eelistada pikaajalist korrashoidu.

Leidsime, et on kasulik, kui Codex loob ja haldab koodibaasis rohkelt agent.md faile. See tegi lihtsaks samade juhiste ja parimate tavade rakendamise eri seanssides. Näiteks, et tagada, et Codex kirjutaks koodi vastavalt meie stiilijuhistele, lisasime järgmise oma kõrgtaseme AGENTS.md faili:

Kus Codex silma paistab

1. Suurte koodibaaside kiire lugemine ja mõistmine: Codex tunneb peaaegu kõiki suuremaid programmeerimiskeeli, mis muudab lihtsamaks samade kontseptsioonide kasutamise paljudel platvormidel ilma keeruliste abstraktsioonideta.
2. Testide katvus: Codex on (ainulaadselt) entusiastlik ühiktestide kirjutamise suhtes, et katta lai valik juhtumeid. Mitte iga test ei olnud põhjalik, kuid katvuse ulatus aitas regressioone ennetada. 
3. Tagasiside rakendamine: sarnasel moel on Codex osav tagasisidele reageerimisel. Kui CI ebaõnnestus, saime logiväljundi viipale kleepida ja paluda Codexil parandusi välja pakkuda.
4. Massiivselt paralleelne, ühekordne täitmine: enamik ei ületa seansside arvu piire, mida nad korraga käivitada suudaksid. On väga võimalik testida mitut ideed paralleelselt ja käsitleda koodi kui ajutist.
5. Uue perspektiivi pakkumine: disainiaruteludes kasutasime Codexit generatiivse tööriistana, et tutvuda võimalike tõrkepunktidega ja avastada uusi viise probleemi lahendamiseks. Näiteks kui me kujundasime videopleieri mälu optimeerimist, sirvis Codex mitmeid SDK-sid, et pakkuda välja lähenemisviise, mida me poleks jõudnud ise läbi töötada. Codexi uurimistöö tulemused osutusid hindamatuks lõpliku rakenduse mälumahu vähendamisel.
6. Kõrgema mõjuga töö võimaldamine: praktikas kulutasime rohkem aega koodi ülevaatamisele ja suunamisele kui selle ise kirjutamisele. Seda öeldes on Codex ka koodi ülevaatamisel väga hea, sageli avastades vead enne, kui need liidetakse kokku, parandades töökindlust.

Kui olime need omadused tunnistanud, muutus meie töö mudel selgemaks. Me toetusime Codexile, et teha suur osa rasket tööd hästi mõistetavate mustrite ja selgelt piiritletud ulatuste sees, samal ajal kui meie meeskond keskendus arhitektuurile, kasutajakogemusele, süsteemsetele muudatustele ja lõplikule kvaliteedile.

Isegi parimal uuel, vanemtöötajal ei ole kohe alguses õiget vaatenurka pikaajaliste kompromisside tegemiseks. Selleks, et Codexit tõhusalt ära kasutada ja tagada selle töökindlus ja hooldatavus, oli oluline, et me ise jälgiksime rakenduse süsteemide disaini ja võtmetähtsusega kompromisse. Need hõlmasid rakenduse arhitektuuri kujundamist, modulariseerimist, sõltuvuste süstimist ja navigeerimist; samuti rakendasime autentimist ja põhilisi võrgustikuvoolusid. 

Sellest alusest kirjutasime mõned esinduslikud funktsioonid algusest lõpuni. Me kasutasime reegleid, mida soovisime, et kogu koodibaas järgiks, ja dokumenteerisime projektiülesed mustrid edasi liikudes. Suunates Codexit esinduslikele omadustele, suutis see meie standardite raames iseseisvamalt töötada. Projektis, mille me hindame olevat 85% Codexi kirjutatud, aitas hoolikalt planeeritud alus vältida kulukat tagasiminekut ja refaktoreerimist. See oli üks olulisemaid otsuseid, mille me tegime. 

Idee ei olnud teha „midagi, mis lihtsalt töötab“ nii kiiresti kui võimalik, vaid luua „midagi, mis mõistab, kuidas me tahame, et asjad töötaksid“. Koodi kirjutamiseks on palju „õigeid” viise. Me ei pidanud Codexile täpselt ütlema, mida teha; pidime Codexile näitama, mis on meie tiimis „õige“. Kui olime oma lähtepunkti kindlaks määranud ja kuidas meile meeldib ehitada, oli Codex valmis alustama.

Et näha, mis juhtuks, proovisime teha viiba: „Ehita Sora Androidi rakendus iOS-koodi põhjal. Läks“. Kuid katkestasime kiiresti selle tee. Kuigi Codexi loodud toode tehniliselt töötas, oli kasutajakogemus alla arvestuse. Ilma selge arusaamiseta lõpp-punktidest, andmetest ja kasutajavoogudest oli Codexi ühevõtte kood ebausaldusväärne (isegi ilma agendi kasutamiseta on riskantne liita kokku tuhandeid koodiridu). 

Me oletame, et Codex edeneks hästi kirjutatud näidete liivakastis; ja meil oli õigus. Codexilt paluda, et see „ehitaks selle seadete ekraani“ peaaegu ilma kontekstita oli ebausaldusväärne. Paludes Codexil „ehitada see seadete ekraan, kasutades sama arhitektuuri ja mustreid nagu see teine ekraan, mida sa just nägid”, töötas palju paremini. Inimesed tegid struktuursed otsused ja määrasid invariante; seejärel täitis Codex selle struktuuri sees suure hulga koodiga.

Meie järgmine samm Codexi potentsiaali maksimeerimisel oli välja selgitada, kuidas võimaldada Codexil töötada pikka aega (hiljuti, kauem kui 24 tundi⁠), järelevalveta.

Alguses, kui hakkasime Codexit kasutama, jõudsime viipade juurde, näiteks: „Siin on funktsioon. Siin on mõned failid. Palun ehita see.“ See mõnikord töötas, kuid enamasti tootis koodi, mis küll tehniliselt kompileerus, kuid kaldus kõrvale meie arhitektuurist ja eesmärkidest.

Nii siis me muutsime töövoogu. Iga mittetriviaalse muudatuse puhul palusime esmalt Codexil aidata meil mõista, kuidas süsteem ja kood töötavad. Näiteks paluksime tal lugeda komplekti seotud faile ja kokku võtta, kuidas see funktsioon töötab; näiteks, kuidas andmed voolavad API-st läbi varamukihi, vaatemudeli ja kasutajaliidese. Seejärel me kavatseme selle arusaama parandada või täiustada. Näiteks võiksime välja tuua, et teatud abstraktsioon kuulub tegelikult teise kihti või et antud klass eksisteerib ainult võrguühenduseta režiimi jaoks ja seda ei tohiks laiendada.

Sarnaselt sellele, kuidas sa võiksid kaasata uue, väga võimeka meeskonnakaaslase, lõime koos Codexiga kindla plaani. See plaan nägi sageli välja nagu miniatuurne disainidokument, mis juhendas, millised failid peaksid muutuma, millised uued olekud tuleks kasutusele võtta ja kuidas loogika peaks kulgema. Alles siis palusime Codexil hakata plaani rakendama, üks samm korraga. Üks kasulik nõuanne: väga pikkade ülesannete puhul, kus jõuame oma kontekstiakna piirini, palume Codexil oma plaan faili salvesta, et saaksime sama suunda rakendada erinevates olukordades.

See lisaplaneerimise etapp osutus ajakulu väärt olevaks. See võimaldas meil lasta Codexil töötada pikalt „järelevalveta“, sest me teadsime selle plaane. See muutis koodi ülevaatamise lihtsamaks, sest saime kontrollida teostust oma plaani järgi, selle asemel et lugeda kontekstita erinevusi. Ja kui midagi läks valesti, saime esmalt plaani ja teiseks koodi kõrvalda vead. 

Dünaamika tundus sarnane sellele, kuidas hea disainidokument annab tehnoloogiajuhile projektis kindlustunde. Me ei genereerinud lihtsalt koodi: me tootsime koodi, mis toetas ühist tegevuskava.

Projekti tipphetkel jooksutasime sageli mitut Codexi seanssi paralleelselt. Üks töötas taasesituse kallal, teine otsingu kallal, kolmas veakäsitluse kallal ja mõnikord neljas testide või refaktorite kallal. See tundus vähem nagu tööriista kasutamine ja rohkem nagu meeskonna juhtimine.

Iga sessioon annaks meile perioodiliselt aru tehtud edusammude kohta. Üks võiks öelda: „Olen selle mooduli planeerimise lõpetanud; siin on minu ettepanek“, samas kui teine pakub suurt diffi uue funktsiooni jaoks. Igaüks vajas tähelepanu, tagasisidet ja ülevaatamist. See oli hämmastavalt sarnane sellele, kui oled tehnoloogiajuht mitme uue inseneriga, kes kõik teevad edusamme ja vajavad juhendamist.

Tulemuseks oli koostöösuund. Codexi toorkodeerimisvõime vabastas meid pikast käsitsi tippimisest. Meil oli rohkem aega arhitektuuri üle mõtlemiseks, pull requestide hoolikalt lugeda ja rakendust testida. 

Samal ajal tähendas see lisakiirus, et meie ülevaatuse järjekorras oli alati midagi ootamas. Codexit ei seganud kontekstivahetus, aga meid küll. Meie arenduse kitsaskoht on nihkunud koodi kirjutamiselt otsuste tegemisele, tagasiside andmisele ja muudatuste integreerimisele.

Siin on koht, kus Brooksi arusaamad jõuavad kohale uuel viisil. Sa ei saa lihtsalt lisada Codexi seansse ja oodata lineaarset kiirendust, samamoodi nagu sa ei saa lihtsalt lisada insenere projekti ja oodata, et ajakava lineaarset väheneks. Iga täiendav „kätepaar“, isegi virtuaalne, lisab koordineerimisele lisakoormust. Meist oli saanud orkestri dirigent, mitte lihtsalt kiiremad soolomängijad.

Alustasime oma projekti suure verstapostiga: Sora oli juba iOS-il saadaval. Me suunasime sageli Codexi iOS-i ja taustaprogrammi koodibaasidele, et see mõistaks peamisi nõudeid ja piiranguid. Projekti vältel naljatasime, et oleme ristplatvormilise raamistiku idee uuesti leiutanud. Unusta React Native või Flutter; platvormideülene tulevik on ainult Codex.

Sellel teemal on kaks põhimõtet.

1. Loogika on teisaldatav. Olenemata sellest, kas kood on kirjutatud Swiftis või Kotlinis, on aluseks olev rakendusloogika – andmemudelid, võrgukõned, valideerimisreeglid, äriloogika – samad. Codex on väga osav Swifti rakenduse lugemisel ja semantika säilitamisel samaväärse Kotlini koodi loomisel.
2. Konkreetsed näited pakuvad võimsat konteksti. Uus Codexi seanss, mis suudab näha „siin on täpselt, kuidas see iOS-is töötab” ja „siin on Androidi arhitektuur”, on palju tõhusam kui see, mis töötab ainult loomuliku keele kirjelduste põhjal.

Nende põhimõtete rakendamine võimaldas meil iOS-i, backendi ja Androidi varamud samas keskkonnas kättesaadavaks teha. Andsime Codexile viibad, nagu:

„Loe need mudelid ja lõpp-punktid iOS koodis läbi ning seejärel tee plaan, kuidas rakendada samaväärne käitumine Androidis, kasutades meie olemasolevat API-klienti ja mudeliklasse.“

Üks väike, kuid kasulik nipp oli täpsustada failis ~/.codex/AGENTS.md, kus kohalikud varamud asusid ja mida need sisaldasid. See tegi Codexil lihtsamaks asjakohase koodi avastamise ja navigeerimise.

Me tegime tõhusalt platvormideülese arendust tõlke kaudu, mitte jagatud abstraktsiooni kaudu. Kuna Codex käsitles suurema osa tõlkimisest, vältisime rakenduskulude kahekordistumist.

Laiem õppetund on see, et Codexi jaoks on kontekst kõik. Codex tegi oma parimat tööd, kui ta mõistis, kuidas funktsioon iOS-is juba töötas, koos arusaamisega, kuidas meie Androidi rakendus oli üles ehitatud. Kui Codexil puudus see kontekst, ei olnud see „keeldumine koostööst“; see pigem oletas. Mida rohkem me seda nagu uut meeskonnakaaslast kohtlesime ja õigete sisendite andmisse panustasime, seda paremini see toimis.

Neljanda nädala sprindi lõpuks lakkas Codexi kasutamine tundumast nagu eksperiment ja muutus meie vaikimisi arendustsükliks. Kasutasime seda olemasoleva koodi mõistmiseks, muudatuste plaanimiseks ja funktsioonide rakendamiseks. Me vaatasime selle väljundit üle samamoodi, nagu vaataksime üle meeskonnakaaslase oma. See oli lihtsalt nii, kuidas me tarkvara tarnisime.

Selgus, et tehisintellekti abil arendamine ei vähenda vajadust põhjalikkuse järele; see hoopis suurendab seda. Nii võimekas kui Codex ka on, on selle eesmärk jõuda punktist A punkti B, kohe. See on põhjus, miks tehisintellekti abiga kodeerimine ei toimi ilma inimesteta. Tarkvaraarendajad suudavad mõista ja rakendada süsteemide reaalseid piiranguid, parimaid viise tarkvara arhitektuuri loomiseks ning kuidas ehitada, pidades silmas tuleviku arenduse ja tootmisplaane. Homme tarkvaraarendaja supervõimed on sügav süsteemide mõistmine ja võime teha koostööd tehisintellektiga pikkade ajahorisontide jooksul. 

Tarkvaraarenduse kõige huvitavamad osad on köitvate toodete loomine, skaleeritavate süsteemide projekteerimine, keeruliste algoritmide kirjutamine ning katsetamine andmete, mustrite ja koodiga. Kuid tarkvaraarenduse mineviku ja oleviku reaalsused on sageli pigem igapäevased: nuppude tsentreerimine, lõpp-punktide ühendamine ja boilerplate-koodi kirjutamine. Nüüd võimaldab Codex keskenduda tarkvaratehnika kõige tähenduslikumatele osadele ja põhjustele, miks me oma tööd armastame.

Kui Codex on seadistatud konteksti-rikkas keskkonnas, kus see mõistab sinu eesmärke ja kuidas sulle meeldib ehitada, saab iga meeskond oma võimeid mitmekordistada. Meie käivitamise retrospektiiv ei ole universaalne lahendus ja me ei väida, et oleme lahendanud tehisintellekti abil arendamise probleemi. Kuid loodame, et meie kogemus muudab Codexi kaudu teie võimestamise lihtsamaks. 

Kui Codex seitse kuud tagasi teadusliku eelvaate raames käivitati, nägi tarkvaraarendus välja hoopis teistsugune. Sora kaudu saime tutvume arendamise järgmise peatükiga. Kuna meie mudelid ja rakendused pidevalt paranevad, muutub tehisintellekt üha asendamatumaks osaks ehitusest. 

Mida sa oma Codexi meeskonnaga looma hakkad?