Как използвахме Codex, за да изградим Sora за Android за 28 дни

От 26 април 2026 г. продуктът Sora вече не се предлага.

През ноември пуснахме приложението Sora за Android по целия свят, предоставяйки възможност на всеки с Android устройство да превърне кратка подкана в ярко видео. На деня на стартирането приложението достигна №1 в Play Store. Потребителите на Android извършиха генериране на повече от милион видеоклипове през първите 24 часа.

Зад старта стои история: първоначалната версия на приложение за Android на Sora беше създадено за 28 дни, благодарение на същия агент, който е достъпен за всеки екип или разработчик: Codex.

От 8 октомври до 5 ноември 2025 г. малък екип от инженери, работещ заедно с Codex и използващ приблизително 5 милиарда токена, пусна Sora за Android от прототип до глобално пускане. Въпреки мащаба си приложението е с 99.9 процента без сривове и има архитектура, с която се гордеем. Ако се чудите дали сме използвали таен модел, ние използвахме ранна версия на GPT‑5.1‑Codex модел – същата версия, която всеки разработчик или бизнес може да използва днес чрез интерфейс от команден ред (CLI), разширение за IDE или уеб приложение.

Когато Sora стартира на iOS, използването рязко се увеличи. Хората веднага започнаха да генерират поток от видеоклипове. За разлика от това, в Android имахме само малък вътрешен прототип и нарастващ брой предварително регистрирани потребители в Google Play.

Обичайна реакция при пускане с висок риск и под натиск на времето е натрупването на ресурси и добавянето на процеси. Едно продуктивно приложение с такъв обхват и качество обикновено би изисквало много инженери, работещи в продължение на месеци наред, забавени от координацията. 

Американският компютърен архитект Фред Брукс е известен с предупреждението си, че „добавянето на повече хора към закъснял софтуерен проект го прави още по-закъснял.“ С други думи, когато се опитвате да доставите сложен проект бързо, добавянето на повече инженери често може да забави ефективността, като увеличи комуникационната тежест, фрагментацията на задачите и разходите за интеграция. Ние се възползвахме от това прозрение, вместо да го пренебрегнем. Събрахме силен екип от четирима инженери – всички оборудвани с Codex, за да увеличат драстично въздействието на всеки инженер. 

Работейки по този начин, ние доставихме вътрешни компилации на Sora за Android на служителите за 18 дни и я пуснахме публично 10 дни по-късно. Поддържахме високи стандарти в инженерните практики на Android, инвестирахме в поддръжка и осигурихме приложението да отговаря на същите стандарти за надеждност, които бихме очаквали от по-традиционен проект. (Също така продължаваме да използваме Codex интензивно и днес, за да развиваме и въвеждаме нови функции в приложението).

За да разберете как работихме с Codex, е полезно да знаем къде блести и къде той се нуждае от насоки. Третирането му като новоназначен старши инженер беше добър подход. Възможностите на Codex ни позволиха да прекараме повече време в насочване и преглед на код, отколкото в самото му писане.

Къде Codex има нужда от насоки

1. Codex все още не е добър в извеждането на информация, която не му е била предоставена (например Вашите предпочитани архитектурни модели, продуктова стратегия, реално поведение на потребителите и вътрешни норми или преки пътища).
2. По същия начин Codex не можеше да види как приложението всъщност работи: не можеше да отвори Sora на устройство, да забележи, че превъртането не е както трябва, или да усети, че потокът е объркващ. Само нашият екип можеше да се справи с тези задачи, които изискваха опит.
3. Всеки екземпляр изисква интегриране. Споделянето на контекст с ясни цели, ограничения и насоки за „как правим нещата“ беше от съществено значение за доброто изпълнение на Codex.
4. По същия начин Codex изпитваше затруднения с дълбоката архитектурна преценка: оставен сам, той може да въведе допълнителен модел на изглед, където наистина искахме да разширим съществуващ такъв, или да премести логиката в слоя на потребителския интерфейс, която ясно принадлежи на хранилище. Инстинктът му е да накара нещо да работи, а не да даде приоритет на дългосрочната яснота.

