Руководитель продукта OpenAI Codex рассказывает: без стандартов и дорожной карты — как мы создавали продукт?

«Интерес и самостоятельность — самые ключевые и важнейшие качества для людей в эпоху AGI».

Собрано и отредактировано: Deep Tide TechFlow

Гости: Alex, руководитель продукта Codex; Romain, разработчик в части developer experience (DX) Codex

Ведущий: Peter Yang

Источник подкаста: Peter Yang

Оригинальное название: How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain

Дата выхода: 5 апреля 2026 г.

Ключевые тезисы

Alex — руководитель продукта Codex, а Romain отвечает за developer experience. Они позволили мне как редкий случай глубоко разобраться в том, как работает команда Codex: в том, как они используют Codex для создания продуктов, и как выпускают продукт без традиционных требований к продукту и без дорожной карты. Alex также поделился уникальными взглядами о том, как будет развиваться будущее product manager (PM), а также о том, какие факторы действительно важны при найме.

Краткое резюме ярких моментов

Построение в реальном времени и «скорость мышления» с Codex Spark

• «Когда ты хочешь что-то построить… ты можешь переключиться в быстрый режим, даже на Codex Spark — и у тебя появляется такая бешеная скорость мышления, чтобы построить что угодно. Слева GPT-5.4, справа Codex Spark, в среднем примерно 1200 токенов данных в секунду — это просто безумие». ——Romain

О спецификациях и процессе принятия решений

• «Я думаю, в команде Codex, где мы пишем документы-спецификации, очень-очень мало. На самом деле, я считаю, что основная работа — это обеспечить, чтобы люди, максимально близкие к практике, принимали как можно больше решений, поэтому мы пишем спецификации только тогда, когда проблема в итоге превращается в такую, которую невозможно “впихнуть” в голову одного человека». ——Alex

Размывание карьерных границ и эволюция дизайнеров

• «Сейчас наши дизайнеры пишут кода больше, чем инженеры шесть месяцев назад: фокус уже больше не на том, “получится ли сгенерировать код”. По-настоящему важно другое: что мы решим делать и как гарантировать высокое качество продукта. Вот почему для действительно сложных функций я больше склонен найти надежного владельца/ответственного руководителя, который будет этим управлять, а не отдавать это на product manager (PM) — чтобы PM отвечал за внедрение и сопровождение этих систем». ——Alex

Философия продуктового дизайна: сделать так, чтобы модель была «невидимой»

• «Мы очень осторожно проектируем ключевые функции, чтобы они не становились барьером между пользователем и моделью, а делали модель умнее и автоматически выполняли больше задач». ——Alex
• «Затем на этой основе мы думаем, как упаковать продукт для продвинутых пользователей максимально настраиваемым образом, чтобы они сами могли его исследовать и использовать. Например, сейчас уже есть пользователи, которые реализовали sub-agents (саб-агенты)». ——Romain

Философия планирования: отказ от “неловкости середины пути”

• «В OpenAI мы либо планируем краткосрочные цели, либо планируем долгосрочные, но никогда не делаем среднесрочное планирование, потому что среднесрочное планирование слишком сложно. Краткосрочное планирование обычно означает цели на срок до восьми недель с текущего момента; восемь недель — это самый длинный временной диапазон, который мы можем задать. Мы также формируем долгосрочное видение. Например, мы можем смотреть на будущее через год и представлять, что тогда модели станут умнее. Но среднесрочное планирование в такой ситуации выглядит немного неловко: оно обычно проявляется в виде подробной продуктовой дорожной карты, но в целом мы в основном этого не делаем. Мы больше опираемся на сочетание долгосрочного видения и фокусируемся на конкретных задачах, которые помогут нам двигаться к достижению целей». ——Alex

Изменения интерфейса, вызванные «делегированием умным агентам»

• «Кодирование будет происходить в формате “делегирования умным агентам” (agentic delegation). Тебе кажется странным, что в терминале открываешь несколько вкладок и даешь им работать по несколько часов — это очень необычная форма взаимодействия. Нам нужен совершенно новый интерфейс, и тот момент оказался как раз идеальным». ——Romain

Исчезновение карьерных ступеней и «коллапс talent stack»

