Это статья из официального блога OpenAI, но подход меня так зацепил, что решил перевести для всех. Я тоже часто переношу веб-приложения на мобилки примерно таким же способом и было очень здорово увидеть такой же подход (архитектура-как-пример) у по сути создателей сильного AI. Пишу про разные похожие интересные вещи тут
В ноябре мы представили миру приложение Sora для Android, предоставив любому пользователю с Android-устройством возможность превращать короткие текстовые промпты в живые видео. В день запуска приложение заняло 1-е место в Play Store. За первые 24 часа пользователи Android сгенерировали более миллиона видеороликов.
За этим запуском стоит история: первая версия продакшн-приложения Sora для Android была создана всего за 28 дней благодаря тому же агенту, который доступен любой команде или разработчику – Codex.
С 8 окт��бря по 5 ноября 2025 года небольшая команда инженеров, работая бок о бок с Codex и израсходовав примерно 5 миллиардов токенов (вау), провела Sora для Android от прототипа до глобального запуска. Несмотря на скорость разработки и масштаб, приложение демонстрирует показатель стабильности (crash-free) 99,9% и архитектуру, которой мы гордимся. Если вам интересно, использовали ли мы какую-то секретную модель – нет, мы использовали раннюю версию модели GPT-5.1-Codex, ту самую, которую любой разработчик или компания могут использовать уже сегодня через CLI, расширение для IDE или веб-приложение.
Принимая закон Брукса: оставаться гибкими, чтобы двигаться быстро
Когда Sora вышла на iOS, использование взлетело моментально. Люди тут же начали генерировать потоки видео. На Android же у нас был только небольшой внутренний прототип и растущее число предрегистраций в Google Play.
Обычная реакция на запуск с высокими ставками и сжатыми сроками – навалиться ресурсами и усилить процессы. Продакшн-приложение такого масштаба и качества обычно требует работы множества инженеров в течение нескольких месяцев, замедляемых необходимостью координации.
Американский архитектор ПО Фред Брукс знаменит своим предостережением: «Добавление людей в запаздывающий проект лишь делает его еще более запаздывающим». Другими словами, когда вы пытаетесь быстро выпустить сложный проект, добавление новых инженеров часто снижает эффективность из-за накладных расходов на коммуникацию, фрагментацию задач и интеграцию. Мы решили не игнорировать этот инсайт, а опереться на него. Мы собрали сильную команду всего из четырех инженеров, каждый из которых был вооружен Codex для радикального увеличения личного импакта.
Работая в таком режиме, мы выпустили внутреннюю сборку Sora для Android для сотрудников всего за 18 дней, а публичный релиз состоялся спустя еще 10 дней. Мы сохранили высокую планку инженерных практик Android, вложились в поддерживаемость кода и придерживались того же уровня надежности, которого ожидали бы от более традиционного проекта. (Мы также продолжаем активно использовать Codex и сегодня для развития приложения и внедрения новых функций).
Онбординг нового сеньор-инженера
Чтобы понять, как мы работали с Codex, полезно знать, где он силен, а где ему нужно направление. Относиться к нему как к только что нанятому сеньор-инженеру — отличный подход. Способности Codex позволили нам тратить больше времени на руководство и ревью кода, чем на его написание.
Где Codex нужно руководство
Codex пока не умеет идеально догадываться о том, чего ему не сказали (например, о ваших предпочтительных архитектурных паттернах, продуктовой стратегии, реальном поведении пользователей и внутренних нормах или шорткатах). Точно так же Codex не мог видеть, как приложение работает в реальности: он не мог открыть Sora на устройстве, заметить, что скролл «подтормаживает», или почувствовать, что флоу (поток действий пользователя) запутан. Только наша команда могла закрыть эти экспертные задачи.
Каждый инстанс (экземпляр) требует онбординга. Передача контекста с четкими целями, ограничениями и гайдлайнами «как мы это делаем» была критически важна для того, чтобы Codex работал хорошо. В том же духе, Codex иногда испытывал трудности с глубокими архитектурными решениями: предоставленный сам себе, он мог ввести лишнюю вью-модель там, где мы хотели расширить существующую, или запихнуть в UI-слой логику, которой явно место в репозитории. Его инстинкт — заставить что-то работать, а не приоритезировать чистоту кода в долгосрочной перспективе.
Мы обнаружили, что крайне полезно поручать Codex создание и поддержку большого количества файлов AGENT.md по всей кодовой базе. Это позволило легко применять единые руководства и лучшие практики (best practices) в рамках разных сессий. Например, чтобы гарантировать, что Codex пишет код в соответствии с нашими стайл-гайдами, мы добавили следующие инструкции в наш корневой файл AGENTS.md:
## Formatting and static checks
- **Always run** `./gradlew detektFix` (or for the affected modules) **before committing**. CI will fail if formatting or detekt issues are present.Где Codex превосходит ожидания
Быстрое чтение и понимание больших кодовых баз: Codex знает практически все основные языки программирования, что упрощает использование одних и тех же концепций на разных платформах без сложных абстракций.
Покрытие тестами: Codex (уникально) с энтузиазмом пишет юнит-тесты для покрытия широкого спектра кейсов. Не каждый тест был глубоким, но широта покрытия помогла предотвратить регрессии.
Реакция на фидбэк: В том же ключе, Codex хорош в реагировании на обратную связь. Когда падал CI, мы могли просто вставить вывод лога в промпт и попросить Codex предложить исправления.
Массовое параллельное одноразовое выполнение: Большинство не упрется в лимит количества сессий, которые можно запустить одновременно. Вполне реально тестировать несколько идей параллельно и относиться к коду как к расходному материалу.
Предложение новой перспективы: В дизайн-обсуждениях мы использовали Codex как генеративный инструмент для исследования потенциальных точек отказа и поиска новых способов решения проблем. Например, при проектировании оптимизации памяти видеоплеера Codex просеял множество SDK, чтобы предложить подходы, на разбор которых у нас не было бы времени. Инсайты из «исследования» Codex оказались бесценны для минимизации потребления памяти в финальном приложении.
Освобождение для работы высокого уровня: На практике мы тратили больше времени на ревью и управление кодом, чем на его написание. При этом Codex очень хорош и в код-ревью, часто отлавливая баги до того, как они попадут в мердж, что повышает надежность.
Как только мы приняли эти характеристики, наша рабочая модель стала понятнее. Мы полагались на Codex в выполнении огромного объема тяжелой работы внутри хорошо понятных паттернов и четко очерченных границ, в то время как наша команда фокусировалась на архитектуре, пользовательском опыте (UX), системных изменениях и финальном качестве.
Закладка фундамента вручную
Даже лучший новый сеньор не обладает правильной точкой обзора для принятия долгосрочных компромиссных решений сразу же. Чтобы использовать Codex и гарантировать, что его работа будет надежной и поддерживаемой, было ключевым моментом, что мы сами контролировали системный дизайн приложения и ключевые трейд-оффы. Сюда входили формирование архитектуры приложения, модуляризация, внедрение зависимостей (DI) и навигация; мы также сами реализовали аутентификацию и базовые сетевые флоу.
На этом фундаменте мы реализовали несколько репрезентативных функций от начала до конца (end-to-end). Мы использовали правила, которым должна была следовать вся кодовая база, и документировали общепроектные паттерны по ходу работы. Указывая Codex на эти эталонные функции, мы добились того, что он смог работать более автономно, оставаясь в рамках наших стандартов. Для проекта, который, по нашим оценкам, на 85% написан Codex, тщательно спланированный фундамент позволил избежать дорогостоящего переписывания и рефакторинга. Это было одно из самых важных решений, которые мы приняли.
Идея была не в том, чтобы как можно быстрее сделать «что-то рабочее», а в том, чтобы создать «что-то, что понимает, как именно мы хотим, чтобы оно работало». Существует много «правильных» способов написать код. Нам не нужно было говорить Codex, что именно делать; нам нужно было показать Codex, что считается «правильным» в нашей команде. Как только мы установили отправную точку и то, как мы любим строить, Codex был готов к старту.
Чтобы посмотреть, что получится, мы попробовали промпт: «Создай Android-приложение Sora на основе кода iOS. Вперед», но быстро свернули с этого пути. Хотя то, что создал Codex, технически работало, продуктовый опыт был посредственным. А без четкого понимания эндпоинтов, данных и пользовательских флоу, код, написанный «с одного промпта» (single-shot), был ненадежным (даже без использования агента рискованно мерджить тысячи строк кода).
Мы выдвинули гипотезу, что Codex расцветет в «песочнице» из хорошо написанных примеров; и мы оказались правы. Просить Codex «сделать экран настроек» почти без контекста – ненадежно. Просить Codex «сделать этот экран настроек, используя ту же архитектуру и паттерны, что и вот этот другой экран, который ты только что видел» – работало куда лучше. Люди принимали структурные решения и задавали инварианты; Codex затем заполнял большие объемы кода внутри этой структуры.
Планирование с Codex перед написанием кода
Нашим следующим шагом в максимизации потенциала Codex стало понимание того, как позволить Codex работать в течение длительных периодов времени (в последнее время — более 24 часов) без присмотра.
В начале использования Codex мы сразу переходили к промптам типа: «Вот фича. Вот файлы. Пожалуйста, собери это». Иногда это срабатывало, но чаще выдавало код, который технически компилировался, но отклонялся от нашей архитектуры и целей.
Поэтому мы изменили рабочий процесс. Для любого нетривиального изменения мы сначала просили Codex помочь нам понять, как работают система и код. Например, мы просили его прочитать набор связанных файлов и саммаризировать, как работает эта фича; скажем, как данные текут от API через слой репозитория, вью-модель и в UI. Затем мы корректировали или уточняли его понимание. (Например, мы указывали, что конкретная абстракция на самом деле принадлежит другому слою или что данный класс существует только для офлайн-режима и его не следует расширять).
Подобно тому, как вы взаимодействуете с новым, высококвалифицированным коллегой, мы работали с Codex над созданием надежного плана реализации. Этот план часто выглядел как миниатюрный дизайн-документ, указывающий, какие файлы должны измениться, какие новые состояния нужно ввести и как должна проходить логика. Только после этого мы просили Codex начать выполнять план, шаг за шагом. Один полезный совет: для очень длинных задач, где мы упирались в лимит контекстного окна, мы просили Codex сохранить свой план в файл, что позволяло нам применять одно и то же направление в разных инстансах.
Этот дополнительный цикл планирования стоил потраченного времени. Он позволил нам оставлять Codex работать «без присмотра» на долгие отрезки, потому что мы знали его планы. Это упростило код-ревью, так как мы могли сверять реализацию с нашим планом, а не читать дифф (diff) без контекста. И когда что-то шло не так, мы могли сначала отлаживать план, а потом код.
Динамика ощущалась схожей с тем, как хороший дизайн-документ дает техлиду уверенность в проекте. Мы не просто генерировали код: мы производили код, который поддерживал общий roadmap.
Распределенная инженерия
На пике проекта мы часто запускали несколько сессий Codex параллельно. Одна работала над воспроизведением видео, другая – над поиском, третья – над обработкой ошибок, а иногда еще одна – над тестами или рефакторингом. Это ощущалось не столько как использование инструмента, сколько как управление командой.
Каждая сессия периодически отчит��валась нам о прогрессе. Одна могла сказать: «Я закончил планирование этого модуля; вот что я предлагаю», в то время как другая предлагала большой дифф для новой фичи. Каждая требовала внимания, фидбэка и ревью. Это было до жути похоже на роль техлида с несколькими новыми инженерами: все двигаются вперед, всем нужно руководство.
Результатом стал коллаборативный поток (flow). Чистая способность Codex к кодингу освободила нас от большого количества ручного набора текста. У нас появилось больше времени на обдумывание архитектуры, внимательное чтение пулл-реквестов и тестирование приложения.
В то же время эта дополнительная скорость означала, что у нас всегда что-то висело в очереди на ревью. Codex не блокировался переключением контекста, а мы – да. Наше «бутылочное горлышко» в разработке сместилось с написания кода на принятие решений, дачу фидбэка и интеграцию изменений.
Именно здесь инсайты Брукса раскрываются по-новому. Вы не можете просто добавлять сессии Codex и ожидать линейного ускорения, точно так же, как не можете бесконечно добавлять инженеров в проект, ожидая линейного сокращения сроков. Каждая дополнительная «пара рук», даже виртуальных, добавляет накладные расходы на координацию. Мы стали дирижерами оркестра, а не просто более быстрыми солистами.
Codex как кроссплатформенная суперсила
Мы начали наш проект с огромного подспорья: Sora уже вышла на iOS. Мы часто указывали Codex на кодовые базы iOS и бэкенда, чтобы помочь ему понять ключевые требования и ограничения. На протяжении проекта мы шутили, что изобрели идею кроссплатформенного фреймворк�� заново. Забудьте про React Native или Flutter; будущее кроссплатформы – это просто Codex.
Под этой шуткой лежат два принципа:
Логика портативна. Написан ли код на Swift или на Kotlin, лежащая в основе логика приложения – модели данных, сетевые вызовы, правила валидации, бизнес-логика – одинакова. Codex очень хорош в чтении реализации на Swift и создании эквивалента на Kotlin с сохранением семантики.
Конкретные примеры дают мощный контекст. Свежая сессия Codex, которая может видеть «вот как именно это работает на iOS» и «вот архитектура Android», куда эффективнее, чем та, которая работает только по описаниям на естественном языке.
Заставив эти принципы работать, мы сделали репозитории iOS, бэкенда и Android доступными в одной среде. Мы давали Codex промпты вроде:
«Прочитай эти модели и эндпоинты в коде iOS, а затем предложи план реализации эквивалентного поведения на Android, используя наш существующий API-клиент и классы моделей».
Одним маленьким, но полезным трюком было детальное описание в ~/.codex/AGENTS.md, где находятся локальные репозитории и что они содержат. Это упростило Codex обнаружение и навигацию по релевантному коду.
Мы, по сути, занимались кроссплатформенной разработкой через перевод, а не через общую абстракцию. Поскольку Codex брал на себя большую часть перевода, мы избежали удвоения затрат на реализацию.
Более широкий урок заключается в том, что для Codex контекст – это всё. Codex выдавал лучшие результаты, когда понимал, как фича уже работает в iOS, в сочетании с пониманием того, как структурировано наше Android-приложение. Когда Codex не хватало этого контекста, он не «отказывался сотрудничать»; он гадал. Чем больше мы относились к нему как к новому коллеге и вкладывались в предоставление правильных входных данных, тем лучше он работал.
Программная инженерия завтрашнего дня, уже сегодня
К концу нашего четырехнедельного спринта использование Codex перестало ощущаться как эксперимент и стало нашим дефолтным циклом разработки. Мы использовали его для понимания существующего кода, планирования изменений и реализации фич. Мы ревьюили его выдачу так же, как ревьюили бы работу коллеги. Это стало просто способом, которым мы шипим софт.
Стало ясно, что AI-ассистированная разработка не снижает потребность в строгости; она ее повышает. Каким бы способным ни был Codex, его цель – добраться из точки А в точку Б, сейчас. Вот почему кодинг с ИИ не работает без людей. Инженеры ПО могут понимать и применять реальные системные ограничения, лучшие способы архитектуры софта и то, как строить с учетом будущих планов развития и продукта. Суперсилами инженера завтрашнего дня станут глубокое системное понимание и способность работать совместно с ИИ на длинных временных горизонтах.
Самые интересные части программной инженерии – это создание привлекательных продуктов, проектирование масштабируемых систем, написание сложных алгоритмов и эксперименты с данными, паттернами и кодом. Однако реалии инженерии прошлого и настоящего часто склоняются к рутине: центрирование кнопок, связывание эндпоинтов и написание бойлерплейта. Теперь Codex делает возможным сфокусироваться на самых значимых частях программной инженерии и причинах, по которым мы любим наше ремесло.
Как только Codex настроен в богатой контекстом среде, где он понимает ваши цели и то, как вы любите строить, любая команда может мультиплицировать свои возможности. Наше ретро по запуску – не универсальный рецепт, и мы не утверждаем, что решили проблему AI-разработки. Но мы надеемся, что наш опыт поможет вам найти лучшие способы дать Codex возможность усилить вас.
Когда Codex запустился в превью для исследователей семь месяцев назад, программная инженерия выглядела совсем иначе. Благодаря Sora нам удалось исследовать следующую главу инженерии. По мере того как наши модели и обвязка продолжают улучшаться, ИИ будет становиться все более незаменимой частью создания продуктов.
Что вы создадите со своей собственной командой Codex?
