[Перевод] Как устроен Codex

Подробный разбор того, как команда OpenAI Codex создаёт своего кодового агента, как его используют инженеры и что это может значить для будущего разработки ПО.

Лично я проникся этим ассистентом после записи подкаста The Pragmatic Engineer с Петером Штайнбергером, создателем OpenClaw, в котором тот рассказал, что пишет весь код OpenClaw с помощью Codex. Кстати, в понедельник Петер объявил, что присоединяется к OpenAI для работы над агентами нового поколения. Это серьёзная победа для OpenAI, при этом OpenClaw остаётся независимым проектом с открытым исходным кодом. Послушайте мой подкаст с Петером — его первое подробное интервью, записанное примерно тогда, когда OpenClaw (тогда ещё Clawd) набирал огромную популярность.

Чтобы разобраться, как устроен Codex, как команды внутри OpenAI его используют и как он влияет на инженерные практики у создателей ChatGPT, я поговорил с тремя сотрудниками OpenAI:

• Тибо Соттио (Thibault Sottiaux) — руководитель Codex.

• Шао-Цянь Ма (Shao-Qian (SQ) Mah) — исследователь в команде Codex, обучающий модели, на которых тот работает.

• Эмма Тан (Emma Tang) — руководитель data-инфраструктуры; она не входит в команду Codex, но её команда активно им пользуется.

В этом разборе:

1. Как всё начиналось. От внутреннего эксперимента в конце 2024 года до продукта, которым пользуется больше миллиона разработчиков.

2. Технологические и архитектурные решения. Почему Rust и open source? Подробно о том, как работает агентный цикл.

3. Как Codex создаёт сам себя. По оценкам команды, более 90% кода приложения написано самим агентом. А ещё: интересные инженерные практики — как проводят код-ревью, самотестирование Codex и онбординг новых инженеров.

4. Исследования. Обучение следующей модели с помощью текущей и параллели с разработкой ПО. Запуск eval'ов, A/B-тестирование и внутренний догфудинг (использование сотрудниками собственных наработок в повседневной работе — прим. перев.).

5. Использование Codex в OpenAI. Команда Эммы по работе с данными создала внутреннего «дата-агента» за два месяца — раньше на это ушло бы больше года. Количество PR стало таким, что традиционный процесс ревью начинает трещать по швам.

6. Как меняется разработка ПО в OpenAI. «Правило 30/70», возвращение некоторых инженеров к автодополнению по Tab и значение «инженерного вкуса» (в оригинале просто taste. «Инженерный вкус» или «чутьё», наверное, звучит понятней. Дальше по тексту просто «вкус» — прим. перев.).

7. Дальнейшие планы. Качественный скачок с GPT-5.2, потенциал неиспользованных возможностей и куда движется Codex.

На прошлой неделе на дебютном Pragmatic Summit в Сан-Франциско состоялась беседа у камина с Тибо, мной и аудиторией, где были раскрыты новые подробности об устройстве Codex.

Тибо, руководитель Codex в OpenAI (слева), и Виджай Раджи, CTO по приложениям в OpenAI (в центре), на сцене первого Pragmatic Summit в Сан-Франциско.

Давние читатели могут вспомнить подробный разбор под названием Как устроен Claude Code, основанный на интервью с инженерами-основателями Claude Code. Некоторые параллели с сегодняшней темой очевидны: и Codex, и Claude Code сделали ставки, которые, похоже, окупаются. Поначалу я был скептически настроен, когда общался с командой Codex в октябре прошлого года, потому что подход с облачными долгими (long-running) задачами мне не откликался. Но теперь я изменил мнение.

1. Как всё начиналось

В 2024 году OpenAI экспериментировала с различными подходами к созданию программного агента. Осенью компания объявила, что создание aSWE (автономного инженера-программиста) станет главной целью на 2025 год. Этот замысел исходил от руководства: Грег Брокман и Сэм Альтман были убеждены, что рядом с командами должен работать автономный инженер-программист. Тибо описывает ход мыслей:

В проект были привлечены несколько человек, работавших над более ранними прототипами:

• Майкл Болин — техлид репозитория Codex с открытым исходным кодом.

• Габриэль Пил — впоследствии практически в одиночку создал расширение для VS Code и заложил фундамент десктопного приложения Codex.

• Фуад Матин — руководил первым релизом Codex CLI и отвечает за подход агента к безопасности.