• «Это почти размывает каждую традиционную карьерную лестницу продвижения. По сути, каждый из нас — “builder” (создатель), и все вместе мы координируем работу, чтобы выполнить построение. Если в стартапе есть PM, а инженеров меньше примерно 20 человек, это может быть опасным сигналом. Интерес и самостоятельность — самые ключевые и важнейшие качества для людей в эпоху AGI». ——Romain / Alex

Критерии найма: работы важнее резюме

• «Когда кто-то через direct message говорит, что ему интересно присоединиться к нашей команде, моя первая реакция — посмотреть, есть ли у него ссылки на работы. Если такие ссылки есть, я всегда их открываю, чтобы понять, правда ли он что-то строит: мне гораздо больше хочется видеть его идеи и то, что он реально построил. Я вообще не знаю, в какие университеты эти люди поступали». ——Alex

Демонстрация на месте: создание игры за несколько секунд с Codex Spark

Ведущий Peter: Я сегодня очень взволнован, потому что веду разговор с Alex и Romain — они из команды Codex в OpenAI. Сейчас они продемонстрируют, как построить новые функции Codex: какие возможности есть у Codex и как команда Codex постоянно выпускает продукты. Хотите, я быстро покажу, что вообще можно построить с помощью одноразового промпта (one-shot)?

Romain：

Конечно. Дайте мне показать экран. На самом деле, я могу показать очень много всего, но, возможно, достаточно быстро взглянуть — например, вот iOS-приложение, которое я постоянно разрабатываю. Если я хочу создать в этом приложении новую функцию, я могу просто продиктовать: «Эй, можешь добавить новый экран для миссии NASA по возврату на Луну?» Затем я отправляю этот промпт в GPT-5.4, и модель создаст новый экран именно для этого конкретного APP.

Но у нас есть и модель Codex Spark, которая помогает тебе за считанные секунды продумать и итеративно улучшить что угодно. Давайте покажу разницу в том, как Spark-модель отвечает быстро. Слева GPT-5.4, справа Codex Spark. Затем в среднем примерно 1200 токенов данных в секунду — это просто безумие. Поэтому когда ты хочешь что-то построить, например игру — прямо перед тем, как мы начали этот разговор, я на самом деле открыл приложение Codex и с помощью быстрого промпта создал небольшую 2D-игру, похожую на Animal Crossing.

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

Peter：Может, добавить больше декора — домики, деревья — чтобы она стала более живой?

Romain：

Тогда я отправлю это задание — и буквально за несколько секунд Codex Spark сделает правки. Мы увидим изменения в реальном времени — и готово: вот мы уже видим, что появились новые деревья.

Вот почему я так взволнован Codex: ты действительно можешь получить передовую модель уровня GPT-5.4, которая способна справляться с очень сложными задачами — например, анализом или миграцией миллионов строк кода. Но если у тебя возникла вдохновленность и при этом ясная мысль, ты можешь переключиться в быстрый режим — даже на Codex Spark — и тогда появляется такая бешеная скорость мышления, чтобы построить что угодно.

Для продуктовых спецификаций мы пишем примерно 10 пунктов — и всё

Ведущий Peter: Я правда очень хочу понять, как вы в команде на практике строите продукт с помощью Codex. Alex, вы пишете спецификации? Или вы заставляете GPT писать спецификацию? Какую модель вы используете, чтобы всё это работало?

Alex：

Я думаю, в команде Codex мы пишем документы-спецификации очень-очень мало. На самом деле, я** считаю, что основная работа — заставить людей, максимально близких к реальности, принимать как можно больше решений,** поэтому мы пишем спецификации только тогда, когда проблема в итоге превращается в такую, которую сложно “впихнуть” в голову одного человека. Кстати, сейчас один человек может уместить в голове очень многое — потому что он может переделегировать большую часть кодинга, поэтому одному человеку сейчас реально доступно больше. Но если в итоге всё превращается в задачу, где нужно координировать несколько людей, или, возможно, это очень сложное решение, которое мы должны принять, тогда, возможно, мы напишем спецификацию. Но в таких случаях документы обычно получаются очень-очень короткими. Мы говорим примерно про 10 пунктов — и всё.

