Ako sme pomocou agenta Codex vydali nástroj Sora pre Android za 28 dní

Od 26. apríla 2026 už produkt Sora nebude dostupný.

V novembri sme uviedli na trh aplikáciu Sora pre Android, čím sme umožnili každému, kto má zariadenie so systémom Android, premeniť krátky príkaz na živé video. V deň spustenia sa aplikácia dostala na prvé miesto v obchode Play Store. Používatelia systému Android vygenerovali viac ako milión videí počas prvých 24 hodín.

Za týmto uvedením sa ukrýva príbeh: počiatočná verzia produkčnej aplikácie Sora pre Android vznikla za 28 dní, a to vďaka rovnakému agentovi, ktorý je k dispozícii každému tímu alebo vývojárovi: Codex.

Štíhly inžiniersky tím, ktorý pracoval spolu s agentom Codex a spotreboval približne 5 miliárd tokenov, od 8. októbra do 5. novembra 2025 priviedol aplikáciu Sora pre Android z prototypu až ku globálnemu uvedeniu. Napriek svojej veľkosti má táto aplikácia mieru bezporuchovosti 99,9 percenta a architektúru, na ktorú sme hrdí. Ak sa pýtate, či sme použili tajný model, použili sme skoršiu verziu modelu GPT‑5.1‑Codex – čiže rovnakú verziu, ktorú môže dnes použiť akýkoľvek vývojár alebo podnik prostredníctvom CLI, rozšírenia IDE alebo webovej aplikácie.

Keď bola Sora uvedená na systém iOS, jej používanie prudko vzrástlo. Ľudia okamžite začali generovať množstvo videí. V systéme Androide sme naopak mali iba malý interný prototyp a narastajúci počet vopred registrovaných používateľov v službe Google Play.

Bežnou reakciou na spustenie v dôležitej situácii a pod časovým tlakom je hromadenie zdrojov a pridávanie procesov. Produkčná aplikácia tohto rozsahu a kvality by si zvyčajne vyžadovala niekoľkomesačnú prácu množstva inžinierov, ktorú by ešte spomaľovala koordinácia. 

Slávny je výrok amerického počítačového architekta Freda Brooksa, ktorý varoval, že „pridanie ďalších ľudí k oneskorenému softvérovému projektu spôsobí jeho ďalšie oneskorenie.“ Inými slovami: keď sa snažíte rýchlo dokončiť zložitý projekt, pridanie ďalších inžinierov môže často spomaliť efektivitu tým, že zvyšuje komunikačné náklady, fragmentáciu úloh a náklady na integráciu. Namiesto ignorovania tejto informácie sme ju prijali; zostavili sme silný tím štyroch inžinierov, pričom všetci sú vybavení agentom Codex na drastické zvýšenie vplyvu každého inžiniera. 

Týmto spôsobom sme za 18 dní dodali internú zostavu aplikácie Sora pre Android zamestnancom a o 10 dní neskôr sme ju uviedli verejne. Udržiavali sme vysokú latku v oblasti inžinierskych postupov pre Android, investovali sme do udržateľnosti a zaistili sme rovnakú úroveň spoľahlivosti aplikácie, akú by sme očakávali od tradičnejšieho projektu. (Taktiež dnes ďalej používame Codex na vývoj a prinášanie nových funkcií do aplikácie).

Aby ste pochopili, ako sme pracovali s agentom Codex, je užitočné vedieť, v čom vyniká a kde ho treba usmerniť. Dobrým prístupom bolo zaobchádzať s ním ako s novoprijatým vyšším inžinierom. Vďaka schopnosti agenta Codex sme mohli stráviť viac času usmerňovaním a kontrolou kódu namiesto toho, aby sme ho sami napísali.

Kde treba agenta Codex usmerniť

