Руководитель Codex: «Все — строитель» — это очень плохая идея.

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

С его точки зрения, когда почти каждый в компании может быстро собрать прототип функции, настоящая проблема уже не в том, «можно ли это сделать», а в том, «стоит ли это делать».

В беседе с Ленни Эндрю Амброзино подробно рассказал о внутреннем процессе разработки OpenAI: когда стоимость реализации резко снижена ИИ, каждый этап разработки продукта — от постановки задачи, документации, прототипирования, дизайна до распределения ролей, командной работы и планирования продукта — меняется. Какие старые правила перестают действовать? Какие новые стандарты формируются? Когда реализация перестаёт быть дефицитом, что становится настоящим дефицитом?

Некоторые ключевые идеи:

Когда 90 человек могут сделать 90 прототипов, которые выглядят готовыми к запуску, самым ценным становится вкус.

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

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

Достаточность функции часто определяется не её формой, а тем, насколько умна модель.

Как Codex когда-то перевернул ChatGPT, так и Codex может быть перевёрнут новыми попытками. Нужно сохранять культуру исследований снизу вверх; нельзя ожидать, что одна и та же команда будет одновременно шлифовать детали и разрушать себя.

Ниже — самая суть беседы.

Когда стоимость реализации снижается, вкус становится важнее

Ленни: Ты говорил, что ИИ меняет форму работы над продуктом. Ты сейчас работаешь, возможно, в самой передовой команде ИИ-продуктов в мире. Как конкретно изменилась работа продуктовой команды по сравнению с двумя годами назад?

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

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

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

Даёшь людям бесконечные токены, и каждый в OpenAI проявляет инициативу, у каждого есть хорошие идеи. Так что все делают что-то своё. Сейчас в компании есть функция, которую нам срочно нужно сделать, и я уверен, что одновременно 90 разных, нескоординированных маленьких команд реализуют и пробуют её по-своему. Из этих 90 попыток какие хорошие? Какие части нужно включить в другие? Как это определить? Должно ли это быть частью другой функции? Сколько опций должно быть в переключателе? Вот эти вопросы.

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

Ленни: Раньше все писали PRD, стратегические документы, а теперь все сразу делают прототипы. Многие в компании приходят к похожим идеям, появляется 90 разных штук, и из них выбирают направление?

Эндрю Амброзино: Да, такое происходит в большом количестве. Не только в OpenAI. Ты уже видишь, как многие продуктовые руководители говорят: «PRD умер, да здравствуют прототипы», но я с этим совершенно не согласен.

Потому что реализация стала дешёвой в каждом медиуме, и очень соблазнительно пропустить размышления и сразу делать прототип. Особенно если ты не инженер, никогда не писал код, нет интереса или времени, тебе хочется сказать: «PRD умер, дай я просто покажу тебе, что я хочу».

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

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

Ленни: Есть понятие primal mark (первичная отметка) — первый мазок художника на холсте, от которого всё остальное отталкивается. Ты имеешь в виду, что иногда прототип — это ошибочный первый шаг? Потому что все на нём зацикливаются, а не думают о более крупной концепции?

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

Теперь эти вещи разъединились. Раньше, чтобы получить ресурсы на разработку, нужно было сначала достаточно снизить риски. Теперь этого порога нет. Поэтому что-то, что было просто исследовательским, уже выглядит готовым к запуску, визуально оно готово. Но оно может быть совершенно не в том направлении, не соответствовать исследованиям, не тому, что нужно пользователям, не оптимально для бизнеса.

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

Ленни: Слово «вкус» сейчас модное. Что конкретно ты имеешь в виду под «хорошим вкусом»?

Эндрю Амброзино: Вкус нужно разложить.

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

Это действительно важно, но настоящий вопрос вкуса: если мы можем сделать всё, какова цель? Как туда попасть?

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

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

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

Это практические причины, и они исчезнут. Модели станут довольно хороши в дизайне, но есть и более сложные вещи.

Первое: дизайн культурно обусловлен. Помнишь, в прошлом году каждый новый сайт копировал дизайн Linear. Если модель каждый раз будет выдавать сайт Linear, это не вызов. В дизайне важность новизны намного выше, чем в разработке ПО. В разработке ПО ты бы хотел, чтобы модель строго следовала известным паттернам, но дизайн требует определённой случайности и новизны.

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

Ленни: Дженни Вэнь (руководитель дизайна Claude Code от Anthropic) сказала, что процесс дизайна умер, нужно просто строить. Что ты думаешь?

Эндрю Амброзино: Мы с Дженни, возможно, во многом согласны. Формальный процесс дизайна — да, я согласен, он умер. И я не был его фанатом ещё до ИИ.

