Jak jsme použili Codex k vytvoření nástroje Sora pro Android za 28 dní

Od 26. dubna 2026 už produkt Sora nebude k dispozici.

V listopadu jsme globálně spustili aplikaci Sora pro Android, která umožňuje komukoli se zařízením Android proměnit krátký prompt v živé video. V den spuštění se aplikace dostala na 1. místo v Play Store. Uživatelé systému Android vytvořili více než milion videí během prvních 24 hodin.

Za uvedením se skrývá příběh: počáteční verze produkční aplikace Sora pro Android byla postavena za 28 dní, díky stejnému agentovi, který je k dispozici jakémukoli týmu nebo vývojáři: Codex.

Od 8. října do 5. listopadu 2025 malý tým vývojářů, který pracoval s nástrojem Codexu a spotřeboval přibližně 5 miliard tokenů, dodal nástroj Sora pro Android od prototypu až po globálního uvedení. Navzdory své velikosti má aplikace míru provozu bez pádů 99,9 procenta a architekturu, na kterou jsme hrdí. Pokud přemýšlíš, zda jsme použili tajný model, použili jsme ranou verzi modelu GPT‑5.1‑Codex – stejnou verze, kterou může dnes jakýkoli vývojář nebo firma použít prostřednictvím rozhraní příkazového řádku, rozšíření IDE nebo webové aplikace.

Když byla aplikace Sora uvedena na systém iOS, používání prudce vzrostlo. Lidé okamžitě začali vytvářet řadu videí. Pro Android jsme naopak měli jen malý interní prototyp a rostoucí počet předregistrovaných uživatelů na Google Play.

Běžnou reakcí na uvedení s vysokými riziky a časovým tlakem je navýšit zdroje a přidat procesy. Produkční aplikace tohoto rozsahu a kvality by obvykle zahrnovala mnoho vývojářů, kteří by pracovali několik měsíců a které by zpomalovala koordinace. 

Americký počítačový architekt Fred Brooks slavně varoval, že „přidání více lidí do zpožděného softwarového projektu ho zpozdí ještě více.“ Jinými slovy, když se snažíš rychle dodat složitý projekt, přidání dalších vývojářů může často snížit efektivitu tím, že zvyšuje komunikační zátěž, fragmentaci úkolů a náklady na integraci. Místo abychom tento poznatek ignorovali, využili jsme ho: sestavili jsme silný tým čtyř vývojářů – všechny jsme vybavili nástrojem Codex, aby se drasticky zvýšil vliv každého vývojáře. 

Tímto způsobem jsme za 18 dní dodali zaměstnancům interní výstavbu Sora pro Android a o 10 dní později jsme ji veřejně spustili. Udrželi jsme vysoké standardy pro vývojářské postupy v systému Android, investovali do udržovatelnosti a udržovali aplikaci na stejné úrovni spolehlivosti, jakou bychom očekávali od tradičnějšího projektu. (Codex i nadále rozsáhle používáme při vývoji a přidávání nových funkcí do aplikace).

K pochopení, jak jsme pracovali s nástrojem Codex, je užitečné vědět, kde vyniká a kde potřebuje pomoc. Jednat s ním jako s nově přijatým seniorním vývojářem byl dobrý přístup. Schopnosti nástroje Codex nám umožnily trávit více času řízením a kontrolou kódu než jeho psaním.

Kde Codex potřebuje vedení

1. Codex zatím není dobrý při odvozování toho, co mu nebylo řečeno (např. vaše preferované architektonické vzory, produktová strategie, reálné chování uživatelů a interní normy nebo klávesové zkratky).
2. Podobně Codex nemohl vidět, jak aplikace skutečně běží: Nemohl otevřít Sora na zařízení, všimnout si, že posouvání nepůsobí dobře, nebo zaznamenat, že způsob používání je matoucí. Tyto věci týkající se používání musel udělat náš tým.
3. Každá instance vyžaduje nástup. Sdílení kontextu s jasnými cíli, omezeními a pokyny ohledně toho, „jak pracujeme“, bylo klíčové pro to, aby Codex fungoval efektivně.
4. Ve stejném duchu měl Codex potíže s hlubokým architektonickým úsudkem: Kdyby byl ponechán sám sobě, mohl by zavést další model zobrazení tam, kde jsme opravdu chtěli rozšířit stávající, nebo do vrstvy uživatelského rozhraní přesunout logiku, která jasně patřila do repozitáře. Jeho instinktem je něco uvést do provozu, ne upřednostňovat dlouhodobou čistotu.