В OpenAI две команды занялись разными аспектами задачи: Codex Web сфокусировалась на асинхронном облачном решении, а Codex CLI — на итеративной локальной разработке. Оба продукта были запущены весной: Codex CLI анонсировали в апреле 2025 года, а Codex в ChatGPT представили в мае.

2. Технологические и архитектурные решения

Очевидное различие между Codex и Claude Code — язык программирования. Claude Code написан на TypeScript, «on distribution», что играет на сильных сторонах модели (Видимо, имеется в виду, что Claude лучше пишет на TypeScript, чем на Rust и для разработчиков это плюс. Прим. пер.). Тем временем Codex CLI написан на Rust. Тибо объясняет почему:

• Производительность: мы хотим в перспективе запускать этого агента в огромном масштабе, где важна каждая миллисекунда. Производительность также важна при локальном запуске в песочнице.

• Корректность: мы хотели выбрать язык, который помогает исключить целый класс ошибок благодаря строгой типизации и управлению памятью.

• Инженерная культура и качество кода: есть интересный эффект от выбора языка — он задаёт планку для инженерного качества. Мы выбрали Rust, потому что для ядра нашего агента критически важно максимальное качество реализации».

Был и практический аргумент — зависимости. Выбор TypeScript означает использование npm. А npm нередко тянет за собой пакеты, устройство которых не до конца понятно, — что явно может быть проблемой. Выбрав Rust, команда обходится минимальным количеством зависимостей и может тщательно проверить каждую из них.

Кроме того, в перспективе команда хочет запускать агента Codex в самых разных окружениях — не только на ноутбуках и в дата-центрах, но и, например, на встраиваемых системах. С точки зрения производительности Rust делает это более достижимым, чем TypeScript или Go.

Тибо рассказывает, что на начальном этапе производительность разработки на Rust уступала TypeScript, но они рассчитывали, что модель это наверстает. Кроме того, Rust давал дополнительный инженерный вызов. Команда Codex также наняла автора Ratatui — Rust-библиотеки для создания терминальных интерфейсов (TUI). Теперь он работает в команде Codex на полную ставку, занимаясь open source.

Ядро агента и CLI полностью открыты на GitHub.

Как работает Codex

Основной цикл — это конечный автомат, а агентный цикл — центральная логика Codex CLI. Этот цикл оркестрирует взаимодействие между пользователем, моделью и инструментами, которые модель использует. Такой «агентный цикл» лежит в основе любого ИИ-агента, не только Codex. Вот как Codex реализует его на верхнем уровне:

Как работает Codex, верхнеуровневая схема

1. Сборка промпта: агент берёт пользовательский запрос и формирует промпт для модели. Помимо запроса промпт включает системные инструкции (стандарты кодирования, правила), список доступных инструментов (включая MCP-серверы) и собственно входные данные: текст, изображения, файлы, содержимое AGENTS.md и информацию о локальном окружении.

2. Инференс: промпт преобразуется в токены и подаётся модели, которая в потоковом режиме возвращает события: шаги рассуждений, вызовы инструментов или ответ.

3. Ответ:

   • Ответ транслируется пользователю через отображение в терминале.

   • Если модель решает использовать инструмент, выполняется соответствующий вызов: чтение файла, выполнение bash-команды, написание кода. Если команда завершается с ошибкой, сообщение об ошибке передаётся обратно модели, та пытается диагностировать проблему и может решить повторить попытку.

4. Ответ инструмента (опционально): если инструмент был вызван, его ответ возвращается модели. Шаги 3 и 4 повторяются, пока нужны дополнительные вызовы инструментов.

5. Ответ ассистента: «финальное сообщение», предназначенное пользователю, завершает один шаг цикла. Затем цикл запускается снова со следующим запросом от пользователя.

Сжатие контекста — важная техника для эффективной работы агентов, ведь по мере работы контекстное окно быстро заполняется. Когда сессия превышает определённое количество токенов, Codex обращается к специальному эндпоинту Responses API, который генерирует сжатое представление истории разговора. Это представление заменяет старый ввод и позволяет избежать квадратичного роста затрат на инференс. О том, как self-attention масштабируется квадратично, мы рассказывали в нашем разборе архитектуры ChatGPT за 2024 год.

Безопасность — важный аспект, учитывая недетерминированность LLM. Codex работает в песочнице, которая по умолчанию ограничивает доступ к сети и файловой системе. Тибо размышляет об этом выборе:

