Как мы использовали Codex для создания Sora для Android за 28 дней12.12.2025 00:00

По состоянию на 26 апреля 2026 года продукт Sora больше недоступен.

В ноябре мы представили всему миру Android-приложение Sora, предоставив любому владельцу Android-устройства возможность превратить короткую текстовую подсказку в яркое видео. В день запуска приложение заняло первое место в Play Store. За первые 24 часа пользователи Android сгенерировали более миллиона видеороликов.

За этим релизом стоит интересная история: первая версия продакшн-приложения 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 испытывал трудности с принятием глубоких архитектурных решений: предоставленный сам себе, он мог внедрить дополнительную модель представления (view model) там, где мы хотели расширить существующую, или перенести в UI-слой логику, которая явно принадлежала репозиторию. Его инстинкт — заставить код работать, а не ставить во главу угла долгосрочную чистоту.

Мы нашли полезным поручить 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 и гарантировать надежность и поддерживаемость его работы, было ключевым моментом самостоятельно контролировать системный дизайн приложения и ключевые компромиссы. Сюда входили формирование архитектуры приложения, модульность, внедрение зависимостей (dependency injection) и навигация; кроме того, мы самостоятельно реализовали аутентификацию и базовые сетевые сценарии.

Опираясь на этот фундамент, мы от начала и до конца написали несколько репрезентативных функций. Мы использовали правила, которым должна была следовать вся кодовая база, и по ходу дела документировали общепроектные паттерны. Указывая Codex на типичные функции, мы позволяли ему работать более самостоятельно в рамках наших стандартов. Для проекта, который, по нашим оценкам, на 85% написан с помощью Codex, тщательно спланированный фундамент позволил избежать дорогостоящих возвратов назад и рефакторинга. Это было одно из самых важных решений, которые мы приняли.

Идея заключалась не в том, чтобы как можно быстрее сделать «хоть что-то работающее», а в том, чтобы сделать «то, что понимает, как именно мы хотим видеть рабочий процесс». Существует множество «правильных» способов написания кода. Нам не нужно было указывать Codex каждый шаг; нам нужно было показать Codex, что считается «правильным» в нашей команде. Как только мы зафиксировали стартовую точку и предпочтительный стиль разработки, Codex был готов к работе.

Ради эксперимента мы попробовали дать промт: «Создай Android-приложение Sora на основе кода для iOS. Поехали», но быстро отказались от этого пути. Хотя то, что создал Codex, технически работало, качество пользовательского опыта оставляло желать лучшего. А без четкого понимания эндпоинтов, данных и пользовательских сценариев код, сгенерированный за один раз, оказался ненадежным (Даже без использования агента объединять тысячи строк чужого кода — большой риск.)

Мы предположили, что Codex будет процветать в «песочнице» из хорошо написанных примеров — и оказались правы. Просить Codex «создать этот экран настроек» почти без контекста было неэффективно. Просьба «создать этот экран настроек, используя ту же архитектуру и паттерны, что и на том другом экране, который ты только что видел» работала намного лучше. Люди принимали структурные решения и задавали инварианты, а затем Codex заполнял большие объемы кода внутри этой структуры.

Следующим шагом на пути к раскрытию полного потенциала Codex стало выяснение того, как заставить его работать автономно в течение длительного времени (в последнее время — более 24 часов⁠) без присмотра.

На раннем этапе использования Codex мы бросались в крайности с такими промтами: «Вот фича. Вот несколько файлов. Пожалуйста, сделайте ее». Иногда это срабатывало, но чаще приводило к коду, который технически компилировался, но при этом отклонялся от нашей архитектуры и целей.

Поэтому мы изменили рабочий процесс. Для любого нетривиального изменения мы сначала просили Codex помочь нам разобраться в том, как работают система и код. Например, мы просили его прочитать набор связанных файлов и обобщить принципы работы функции: скажем, как данные поступают из API через слой репозитория и модель представления в пользовательский интерфейс. Затем мы корректировали или уточняли его понимание. (Например, указывали, что конкретная абстракция на самом деле должна находиться в другом слое или что данный класс существует исключительно для офлайн-режима и не подлежит расширению.)

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

Этот дополнительный цикл планирования полностью оправдал потраченное время. Он позволил нам оставлять Codex работать «без присмотра» на долгое время, поскольку мы были уверены в его планах. Это облегчило ревью кода, так как мы могли сверять реализацию с планом, а не читать дифф (diff) без контекстного понимания. А когда что-то шло не так, мы могли отлаживать сначала план, а уже во вторую очередь — сам код.

Эта динамика напоминала то, как качественный проектный документ дает техлиду уверенность в проекте. Мы не просто генерировали код — мы создавали код, поддерживающий общую дорожную карту.

В пиковые моменты проекта мы часто запускали несколько сеансов 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?