Много лет назад, когда я делал стартапы, была статья «Фабрика кейсов», о том, как дизайнеров учат следовать фиксированному процессу и постепенно начинают ценить сам процесс выше результата. Если что-то прошло через этот процесс, автоматически делаются два вывода: во-первых, это будет хорошо, процесс гарантирует качество; во-вторых, даже если этим никто не пользуется, это хорошо, потому что прошло процесс.

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

Потом появились Figma и Origami, и мы втянули интерактивные прототипы в процесс. Теперь проблема в том, что можно втянуть всю реализацию в начало процесса. Полностью отшлифованный прототип, который выглядит готовым к запуску. Достаточно людей в компании видят его и спрашивают: «Можем мы сейчас это выпустить?» Но на самом деле вы всё ещё на ранней стадии дизайнерских исследований, просто никто не говорит об этом прямо.

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

Привязывать процесс дизайна к конкретному медиуму — вот где опасность. У дизайнеров теперь больше инструментов. Ты можешь поместить что-то прямо в существующий продукт, можешь делать A/B-тесты. У многих компаний есть baby-версии продуктов — baby Cursor, baby Codex — сильно упрощённая кодовая база, которая имитирует все взаимодействия реального продукта. Ты можешь использовать её для vibe code (атмосферного программирования): «А что, если боковая панель станет такой? А если выпадет панель?» Это новый инструмент дизайнера, но он требует старого понимания: где ты сейчас в процессе.

Роли и должности сливаются, но PM не исчезнут

Ленни: Многие компании говорят о «смерти ролей». Ты думаешь, разделение на PM, инженера и дизайнера полностью исчезнет?

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

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

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

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

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

Я долго считал, что не должен быть инженером-программистом, потому что мне всё равно на ассемблер и не хочется запоминать систему типов TypeScript. У этих ролей всегда были определённые барьеры, будто «быть хорошим в этой роли равно отлично владеть этим инструментом». Думаю, это начинает размываться, но люди преувеличивают.

Ленни: В вашей команде Codex действительно больше слияния ролей. Как это выглядит конкретно?

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

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

Если разложить всё, что делает определённый человек в дизайн-команде, там может быть много кода и много продуктовой работы. Но если взять «среднее» по этим делам, он всё равно окажется в области, более склонной к дизайну.

Ленни: Ты упомянул, что работа продакт-менеджера больше похожа на zone defense (зонную защиту). Что конкретно ты имеешь в виду?

Эндрю Амброзино: Если два продакт-менеджера сотрудничают слишком плотно, это обычно нехороший сигнал. Лучше смотреть на команду как на силовую раскладку: где есть пробелы, где ещё никто не покрывает?

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

Поэтому нужно развернуть команду: кто на что способен? Держать их на некотором расстоянии друг от друга, чтобы обеспечить достаточный охват. А затем заполнять пробелы, например: «Мы хотим нанять инженера с сильным продуктовым мышлением». Мы не хотим, чтобы группа людей сначала писала много кода, а потом всей продуктовой команде приходилось проверять и калибровать согласованность продукта. Мы хотим, чтобы каждый обладал этими способностями, просто углубления должны меняться.

Ленни: Значит, сейчас самые ценные люди — те, кто может провести идею от начала до конца и имеет вкус, чтобы сказать «это круто»?

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

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

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

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

Но в то же время мы не получаем каждый день PR от нескольких тысяч человек. В команде десятки инженеров, дизайнеров примерно вдвое меньше, плюс несколько продакт-менеджеров. Подавляющее большинство — IC. Влияние команды велико, но управленческих уровней не много. Здесь много людей, которые раньше основывали компании, много тех, кто работает с «предпринимательским мышлением» в большой компании, и много людей с отличным вкусом.

Весь Codex сформирован петлёй dogfooding. У всех нас есть общее желание: как можно больше работы делать внутри самого приложения, даже если временно оно не лучший инструмент, потому что только так у него в итоге будет шанс стать лучшим. Мы часто намеренно не улучшаем некоторые внутренние процессы, а позволяем продукту становиться лучше, чтобы он мог поддерживать эти процессы. Это довольно некомфортное состояние. Но неделя за неделей оно действительно меняется.

Codex, запущенный на три месяца раньше, умер бы; единственная разница — прогресс модели

Ленни: В таком быстром темпе изменений как вы планируете? Насколько далеко смотрите?

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

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

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

Ленни: Есть конкретный пример того, насколько важен тайминг?

Эндрю Амброзино: С Codex хорошая история. Я абсолютно уверен, что приложение Codex, которое мы выпустили в феврале, если бы оно было готово и выпущено в ноябре, с треском провалилось бы на рынке. Единственная разница — между ноябрём и февралём модель улучшилась. Тот же продукт, та же форма, совершенно разные результаты — разница в несколько месяцев.