Новые версии выходят несколько раз в неделю. Внутри команды новая версия Codex выкатывается до трёх-четырёх раз в день. Внешние релизы выходят каждые несколько дней и распространяются через пакетные менеджеры, Homebrew и npm.

Недавний пост Майкла Болина «Разворачиваем агентный цикл Codex» подробно описывает внутреннее устройство агентного цикла.

3. Как Codex создаёт сам себя

По оценкам команды более девяноста процентов кода приложения Codex сгенерировано самим Codex и это примерно совпадает с тем, что Anthropic сообщает о Claude Code, со слов его создателя Бориса Черни, рассказавшего мне об этом. Обе ИИ-лаборатории разделяют эту метацикличность — использование инструментов для написания кода для создания самих себя.

Тибо рассказывает, что типичный инженер в команде Codex параллельно запускает от четырёх до восьми агентов, каждый из которых выполняет одну из множества задач:

• Реализация фич

• Код-ревью

• Ревью безопасности

• Изучение кодовой базы

• Анализ планов и подготовка саммари

• Обзор того, что сделали коллеги, и обобщение изменений

• Исправление багов

• … и многое другое.

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

Часто используемые «навыки»

Agent Skills — это способ расширить возможности Codex специализированными навыками; концепция практически идентична навыкам Claude Code. Внутри команды Codex создано более 100 навыков, которыми можно обмениваться и выбирать нужные. Три интересных примера:

• Security best-practices skill: подробное описание всех практик безопасности, принятых в команде. При вызове Codex проходит по каждому пункту, проверяет код и фиксит его.

• “Yeet” skill берёт коммиты, пишет описание pull request'а и заголовок на основе исходного плана и создаёт черновик pull request'а за один шаг.

• Datadog integration skill: Codex подключается к Datadog (система мониторинга — прим. перев.), анализирует алерты и инциденты, находит проблемы и пытается сгенерировать исправление.

Тибо воспринимает навыки как инструмент, направляющий модель к более специфичному поведению, причём навыки можно комбинировать. Навыки постоянно публикуются внутри компании, и члены команды копируют их друг у друга.

Многоуровневое код-ревью

Команда настроила ИИ-ревью кода, которое работает постоянно. Для код-ревью была обучена специализированная модель, оптимизированная на соотношение сигнала к шуму. Примерно девять из десяти комментариев указывают на реальные проблемы, говорит Тибо, это на уровне человеческих ревьюеров или чуть лучше. ИИ-ревью запускается автоматически при переводе пулл-реквеста из состояния «draft» в «in-review» через GitHub webhook.

После ИИ-ревью возможны два варианта:

• Некритичный код: можно мержить без дополнительного ревью человеком. Для некритичных частей кода, где скорость важнее идеала, инженер, запускающий агента, может решить вмержить код после ИИ-ревью, если считает его годным.

• Ключевые части кодовой базы: обязательное ревью человеком. Для ключевых частей — ядра агента и компонентов с открытым исходным кодом — команда настаивает на тщательном кожаном ревью.

Другие инженерные практики команды

Вот ещё практики, которые Тибо считает полезными для команды:

