Керівник Codex: «Всі є builder» — це дуже погана ідея.

Ендрю Амбросіно є керівником команди 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 компоненти один за одним. Глибокий підхід — зрозуміти, що ці дві речі, які виглядають по-різному, насправді належать до одного стилю списку і передають одну й ту саму модель взаємодії. Цей рівень абстракції сучасні технології ще не досягають.

Ленні: Дженні Вен (керівниця дизайну Anthropic Claude Code) сказала, що дизайнерський процес мертвий, просто створюйте. Що ви думаєте?

Ендрю Амбросіно: З Дженні ми, мабуть, згодні в багатьох речах. Щодо формального дизайнерського процесу, я згоден з нею: він мертвий. І я не був його фанатом ще до ШІ.

Багато років тому, коли я створював стартап, була стаття під назвою «Фабрика кейсів», де йшлося про те, що дизайнерів навчають дотримуватися певного набору процедур, і поступово вони починають вважати сам процес важливішим за результат. Якщо річ пройшла цей процес, то автоматично робилися два висновки: по-перше, вона буде хорошою, тому що процес гарантує якість; по-друге, навіть якщо ніхто не користуватиметься нею, вона все одно хороша, тому що вона пройшла процес.

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

Потім з'явилися Figma і Origami, і ми додали інтерактивні прототипи в процес. Тепер проблема полягає в тому, що ви можете винести всю реалізацію на самий початок процесу. Повністю деталізований прототип виглядає так, ніби його можна одразу запускати. Досить багато людей у компанії бачать це і запитують: «Ми можемо випустити це зараз?» Але насправді ви все ще на ранній стадії дизайнерського дослідження, просто ніхто цього не говорить.

Тому твердження «дизайнерський процес мертвий» є одночасно правильним і неправильним. Якщо ви прив'язані до конкретних інструментів і конкретних щоденних операцій, то він справді мертвий. Але усвідомлення «на якому етапі процесу ми зараз» важливіше, ніж будь-коли.

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

Посади та ролі зливаються, але PM не зникнуть

Ленні: Багато компаній говорять про «смерть ролей». Чи зникне повністю поділ на PM, інженерів і дизайнерів?

Ендрю Амбросіно: Деякі компанії люблять гнатися за трендами і впадати в крайнощі. Небезпека ліквідації поняття ролей полягає в тому, що це може одночасно знищити розуміння того, що в цих сферах існує професія з найкращими практиками, яких варто навчатися.

Я чую, як багато компаній кажуть: «Ми ліквідуємо продуктові ролі». Я вважаю, що це погана ідея. Потім вони кажуть: «Кожен є будівником». У результаті управління продуктом, дисципліна, яка накопичила справжні найкращі практики та справжні шишки, просто викидається. Тому що хтось написав кілька рядків коду і вирішив, що все гаразд. Це не дуже хороший стан.

Я вітаю зникнення кордонів «це не твоя сфера, ти не можеш цього робити», але потрібен баланс. Не кожен може робити все, і це стосується як широти, так і глибини. Ось чому менеджери не зникнуть.

Крім того, кожна дисципліна має компонент навичок. Багато інженерів не визнають цього, вважаючи, що в інженерії є навички, а всі інші ролі — це просто «атмосфера». Це не так. Те, що ви вмієте користуватися Excel, не означає, що ви можете працювати у фінансовому відділі.

Я думаю, що зараз відбувається більше те, що людям стало легше співпрацювати між ролями, а також легше вивчати найкращі практики з інших сфер, не прив'язуючи свою ефективність у певній ролі до здатності використовувати певний інструмент.

Я довго вважав, що не варто бути інженером програмного забезпечення, тому що мене не цікавить асемблер, і я не хочу запам'ятовувати систему типів TypeScript. У цих ролей завжди були певні бар'єри, такі як «бути хорошим у цій ролі = добре володіти цим інструментом». Мені здається, це починає зникати, але люди це перебільшують.

Ленні: У вашій команді Codex справді більше злиття ролей. Як це виглядає конкретно?

Ендрю Амбросіно: У команді Codex ми справді спостерігаємо більше злиття ролей, ніж в інших командах компанії та в інших галузях. Частково це тому, що це технічний продукт, орієнтований на інженерів. Тому наші дизайнери говорять мовою інженерів, наші продакт-менеджери говорять технічною мовою і вміють писати код.

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

Якщо розкласти всі справи, які робить певна людина в дизайн-команді, виявиться, що серед них може бути багато написання коду, а також багато роботи, пов'язаної з продуктом. Але якщо взяти «середнє» цієї роботи, вона все одно опиниться в області, яка більше схиляється до дизайну.

Ленні: Ви згадали, що робота продакт-менеджера більше схожа на зонний захист (zone defense). Що це означає?