Zjistili jsme, že je užitečné nechat Codex vytvářet a udržovat velké množství souborů AGENT.md v celé kódové základně. To usnadnilo použití stejných pokynů a osvědčených postupů napříč relacemi. Například, abychom zajistili, že Codex píše kód podle našich stylových pokynů, přidali jsme do našeho hlavního souboru AGENTS.md následující:

Kde Codex vyniká

1. Rychlé čtení a porozumění rozsáhlým kódovým základnám: Codex zná v podstatě všechny hlavní programovací jazyky, což usnadňuje využití stejných konceptů napříč mnoha platformami bez složitých abstrakcí.
2. Testování pokrytí: Codex je (jedinečně) ochotný psát jednotkové testy, které pokrývají širokou škálu případů. Ne každý test byl důkladný, ale mít široké pokrytí bylo užitečné při prevenci kroků zpět. 
3. Aplikování zpětné vazby: Podobně je Codex dobrý v reakci na zpětnou vazbu. Když CI selhalo, mohli jsme vložit výstup protokolu do promptu a požádat Codex, aby navrhl opravy.
4. Masivně paralelní, jednorázové provedení: Většina uživatelů nevyužije limity počtu relací, které by mohli ve skutečnosti spustit najednou. Je velmi snadné testovat více nápadů současně a považovat kód za jednorázový.
5. Nabídnutí nového úhlu pohledu: Při diskuzích o designu jsme použili Codex jako generativní nástroj k prozkoumání potenciálních bodů selhání a objevování nových způsobů, jak řešit problém. Například zatímco jsme navrhovali optimalizace paměti pro video přehrávače, Codex procházel několika sadami SDK, aby navrhl přístupy, které bychom neměli čas sami analyzovat. Poznatky z výzkumu nástroje Codex se ukázaly jako neocenitelné při minimalizaci velikosti využití paměti v konečné aplikaci.
6. Umožnění práce s vyšší přidanou hodnotou: V praxi jsme nakonec strávili více času kontrolou a řízením kódu než jeho psaním sami. Codex je také velmi dobrý v revizi kódu, často zachytí chyby ještě před jejich sloučením, čímž zlepšuje spolehlivost.

Jakmile jsme si tyto charakteristiky uvědomili, náš pracovní model získal na přímočarosti. Opírali jsme se o Codex při zvládání velké množství náročné práce v rámci dobře pochopených vzorů a jasně vymezených oblastí, zatímco náš tým se soustředil na architekturu, uživatelskou funkčnost, systémové změny a konečnou kvalitu.

Ani ten nejlepší nový seniorní vývojář nemá hned na začátku správný nadhled pro dělání dlouhodobých kompromisů. Abychom využili Codex a zajistili, že jeho práce bude robustní a udržitelná, bylo klíčové, abychom sami dohlíželi na návrh systémů aplikace a klíčová rozhodnutí. Ty zahrnovaly utváření architektury aplikace, modularizaci, vkládání závislostí a navigaci; také jsme implementovali ověřování a základní síťové toky. 

Na tomto základě jsme napsali několik reprezentativních funkcí od začátku do konce. Použili jsme pravidla, která jsme chtěli v celé kódové základně, a během práce jsme dokumentovali vzory platné pro celý projekt. Tím, že jsme Codex nasměrovali na reprezentativní funkce, mohl pracovat samostatněji v rámci našich norem. U projektu, o kterém odhadujeme, že byl z 85 % napsán nástrojem Codex, pečlivě naplánovaný základ zabránil nákladnému vracení se a refaktorování. Bylo to jedno z nejdůležitějších rozhodnutí, které jsme udělali. 

Myšlenka nebyla vytvořit „něco, co funguje“ co nejrychleji, ale vytvořit „něco, co chápe, jak chceme, aby věci fungovaly.“ Existuje mnoho „správných“ způsobů, jak psát kód. Nemuseli jsme nástroji Codex přesně říkat, co má dělat, potřebovali jsme mu ukázat, co je v našem týmu správné“. Jakmile jsme si stanovili výchozí bod a způsob, jakým chceme stavět, Codex byl připraven začít.

Abychom zjistili, co by se stalo, zkusili jsme zadat: „Postav aplikaci Sora pro Android na základě kódu pro iOS. Do toho,“ ale rychle tuto cestu opustil. I když to, co Codex vytvořil, technicky fungovalo, produktové prostředí bylo podprůměrné. A bez jasného pochopení koncových bodů, dat a toků uživatelů byl první pokus o kód nástroje Codex nespolehlivý (I bez použití agenta je riskantní sloučit tisíce řádků kódu.) 

