Как мы использовали Codex для разработки Sora на Android за 28 дней

С 26.04.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 было понять, как дать ему возможность работать без контроля в течение длительного времени (недавно более 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 создаст ваша команда?