Ленни: То, что не работает сейчас, может сработать позже? Нужно сохранять более высокие амбиции?

Эндрю Амброзино: Да. Я рекомендую не судить поспешно: «Эта функция сейчас не работает, значит, она плохая». Возможно, она просто ещё не созрела.

Вернёмся к первоначальному запуску Codex — Codex web. По сути, ты даёшь модели задачу, она её выполняет и возвращает результат. Звучит не радикально, но проблема в том, что она делала это недостаточно хорошо; та форма была слишком опережающей.

Потом появился Claude Code — полностью локальный, не подключён к облаку, не притворяется, что он AGI. Он задаёт вопросы, ждёт, ты не можешь доверить ему всю свою жизнь. Он был намного удобнее, потому что соответствовал тогдашнему уровню модели.

Мы были слишком «AGI». Я часто вспоминаю этот урок. Раньше провал продукта на рынке многое говорил о форме продукта или способе коммуникации. Теперь по-другому: тебе, возможно, придётся выпускать одну и ту же вещь шесть раз, пока она не добьётся успеха, и форма может остаться неизменной.

То же самое с браузером в приложении. У нас когда-то была работающая версия, ещё во времена Atlas у нас были агенты, выполняющие задачи в браузере. Ещё раньше был Operator в ChatGPT, который не удался. Но если посмотреть на Operator, Atlas, Codex и ChatGPT в связке, можно увидеть непрерывную эволюционную линию. По сути, это та же функция, просто перевыпускаемая по мере изменения уровня интеллекта, и результаты кардинально меняются.

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

Ленни: Каково видение Codex? Куда ты его ведёшь?

Эндрю Амброзино: В январе и феврале этого года, во время внутреннего тестирования, мы обнаружили чёткий PMF в рабочих процессах инженерии и исследований. Но в то же время люди из маркетинга, коммуникаций, финансов и юриспруденции тоже использовали Codex, даже несмотря на то, что приложение для них не очень дружелюбно — оно показывало им код, заставляло одобрять выполнение поисковых инструментов в командной строке.

Мы пробовали добавлять возможности Codex в другие продукты: десктопное приложение ChatGPT, браузер Atlas. И случилось самое раздражающее: никто не хотел покидать приложение Codex, чтобы использовать продукты, якобы созданные специально для них.

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

Это не продукт в духе «нарисовать прямоугольник на экране, и всё должно быть внутри». Скорее это база, где ты начинаешь работу, заканчиваешь работу, управляешь автоматизациями, а он вызывает все необходимые тебе инструменты. Кто-то назвал эту форму «суперприложением». Жаль, что они так это назвали, потому что теперь я слышу это слово почти каждый день.

У Дэна Шиппера есть интересная мысль: в будущем мы будем использовать SaaS-инструменты «изнутри наружу» в Codex. Notion, Linear, Salesforce — ты не открываешь их в браузере, а агент делает это за тебя в Codex. Мы действительно работаем над этим: браузер в приложении, расширение Chrome, computer use — всё это способы взаимодействия Codex с внешними инструментами.

Лучший пример: наш внутренний видеопродюсер Брент смонтировал релизное видео Codex с помощью Codex. Codex не видеоредактор, в нём нет такого интерфейса. Но он понял, что Брент использует Premiere Pro, и смог вносить изменения, редактируя файлы за Premiere Pro. Когда он обнаружил, что не может сделать всё, он сам написал расширение для Premiere Pro, установил его в Premiere Pro и начал общаться с Premiere Pro через это расширение. Мы были потрясены, увидев это.

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

Уметь писать код уже не важно, важно уметь удалять код

Ленни: От написания кода вручную до 100% кода, написанного ИИ, а теперь до агентов и циклов. Как сейчас работают самые передовые команды?

Эндрю Амброзино: Циклы? Это было на прошлой неделе.

Мы постоянно обсуждали вопрос: «Какой процент кода продукта написан ИИ?». По стандартам прошлого года сейчас 100% нашего кода написано ИИ. Так что вопрос больше не в том, «сколько написано ИИ», а в том, «написан ли код под надзором или без надзора» — это совершенно другое измерение. Я приветствую, когда планка постоянно поднимается, потому что это означает, что мы добиваемся прогресса в продукте.

Мы много экспериментируем с автономной разработкой ПО, например, с harness engineering: «А что, если модель будет автоматически делать сборку мусора и очистку кодовой базы по ночам?»

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

То же самое с запросами функций (feature requests). Как научить модель оценивать, какие функции стоит делать, какие следует игнорировать, какие стоит объединить и переопределить? И как научить модель строить правильные абстракции?