1. Codex zatiaľ nie je skvelý v odvodzovaní toho, čo mu nepoviete (napr. vaše preferované architektonické vzory, produktová stratégia, skutočné správanie používateľov a interné normy alebo skratky).
2. Podobne platí, že Codex nemohol vidieť, ako aplikácia skutočne beží: Nemohol otvoriť aplikáciu Sora v zariadení, všimnúť si, že posúvanie je nesprávne, alebo cítiť, že neplynie prirodzene Tieto zážitkové úlohy dokázal absolvovať iba náš tím.
3. Každá inštancia si vyžaduje zaradenie. Zdieľanie kontextu s jasnými cieľmi, obmedzeniami a usmerneniami o „našich postupoch“ bolo nevyhnutné pre správne fungovanie agenta Codex.
4. V rovnakom duchu mal Codex problémy s hlbokým architektonickým úsudkom: Ak by bol ponechaný sám na seba, mohol by zaviesť ďalší model zobrazenia tam, kde sme naozaj chceli rozšíriť ten existujúci, alebo presunúť logiku do vrstvy používateľského rozhrania, ktorá jasne patrila do repozitára. Inštinktívne sa snaží niečo uviesť do chodu, nie uprednostňovať dlhodobú usporiadanosť.

Zistili sme, že je užitočné, keď Codex vytvára a udržiava veľké množstvo súborov AGENT.md v celej kódovej základni. To uľahčilo aplikáciu rovnakých usmernení a osvedčených postupov naprieč reláciami. Aby sme napríklad zabezpečili, že Codex napíše kód podľa našich štylistických pokynov, pridali sme do nášho súboru AGENTS.md na najvyššej úrovni toto:

V čom Codex vyniká

1. Rýchle čítanie a pochopenie rozsiahlych kódových základní: Codex pozná v podstate všetky hlavné programovacie jazyky, čo uľahčuje využívanie rovnakých konceptov na mnohých platformách bez zložitých abstrakcií.
2. Testovacie pokrytie: Codex je (unikátne) nadšený písaním jednotkových testov, ktoré pokrývajú širokú škálu prípadov. Nie každý test bol hlboký, ale široké pokrytie bolo užitočné pri predchádzaní regresiám. 
3. Aplikovanie pripomienok: Podobne je Codex zručný v reakciách na pripomienky. Keď CI zlyhal, mohli sme vložiť výstup protokolu do príkazu a požiadať Codex, aby navrhol opravy.
4. Vo veľkej miere paralelná jednorazová realizácia: Väčšina nebude posúvať hranice počtu relácií, ktoré by mohli skutočne bežať naraz. Je veľmi užitočné testovať viacero nápadov súčasne a považovať kód za jednorazový.
5. Ponúkanie novej perspektívy: V diskusiách o dizajne sme používali Codex ako generatívny nástroj na skúmanie potenciálnych bodov zlyhania a objavovanie nových spôsobov riešenia problému. Zatiaľ čo sme napríklad navrhovali optimalizácie pamäte pre prehrávač videí, Codex prehľadával viaceré súpravy SDK, aby navrhol prístupy, ktoré by sme nemali čas analyzovať. Poznatky z výskumu agenta Codex sa ukázali ako neoceniteľné pri minimalizácii pamäťovej stopy vo výslednej aplikácii.
6. Umožnenie práce s vyššou pridanou hodnotou: V praxi sme nakoniec strávili viac času kontrolou a usmerňovaním kódu než jeho písaním. Napriek tomu je Codex veľmi dobrý aj pri kontrole kódu, pričom často zachytáva chyby ešte predtým, ako sa zlúčia, čím zvyšuje spoľahlivosť.

Keď sme si uvedomili tieto charakteristiky, náš pracovný model začal byť priamočiarejší. Na agenta Codex sme sa spoliehali, aby sme zvládli veľké množstvo náročnej práce v rámci dobre pochopených vzorov a presne vymedzených oblastí, zatiaľ čo náš tím sa sústredil na architektúru, používateľskú skúsenosť, systémové zmeny a výslednú kvalitu.

Ani ten najlepší nový vyšší zamestnanec nemá okamžite správny východiskový bod na to, aby robil dlhodobé kompromisy. Aby sme mohli využiť Codex a zabezpečiť, že jeho práca bude robustná a udržateľná, bolo kľúčové, aby sme sami dohliadali na návrh systémov aplikácie a kľúčové kompromisy. Patrilo k nim formovanie architektúry aplikácie, modularizácia, vkladanie závislostí a navigácia; implementovali sme tiež autentifikáciu a základné sieťové procesy. 