Ендрю Амбросіно: Якщо двоє продакт-менеджерів співпрацюють надто тісно, це зазвичай поганий знак. Краще дивитися на команду як на силове поле, де є прогалини, які ще ніхто не покриває?

У сучасному світі кураторство, спрямування та узгодження стали найважливішою роботою. Кожен постійно генерує ідеї, все середовище наповнене шумом. Старий підхід «зверху вниз, з річним плануванням» більше не працює. Нам потрібні люди, які виступають як охоронці смаку, які ведуть річ від концепції до продукту. А це означає, що ви повинні охоплювати всі куточки компанії.

Тому потрібно розкласти команду, подивитися, хто в чому сильний? Тримати їх на певній відстані один від одного, щоб забезпечити достатнє покриття. А потім заповнювати прогалини, наприклад: «Ми хочемо найняти інженера з сильним продуктовим мисленням». Ми не хочемо, щоб група людей спочатку написала купу коду, а потім вся продуктова команда мала перевіряти та калібрувати узгодженість продукту. Ми хочемо, щоб кожен мав ці навички, просто напрямок їхнього поглиблення має змінюватися.

Ленні: Отже, зараз найцінніші люди — це ті, хто може провести ідею від початку до кінця, і мають смак, щоб знати, що «це круто»?

Ендрю Амбросіно: Так, я вважаю, що це найголовніша зміна зараз. Це також відображає моє розуміння відносин між IC (індивідуальними виконавцями) і менеджерами. Я не кажу, що управління зникне, або що всі стали просто IC. Справа в тому, що зараз кожен певною мірою виконує обидві ролі.

Якщо ви IC, ви вже не просто стукаєте по клавішах, символ за символом. Ви насправді керуєте чимось: керуєте агентами, керуєте роботою, організованою для спільного виконання завдань. Якщо ви керівник команди, ви робите те саме, але з іншою гранулярністю управління.

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

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

Але водночас ми не отримуємо щодня PR (pull requests) від кількох тисяч людей. У команді десятки інженерів, дизайнерів приблизно вдвічі менше, ніж інженерів, плюс кілька продакт-менеджерів. Переважна більшість — 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 desktop, Atlas browser. І сталося найнеприємніше: ніхто не хотів залишати програму Codex і переходити на ці продукти, які нібито були створені спеціально для них.

Це наштовхнуло нас на думку, що між інструментами для розробників та інструментами для загальної роботи зі знаннями існує багато тонких точок дотику. Ми справді віримо, що форма продукту, яку ми будуємо, є правильною формою для підтримки різноманітних глибоких вертикальних сценаріїв. Починаємо з простого, а потім, у міру необхідності, поступово додаємо складність.

Це не той продукт, де «ви малюєте прямокутник на екрані, і все має відбуватися всередині нього». Швидше, це база: ви починаєте тут роботу, закінчуєте її, керуєте автоматизованими процесами, а вона викликає всі необхідні вам інструменти. Хтось називає цю форму «супердодаток». Я шкодую, що вони це зробили, тому що тепер я чую це слово майже щодня.

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

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

Це хороша модель: є професійний інструмент, який робить свою справу. Codex не повинен стати кращим відеоредактором; він повинен просто безшовно взаємодіяти з професійними інструментами.

Вміння писати код не важливе, важливо вміння видаляти код

Ленні: Від написання коду вручну до 100% коду, написаного ШІ, а тепер до агентів і циклів. Як зараз працюють найпередовіші команди?

Ендрю Амбросіно: Цикли? Це було минулого тижня.

Ми постійно обговорюємо питання: «Який відсоток продукту написаний ШІ?» За стандартами минулого року, зараз 100% нашого коду написано ШІ. Тому питання більше не «скільки написано ШІ», а «код написаний під наглядом чи без нагляду». Це зовсім інший вимір. Я вітаю цю зміну стандартів, тому що це означає, що ми робимо прогрес у продукті.

Ми провели багато досліджень щодо автономної розробки програмного забезпечення: наприклад, інженерію harness, або «що, якщо модель вночі автоматично виконує збірку сміття та очищення кодової бази?»

Але у всіх сучасних моделей є проблема: вони завжди додають складність. Якщо дослідники слухають: будь ласка, навчіть моделі видаляти код. Коли ви намагаєтеся повністю перейти на автопілот, це стає серйозною проблемою, як на рівні людей, так і на рівні кодової бази.

Те саме стосується функціональних запитів. Як навчити модель визначати, які функції варто робити, які варто ігнорувати, які варто об'єднати та перевизначити? І як навчити модель будувати правильні абстракції?

Ці здібності постійно вдосконалюються. Але я не вважаю, що ми вже досягли того етапу, коли можна встановити цикл і дозволити моделі автоматично «покращувати додаток», постійно слухаючи Twitter, Slack та електронну пошту, і самостійно завершувати ітерації. Хоча ми справді намагаємося втілити це в життя.