Ведущий Peter: Хорошо. Можете показать мне, как это работает? Например, вы даете Codex несколько пунктов, а он, возможно, сначала пишет реальные требования?

Romain：

Конечно, можно! Но я сначала хочу показать вам более простой пример. Допустим, мы разрабатываем iOS-приложение, и оно уже завершило некоторые задачи. Сейчас у вас есть идеи для новой функциональности, но вы еще не уверены в конкретном направлении. В этот момент сильная сторона Codex как раз в том, что он помогает нам спланировать следующий шаг. Например, мне достаточно нажать Shift+Tab, чтобы войти в «плановый режим» (Plan Mode), и ввести «что мы собираемся построить» — и Codex автоматически сгенерирует черновой план. Он проанализирует текущую кодовую базу, поймет текущее состояние проекта и предложит несколько потенциальных идей. Параллельно я могу добавить свои мысли, направляя модель на генерацию более полноценного плана.

В процессе вы увидите, что Codex по текущему коду и файлам дает некоторые рекомендации. Например, он может спросить: «Стоит ли нам продолжать дорабатывать ранее упомянутую функцию? Или лучше оптимизировать надежностный дашборд (reliability dashboard)?» Если мы решим оптимизировать надежностный дашборд, он дальше будет направлять нас размышлять: кто целевые пользователи этой оптимизации? Весь процесс ощущается так, будто вы работаете вместе с партнером по мозговому штурму.

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

Alex：

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

Но, честно говоря, иногда я не использую напрямую решения, которые генерирует Codex — особенно когда изменения довольно сложные. Я исследую через «плановый режим» (Plan Mode), формирую ясную картинку, а затем делюсь этими идеями с командой инженеров. В итоге этот процесс мышления оказывается важнее, чем сам сгенерированный план.

Кстати, в нашей команде дизайнеры сейчас пишут кода больше, чем инженеры полгода назад — раньше это было просто немыслимо. Это в основном благодаря прогрессу инструментов: дизайнеры могут глубже вовлекаться в разработку. Но меня также часто поддразнивают, что в прошлом году я сдал слишком мало PR (запросов на слияние). Хотя многие изменения — это действительно небольшие правки, я всё-таки думаю, что мне стоит делать больше.

Теперь наш** фокус уже не на том, “можем ли мы сгенерировать код”,** потому что агентам (Agent) уже доступно выполнить большую часть задач по кодингу.** По-настоящему важно другое: что мы решаем делать и как обеспечить высокое качество продукта.** Вот почему для очень сложных функций я скорее предпочту найти надежного ответственного руководителя, а не поручать это product manager (PM) — отвечать за внедрение и сопровождение этих систем.

Дизайнеры пишут код больше, чем инженеры 6 месяцев назад

**Ведущий Peter: — Приложение Codex использовать очень интуитивно и просто. По сравнению с некоторыми профессиональными продуктами снаружи я думаю, что кривая обучения у Codex заметно ниже. Другие профессиональные продукты, даже если они мощные, требуют много времени на обучение. Я даже думаю, что если бы я не следил за этим в Twitter, я, возможно, вообще бы не понял, как ими пользоваться.

Но одна вещь, которая меня впечатлила в Codex: он не только прост и удобен, но и предлагает множество расширенных функций — skills (навыки) и automations (автоматизации). Вы внутри команды регулярно используете эти функции?**

Romain：

Да, мы используем их очень часто. На самом деле, я считаю, что skills — одна из самых интересных функций в приложении Codex. Например, сейчас если вы работаете вместе с дизайнером в Figma: просто откройте skill для Figma — и вы сможете напрямую извлечь все детали из файла Figma, включая React-компоненты, переменные и т.д., после чего Codex автоматически сгенерирует соответствующий код. Или, например, вы разрабатываете приложение и хотите поделиться им или развернуть его в Vercel, Cloudflare или Render: достаточно дать простую команду через skills, и Codex автоматически выполнит эти задачи.

Недавно я разговаривал с другом: он рассказал, что у него много идей, как улучшить продукт, и попросил Codex: «Запиши все эти задачи в Linear, чтобы мне было удобно отслеживать». Он использовал skill Linear. Затем он сказал Codex: «Я ложусь спать. Продолжай выполнять все задачи, о которых мы говорили, и помечай их как выполненные». А на следующий день, когда он проснулся, оказалось, что все задачи действительно выполнены.

