История с Android‑приложением Sora — это не просто кейс «мы быстро сделали хитовый продукт». Это первый крупный публичный пример того, как промышленная разработка сама превращается в совместную работу людей и ИИ, причём с реальной, а не декоративной долей автоматики.
За 28 дней:
- команда из 4 инженеров,
- с помощью Codex (версия на базе GPT‑5.1),
- написала Android‑приложение Sora,
- при этом около 85% кода сгенерировано ИИ,
- приложение выдержало запуск на сотни тысяч пользователей с 99,9% безаварийности и сразу вылетело в топ Google Play.
Разберём, как им это удалось, что реально умеет Codex и как меняется роль инженера в такой схеме.
1. Контекст: «Брукс, но с ИИ» — не добавляй людей, усиливай каждого
К моменту, когда Sora на iOS «взорвала» аудиторию, ситуация была типичная для горячего релиза:
- iOS‑версия уже в продакшене и тонет в пользовательском трафике,
- под Android есть только внутренний прототип,
- очередь предрегистраций в Google Play растёт.
Классическая реакция индустрии:
- срочно набрать десятки разработчиков,
- накрутить совещания и процессы,
- и через несколько месяцев, после борьбы с координацией и интеграцией, выкатить первую стабильную версию.
OpenAI пошла по пути, противоположному инстинктам, но согласованному с законом Брукса:
«Добавление людей в отстающий софт‑проект только ещё больше его задерживает».
Вместо расширения команды — микро‑отряд из 4 человек, каждому выдали по «цифровому напарнику» Codex и построили процесс так, чтобы поднять производительность каждого инженера на порядок, а не на 10–20%.
Результат:
- 18 дней — первая внутренняя сборка Sora для Android для сотрудников;
- ещё 10 дней — доводка и публичный релиз.
2. Codex как «новичок‑сеньор»: что он умеет и чего не может
OpenAI сознательно позиционирует Codex не как «волшебную IDE», а как виртуального коллегу уровня «только что вышедший на работу сеньор»:
- он знает языки, паттерны, фреймворки,
- быстро ориентируется в больших кодовых базах,
- может сам расписать план и реализовать фичу,
- но не знает ваших внутренних «неписаных правил», бизнес‑контекста, UX‑чувствительности.
Отсюда модель взаимодействия:
- человек задаёт архитектуру, дизайн, границы,
- Codex делает основной объём рутинного кода, тестов, адаптаций,
- человек остаётся в цикле: план → ревью → корректировки.
Это принципиальное отличие от «vibe‑программирования», когда разработчик просто бездумно нажимает «принять» на код, который показался «вроде нормальным». Здесь практика ближе к тому, что Simon Willison называет vibe engineering:
ИИ — активный участник, но человек контролирует структуру, принимает решения, определяет стандарты.
3. Где Codex слаб: опыт, UX и «невидимые» правила
Из кейсов команды Sora хорошо видно, где границы нынешних код‑моделей:
- Нет ощущения продукта.
Codex не видит, как приложение ощущается на живом устройстве:
- не чувствует, что скролл «дёрганый»,
- не замечает неудобные пользовательские потоки,
- не понимает эмоциональные нюансы UX.
Всё, что связано с ощущением «это удобно и приятно», остаётся сугубо человеческой работой.
- Не знает локальных «традиций».
Codex не видит:
- любимые архит. паттерны команды,
- скрытые компромиссы продуктовой стратегии,
- внутренние ограничения (legacy, политика безоп., «мы так не делаем, потому что…»).
- Стремление «лишь бы работало».
Без контроля Codex склонен:
- запихнуть бизнес‑логику в UI‑слой,
- наплодить лишние ViewModel’и,
- нарушить репозиторские границы и чистую архитектуру.
Его «инстинкт» — сделать работающий прототип, а не поддерживаемую систему.
Поэтому OpenAI буквально «обучает» Codex культуре проекта — через:
- файлы вроде AGENTS.md с чёткими правилами по форматированию, стат‑чекам, паттернам;
- повторное использование этих инструкций в разных сессиях;
- постоянный ревью и поправки.
4. Где Codex силён: чтение, тесты, параллелизм, новый взгляд
Сильные стороны:
- Чтение и понимание больших кодовых баз.
Codex:
- одинаково комфортно работает со Swift, Kotlin, backend‑кодом,
- быстро устраняет «семантический барьер» между платформами: читает Swift и пишет эквивалент на Kotlin.
- Массовое тестирование.
Модель с энтузиазмом пишет:
- кучи unit‑тестов,
- проверки на edge‑кейсы,
- regression‑страховки.
Не все тесты глубокие, но широкое покрытие сильно снижает риск регрессий, особенно в быстро растущем коде.
- Реакция на CI и ошибки.
Codex отлично справляется с задачей:
- «вот логи падения CI, исправь»,
- сам предлагает патч, перепроверяет.
- Параллельные ветки разработки.
Команда держала несколько параллельных сессий Codex:
- одна сессия — плеер,
- другая — поиск,
- третья — обработка ошибок,
- четвёртая — тесты/рефакторинг.
Это уже похоже не на «один инструмент», а на маленькую распределённую команду.
- Исследование и новые решения.
В обсуждениях дизайна команды использовали Codex как «research‑агента»:
- тот обходит SDK и документацию,
- предлагает неожиданные варианты оптимизаций (например, по памяти),
- поднимает потенциальные проблемные точки.
Для инженеров это — ускоренный «ресёрч», который они бы сами не успели проделать.
5. Архитектура прежде всего: почему 85% кода от ИИ не развалились
Ключевой принцип, который OpenAI подчёркивает:
«Наша задача — не как можно быстрее получить что‑то работающее, а получить что‑то, что работает по правилам».
Поэтому:
- архитектура приложения,
- модули, зависимости, DI,
- навигация, аутентификация, базовая сеть
— были заложены руками людей. Это — фундамент, на котором уже можно было безопасно дать Codex развернуться на «85% кода».
Эксперимент «давайте просто скажем Codex: "сделай Android‑версию по образцу iOS"» закончился предсказуемо:
- «технически работает»,
- UX — неприемлем,
- структура — хрупкая и трудноподдерживаемая.
Вывод: Codex хорошо работает, когда:
- есть ясные, качественные примеры (iOS‑код, backend),
- есть чётко заданные паттерны и стандарты,
- есть ограниченный и понятный sandbox, в котором он может свободно генерировать.
6. Планирование → затем код: как научить ИИ работать «в долгую»
Чтобы Codex мог:
- долго выполнять сложную задачу,
- не теряя нить в огромном контексте,
команда изменила рабочий процесс:
- Сначала — понимание.
Codex читает набор файлов и сам объясняет, что делает существующая система:
как данные идут от API до Repository → ViewModel → UI. - Потом — совместный план.
Инженеры и Codex формируют «мини‑дизайн‑док»:
- какие файлы меняем,
- какие новые состояния / сущности вводим,
- какой поток данных.
- Только затем — реализация.
Codex пошагово реализует план. - Память между сессиями.
Для очень длинных задач:
- план сохраняется в файл,
- в новых сессиях подключается тот же файл,
- контекст и намерения сохраняются даже при ограничении окна.
Эта схема даёт:
- понятную точку для ревью (можно проверять соответствие кода плану),
- удобный дебаг (сначала отлаживаешь план, потом реализацию),
- возможность долго оставлять Codex «работать один», не боясь полного отрыва от задачи.
7. «Кросс‑платформенный фреймворк» на базе Codex
Самая забавная шутка команды OpenAI:
«Мы переизобрели кросс‑платформенный фреймворк, забыли React Native и Flutter: будущее кросс‑платформы — это Codex».
Под шуткой — два реальных принципа:
- Логика переносима, язык — вторичен.
Бизнес‑логика, модели, валидации, правила — одинаковые, что на Swift, что на Kotlin.
Codex умеет:
- читать Swift‑реализацию,
- писать семантически эквивалентный код на Kotlin.
- Примеры > описаний.
Ему гораздо проще:
- посмотреть, как фича реализована на iOS,
- понять Android‑архитектуру,
- и перенести поведение,
чем пытаться «с нуля» реализовать по текстовому описанию.
Практически:
- iOS, backend и Android‑репозитории лежали вместе,
- в AGENTS.md описано, где что находится,
- промпт выглядел как:
«прочитай модели и эндпоинты в iOS, составь план реализации на Android с использованием имеющихся API‑клиентов».
Результат:
- Codex выступает как «живой мост» между платформами,
- снижая стоимость поддержки мультиплатформы.
8. Codex внутри OpenAI: ИИ, который помогает улучшать самого себя
Интересная деталь: внутренняя роль Codex в OpenAI уже:
- ~70% всех PR каждую неделю проходят с его участием,
- он пишет не только продуктовый код, но и research‑harness’ы, тестовые каркасы, инфраструктурные скрипты,
- его используют для мониторинга собственного обучения: он анализирует логи, результаты, помогает настраивать пайплайны.
Фактически выстраивается полурекурсивный контур:
- Люди проектируют архитектуру и цели Codex.
- Codex пишет код, который:
- расширяет его же инфраструктуру,
- улучшает его тестовые и обучающие пайплайны.
- Новый Codex обучается уже с учётом этих улучшений и пишет другой, более качественный код.
Это не «полная автоэволюция», но уже реальный пример AI‑системы, помогающей самоё себя улучшать под контролем людей.
9. Как меняется роль инженера: от «того, кто пишет» к «тому, кто решает»
Выводы OpenAI из Sora‑кейса:
- «AI‑кодер» не снижает требовательность к инженерии — наоборот, вынуждает быть строже к архитектуре, стилю и процессам.
- Роль разработчика смещается от:
- «писать руками каждую строчку»
к
- глубокому пониманию системы,
- постановке задач ИИ,
- валидации и интеграции результата,
- структурированию кода и эволюции архитектуры.
Рабочий день становится скорее днём тимлида/архитектора, чем «джуниора за клавиатурой»:
- несколько параллельных Codex‑сессий, как несколько джунов;
- каждому нужно:
- объяснить задачу,
- задать рамки и стандарты,
- принять/отклонить результат.
Сама разработка превращается в «оркестровку»:
меньше — про набор текста, больше — про принятие решений, ревью и управление изменениями.
10. Что это означает для индустрии
История Sora для Android — не универсальный рецепт, но это первый масштабный полевой отчёт, что:
- 80–90% кода сложного продакшн‑приложения вполне реально отдать ИИ,
- при условии, что люди держат в руках архитектуру, стандарты и продуктовое видение,
- и умеют построить правильный «контур взаимодействия» с моделью.
Для будущего разработчиков это задаёт новую норму:
- «суперсила» инженера — не скорость ручного набора,
а глубокое системное мышление и умение вести долгосрочный диалог с ИИ о коде и системе. - команды будут становиться меньше по числу людей, но плотнее насыщены ИИ‑агентами.
- классический закон Брукса никуда не девается —
просто в роли «дополнительных людей» теперь выступают ещё и Codex‑подобные модели.
OpenAI честно признаёт: их практика — не серебряная пуля и не финальная форма AI‑разработки. Но именно такие кейсы постепенно превращают лозунг «ИИ пишет ИИ» из маркетинга в рабочий стандарт.
А дальше вопрос уже не в том, заменит ли Codex программистов, а в том, какие именно программисты смогут эффективно работать в мире, где у каждого есть свой Codex.
Хотите создать уникальный и успешный продукт? СМС – ваш надежный партнер в мире инноваций! Закажи разработки ИИ-решений, LLM-чат-ботов, моделей генерации изображений и автоматизации бизнес-процессов у профессионалов.
ИИ сегодня — ваше конкурентное преимущество завтра!
Тел. +7 (985) 982-70-55
E-mail sms_systems@inbox.ru
Сайт https://www.smssystems.ru/razrabotka-ai/