Намерихме за полезно Codex да създава и поддържа голямо количество файлове AGENT.md в цялата кодова база. Това улесни прилагането на същите насоки и най-добри практики в различни сесии. Например, за да гарантираме, че Codex пише код според нашите насоки за стил, добавихме следното към нашия основен файл AGENTS.md:

Където Codex превъзхожда

1. Бързо четене и разбиране на големи кодови бази: Codex познава практически всички основни програмни езици, което улеснява използването на същите концепции на много платформи без сложни абстракции.
2. Тестово покритие: Codex е (уникално) ентусиазиран да пише модулни тестове, за да обхване широк спектър от случаи. Не всеки тест беше задълбочен, но обхватът на покритието беше полезен за предотвратяване на регресии. 
3. Прилагане на обратна връзка: По подобен начин Codex е добър в реагирането на обратната връзка. Когато общият интерфейс (CI) не успее, можем да вмъкнем изходните данни от регистъра в подкана и да помолим Codex да предложи поправки.
4. Масово паралелно, еднократно изпълнение: Повечето няма да достигнат границите на броя сесиите, които могат да изпълняват едновременно. Възможно е да се тестват множество идеи паралелно и кодът да се разглежда като нещо временно.
5. Предлагане на нова перспектива: В дискусиите за дизайн използвахме Codex като генеративен инструмент за изследване на потенциални точки на отказ и откриване на нови начини за решаване на проблем. Например, докато проектирахме оптимизации на паметта на видео плеъра, Codex прегледа множество SDK, за да предложи подходи, които нямаше да имаме време да анализираме. Изводите от изследванията на Codex се оказаха безценни за минимизиране на потреблението на паметта в крайното приложение.
6. Осигуряване на работа с по-висока стойност: На практика прекарвахме повече време в преглеждане и насочване на кода, отколкото в самото му писане. Въпреки това Codex е много добър и в прегледа на кода, като често улавя грешки, преди те да бъдат обединени, което подобрява надеждността.

След като признахме тези характеристики, нашият модел на работа стана по-опростен. Ние разчитахме на Codex да свърши огромно количество тежка работа в рамките на добре разбрани модели и добре ограничени обхвати, докато нашият екип се фокусираше върху архитектурата, потребителското изживяване, системните промени и крайното качество.

Дори най-добрият нов старши служител няма правилната перспектива, за да прави дългосрочни компромиси веднага. За да използваме Codex и да гарантираме, че работата му е стабилна и надеждна, беше от ключово значение сами да наблюдаваме проектирането на системите на приложението и основните компромиси. Те включваха оформянето на архитектурата на приложението, модулизация, инжектиране на зависимости и навигация. Също така внедрихме удостоверяване и основни мрежови потоци. 

Въз основа на това написахме няколко представителни функции от начало до край. Използвахме правилата, които искахме целият код да следва, и документирахме моделите за целия проект в процеса на работа. Като насочихме Codex към представителни характеристики, той успя да работи по-независимо в рамките на нашите стандарти. За проект, който според нашите оценки е 85% написан от Codex, внимателно планираната основа предотврати скъпоструващото връщане назад и рефакториране. Това беше едно от най-важните решения, които взехме. 

Идеята не беше да се направи „нещо, което работи“ възможно най-бързо, а по-скоро да се създаде „нещо, което разбира как искаме нещата да работят.“ Съществуват много „правилни“ начини за писане на код. Не трябваше да казваме на Codex точно какво да прави, трябваше да покажем на Codex какво е „правилно“ за нашия екип. След като установихме отправната си точка и начина, по който обичаме да изграждаме, Codex беше готов да започне.

За да видим какво ще се случи, опитахме да направим подкана: „Изгради приложението Sora за Android въз основа на кода за iOS. Започни“, но бързо прекратихме този начин. Докато това, което Codex създаде, технически работеше, продуктовото изживяване беше незадоволително. И без ясно разбиране на крайните точки, данните и потоците на потребителите, кодът на Codex, който се създаде еднократно, беше ненадежден (Дори без използване на агент е рисковано да се извърши обединяване на хиляди редове код.) 

Ние предположихме, че Codex ще процъфтява в среда с добре написани примери и бяхме прави. Да поискате от Codex да „изгради този екран с настройки“ с почти никакъв контекст беше ненадеждно. Да помолите Codex да „изгради този екран с настройки, използвайки същата архитектура и модели като този друг екран, който току-що видях“, работеше много по-добре. Хората взеха структурните решения и зададоха инвариантите, след това Codex запълни големи количества код в тази структура.