Předpokládali jsme, že se nástroji Codex bude dařit v prostředí dobře napsaných příkladů, a měli jsme pravdu. Požádat Codex, aby „vytvořil tuto obrazovku nastavení“ téměř bez kontextu, nebylo spolehlivé. Požádat Codex, aby „vytvořil tuto obrazovku nastavení pomocí stejné architektury a vzorů jako tu jinou obrazovku, kterou právě viděl“, fungovalo mnohem lépe. Lidé učinili rozhodnutí o struktuře a nastavili invarianty, Codex pak doplnil velké množství kódu v rámci této struktury.

Naším dalším krokem v maximalizaci potenciálu nástroje Codex bylo zjistit, jak mu umožnit pracovat po dlouhou dobu (nedávno více než 24 hodin⁠), bez dohledu.

Na začátku používání nástroje Codex jsme rychle přešli k promptům jako: „Tady je funkce. Tady jsou nějaké soubory. Vytvoř to.“ To někdy fungovalo, ale většinou vedlo k vytvoření kódu, který se sice technicky zkompiloval, ale odchyloval se od naší architektury a cílů.

Tak jsme pracovní postup změnili. U každé nezanedbatelné změny jsme nejprve požádali Codex, aby nám pomohl pochopit, jak systém a kód fungují. Například jsme ho požádali, aby přečetl sadu souvisejících souborů a shrnul, jak tato funkce funguje, například jak data proudí z rozhraní API přes vrstvu úložiště, model zobrazení a do uživatelského rozhraní. Pak jsme opravili nebo zdokonalili jeho porozumění. (Například jsme poukázali na to, že určitá abstrakce ve skutečnosti patří do jiné vrstvy nebo že daná třída existuje pouze pro offline režim a neměla by být rozšiřována.)

Podobně s novým velmi schopným členem týmu jsme spolupracovali s nástrojem Codex, abychom vytvořili solidní implementační plán. Tento plán často vypadal jako miniaturní návrhový dokument, který určoval, které soubory se mají změnit, jaké nové stavy se mají zavést a jak má logika plynout. Teprve potom jsme požádali Codex, aby začal uplatňovat plán, krok za krokem. Jeden užitečný tip: U velmi dlouhých úkolů, kde narazíme na limit našeho kontextového okna, požádáme Codex, aby uložil svůj plán do souboru, což nám umožní aplikovat stejný směr napříč instancemi.

Ukázalo se, že tento krok plánování navíc stál za to. Umožnil nám nechat Codex po dlouhou dobu běžet „bez dozoru“, protože jsme znali jeho plány. Usnadnilo to kontrolu kódu, protože jsme mohli zkontrolovat implementaci podle našeho plánu, místo abychom četli rozdíly v kódu bez kontextu. A když se něco pokazilo, mohli jsme nejprve ladit plán a až poté kód. 

Dynamika byla podobná tomu, jak dobrý návrhový dokument dává technickému vedoucímu důvěru v projekt. Nejenže jsme vytvářeli kód: vytvářeli jsme kód, který podporoval sdílený plán.

Na vrcholu projektu jsme často spouštěli více relací Codex současně. Jeden pracoval na přehrávání, další na vyhledávání, další na zpracování chyb a někdy další na testech nebo refaktoringu. Působilo to méně jako používání nástroje a více jako řízení týmu.

Každá relace nám pravidelně podávala zprávy o pokroku. Jeden mohl říct: „Dokončil jsem plánování tohoto modulu, tady je můj návrh,“ zatímco jiný nabídl velký kus kódu pro novou funkci. Každý potřeboval pozornost, zpětnou vazbu a revizi. Bylo to až neuvěřitelně podobné tomu být technickým vedoucím s několika novými vývojáři, kteří všichni dělají pokrok a všichni potřebují vedení.

Výsledkem byl tok spolupráce. Surové schopnosti kódování Codex nás osvobodily od spousty ručního psaní. Měli jsme více času přemýšlet o architektuře, pečlivě číst pull requesty a testovat aplikaci. 

Zároveň vyšší rychlost znamenala, že jsme vždy něco čekalo ve frontě na kontrolu. Codex se nezasekával přepínáním kontextu, ale my ano. Naše úzké místo ve vývoji se přesunulo od psaní kódu k rozhodování, dávání zpětné vazby a integraci změn.

Tady je místo, kde se Brooksovy poznatky uplatní novým způsobem. Nemůžeš jednoduše přidávat relace Codex a očekávat lineární zrychlení, stejně jako nemůžeš neustále přidávat vývojáře do projektu a očekávat, že se harmonogram lineárně zkrátí. Každý další „pár rukou“, i když jen virtuální, přidává koordinační zátěž. Stali jsme se dirigenty orchestru místo, abychom byli jen rychlejšími sólovými hráči.