Alex：

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

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

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

Romain：

Затем на этой основе мы думаем, как упаковать продукт для продвинутых пользователей максимально конфигурируемым образом — чтобы они сами могли исследовать и использовать. Например, сейчас уже есть пользователи, которые реализовали sub-agents (саб-агенты). Эти возможности не были тем, что мы целенаправленно проектировали: пользователи сами их находили и экспериментировали с ними. Наблюдая за тем, как пользователи используют эти функции, мы узнали многое.

Дальше мы подумаем: как сделать эти функции максимально простыми и для других пользователей? Приложение Codex — хороший пример. Где-то в декабре прошлого года, когда GPT-5.2 Codex вышел, способности модели начали постепенно стабилизироваться, но при этом модель также перешла критическую точку. Пользователи могли начать делегировать модели более длинные и сложные задачи, и модель могла выполнить их за один раз.

Мы начали замечать, что некоторые пользователи уже используют tmuxing — это способ запускать несколько параллельных задач в терминале, разделяя окна, чтобы всё работало одновременно. Мы видели на соцсетях очень интересные примеры, например фото Peter Steinberger: на его экране 18 терминальных окон, раскиданных по трем мониторам — выглядит как «креативная открытая лапа». Нам понравилось, что пользователи используют Codex в таком продвинутом стиле.

Параллельно мы продолжали улучшать базовый продукт, например возможности делегирования задач в CLI, чтобы они работали хорошо. Но мы также понимали: возможно, так работают только топовые 1% инженеров. И тогда мы задумались: как сделать эти возможности более интуитивными? Именно поэтому мы разработали приложение Codex.

Когда вы впервые открываете приложение Codex, оно выглядит как простое чат-окно. Вы можете сразу начать использовать — и оно будет работать нормально, а со временем вы постепенно обнаружите больше возможностей: боковую панель, умение запускать несколько задач и легкое переключение между задачами. Вы почувствуете себя невероятно эффективным. А затем вы, возможно, заметите вкладку «skills» и начнете исследовать еще больше функций. Мы хотим, чтобы при использовании приложения Codex у пользователей было почти игровое ощущение — постоянное открытие новых возможностей.

Romain：

Полностью согласен. И именно это было нашим видением с самого начала: кодирование будет происходить в формате “делегирования умным агентам” (agentic delegation). Даже когда мы примерно год назад начали разрабатывать Codex, мы постоянно думали об этом будущем. Мы верим, что инженеры смогут одновременно заниматься несколькими задачами, а модель будет отвечать за выполнение сложных деталей.

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

Alex：

Если оглянуться на развитие Codex, мы прошли два важных «vibe shift» (точки смены подхода). **Первый — в прошлом августе: ** мы запустили продукт Codex Cloud. Это была отличная идея — пользователи тогда были очень взволнованы, но, возможно, было немного рановато. Поэтому в августе мы выпустили GPT-5 — очень сильную интерактивную модель кодинга — и решили сосредоточиться на том, с чем модель в тот момент уже умела справляться. Так мы запустили Codex CLI и IDE-плагины, и количество пользователей быстро выросло в течение нескольких месяцев примерно в 20–30 раз — это было потрясающе.

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

Наше планирование делится на краткосрочное и долгосрочное — и мы не делаем среднесрочное планирование

Ведущий Peter: Мне интересно, как разработали приложение Codex. Вы год назад составляли какой-то план на год, например: «мы планируем выпустить приложение Codex в определенный момент»? Или вы больше наблюдали спрос на рынке и быстро прототипировали какие-то идеи?

Alex：

На самом деле, не то и не другое. Я услышал от нашего исследователя Андрея (Andre) очень хорошую рекомендацию: в OpenAI мы либо планируем краткосрочные цели, либо планируем долгосрочные, но не делаем среднесрочное планирование, потому что оно слишком сложное.

Краткосрочное планирование обычно означает цели максимум на восемь недель с текущего момента; восемь недель — это самый длинный временной диапазон, который мы можем задать. В рамках этого временного окна мы ставим конкретную цель и собираем команду, чтобы полностью ее выполнить. Это сильная сторона OpenAI — мы умеем организовывать команду вокруг четкой цели.

