Як ми використовували Codex для розробки Sora на Android за 28 днів

Станом на 26 квітня 2026 року продукт Sora більше недоступний.

У листопаді ми випустили програму Sora для Android на світовий ринок, надавши кожному користувачу Android-пристрою можливість перетворити короткий запит на яскраве відео. У день запуску програма зайняла перше місце в рейтингах Play Store. Користувачі Android згенерували понад мільйон відео за перші 24 години.

За запуском стоїть ціла історія: початкова версія продакшн-версії програми Sora для 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 був готовий розпочати роботу.

Щоб побачити, що станеться, ми спробували дати команду: «Створи Android-програму Sora на основі коду iOS. Уперед!», але швидко від цього відмовилися. Хоча те, що створив Codex, технічно працювало, враження від використання продукту були нижче середнього. Без чіткого розуміння кінцевих точок, даних і потоків користувача одноразовий код Codex був ненадійним (навіть без використання агента, злиття тисяч рядків коду було ризикованим). 

Ми припустили, що Codex буде краще з добре прописаними прикладами — і ми мали рацію. Запросити у Codex «створи ось цей екран налаштувань» із майже повною відсутністю контексту було ненадійно. Але прохання до Codex «створи ось цей екран налаштувань, використовуючи ту ж архітектуру і патерни, що і на іншому екрані, який ти щойно бачив», виявилося набагато успішнішим. Люди приймали структурні рішення та встановлювали інваріанти; Codex потім заповнював великі обсяги коду всередині цієї структури.

Наш наступний крок у максимізації потенціалу Codex полягав у тому, щоб з’ясувати, як забезпечити роботу Codex протягом тривалих періодів часу (нещодавно — більше 24 годин⁠) без нагляду.

На ранніх етапах використання Codex ми перейшли до підказок на кшталт: «Ось функція. Ось декілька файлів. Виконай розробку.» Іноді це спрацьовувало, але в основному створювався код, який технічно компілювався, але відхилявся від нашої архітектури та цілей.

Тому ми змінили робочий процес. Для будь-якої нетривіальної зміни ми спочатку просили Codex допомогти нам зрозуміти, як функціонують система та код. Наприклад, ми просили його прочитати набір пов'язаних файлів та резюмувати, як працює та чи інша функція; скажімо, як дані проходять від API через шар репозиторію, модель представлення і в інтерфейс користувача. Далі ми виправляли чи уточнювали його розуміння. Наприклад, ми вказували, що певна абстракція дійсно належить іншому рівню, або що цей клас існує тільки для офлайн-режиму і не повинен розширюватися.

Щоб створити надійний план реалізації, ми працювали з Codex так, як можна було б взаємодіяти з новим висококваліфікованим членом команди. Цей план часто виглядав як мініатюрний проєктний документ, який вказує на те, які файли слід змінити, які нові стани слід ввести і як повинна розвиватися логіка. Тільки тоді ми просили Codex починати застосовувати план крок за кроком. Корисна порада: для дуже довгих завдань, коли ми досягаємо межі нашого контекстного вікна, ми просимо Codex зберегти свій план у файл, що дозволяє нам застосовувати один і той же напрямок у різних випадках.

Цей додатковий цикл планування виявився вартим витраченого часу. Це дозволяло нам запускати Codex без нагляду на тривалі періоди, тому що ми знали його плани. Це спростило перевірку коду, тому що ми могли звіряти реалізацію з нашим планом, а не читати різницю без контексту. Коли щось йшло не так, ми могли спочатку налагодити план, а потім код. 

Динаміка була схожа на те, як якісний проєктний документ вселяє впевненість у проєкт у технічного керівника. Ми не просто генерували код: ми створювали код, що підтримував спільну дорожню карту.

На піку проєкту ми часто запускали кілька сеансів Codex паралельно. Один займався відтворенням, інший — пошуком, третій — обробкою помилок, а іноді ще один — тестами чи рефакторингом. Це було менше схоже на використання інструменту та більше на керування командою.

Кожен сеанс періодично звітував нам про прогрес. Один міг видати: «Я закінчив планувати цей модуль; ось що я пропоную», тоді як інший пропонував значну зміну нової функції. Кожному потрібна була увага, відгук та перевірка. Це було вражаюче схоже на те, як бути технічним лідером для кількох нових інженерів-розробників, які роблять успіхи, але їм поки що потрібна допомога.

В результаті ми отримали безперервний процес спільної роботи. Базова здатність Codex до програмування звільнила нас від годин ручного введення. У нас було більше часу, щоб думати про архітектуру, ретельно вивчати pull-запити та тестувати програму. 

Водночас, додаткова швидкість означала, що в нашій черзі на перевірку завжди щось було. Codex не заважало перемикання контексту, а от нам — так. Для нас складність у розробці змістилася з написання коду на прийняття рішень, надання відгуку та інтеграцію змін.