Projekt jsme začali s velkým základním kamenem: aplikace Sora již byla vydána na iOS. Často jsme nasměrovali Codex na kódové základny iOS a back-endu, abychom mu pomohli pochopit klíčové požadavky a omezení. Během projektu jsme si dělali legraci, že jsme znovu vynalezli myšlenku multiplatformního frameworku. Zapomeň na React Native nebo Flutter, budoucnost kódování mezi platformami je jen Codex.

Pod vtipem se skrývají dvě zásady:.

1. Logika je přenosná. Ať už je kód napsán v jazyce Swift nebo Kotlin, základní logika aplikace – datové modely, síťová volání, validační pravidla, obchodní logika – zůstává stejná. Codex je velmi dobrý v čtení implementace jazyka Swift a vytváření ekvivalentu v jazyce Kotlin se stejnou sémantikou.
2. Konkrétní příklady poskytují silný kontext. Nová relace Codex, která vidí „tady je přesně, jak to funguje na iOS“ a „tady je architektura Android“, je mnohem efektivnější než ta, která pracuje pouze s popisy v přirozeném jazyce.

Uplatněním těchto principů jsme zpřístupnili iOS, backend a repozitáře Android ve stejném prostředí. Dali jsme nástroji Codex prompty jako:

„Přečti si tyto modely a koncové body v kódu pro iOS a pak navrhni plán, jak implementovat ekvivalentní chování v systému Android pomocí našeho stávajícího klienta rozhraní API a tříd modelů.“

Jedním malým, ale užitečným trikem bylo podrobně popsat v ~/.codex/AGENTS.md, kde se nacházejí lokální repozitáře a co obsahují. To nástroji Codex usnadnilo objevování a orientaci v relevantním kódu.

Efektivně jsme prováděli vývoj napříč platformami pomocí překladu místo sdílené abstrakce. Protože Codex zvládl většinu překladu, vyhnuli jsme se zdvojnásobení nákladů na implementaci.

Širší poučení je, že pro Codex je kontext vším. Codex odvedl svou nejlepší práci, když pochopil, jak funkce již funguje v iOS, ve spojení s pochopením struktury naší aplikace pro Android. Když Codex tento kontext postrádal, nešlo o „odmítání spolupráce“, pouze hádal. Čím více jsme s ním zacházeli jako s novým členem týmu a investovali do poskytování správných vstupů, tím lépe fungoval.

Na konci našeho čtyřtýdenního sprintu přestalo používání nástroje Codex působit jako experiment a stalo se naším výchozím vývojovým cyklem. Použili jsme to k pochopení stávajícího kódu, plán změn a implementaci funkcí. Zkontrolovali jsme jeho výstup stejným způsobem, jakým bychom zkontrolovali výstup kolegy. Byl to prostě způsob, jak jsme dodávali software.

Ukázalo se, že vývoj s asistencí umělé inteligence nesnižuje potřebu důslednosti, naopak ji zvyšuje. Ačkoli je Codex velmi schopný, jeho cílem je nyní dostat se z bodu A do bodu B. To je důvod, proč kódování s asistencí umělé inteligence nefunguje bez lidí. Softwaroví vývojáři mohou pochopit a aplikovat reálná omezení systémů, nejlepší způsoby, jak navrhnout software a jak budovat s ohledem na budoucí vývoj a produktové plány. Superschopnosti softwarového vývojáře budoucnosti budou hluboké porozumění systémům a schopnost spolupracovat s umělou inteligencí na dlouhých časových horizontech. 

Nejzajímavější části softwarového vývoje je vytváření poutavých produktů, navrhování škálovatelných systémů, psaní složitých algoritmů a experimentování s daty, vzory a kódem. Realita softwarového vývoje minulosti a současnosti je často mnohem všednější: centrování tlačítek, zapojování koncových bodů a psaní šablonového kódu. Nyní Codex umožňuje soustředit se na nejvýznamnější části softwarového vývoje a důvody, proč svou práci milujeme.

Jakmile je Codex nastaven v prostředí bohatém na kontext, kde rozumí tvým cílům a tomu, jak chceš tvořit, může jakýkoli tým znásobit své schopnosti. Naše zpětná vazba k uvedení není univerzálním řešením a netvrdíme, že jsme vyřešili vývoj s asistencí umělé inteligence. Doufáme však, že naše zkušenosti usnadní nalezení nejlepších způsobů, jak umožnit nástroji Codex, aby vám dával větší možnosti. 

Když byl Codex před sedmi měsíci uveden jako náhled pro výzkumné účely, softwarový vývoj vypadal velmi odlišně. Prostřednictvím aplikace Sora jsme mohli prozkoumat další kapitolu vývoje. Jak se naše modely a systémy neustále zlepšují, umělá inteligence se stane stále více nepostradatelnou součástí budování. 

Co vytvoříš se svým vlastním týmem Codex?