С другой стороны, мы также формируем долгосрочное видение. Например, мы можем смотреть на год вперед и представлять, что тогда модели станут умнее. Допустим, мы можем воображать будущее, где модель сможет работать самостоятельно, без необходимости использовать наши ресурсы компьютера и без ограничения «выполнять только одну вещь за раз». Мы хотим иметь бесконечное число моделей, которые смогут независимо выполнять задачи, самопроверять код и даже самостоятельно развертываться и мониторить работу — и нам не нужно будет вручную подсказывать им.

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

В качестве примера возьмем приложение Codex. Тогда одной из наших стратегических целей было освободить пользователей от конкретного рабочего пространства (workspace). Традиционные инструменты разработки (например, VS Code) обычно привязаны к определенному рабочему пространству: к конкретной проверке репозитория или папке. Даже если использовать git worktree, за раз можно открыть только один рабочий каталог, и CLI в этом плане тоже ограничен.

Но наше видение было таким: пользователи будут сотрудничать с умным агентом (agent) в облаке, и эти agent смогут работать самостоятельно. Мы хотим, чтобы пользователи могли взаимодействовать одновременно с несколькими agent, и даже чтобы один agent координировал работу нескольких agent — этот опыт должен быть естественным и интуитивным.

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

Когда мы начали разрабатывать это приложение, у нас было много таких «размышлений о видении» — довольно абстрактных идей. Параллельно наши инженеры делали разные прототипы. Они говорили: «Я хочу, чтобы у нас было приложение». И тогда начались попытки разрабатывать разные версии. На самом деле, мы даже проводили «hacker week»: несколько инженеров независимо разрабатывали разные версии приложения. Возможно, вы тоже участвовали — я не помню точно.

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

Но на тот момент у проекта было и немного спорных моментов: действительно ли нам нужно разрабатывать приложение? Наш IDE-плагин уже стал очень популярным — стоит ли сосредоточиться на улучшении качества плагина? CLI тоже имел большой потенциал. Тогда если мы все-таки разрабатываем приложение — в чем будет его смысл? В каком направлении нам нужно двигаться? Это были вопросы, с которыми мы столкнулись в начале проекта.

Romain：

Да, к счастью, у нас в тот момент уже была очень зрелая платформа IDE-плагинов, и мы глубоко ее оптимизировали. Пользователи могли использовать эти плагины в VS Code, Cursor, Windsurf и других IDE. Мы накопили много опыта в кодовой базе IDE-плагинов — и это дало очень надежную стартовую точку для разработки приложения Codex.

Alex：

Да, это верно. На самом деле, приложение Codex и IDE-плагины на нижнем уровне имеют много общего по коду. Они подключаются к одному и тому же core Codex harness — это open-source framework, написанный на Rust, и CLI тоже использует его. Мы изначально намеренно выбрали слоистую архитектуру, чтобы обеспечивать совместное использование кода и расширение функциональности между разными инструментами.

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

Alex：

Я думаю, способ мышления нашей команды очень сильно повлиял на AGI-видение. Мы постоянно думали: каким будет будущий способ работы?

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

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

Romain：

Да, и аудитория этого приложения — не только новички. На самом деле даже самые опытные и продвинутые инженеры, включая топовых инженеров внутри OpenAI — например, Peter, OpenClaw и Greg Brockman — сейчас начинают использовать приложение Codex как основной инструмент разработки. Это показывает, что** наше видение «делегирования умным агентам» постепенно становится реальностью.**

Alex：

Да. Мы упомянули Peter, потому что он только что присоединился к OpenAI, и нам это очень понравилось. В октябре прошлого года, когда я гулял с ним по Fort Mason в Сан-Франциско, я упомянул идею разработки нового интерфейса. Я сказал, что мы хотим сделать делегирование задач (delegation) более естественным. Тогда он сказал мне, что он никогда не будет пользоваться чем-то подобным.

Но на прошлых выходных он опубликовал твит: «Оказывается, это приложение довольно удобное. Сейчас я уже начал его любить».

Чем занимается Alex в повседневной работе в роли product manager (PM) в Codex