Эти способности постоянно улучшаются. Но я не считаю, что мы уже достигли стадии, когда можно настроить цикл, и модель будет автоматически «улучшать приложение», постоянно слушать Twitter, Slack и почту и самостоятельно проводить итерации. Хотя мы действительно пытаемся воплотить это в жизнь.

Ленни: Думаешь, мы когда-нибудь дойдём до того, что можно поставить цель: «Победить»?

Эндрю Амброзино: «/goal заработать мне миллиард долларов». Не знаю. Я не скажу «никогда» или «всегда».

Ленни: Как ты сам, будучи руководителем продукта и инженерии, используешь ИИ в работе?

Эндрю Амброзино: Кажется, у меня сейчас, возможно, лучшая работа в мире.

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

Позже моя роль изменилась. Мне нужно было больше заниматься продуктовым поиском, понимать, чем занимается команда, исправлять отклонения. И Codex стал моим инструментом для этого: «Помоги мне создать электронную таблицу и структурировать эти данные», «Проведи глубокое внутреннее исследование, какие эксперименты проводились в этом направлении раньше».

Серия релизов в мае — браузер в приложении, computer use, создание артефактов — это был наш первый опыт управления релизами с помощью vibe coordination (атмосферной координации). У меня был документ в Notion со всеми задачами, и я использовал Codex для автоматического сбора прогресса из PR и Slack-каналов, обновления трекера статуса. В то время я считал это передовым способом управления релизами продуктов.

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

Ленни: Как это настроено? Какой рабочий процесс?

Эндрю Амброзино: Сейчас это ещё в стадии обнаружения. Просто делаешь запланированную задачу: «Пройдись по моим Slack-каналам, вот что меня волнует, сгруппируй по этим категориям, вот контекст». Первые несколько раз может потребоваться наводка. Хорошо, что мне не нужно искать, как редактировать инструкции: я просто говорю «в следующий раз измени это», и он обновляется.

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

Ленни: Я сам использовал Codex для автоматизации фильтрации спама. На одном из шагов нужно было зайти в консоль Google Cloud и настроить кучу триггеров API — этот интерфейс был очень раздражающим. Я попросил Codex сделать это, и он просто взял под контроль мой компьютер, используя функцию computer use.

Эндрю Амброзино: Он такой: «Мне плевать на твой коннектор, чувак, я просто начинаю кликать».

Разделение границ между коннекторами, браузером в приложении, расширением Chrome и computer use — это очень интересно. Часто эти границы определяются интуитивно.

Мне кажутся особенно интересными эти личные рабочие процессы. Все экспериментируют с разными вещами, каждый выстраивает совершенно разные системы. Но постепенно вырисовываются общие паттерны. И тогда мы осознаём: «Это должно стать первоклассным опытом в продукте».

Например, память (memory). Многие настраивают базы знаний Obsidian или пространства Notion, чтобы построить свой ментальный дворец. Ты не должен делать это сам. Должна быть достаточно общая функция памяти, которая сделает это за тебя. Мы постоянно фильтруем: что работает на личном уровне, но должно оставаться на личном уровне, а что должно войти в продукт как базовый компонент.

Ленни: Со стороны кажется, что у тебя всё получается. Но наверняка были и неудачи?

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

До этого я много лет занимался стартапами и в итоге разобрал компанию и продал по частям. Работал в высокорегулируемой отрасли — это было сплошное фиаско. Потом пошёл в другой стартап, делал AI-инструменты в другой закрытой регулируемой отрасли — снова провал за провалом. На самом деле я много раз терпел неудачу. Иногда просто нужно совпадение: навыки, страсть и рыночное окно.

Даже сейчас, в проекте по интеграции Codex и ChatGPT, бесчисленное множество мелких неудач. Мы говорим: «Это должно выглядеть так», отправляем в Slack, и тут же получаем 2000 сообщений о том, какие мы глупые. Это то, что мне нравится в OpenAI: люди говорят прямо, безжалостно критикуют внутренние продукты, и именно поэтому внешние продукты получаются неплохими. Прежде чем оказаться на своём нынешнем месте, я терпел неудачи лет 10–15. Так что я до сих пор каждый день немного удивляюсь, что дела идут хорошо.

Ленни: Какой последний совет читателям?

Эндрю Амброзино: Не «заключайте брак» со своим текущим рабочим процессом. Настоящая приверженность должна быть тем результатам, которые можете уникально предоставить только вы. А затем постоянно пытайтесь изменить свой процесс. Если ваш самый гордый навык — «я лучше всех знаю auto layout в Figma», то чем вы занимаетесь? ИИ станет лучше вас. Найдите то, что стоит делать, и найдите способ это сделать.