Следващата ни стъпка за максималното използване на потенциала на Codex беше да разберем как да позволим на Codex да работи за дълги периоди от време (наскоро повече от 24 часа⁠) без надзор.

В началото на използването на Codex, ние се обръщахме към подкани като „Ето функцията“. Ето няколко файла. Моля, изгради го. Това понякога работеше, но най-често създаваше код, който технически се компилираше, но се отклоняваше от нашата архитектура и цели.

Затова променихме работния процес. За всяка непроста промяна първо помолихме Codex да ни помогне да разберем как работят системата и кодът. Например бихме го помолили да прочете набор от свързани файлове и да обобщи как работи тази функция, например как данните преминават от API през слоя на хранилището, модела на изгледа и в потребителския интерфейс. След това бихме коригирали или прецизирали разбирането му. (Например бихме посочили, че дадена абстракция всъщност принадлежи на различен слой или че даден клас съществува само за офлайн режим и не трябва да се разширява.)

По същия начин, както бихте се ангажирали с нов, висококвалифициран колега, ние работихме с Codex, за да създадем солиден план за изпълнение. Този план често приличаше на миниатюрен документ за проектиране, в който се посочва кои файлове трябва да се променят, какви нови състояния трябва да се въведат и как трябва да протича логиката. Едва след това помолихме Codex да започне да прилага плана стъпка по стъпка. Един полезен съвет: за много дълги задачи, при които достигаме лимита на контекстния прозорец, молим Codex да запише плана си във файл, което ни позволява да прилагаме една и съща посока във всички инстанции.

Този допълнителен цикъл на планиране се оказа, че си заслужава времето. Това ни позволи да оставим Codex да работи „без надзор“ за дълги периоди, защото знаехме неговите планове. Това улесни прегледа на кода, защото можехме да проверим реализацията спрямо нашия план, вместо да четем разлики без контекст. А когато нещо се обърка, бихме могли първо да отстраним грешките в плана и след това в кода. 

Динамиката беше подобна на начина, по който добра проектна документация дава увереност на техническия ръководител в проекта. Ние не само правехме генериране на код: ние създавахме код, който поддържаше споделена пътна карта.

В разгара на проекта често провеждахме множество сесии на Codex паралелно. Един работеше върху възпроизвеждането, друг върху търсенето, трети върху обработката на грешки, а понякога и друг върху тестовете или рефакторирането. Усещането беше по-малко като използване на инструмент и повече като управление на екип.

Всяка сесия периодично ще ни докладва за напредъка. Някоя може да каже: „Приключих с планирането на този модул, ето какво предлагам“, а друга ще предложи голяма разлика за нова функция. Всяка изискваше внимание, обратна връзка и преглед. Беше необичайно подобно на това да бъдете технически ръководител на няколко нови инженери, всички правят напредък, всички се нуждаят от напътствия.

Резултатът беше съвместна работа. Способността на Codex за основно кодиране ни освободи от много ръчно писане. Имахме повече време да обмислим архитектурата, да прегледаме внимателно заявките за изтегляне и да тестваме приложението. 

В същото време тази допълнителна скорост означаваше, че винаги имахме нещо, което чака на опашката за преглед. Codex не беше блокиран от превключване на контекста, но ние бяхме. Нашето тясно място при разработката се измести от писането на код към вземането на решения, даването на обратна връзка и интегрирането на промените.

Тук е мястото, където прозренията на Брукс се проявяват по нов начин. Не можете просто да добавяте сесии на Codex и да очаквате линейни подобрения, както не можете да продължавате да добавяте инженери към проект и да очаквате графикът да се съкрати линейно. Всеки допълнителен „чифт ръце“, дори и виртуални, добавя координационна тежест. Превърнахме се в диригент на оркестър, а не просто в по-бързи солови изпълнители.

Започнахме нашия проект с огромно предимство: Sora вече беше пуснато на iOS. Често насочвахме Codex към кодовите бази на iOS и бекенд, за да му помогнем да разбере ключовите изисквания и ограничения. По време на проекта се шегувахме, че сме преоткрили идеята за междуплатформена рамка. Забравете за React Native или Flutter; бъдещето на междуплатформените технологии е само Codex.