Ведущий Peter: Alex, раньше какое-то время ты был в Codex-команде единственным product manager (PM), верно? Сейчас в команде Codex сколько человек? Примерно 50–100?

Alex：

Примерно в этом диапазоне. В мае у нас было около 8 человек, я не помню точное число. Но с тех пор команда росла очень быстро, сейчас в районе 50–100.

Ведущий Peter: Тогда как ты обычно распределяешь время? Как выглядит твой обычный день? Или у тебя вообще нет типичного дня?

Alex：

Я недавно тоже думал об этом, потому что мне трудно ответить. Я понял, что** мой режим работы на самом деле по этапам,** это просто мой личный стиль и он не обязательно подходит всем.

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

Мы используем Codex, чтобы получать обратную связь: например, понять, о чем обсуждают в Slack, и как пользователи отзываются. Я заставляю Codex резюмировать эту информацию и записываю ее в Linear. Помимо этого, я использую Codex для анализа качества кода и напрямую делаю с его помощью небольшие правки. Потому что иногда, чтобы разобраться с мелкой проблемой, быстрее просто использовать Codex, чем координировать задачи с другими людьми и добиваться приоритетов — особенно когда нашей целью было выпустить приложение за две недели.

В этом процессе, конечно, есть и много человеческих вещей: подбадривать команду, мотивировать, при этом сохранять критичность к тому, что мы разрабатываем. Я также заметил, что понять, в режиме выполнения я или нет, можно по тому, как часто я использую Twitter. Я не знаю почему, но когда мне нужно общаться с людьми, я больше использую Twitter.

А есть и другой режим. Например, сейчас у меня в голове очень четко: мы уже достигли нового этапа. У нас появились очень сильные модели — например, GPT-5.4 показывает себя отлично. А пользовательский опыт в приложении уже превзошел ожидания: он уже охватывает все платформы, включая Windows. Поэтому сейчас я думаю, что пришло время действительно вернуться в облако и вложить туда больше усилий.

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

Ведущий Peter: Сколько вам нужно делать кросс-функционального согласования?

Alex：

В команде нам почти не нужно делать много кросс-функционального согласования: мы немного намеренно относим себя к командам типа «пиратского корабля». Даже внутри команды Codex сейчас только я и два недавно присоединившихся новых product manager. У нас есть некоторые руководители, но хотя до недавнего времени почти все напрямую отчитывались мне, мы все равно ведем проект в достаточно «размытом» совместном формате — поэтому внутри команды согласования не так много.

Но сейчас всё более очевидно, что важная часть построения Codex — это разработка coding agent. И всем становится всё более ясно, что coding agent полезен не только для написания кода, но и для многих других задач.

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

И это заставляет нас понять: нам нужно думать о том, как сделать Codex полезным не только разработчикам. А для этого нужно больше кросс-функционального согласования — потому что в OpenAI у нас есть ChatGPT, и многие пользователи его используют. Поэтому нам нужно очень аккуратно продумать, как лучше объединять эти продукты.

Romain：

С моей точки зрения, сейчас команда developer experience (DevX) немного похожа на продолжение команды Codex. Мы тратим большую часть усилий на Codex — и есть несколько причин.

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

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

Сейчас лучший способ разработки — использовать Codex как точку входа. Если вернуться на год назад, или даже к прошлому лету, когда мы только выпустили GPT-5, нам приходилось писать много гайдов о том, как писать prompt для GPT-5. GPT-5 — это модель с очень сильными возможностями рассуждения, и она сильно отличается от GPT-4. А сейчас мы пытаемся сделать так, чтобы даже в этих use-case’ах разработчики могли выполнять задачи с помощью Codex и skills.

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

Alex：

Я думаю, у нашей команды Codex есть одна очень интересная особенность в стиле работы. Для меня самое лучшее — это** взаимодействие с сообществом.** И онлайн, и на офлайн-мероприятиях мы очень ценим связь с сообществом.

В момент релизов наша работа очень** ориентирована на выпуск — мы четко определяем, когда и какой контент публикуем;** одновременно она очень** ориентирована на обратную связь —** как только сообщество дает фидбек, мы быстро реагируем: исправляем проблемы и обсуждаем это с ними. Поэтому наша команда постоянно в активном онлайн-режиме — и я считаю, что это действительно важно.