Ленні: Ви думаєте, ми дійдемо до того, що можна буде поставити ціль: «виграти»?

Ендрю Амбросіно: «/goal зароби мені мільярд доларів». Я не знаю. Я не скажу, що ніколи або завжди.

Ленні: Як ви, як керівник продукту та інженерії, використовуєте ШІ в роботі?

Ендрю Амбросіно: Здається, зараз я маю, мабуть, найкращу роботу у світі.

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

Пізніше моя роль змінилася. Мені потрібно було більше займатися продуктовим дослідженням, розуміти, що робить команда, виправляти те, що відхиляється від курсу. Тоді Codex став інструментом для цього. «Допоможи мені створити електронну таблицю з цими даними.» «Зроби глибоке внутрішнє дослідження, щоб з'ясувати, які дослідження вже робилися в цьому напрямку.»

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

Тепер щоранку я переглядаю щоденний звіт, який Codex генерує для мене. Він фільтрує те, що потребує моєї уваги, з 3000 Slack-каналів, до яких я приєднаний. Я можу відповісти: «Дай мені п'ять питань, я відповім». Він самостійно налаштовується. Я кажу: «Наступного разу менше звертай уваги на цей робочий процес» або «Це сталося, але не потрапило в звіт, переконайся, що в майбутньому це буде зафіксовано». Він оновлює спосіб сповіщення, коригує фокус уваги.

Ленні: Як це налаштовано? Який робочий процес?

Ендрю Амбросіно: Зараз це все ще на етапі дослідження. Просто створюється заплановане завдання: «Перебери мої канали Slack, ось що мене цікавить, відсортуй за цими категоріями, ось трохи контексту». Перші кілька разів може знадобитися навчання. Добре те, що мені не потрібно йти і редагувати інструкції; я просто кажу: «Наступного разу зміни це», і воно змінюється.

Але я вважаю, що це також ключова проблема форми чат-бота. Я знаю, як це налаштувати, тому що для мене це продуктове дослідження. Але якщо ви не працюєте в OpenAI і не розробляєте цю технологію, ви не захочете з цим розбиратися. Нам потрібно подумати, як зробити цю форму доступною для звичайних людей.

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

Ендрю Амбросіно: Це просто: «Мені байдуже, чи є у тебе з'єднувач, друже, я просто починаю натискати».

Розмежування між з'єднувачами, вбудованим браузером, розширенням Chrome та computer use — це дуже цікава річ. Часто ці межі визначаються інтуїтивно.

Мені здаються особливо цікавими ці особисті робочі процеси. Усі пробують різні речі, і кожен створить абсолютно різну систему. Але поступово виникають спільні патерни. І тоді ми усвідомлюємо: «Це має стати базовою можливістю продукту».

Наприклад, пам'ять. Багато людей налаштовують бази знань в Obsidian або Notion, щоб побудувати свій «ментальний палац». Ви не повинні робити це самостійно. Повинна бути достатньо універсальна функція пам'яті, яка робить це за вас. Ми постійно фільтруємо: що є особистим і має залишитися на особистому рівні, а що має стати базовим компонентом продукту.

Ленні: Сторонні люди бачать лише ваші успіхи. Але напевно були речі, які не вдавалися?

Ендрю Амбросіно: Смішно, коли ви так описуєте. Це, мабуть, перший раз, коли я відчуваю, що не зазнаю невдачі.

Раніше я займався стартапами багато років, і врешті-решт мені довелося просто розібрати компанію і продати її. Працювати у високорегульованих галузях — це був постійний неуспіх. Потім я пішов в інший стартап, робив ШІ-інструменти в іншій закритій регульованій галузі — знову і знову нічого не виходило. Насправді я багато разів зазнавав невдач. Іноді це просто питання часу, коли навички, ентузіазм і ринкове вікно збігаються.

Навіть зараз, у цьому проекті, де ми об'єднуємо Codex і ChatGPT, є незліченна кількість маленьких невдач. Ми говоримо: «Це має виглядати так», — публікуємо в Slack, а потім отримуємо 2000 повідомлень про те, які ми дурні. Це те, що мені подобається в OpenAI: люди прямо кажуть нам, що ми дурні, коли справа стосується внутрішніх продуктів, і саме тому зовнішні продукти виходять хорошими. Перш ніж я опинився на цьому місці, я зазнавав невдач приблизно 10-15 років. Тому я досі щоразу трохи дивуюся, що все йде добре.

Ленні: Які останні поради читачам?

Ендрю Амбросіно: Не прив'язуйтеся назавжди до свого поточного робочого процесу. Справді варто триматися лише за ті результати, які здатні дати лише ви. А потім постійно намагайтеся змінювати свій процес. Якщо ваша найцінніша навичка — «я найкраще знаю auto layout у Figma», то чим ви займаєтеся? ШІ стане кращим за вас у цьому. Знайдіть те, що варто робити, і зробіть це.