В основата на шегата стоят два принципа:.

1. Логиката е преносима. Независимо дали кодът е написан на Swift или Kotlin, основната логика на приложението – модели на данни, мрежови заявки, правила за валидиране, бизнес логика – е една и съща. Codex е много добър в четенето на имплементация в Swift и създаването на еквивалент в Kotlin, който запазва семантиката.
2. Конкретни примери предоставят убедителен контекст. Нова сесия на Codex, която може да види „ето как точно работи това на iOS“ и „ето архитектурата на Android“, е много по-ефективна от такава, която работи само с описания на нормален език.

Прилагайки тези принципи на практика, направихме iOS, бекенда и Android хранилищата достъпни в една и съща среда. Давахме на Codex подкани като:

„Прочети тези модели и крайни точки в кода за iOS и след това предложи план за реализиране на еквивалентното поведение за Android, използвайки нашия съществуващ API клиент и модели на класове.“

Един малък, но полезен трик беше да се опише в ~/.codex/AGENTS.md къде се намират локалните хранилища и какво съдържат. Това улесни Codex да открива и навигира в съответния код.

Ние ефективно извършвахме разработка на различни платформи чрез превод вместо чрез споделена абстракция. Тъй като Codex се справи с по-голямата част от превода, ние избегнахме удвояването на разходите за внедряване.

По-общият извод е, че за Codex контекстът е всичко. Codex постигна най-добрите си резултати, когато разбра как функцията вече работи в iOS, съчетано с разбирането на структурата на нашето приложение за Android. Когато на Codex му липсваше този контекст, той не „отказваше да сътрудничи“, той просто предполагаше. Колкото повече го третирахме като нов колега и инвестирахме в предоставянето на правилното въвеждане, толкова по-добре се представяше.

До края на нашия четириседмичен спринт, използването на Codex спря да се усеща като експеримент и стана нашият цикъл на разработка по подразбиране. Използвахме го, за да разберем съществуващия код, да направим план за промени и да внедрим функции. Прегледахме неговия резултат по същия начин, по който бихме прегледали този на колега. Това беше просто начинът, по който предоставяхме софтуер.

Стана ясно, че развитието с помощта на изкуствен интелект не намалява нуждата от стриктност, напротив, увеличава я. Колкото и способен да е Codex, неговата цел е да стигне от точка А до точка Б сега. Ето защо кодирането, подпомагано от изкуствен интелект, не работи без хората. Софтуерните инженери могат да разбират и прилагат реалните ограничения на системите, най-добрите начини за проектиране на софтуер и как да изграждат с оглед на бъдещите планове за развитие и продукти. Супер силите на софтуерния инженер на утрешния ден ще бъдат дълбокото разбиране на системите и способността да работи съвместно с изкуствения интелект в дългосрочен план. 

Най-интересните аспекти на софтуерното инженерство включват създаването на завладяващи продукти, проектирането на мащабируеми системи, писането на сложни алгоритми и експериментирането с данни, модели и код. Въпреки това реалностите на софтуерното инженерство в миналото и настоящето често са по-банални: центриране на бутони, свързване на крайни точки и писане на шаблонен код. Сега Codex прави възможно да се съсредоточите върху най-смислените части на софтуерното инженерство и причините, поради които обичаме нашата професия.

След като Codex бъде създаден в богата на контекст среда, в която разбира Вашите цели и начина, по който обичате да изграждате, всеки екип може да умножи възможностите му. Нашето изминало пускане не е универсална рецепта и не твърдим, че сме решили проблема с разработването с помощта на изкуствен интелект. Но се надяваме, че нашият опит ще Ви улесни в намирането на най-добрите начини Codex да Ви даде повече възможности. 

Когато Codex беше пуснат като предварителен преглед за изследвания преди седем месеца, софтуерното инженерство изглеждаше много различно. Чрез Sora успяхме да изследваме следващата глава от инженерството. С усъвършенстването на нашите модели и системи, изкуственият интелект ще става все по-незаменима част от изграждането. 

Какво ще създадете със собствения си екип на Codex?