Саме тут ідеї Брукса постали в новому світлі. Не можна продовжувати додавати в проєкт нових інженерів і очікувати, що графік роботи скоротиться лінійно: так само не можна було просто запускати нові сеанси Codex і очікувати на лінійне прискорення. Кожна додаткова пара рук, навіть віртуальна, збільшує навантаження на координацію. Ми стали диригентами оркестру, а не просто швидшими солістами.

Ми розпочали наш проєкт із важливого етапу: Sora вже була випущена на iOS. Ми часто направляли Codex на кодові бази iOS та бекенда, щоб допомогти йому зрозуміти ключові вимоги та обмеження. Протягом усього проєкту ми жартували, що заново винайшли ідею кросплатформного фреймворку. Забудьте про React Native або Flutter; майбутнє кросплатформної розробки — це Codex.

Під жартом ховаються два принципи:

1. Логіка переносима. Незалежно від того, чи написаний код на Swift або Kotlin, основна логіка програми — моделі даних, мережні виклики, правила валідації, бізнес-логіка — залишається незмінною. Codex відмінно справляється з читанням реалізації на Swift та створенням еквівалента на Kotlin із збереженням семантики.
2. Конкретні приклади створюють потужний контекст. Новий сеанс Codex, який може побачити «ось як це працює на iOS» і «ось архітектура Android», набагато ефективніший, ніж той, який працює тільки з описами природною мовою.

Застосовуючи ці принципи, ми зробили репозиторії iOS, backend та Android доступними в одному середовищі. Ми надали Codex, наприклад, такі підказки:

«Прочитай ці моделі та кінцеві точки в коді iOS, а потім запропонуй план з реалізації аналогічної поведінки на Android, використовуючи наш існуючий API-клієнт та класи моделей.»

Один невеликий, але корисний трюк полягав у тому, щоб докладно описати в  ~/.codex/AGENTS.md, де знаходяться локальні репозиторії і що вони містять. Це спростило для Codex виявлення та навігацію за відповідним кодом.

Ми фактично займалися кросплатформною розробкою через переклад, а не загальну абстракцію. Codex виконав велику частину перекладу, а ми уникнули подвоєння витрат на впровадження.

Більш важливий урок полягає в тому, що для Codex контекст — це все. Codex виконував свою роботу найкраще, коли розумів, як функція вже працює в iOS, у поєднанні з розумінням структури нашої програми для Android. Коли Codex не вистачало цього контексту, він не «відмовлявся співпрацювати», а робив припущення. Чим більше ми ставилися до нього як до нового члена команди і вкладалися в надання правильних вступних даних, тим краще він працював.

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

Стало очевидно, що розробка з використанням ШІ не знижує потребу в строгості — навпаки, вона її збільшує. Хоча Codex і має сильні здібності, його мета — просто в найкоротші терміни дістатися з точки A до точки B. Ось чому програмування за допомогою ШІ не працює без людей. Інженери-програмісти можуть розуміти та застосовувати реальні обмеження систем, найкращі методи архітектури програмного забезпечення та особливості розробки з урахуванням майбутніх планів розвитку та планів на продукт. Суперздібності інженера-програміста майбутнього полягатимуть у глибокому розумінні систем та здатності працювати разом з ШІ протягом тривалих періодів часу. 

Найцікавіші аспекти розробки ПЗ — це створення захоплюючих продуктів, проектування систем, що масштабуються, написання складних алгоритмів та експерименти з даними, патернами та кодом. Однак реальність розробки програмного забезпечення в минулому і теперішньому часто виявляється більш повсякденною: вирівнювання кнопок, підключення кінцевих точок, написання шаблонного коду. Codex сьогодні дозволяє зосередитися на найбільш значущих аспектах розробки програмного забезпечення — і причинах, з яких ми любимо свою роботу.

Після налаштування Codex у середовищі, багатому контекстом, де він розуміє ваші цілі та принципи розробки, будь-яка команда зможе помножити свої можливості. Наш ретроспективний аналіз запуску — це не універсальний рецепт, і ми не стверджуємо, що вирішили всі проблеми розробки за допомогою ШІ. Але ми сподіваємося, що наш досвід полегшить пошук найкращих способів розширення можливостей Codex — і, відповідно, ваших. 

Коли Codex було запущено на стадії дослідницького тестування сім місяців тому, розробка програмного забезпечення виглядала зовсім інакше. Завдяки Sora ми змогли дослідити наступний розділ інженерії. У міру того, як наші моделі та системи управління продовжують удосконалюватися, ШІ стає все більш незамінною частиною розробки програмного забезпечення. 

А що разом із Codex створить ваша команда?