Na tomto základe sme napísali niekoľko kompletných reprezentatívnych funkcií. Použili sme pravidlá, ktoré mala podľa nás dodržiavať celá kódová základňa, a pri práci sme dokumentovali vzory platné pre celý projekt. Po nasmerovaní na reprezentatívne funkcie dokázal Codex pracovať nezávislejšie v rámci našich štandardov. Pre projekt, o ktorom odhadujeme, že bol z 85 % napísaný agentom Codex, starostlivo naplánovaný základ zabránil nákladnému spätnému sledovaniu a refaktoringu. Išlo o jedno z najdôležitejších rozhodnutí, ktoré sme prijali. 

Cieľom nebolo čo najrýchlejšie vytvoriť „niečo, čo funguje“, ale skôr vytvoriť „niečo, čo pochopí, ako chceme, aby to fungovalo.“ Existuje mnoho „správnych“ spôsobov, ako písať kód. Agentovi Codex sme nemuseli presne povedať, čo má robiť; potrebovali sme mu ukázať, čo je „správne“ v našom tíme. Keď sme si stanovili východiskový bod a spôsob, akým radi vytvárame, Codex bol pripravený začať.

Aby sme zistili, čo by sa stalo, skúsili sme navrhnúť: „Vytvor aplikáciu Sora pre Android na základe kódu pre iOS. Do toho", ale rýchlo sme sa od toho odklonili. Hoci to, čo Codex vytvoril, technicky fungovalo, používateľský zážitok z produktu bol podpriemerný. A bez jasného pochopenia koncových bodov, údajov a procesov používateľov bol jednorazový kód agenta Codex nespoľahlivý (aj bez použitia agenta je riskantné zlúčiť tisíce riadkov kódu.) 

Predpokladali sme, že Codex bude prosperovať v prostredí Sandbox s dobre napísanými príkladmi; a mali sme pravdu. Požiadať Codex, aby „vytvoril túto obrazovku nastavení“ takmer úplne bez kontextu, bolo nespoľahlivé. Požiadať Codex, aby „vytvoril túto obrazovku nastavení pomocou rovnakej architektúry a vzorov ako túto inú obrazovku, ktorú ste práve videli“, fungovalo oveľa lepšie. Ľudia prijali štrukturálne rozhodnutia a nastavili invarianty; Codex potom vyplnil veľké množstvo kódu v rámci tejto štruktúry.

Naším ďalším krokom pri maximalizácii potenciálu agenta Codex bolo zistiť, ako povoliť agentovi Codex, aby pracoval dlho (nedávno viac ako 24 hodín⁠) bez dozoru.

Na začiatku práce s agentom Codexu sme prešli k príkazom ako: „Tu je funkcia. Tu sú niektoré súbory. Prosím, vytvor to. To niekedy fungovalo, ale väčšinou vznikol kód, ktorý síce technicky fungoval, ale odkláňal sa od našej architektúry a cieľov.

Takže sme zmenili pracovný postup. Pri akejkoľvek netriviálnej zmene sme najprv požiadali Codex, aby nám pomohol pochopiť, ako systém a kód fungujú. Napríklad sme ho požiadali, aby prečítal súpravu súvisiacich súborov a zhrnul, ako táto funkcia funguje; napríklad ako údaje prechádzajú z rozhrania API cez vrstvu repozitára, model zobrazenia a do používateľského rozhrania. Potom sme opravili alebo zdokonalili jeho porozumenie. (Napríklad sme poukázali na to, že určitá abstrakcia skutočne patrí do inej vrstvy alebo že daná trieda existuje iba pre offline režim a nemala by sa rozširovať.)

Podobne ako by ste možno zapojili nového, mimoriadne schopného kolegu, sme spolupracovali s agentom Codex na vytvorení solídneho plánu implementácie. Táto tarifa často vyzerala ako miniatúrny dizajnový dokument, ktorý usmerňuje to, aké súbory by sa mali zmeniť, aké nové stavy by sa mali zaviesť a ako by mala logika plynúť. Až potom sme požiadali agenta Codex, aby začal tento plán krok za krokom uplatňovať. Jeden užitočný tip: pri veľmi dlhých úlohách, kde dosiahneme limit nášho kontextového okna, by sme požiadali agenta Codex, aby uložil svoj plán do súboru, čo nám umožní udržiavať rovnaký smer vo všetkých inštanciách.

