Како го користевме Codex за да ја изградиме Sora за Android за 28 дена

Од 26.04.2026 г., производот Sora повеќе не е достапен.

Во ноември, ја лансиравме апликацијата Sora за Android на светот, давајќи му на секој со Android уред можност да претвори краток промпт во живописно видео. На денот на лансирање, апликацијата достигна #1 во Play Store. Корисниците на Android генерираа повеќе од милион видеа во првите 24 часа.

Зад лансирањето стои приказна: првичната верзија на продукциската Android апликација на Сора беше изградена за 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 сесии паралелно. Еден работеше на репродукција, друг на пребарување, друг на ракување со грешки, а понекогаш и друг на тестови или рефакторирања. Се чувствуваше помалку како користење на алатка и повеќе како управување со тим.

Секоја сесија периодично ќе ни известува за напредокот. Некој може да каже: „Завршив со планирањето на овој модул; еве што предлагам,“ додека друг би понудил голем diff за нова функција. Секој бараше внимание, повратни информации и преглед. Беше неверојатно слично на тоа да си технилки лидер со неколку нови инженери, сите кои напредуваат и сите кои имаат потреба од насоки.

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

Во исто време, таа дополнителна брзина значеше дека секогаш имавме нешто што чекаше во нашиот ред за преглед. Codex не беше блокиран од промена на контекстот, но ние бевме. Нашето тесно грло во развојот се префрли од пишување код кон донесување одлуки, давање повратни информации и интегрирање на промени.

Ова е местото каде што сознанијата на Брукс се појавуваат на нов начин. Не можеш едноставно да додадеш Codex сесии и да очекуваш линеарни забрзувања, исто како што не можеш да продолжиш да додадеш инженери на проект и да очекуваш распоредот да се намали линеарно. Секој дополнителен „пар раце“, дури и виртуелен, додава координациски товар. Станавме диригенти на оркестар, наместо само побрзи соло играчи.

Го започнавме нашиот проект со голем чекор напред: Sora веќе беше испорачана на iOS. Често го насочувавме Codex кон iOS и бекенд кодните бази за да му помогнеме да ги разбере клучните барања и ограничувања. Во текот на проектот се шегувавме дека ја преработивме идејата за рамката за повеќе платформи. Заборави на React Native или Flutter; иднината на повеќето платформи е само Codex.

Под quip лежат два принципа:.

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 престана да се чувствува како експеримент и стана наш стандардeн развоен циклус. Го користевме за да го разбереме постоечкиот код, да направиме план за промени и да имплементираме функции. Го прегледавме неговиот резултат на ист начин како што би прегледале на колега. Тоа беше едноставно како што го испорачувавме софтверот.

Стана јасно дека развојот со помош на вештачка интелигенција не ја намалува потребата за ригорозност; напротив, ја зголемува. Колку и да е способен Codex, неговата цел е да стигне од точка А до точка Б, сега. Ова е причината зошто кодирањето со помош на вештачка интелигенција не функционира без луѓе. Софтверските инженери можат да ги разберат и применат реалните ограничувања на системите, најдобрите начини за архитектура на софтвер и како да градат со оглед на идниот развој и плановите за производи. Супермоќите на утрешниот софтверски инженер ќе бидат длабокото разбирање на системите и способноста за соработка со вештачка интелигенција на долги временски хоризонти. 

Најинтересните делови од софтверското инженерство се создавање привлечни производи, дизајнирање скалабилни системи, пишување сложени алгоритми и експериментирање со податоци, обрасци и код. Сепак, реалностите на софтверското инженерство од минатото и сегашноста често се повеќе обични: центрирање на копчиња, поврзување на крајни точки и пишување шаблонски код. Сега, Codex овозможува да се фокусираме на најзначајните делови од софтверското инженерство и причините зошто го сакаме нашиот занает.

Откако Codex е поставен во средина богата со контекст каде што ги разбира твоите цели и како сакаш да градиш, секој тим може да ги умножи своите способности. Нашата ретроспектива на лансирањето не е универзален рецепт и не тврдиме дека го решивме развојот со помош на вештачка интелигенција. Но, се надеваме дека нашето искуство ќе ви го олесни наоѓањето на најдобрите начини да го оспособите Codex за да ве оспособи вас. 

Кога Codex беше лансиран во истражувачки преглед пред седум месеци, софтверското инженерство изгледаше многу поинаку. Преку Sora, успеавме да го истражи следното поглавје на инженерингот. Како што нашите модели и хардвер се подобруваат, вештачката интелигенција ќе стане сè понезаменлив дел од градењето. 

Што ќе создадеш со твојот сопствен тим на Codex?