Например, когда мы выпускали приложение Codex, мы очень тесно сотрудничали с Dom и его командой. Они помогли нам организовать большое alpha-тестирование: пригласили много пользователей, чтобы совместно разрабатывать продукт. Благодаря их фидбеку мы не только улучшили приложение, но и доработали связанные ресурсы — skills и документацию.

Я думаю, именно в этом и заключается уникальное преимущество нашей команды Codex: поскольку мы open-source, всё, что мы делаем, остается предельно прозрачным, и сообщество активно поддерживает такой подход, давая много обратной связи.

Ведущий Peter: Давайте поговорим про Peter (основателя OpenClaw). Я один из ранних пользователей OpenClaw. Как вы интегрировали Peter в команду? Видение персонального агента (personal agent) связано ли с тем, чем он сейчас занимается? Как вы это планировали?

Alex：

Можно сказать про две стороны. Во-первых, Peter — очень активный пользователь Codex. На самом деле OpenClaw в значительной степени построен с помощью Codex. Он делился большим количеством фидбека, основанного на своем опыте использования, и это очень помогло нам улучшить Codex. Даже если это всего лишь его «подработка», он реально очень вовлечен — и это нас особенно радует.

Во-вторых, я пока не могу раскрыть слишком много деталей, но в целом можно сказать, что он помогает нам построить следующее поколение персональных агентов (personal agent) и напрямую интегрировать их в ChatGPT.

Romain：

Мне кажется, самое завораживающее в работе Peter то, что когда все используют OpenClaw, возможно, они уже смутно видят будущее и возможные варианты, но меня поразило другое: Peter видел это видение очень давно — практически с самого начала.

Если оглянуться на весь 2025 год, он в прошлом году разработал более 40 open-source проектов, и все они были вокруг одной ключевой идеи: получать доступ к его личным инструментам — календарю, твитам и Gmail и т.п. — через командную строку. Через эти проекты он фактически воплотил в реальность видение skills и инструментов CLI. А coding agent, которым мы пользуемся сегодня, построен именно на этом видении.

В будущем этот агент будет не просто инструментом для программирования — он станет любым типом персонального агента (personal agent). Поэтому Peter в этом процессе дал нам очень ценный фидбек: он уже разработал много инструментов, которые сейчас становятся ключевой частью open-source экосистемы.

Ведущий Peter:

Я думаю, люди вроде Peter — действительно потрясающие: они способны создавать такую сильную open-source комьюнити. Его инструменты настолько хороши, что мне даже не хочется открывать никакие другие приложения. Я просто хочу общаться со своими маленькими роботами.

Alex：

К чему ты его подключил? Ты подключил его ко всему?

Ведущий Peter:

Да, я подключил его ко многим сервисам. Например, он может получать доступ к моим банковским данным, моему YouTube-аккаунту, голосовому помощнику, календарю и сервисам Google. Когда я лежу в постели, моя жена спрашивает: «С кем ты разговариваешь?» А я отвечаю: «Я общаюсь со своим роботом OpenClaw».

Но сейчас есть очень много «предпринимателей», которые берут до 5000 долларов, чтобы помочь другим настроить OpenClaw. Поэтому если вы сможете сделать его более массовым и более простым в освоении — это будет огромный прорыв. И да, вы действительно движетесь в правильном направлении.

Традиционная карьерная лестница больше не подходит

Ведущий Peter: Я помню, вы раньше говорили что-то вроде: «сейчас большинству команд уже не нужно так много PM»?

Romain：

Я думаю, один из самых впечатляющих моментов во всех этих инструментах — это не только вопрос PM или необходимости PM. Это почти размывает каждую традиционную карьерную лестницу для продвижения. Раньше у нас были четкие роли: дизайнер отвечает за дизайн, инженер за разработку, PM за управление, и возможно, был какой-то конкретный пропорциональный баланс — вроде “золотой пропорции”.

Но теперь, если ты инженер, твоя продуктивность существенно растет. Если ты дизайнер, то с помощью этих инструментов ты получаешь суперсилы и становишься более техническим. Если ты PM, раньше ты мог писать только стратегические документы, а сейчас ты можешь сразу прототипировать. Это не значит, что тебе нужно отвечать за функцию для миллиардов пользоват