Ukázalo sa, že tento dodatočný plánovací cyklus stál za ten čas. Umožnilo nám to nechať agenta Codex bežať dlho „bez dozoru“, pretože sme poznali jeho plány. Uľahčilo to kontrolu kódu, pretože sme mohli skontrolovať implementáciu podľa nášho plánu namiesto toho, aby ste čítali rozdiely bez kontextu. A keď sa niečo pokazilo, mohli sme najprv doladiť plán a potom kód. 

Dynamika bola podobná tomu, ako keď dobrý dizajnový dokument dodáva technickému vedúcemu dôveru v projekt. Nešlo len o generovanie kódu: vygenerovali sme kód, ktorý podporoval spoločný plán.

Na vrchole projektu sme často spúšťali viacero relácií agenta Codex súčasne. Jeden pracoval na prehrávaní, druhý na vyhľadávaní, tretí na spracovaní chýb a niekedy ďalší na testoch alebo refaktorovaní. Pôsobilo to menej ako používanie nástroja a viac ako riadenie tímu.

Každá relácia nám pravidelne vracala hlásenie o pokroku. Niekto by mohol povedať: „Končím s plánovaním tohto modulu; tu je môj návrh,“ zatiaľ čo niekto iný by ponúkol veľký rozdiel pre novú funkciu. Každý vyžadoval pozornosť, pripomienky a kontrolu. Až znepokojivo sa to podobalo práci technického vedúceho s niekoľkými novými inžiniermi: všetci robia pokrok, všetci potrebujú usmernenie.

Výsledkom bol proces spolupráce. Schopnosť surového kódovania agenta Codex nás oslobodila od množstva manuálneho písania. Mali sme viac času premýšľať o architektúre, starostlivo čítať žiadosti o zlúčenie a testovať aplikáciu. 

Zároveň táto dodatočná rýchlosť znamenala, že nás vždy niečo čakalo v zozname na kontrolu. Codex nebol zablokovaný zmenou kontextu, ale my áno. Naša komplikácia vo vývoji sa presunula z písania kódu na rozhodovanie, poskytovanie pripomienok a integráciu zmien.

V tomto bode Brooksove poznatky nachádzajú nové uplatnenie. Nemôžete jednoducho pridať relácie Codex a očakávať lineárne zrýchlenie, rovnako ako nemôžete neustále pridávať inžinierov do projektu a očakávať, že sa harmonogram lineárne skráti. Každý ďalší „pár rúk“, aj keď len virtuálny, zvyšuje koordinačnú záťaž. Stali sme sa dirigentom orchestra namiesto toho, aby sme boli len rýchlejší sóloví hráči.

Náš projekt sme začali s obrovským míľnikom: Sora už bola k dispozícii pre iOS. Často sme nasmerovali Codex na kódovacie základne iOS a backendu, aby sme mu pomohli pochopiť kľúčové požiadavky a obmedzenia. Počas projektu sme žartovali, že sme znovu objavili myšlienku multiplatformového rámca. Zabudnite na React Native alebo Flutter; budúcnosťou medziplatformovej interakcie je len Codex.

Pod týmto vtipom sa skrývajú dva princípy:

1. Logika je prenosná. Či už je kód napísaný v jazyku Swift alebo Kotlin, základná logika aplikácie – dátové modely, sieťové volania, pravidlá overovania, obchodná logika – sú rovnaké. Codex dokáže veľmi dobre čítať implementáciu v jazyku Swift a vytvoriť ekvivalent v jazyku Kotlin, ktorý zachováva rovnakú sémantiku.
2. Konkrétne príklady poskytujú významný kontext. Nová relácia agenta Codex, ktorá dokáže zobraziť „takto presne to funguje v systéme iOS“ a „tu je architektúra systému Android“, je oveľa efektívnejšia ako tá, ktorá pracuje iba s opismi v prirodzenom jazyku.