• AGENTS.md. Инструкции, хранящиеся внутри репозитория. В команде Codex эти файлы объясняют агенту, как ориентироваться в кодовой базе, какие команды запускать для тестирования и как следовать стандартам проекта. Это нечто вроде README-файлов, но написанных для ИИ-агентов, а не для людей. Agents.md стал де-факто стандартом среди агентов, и единственный крупный агент, который его не использует, — Claude Code. (Claude Code действительно не читает этот файл по умолчанию, но всегда ожидает файл CLAUDE.md. В этом файле можно написать '@AGENTS.md и он тоже всегда будет считываться — прим. перев.).

• Структурировать код для агентов: пишите тесты! (Этот совет разработчики дают друг другу на протяжении всей карьеры — прим. перев.) Команда целенаправленно структурировала кодовую базу так, чтобы «модель неизбежно добивалась успеха». Структурирование означает наличие тестов, чёткие границы модулей и инструкции для модели по запуску валидации (тесты, линтинг и т. д.). Когда модель реализует что-то неправильно, тест падает, агент это замечает и пытается разобраться, что пошло не так. Поскольку модель обучена быть настойчивой, она продолжает попытки, пока не добьётся результата. Задачи могут выполняться 20–30 минут, а иногда и час.

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

• Ночные запуски Codex для генерации предлагаемых исправлений. Команда настроила ночные запуски Codex с инструкцией искать проблемы в коде. Каждое утро инженеры просматривают найденные проблемы, к которым уже готовы исправления на ревью.

• Онбординг в команду Codex через парную работу. Новичков просят сохранять открытость к тому, как устроена разработка в команде Codex, и предупреждают, что процесс создания ПО здесь отличается от большинства других мест. Новый сотрудник работает в паре с инженером из команды и в первой половине дня наблюдает за его процессом разработки с Codex. Во второй половине дня ему дают задачу, и ожидается, что он выкатит её в продакшн в тот же день.

• Безлимитное использование Codex. Для контекста: сотрудники OpenAI — так же, как и в Anthropic — не имеют ограничений на использование LLM. Это логично, учитывая, что они создают инструмент, которым хотят, чтобы клиенты пользовались как можно больше. Тем не менее это контрастирует с компаниями, не занимающимися ИИ. Имейте это в виду, когда мы будем разбирать работу команды.

Использование Codex для отладки Codex

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

Это ещё один пример метацикличности — Codex отлаживает сам себя, или, как минимум, системы, которые им движут!

4. Исследования

Codex создаётся не только инженерами, но и исследователями, один из которых — SQ Ma. Ему удалось перейти из инженерии в исследования благодаря участию в Vesuvius Challenge — проекте по расшифровке обугленных свитков тысячелетней давности из древнеримских Помпей, погребённых катастрофическим извержением Везувия в 79 году н. э. SQ занял второе место, арендуя GPU в Google Cloud, обучая модели и превращая исследовательские идеи в работающие алгоритмы.

Так что же такое «исследования» в OpenAI? Вот что говорит SQ:

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

• Базовая модель обучается на огромном объёме данных.

• В процессе обучения модель усваивает общие паттерны языка — как слова сочетаются друг с другом, как выражаются идеи, как строится рассуждение, — формируя общее представление о мире.

• Затем команда SQ дообучает её для задач программирования и веб-разработки. Они обучают модель тому, как выглядит «красивый» код, каким должно быть production-качество приложений и как делать вещи визуально привлекательными.

Обучение модели имеет параллели с разработкой ПО. Полный цикл обучения, от старта до деплоя, занимает пару месяцев. Команда SQ участвует на всех этапах:

• Планирование: определение целевых показателей модели и приоритетных возможностей

• Непосредственно запуск обучения

• Деплой модели

• Интеграция новой модели с инженерной командой Codex.

Исследовательская команда использует процессы, схожие с классической разработкой ПО:

• Запуск eval'ов работает как непрерывная интеграция (CI) для отслеживания регрессий и улучшений

• A/B-тестирование: используется при раскатке моделей

• Внутренний догфудинг: обязательно проводится перед внешним релизом.

Одна из уникальных особенностей обучения моделей — доставка модели конечным пользователям в виде двух артефактов:

• Сама модель — которая «статична» в том смысле, что не может быть изменена после релиза

• Обвязка (harness): окружение, в котором модель работает, включая начальный промпт. Обвязку можно менять в любое время

Если модель показывает слабые результаты в какой-то области, исправлением может быть изменение части промпта. Это достаточно частая ситуация, когда eval'ы указывают на проблемы; в таких случаях исследователи и инженеры совместно правят промпт обвязки.

SQ не писал код руками уже 4–5 месяцев. Его работа — обучать и создавать следующую версию Codex, и для этого он использует предыдущую. Он создаёт два типа кода:

• Код для eval'ов: дашборды и инструменты визуализации для анализа того, как работает модель и чему она учится.

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

GPT-5.3 Codex, выпущенная две недели назад, — первая модель, которая сыграла ключевую роль в собственном создании. Команда использовала ранние версии для отладки обучения, управления деплоем и диагностики нестабильностей в ходе обучения.

К слову, использование инструмента для создания другого инструмента — не совсем новинка: именно так создавались большинство языков программирования. Например, компилятор языка C был написан на C, а переписывание компилятора Rust на Rust — давняя традиция. Обе ситуации аналогичны тому, что делает команда Codex.

5. Использование Codex в OpenAI

Помимо самой команды Codex, как другие команды в OpenAI работают с ним? Чтобы это выяснить, я поговорил с Эммой Тан, которая работает в компании три года. Её команда создала популярного внутреннего «дата-агента», позволяющего инженерам и исследователям OpenAI быстро получать аналитику, строить графики и посылать сложные запросы к внутреннему хранилищу данных.

До OpenAI Эмма четыре года работала в Stripe, руководя data-инфраструктурой. Она рассказывает, что без ИИ-инструментов создание этого дата-агента заняло бы вечность:

Вот как эта команда использует агент:

Семьдесят процентов кода написано Codex. Это ниже, чем ~90% в команде Codex, но всё равно внушительная доля.

«MCP-фицировали» внутренние инструменты (MCP — Model Context Protocol), которыми они владеют, чтобы Codex мог проще их использовать. Команда Эммы создала MCP-обёртки вокруг своих инструментов, таких как:

• Хранилище метаданных data lake, включающее историю запросов, информацию о таблицах и человеческие аннотации.

• Доступ к Apache Airflow (Airflow — платформа для управления процессами data engineering пайплайнов).

• Доступ к наборам данных Delta Lake.

С этими MCP-сервисами инженеры могут выбирать, как валидировать свою работу:

• Запускать пайплайны вручную, как раньше

• Позволить Codex валидировать их работу, запуская MCP-сервисы, выполняющие те же пайплайны

Создали MCP-сервер для дата-агента. Простой сценарий: внутренние пользователи OpenAI могут подключаться к дата-агенту через MCP с помощью Codex. Настройка пока полуавтоматическая, но работает и пользуется популярностью внутри компании.

Проблема с pull request'ами для дата-агента

Команда Эммы столкнулась с той же проблемой pull request'ов, которую Петер Штайнбергер описал в своём выступлении на The Pragmatic Engineer Podcast: самого кода недостаточно, чтобы оценить качество pull request'а, — нужно также знать намерение и промпт, который был использован.

Эмма объясняет:

Есть все основания полагать, что множество инженерных команд столкнётся с этой же проблемой: при работе с ИИ-сгенерированным кодом нужно ревьюить промпт, а не только код. Именно поэтому Meta добавила фичу «траекторий» поверх существующего процесса код-ревью, и именно поэтому The Pulse освещал, как эта проблема распространяется по индустрии.

6. Как меняется разработка ПО в OpenAI

Ещё несколько месяцев назад инженеры OpenAI писали большую часть кода руками, но сегодня 50–90% генерируется Codex. Так как же меняется роль? Вот что говорят Тибо, SQ и Эмма:

Одни инженеры осваивают быстрее

Эмма наблюдает разный спектр реакций среди коллег:

Некоторые инженеры используют «правило 30/70»: 30% кода пишут руками, а 70% генерирует Codex. Эти 30% — осознанный выбор, потому что это заставляет думать, сохранять связь с кодовой базой и тренировать инженерное чутьё.

Часть инженеров вернулась к автодополнению по Tab. Один инженер OpenAI отключил полное автодополнение Codex и снова включил Tab-completion в IDE, чтобы заставить себя больше думать и лучше понимать происходящее.

Читаемость вызывает беспокойство, делится Эмма:

Отрадно, что даже в OpenAI не нашли «единственно верный способ» работы с Codex. Каждый инженер подходит к нему по-своему, и не все делегируют инструменту всё подряд — но при этом пользуются им все.

«Вкус» становится ключевым навыком

Тибо, Эмма и SQ независимо друг от друга называют «вкус» самым важным качеством для инженера-программиста в новой реальности.

Эмма говорит напрямую:

Тибо говорит, что самые успешные инженеры в его команде сместили фокус и попутно развивают вкус:

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

Он считает, что за инженерами и исследователями остаются решения:

• Архитектура систем и проектные решения

• Понимание человеческих потребностей, определяющих требования к системам

• Предвидение изменений — новых регуляций и бизнес-трансформаций.

Всё вышеперечисленное — то, чего модель не может, потому что ей недоступен контекст человека, живущего в реальном мире.

Новый «10x-инженер» ('10x-engineer', оставил как в оригинале. Можно читать как «инженер будущего» — при. перев.) обладает отличным вкусом. Эмма говорит, что планка для 10x-инженера изменилась:

Её вывод:

Я спросил, какой совет она дала бы тому, кто в начале карьеры, по развитию вкуса. Она ответила:

Продуктивность, похоже, растёт

Эмма говорит, что, несмотря на различия в подходах к использованию Codex, скорость работы по всей команде выросла по сравнению с прошлым годом. Они выпускают больше и быстрее, и признаков замедления нет.

На мой взгляд, OpenAI всегда отличалась высокой скоростью разработки. В 2023 году — ещё до появления самой идеи Codex — я задавался вопросом, как OpenAI удаётся так быстро выпускать продукты. Полагаю, что небольшие автономные команды, не обременённые процессами, были тогда ключевым фактором. Codex теперь делает эту скорость ещё выше.

7. Дальнейшие планы

Я спросил Тибо о дорожной карте проекта, и он раскрыл подробности новых приоритетов:

Десктопное приложение Codex. Новое macOS-приложение было запущено в первую неделю февраля и позволяет управлять несколькими агентами, работающими в отдельных потоках, организованных по проектам. За первые три дня OpenAI зафиксировала более миллиона загрузок приложения Codex, и первые отзывы позитивные.

GPT-5.3-Codex: более мощная модель. На той же неделе OpenAI выпустила новую, более умную модель для программирования, особенно для объемных и длительных задач. Теперь эта модель используется по умолчанию в терминале и десктопном приложении.

Инструменты для профессиональных инженеров-программистов. На данный момент команда Codex смотрим в первую очередь в сторону профессиональных инженеров. Десктопное приложение, CLI, расширение для VS Code — всё это нацелено на продуктовых инженеров. Тибо говорит:

Помню, что Anthropic тоже начинала с инструментов для профессиональных разработчиков, и, похоже, OpenAI считает это верной стратегией — теперь они удваивают ставки.

У команды Codex есть амбиции и за пределами создания инструментов для профессиональных инженеров, говорит Тибо:

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

• Доказательство выполненной работы. Вместо ревью каждой строки вывода модель должна уметь доказать, что она сделала то, что было запрошено. Таким доказательством могут быть результаты тестов, видеозаписи или формальная верификация — но ключевая идея в снижении нагрузки на людей-ревьюеров.

Выводы

Огромное спасибо команде Codex за то, что приоткрыли завесу над своей работой. У ИИ-лабораторий повсюду достаточно стимулов активно использовать собственные продукты и преувеличивать их возможности для внешнего мира, но то, что я нашёл в OpenAI, оказалось более взвешенным, чем я ожидал.

Стоит помнить, что это команда без каких-либо ограничений на потребление токенов. Обычно компании следят за этими расходами и сокращают их, когда те выходят за рамки, но за исключением нескольких компаний, включая OpenAI и Anthropic, большинство устанавливают лимиты.

Степень использования ИИ также разнится даже внутри мировой ИИ-лаборатории, коей является OpenAI.

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

Неудивительно, что инженеры в самой команде Codex пишут почти весь код с помощью промптов, но в других командах компании эта доля значительно ниже — около 70%, и растёт.

Тем временем, когда часть людей использует агентов непрерывно, появляются новые инженерные подходы. Интересные находки из OpenAI:

• Навыки, передаваемые между командами: полезные навыки распространяются для использования с агентами. На мой взгляд, эти навыки похожи на API-обёртки или упакованные промпты.

• Многоуровневое код-ревью: менее важный код ревьюится только ИИ, тогда как критический код обязательно проходит и человеческое ревью.

• Агенты, запускающие свои тесты: одна из завораживающих возможностей Codex — агент может валидировать собственную корректность, запуская собственный набор тестов. Звучит немного фантастически, но в этом есть логика.

Тестирование приобретает всё большее значение в эпоху агентной разработки. Codex используют миллионы инженеров, поэтому он должен работать корректно. Но не весь код, попадающий в Codex, ревьюится человеком — часть мержится после ИИ-ревью. Именно валидация агентом собственной работы через запуск тестов делает это возможным.

У меня складывается ощущение, что это — проблеск будущего ПО, создаваемого ИИ: валидация может стать важнее самого сгенерированного кода.

Pull request'ы уже начинают «ломаться». В OpenAI команды ощущают боль от отсутствия доступа к промпту, использованному для генерации pull request'а, и применяют самодельные обходные решения. Сама концепция pull request'ов может быть готова к переосмыслению, и, возможно, появится новый инфраструктурный слой.

Тем временем «вкус» становится отличительным качеством инженера-программиста. В OpenAI все говорят о вкусе, но дать ему определение сложно. В данном случае, похоже, это сочетание достаточного опыта, чтобы распознавать хорошее решение, инженерного чутья, чтобы замечать, когда ИИ-сгенерированный код неоптимален, и заинтересованности в том, чтобы это исправить.

Надеюсь, вам понравился этот подробный разбор одного из ведущих кодовых инструментов на сегодняшний день. Спасибо за внимание.