Building Codex with Tibo Sottiaux Ведущий: Гергей Орос
Конспект интервью, опубликованного 9 сентября 2026 года. Описания внутренних процессов и оценки результатов передают рассказ Тибо.
Суть интервью
Надёжный агент требует работы вокруг модели
Команда Codex одновременно улучшает модель, инструменты и способ разработки самого продукта. Эти части меняются с разной скоростью: временное правило в среде выполнения можно убрать, когда модель научится нужному поведению.
ЯДРО
Отделить агента от интерфейса
Общее ядро должно поддерживать разные продукты. Rust помогает проверять ограничения до запуска программы.
До OpenAI Тибо работал в Google: над ускорением мобильного веба, отзывами в Google Maps и инструментами исследователей DeepMind. Закрытие первого проекта научило его проверять реальную востребованность продукта. В OpenAI его привлекла тесная связь исследований и разработки продукта. 07:20 ↗13:00 ↗
Ранние внутренние агенты работали с Python-кодовой базой OpenAI. Команда учила их учитывать стиль и архитектурные решения существующего проекта. В дальнейшем эта исследовательская работа соединилась с проектом AS3.
Тибо описывает ранний облачный Codex как продукт с избыточным трением для пользователя. Способ взаимодействия с агентом пришлось искать через итерации; качество модели само по себе ещё не обеспечивало удобный рабочий процесс.
Для ядра выбрали Rust: на масштабе важны эффективность, безопасность и проверки на этапе компиляции. По словам Тибо, строгие ограничения полезны и агенту, который пишет код.
Граница важнее первоначального языка
Тибо допускает, что Python или TypeScript тоже позволили бы построить успешный продукт. Но ожидает, что позднее команде пришлось бы переписать ядро.
Главное архитектурное решение в его рассказе: не переплетать логику агента с конкретным интерфейсом. Иначе новый способ взаимодействия с Codex потребует переделывать внутреннее устройство.
Пользователь должен иметь возможность сменить модель
Сообщество получает доступ к устройству агента
Открытый репозиторий позволяет направить Codex на его собственный код: разобраться в поведении, предложить исправление и обсудить изменение. Новый сотрудник может прийти в команду уже знакомым с кодовой базой и процессом внесения изменений.
У открытости есть цена. Команда проводит дополнительные границы между публичным и внутренним кодом, раньше показывает возможности конкурентам и тратит время на некачественные внешние изменения.
Тибо считает бессмысленным удерживать пользователя запретом на внешнюю модель: небольшую интеграцию всё равно добавят в форке. Возможность переключиться сохраняет привычное окружение пользователя и даёт команде обратную связь о качестве моделей.
Команда хочет выигрывать за счёт качества модели, эффективности и продукта. В этой логике открытое сравнение с другими моделями полезнее технического ограничения выбора.
Harness здесь означает программную среду вокруг модели: цикл выполнения, инструменты, ограничения доступа и инструкции. По рассказу Тибо, Codex по умолчанию запускает инструменты локально в изолированной среде, а для выхода за разрешённые границы запрашивает согласие пользователя.
В облачном варианте используется управляемая виртуальная машина или контейнер Kata. Это освобождает ресурсы ноутбука и позволяет запускать больше работы, но усложняет доступ к локальному окружению. Команда рассчитывает, что агент со временем удешевит настройку и поддержку облачной среды разработки. Это её ожидание, а не доказанная стоимость эксплуатации.
Из чего складывается работа агента · Схема по объяснению Тибо
Это упрощённое разделение ролей. Среда исполнения даёт агенту доступ к инструментам и результатам их работы; правила доступа задаёт окружающее программное обеспечение.
Harness должен немного опережать модель: подсказывать недостающее поведение и обеспечивать управляемость. Пример Тибо: сначала модель нужно отдельно побуждать запускать тесты; после обучения такое напоминание становится лишним.
Поэтому длинное управляющее сообщение не считается накопленной ценностью само по себе. По мере улучшения модели его можно сокращать вместе с дополнительной логикой.
Разработчики обсуждают слабости с исследователями. Если модель скоро научится нужному поведению, дорогое обходное решение может не окупиться. Если улучшение далеко, проблему приходится решать в продукте.
Тибо называет горизонты в один, три и шесть месяцев для такого обсуждения. Это способ планировать работу, а не обещание конкретных релизов.
Человеческое ревью смещается к намерению изменения
Внутри OpenAI Codex работает не только с исходниками. По словам Тибо, агенту доступны рабочие обсуждения в Slack и документы, поэтому через него удобно находить объяснения решений и контекст задачи. В команде вошёл в привычку вопрос: «А ты спросил Codex?»
Этот способ работы зависит от доступа к знаниям. Один репозиторий не содержит всех договорённостей и причин, по которым система устроена именно так.
Проверки корректности и безопасности команда автоматизирует. Тибо говорит, что сигнал от проверки безопасности блокирует слияние изменения. При этом он предлагает обсуждать с людьми намерение, контракт и инварианты ещё до pull request, когда решение дешевле изменить.
Инварианты описывают условия, которые система обязана сохранять после изменения. Проверки кода полезны, но выбор самих условий остаётся частью инженерной работы.
Как меняется распределение работы · Схема по объяснению Тибо
Схема обобщает обсуждение, а не описывает обязательный регламент OpenAI. Предложение Тибо: переносить содержательную дискуссию о решении на более ранний этап.
Дешёвые изменения повышают ценность хороших границ
Тибо приводит пример обновления сторонней зависимости: при хорошем описании изменений и документации агент может пройти по кодовой базе и адаптировать места использования. Исправления безопасности и рутинную поддержку становится проще начать, когда не требуется столько ручной работы.
Для более крупных переделок он предлагает закреплять границы: контракт, потребление ресурсов, доступ к данным и безопасность. Внутри этих условий агент может менять реализацию с меньшим числом обсуждений. Плохие границы по-прежнему замедляют работу и заставляют затрагивать соседние сервисы.
Тибо предлагает мысленный пример: за выходные над системой начинают работать сто агентов. В такой ситуации абстракции, документация и границы модулей помогают удерживать изменения согласованными.
Это иллюстрация нагрузки на архитектуру, а не измеренный результат запуска ста агентов.
Общий продукт должен соединить локальную и облачную работу
В обсуждении объединения ChatGPT и Codex Тибо выделяет различие сред: Codex может работать на компьютере пользователя, а ChatGPT опирается на управляемую облачную инфраструктуру. Свести эти подходы означает также обеспечить сопоставимые возможности для сотен миллионов пользователей при приемлемой стоимости.
По его рассказу, Codex помогал команде строить инфраструктуру, согласовывать плагины и библиотеки, фиксировать обсуждения. Цель объединения он формулирует как доступ к возможностям без лишних ограничений со стороны выбранного режима работы.
Это личные примеры и ориентиры планирования из интервью, не сравнительные измерения производительности. Тибо диктует задачи в ChatGPT Work с телефона и настраивает навыки и инструкции для повторяющихся отчётов, слайдов и исследований.
Навигация по интервью
Вернуться к объяснению автора
Точки ниже совпадают с главами автора. Каждое время открывает соответствующий момент YouTube.
Инженерам, которые хотят работать с ИИ, Тибо советует развивать глубокое любопытство, быстро осваивать незнакомые системы и задавать хорошие вопросы. Технической подготовки недостаточно без понимания задач пользователей. 1:10:44 ↗
Отметки сохраняются в этом браузере, если локальное хранилище доступно.