Uplatnením týchto princípov sme sprístupnili repozitáre pre iOS, backend a Android v rovnakom prostredí. Dali sme agentovi Codex príkazy ako:

„Prečítaj si tieto modely a koncové body v kóde pre iOS a potom navrhni plán na implementáciu ekvivalentného správania v systéme Android pomocou nášho existujúceho rozhrania API klienta a tried modelov.“

Jedným malým, ale užitočným trikom bolo podrobne uviesť v časti ~/.codex/AGENTS.md, kde sa nachádzajú lokálne repozitáre a čo obsahujú. To uľahčilo agentovi Codex objavovať a navigovať relevantný kód.

Efektívne sme realizovali vývoj naprieč platformami prostredníctvom prekladu namiesto zdieľanej abstrakcie. Keďže Codex zvládol väčšinu prekladu, vyhli sme sa zdvojnásobeniu nákladov na implementáciu.

Širšia lekcia je, že pre agenta Codex je kontext všetkým. Codex odviedol najlepšiu prácu, keď pochopil, ako funkcia už fungovala v systéme iOS, v kombinácii s pochopením, ako bola štruktúrovaná naša aplikácia pre Android. Keď agentovi Codex chýbal tento kontext, nešlo o „odmietanie spolupráce“; išlo o hádanie. Čím viac sme s ním zaobchádzali ako s novým členom tímu a investovali do poskytovania správnych vstupov, tým lepšie fungoval.

Na konci nášho štvortýždňového šprintu prestalo používanie agenta Codex pôsobiť ako experiment a stalo sa naším predvoleným vývojovým cyklom. Použili sme ho na pochopenie existujúceho kódu, plánovanie zmien a implementáciu funkcií. Kontrolovali sme jeho výstup rovnako, ako by sme kontrolovali výstup kolegu. Bol to jednoducho spôsob, ako sme poskytovali softvér.

Ukázalo sa, že vývoj s podporou umelej inteligencie neznižuje potrebu dôkladnosti; naopak – zvyšuje ju. Hoci je Codex schopný, jeho cieľom je teraz dostať sa z bodu A do bodu B. Preto kódovanie s podporou umelej inteligencie nefunguje bez ľudí. Softvéroví inžinieri dokážu pochopiť a aplikovať reálne obmedzenia systémov, najlepšie spôsoby architektúry softvéru a to, ako vytvárať s ohľadom na budúci vývoj a produktové plány. Superschopnosťami softvérového inžiniera zajtrajška budú hlboké pochopenie systémov a schopnosť spolupracovať s umelou inteligenciou počas dlhých časových horizontov. 

Najzaujímavejšími časťami softvérového inžinierstva sú vytváranie pútavých produktov, navrhovanie škálovateľných systémov, písanie zložitých algoritmov a experimentovanie s dátami, vzormi a kódom. Realita softvérového inžinierstva v minulosti a v súčasnosti je často všednejšia: centrovanie tlačidiel, zapájanie koncových bodov a písanie šablón. Teraz Codex umožňuje sústrediť sa na najvýznamnejšie časti softvérového inžinierstva a dôvody, prečo milujeme naše remeslo.

Keď je Codex nastavený v prostredí bohatom na kontext, kde rozumie vašim cieľom a tomu, ako radi tvoríte, každý tím môže znásobiť svoje schopnosti. Naša retrospektíva tohto uvedenia nie je univerzálnym riešením a netvrdíme, že sme vyriešili vývoj s pomocou umelej inteligencie. Dúfame však, že naša skúsenosť uľahčí hľadanie najlepších spôsobov, ako pomôcť agentovi Codex v tom, aby pomohol vám. 

Keď bol Codex pred siedmimi mesiacmi spustený ako ukážka na výskum, softvérové inžinierstvo vyzeralo úplne inak. Prostredníctvom nástroja Sora sme mohli preskúmať ďalšiu kapitolu inžinierstva. Postupne s tým, ako sa naše modely a ich využitie neustále zlepšujú, umelá inteligencia bude čoraz nepostrádateľnejšou súčasťou tvorby. 

Čo vytvoríte so svojím vlastným tímom agenta Codex?