Керівник продукту OpenAI Codex особисто розповідає: без стандартів і дорожньої карти — як ми створюємо продукти?

«Цікавість і автономність — це найсуттєвіші й найважливіші якості для людей в епоху AGI».

Упорядкування й компіляція: глибокий приплив TechFlow

Гість: Alex, керівник продукту Codex; Romain, developer experience у Codex

Ведучий: Peter Yang

Джерело подкасту: Peter Yang

Заголовок: How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain

Дата виходу: 2026年4月5日

Ключові тези

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

Короткий підсумок найцікавіших думок

Побудова в реальному часі та «швидкість мислення» Codex Spark

• «Коли ти хочеш щось створити… ти можеш перемкнутися в швидкий режим і навіть у Codex Spark, і тоді ти отримуєш цю божевільну швидкість мислення, щоб побудувати будь-що. Зліва GPT-5.4, справа Codex Spark, у середньому приблизно 1200 даних (tokens) за секунду — це просто божевілля». ——Romain

Про специфікації документів і процес ухвалення рішень

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

Професійні межі розмиваються, а дизайнери еволюціонують

• «Дизайнери в нашій команді зараз пишуть більше коду, ніж інженери шість місяців тому. Наш фокус уже не в тому, “чи може згенерувати код”, а в іншому: ми вирішуємо, що саме робимо, і як забезпечуємо високу якість продукту. Саме тому для дуже складних фіч я більше схиляюся знайти стабільного відповідального керувати цим, а не доручати продукт-менеджеру (PM) відповідати за впровадження та підтримку цих систем». ——Alex

Філософія дизайну продукту: щоб модель була “невидимою”

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

Філософія планування: відмова від “незручного проміжного етапу”

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

Зміни інтерфейсу, які приносить “делегування розумним агентам”

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

Зникає кар’єрна драбина та відбувається “колапс кадрового стеку”

• «Це майже розмиває кожну традиційну кар’єрну сходинку для просування. Насправді кожен із нас є “конструктором (builder)”, і всі ми спільно працюємо над тим, щоб щось збудувати. Якщо в стартапі є PM, а інженерів менше ніж приблизно 20, це може бути небезпечним сигналом. Цікавість і автономність — це найсуттєвіші й найважливіші якості для людей в епоху AGI». ——Romain / Alex

Критерії найму: роботи важать більше, ніж резюме

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

Живий демонстраційний виступ: побудувати гру за кілька секунд за допомогою Codex Spark

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

Romain:

Звісно — дозвольте мені поділитися своїм екраном. Насправді є дуже багато речей, які я можу показати, але, можливо, швидко глянемо — наприклад, ось iOS-застосунок, який я постійно будую. Якщо я хочу створити для цього застосунку нову функцію, я можу просто продиктувати: “Гей, ти можеш додати новий екран для місії повернення NASA на Місяць?” Потім я відправляю цей промпт через GPT-5.4, і модель створює новий екран саме для цього APP.

А ще в нас є модель Codex Spark — вона може допомогти тобі за лічені секунди продумати й виконати ітерації для будь-чого. Дозвольте мені показати різницю в тому, як швидко вона реагує. Зліва GPT-5.4, справа Codex Spark. І в середньому приблизно 1200 tokens за секунду — це просто божевілля. Тож коли ти хочеш щось збудувати, наприклад гру — прямо перед початком цієї розмови я насправді зайшов у 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?” Якщо ми вирішимо оптимізувати reliability dashboard, він ще далі підштовхне нас мислити: хто саме є цільовими користувачами цієї оптимізації. Уся ця історія дуже схожа на співпрацю з партнером по мозковому штурму.

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

Alex:

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

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

До речі, в нашій команді дизайнери зараз пишуть коду більше, ніж інженери шість місяців тому — це раніше було немислимо. Основною причиною є прогрес інструментів, який дозволяє дизайнерам глибше залучатися до розробки. Але мене також часто підколюють за те, що минулого року я подав замало PR (запитів на злиття коду). Хоча багато змін — це маленькі правки, я справді думаю, що мені варто робити більше.

Тепер наш фокус уже не в тому, “чи може він згенерувати код”, тому що агенти (Agent) вже можуть виконати більшість кодувальних задач. Справді важливе інше: ми вирішуємо, що саме робимо, і як забезпечуємо високу якість продукту. Саме тому для дуже складних фіч я більше схиляюся знайти стабільного відповідального керувати цим, а не доручати продукт-менеджеру (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 це як open-source набір інструментів: користувач може занурюватися в нього та налаштовувати під власні потреби.

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

Водночас ми також усвідомлюємо: лише побудувати продукт для таких “просунутих” користувачів недостатньо, інакше продукт зрештою стане складним і незрозумілим. Нам потрібно знайти баланс: задовольнити потреби досвідчених користувачів і водночас зробити продукт простим та інтуїтивним для звичайних. Тому** ми дуже обережно підходимо до дизайну ключових функцій, щоб вони не ставали перешкодою між користувачем і моделлю, а навпаки — робили модель розумнішою та автоматично виконували більше задач.**

Romain:

І на цій основі ми думаємо, як упакувати продукт для досвідчених користувачів максимально конфігурованим способом, щоб вони самі могли досліджувати й використовувати. Наприклад, зараз уже є користувачі, які реалізували sub-agents (сабагенти). Ці функції не були тим, що ми навмисно спроєктували — це користувачі самі знайшли й експериментально опробували. Спостерігаючи за тим, як користувачі використовують ці функції, ми дізналися дуже багато.

Далі ми замислюємося: як зробити ці функції суперпростими й для інших користувачів? Codex app — гарний приклад. Близько того моменту, коли GPT-5.2 Codex було випущено минулого грудня, можливості моделі почали поступово стабілізуватися, але ми також перетнули певний поріг. Користувачі можуть почати делегувати моделі довші та складніші задачі, а модель може виконати ці задачі за один підхід.

Ми почали звертати увагу на те, що деякі користувачі вже використовують tmuxing — спосіб запускати кілька паралельних задач у терміналі, коли в терміналі розділяють вікна, щоб одночасно виконувати кілька задач. Ми бачили дуже цікаві приклади в соцмережах: наприклад, є фото Peter Steinberger, на якому на екрані видно 18 термінальних вікон, рознесених на три монітори, і це виглядає як якась “креативна відкрита лапа”. Ми побачили, як користувачі використовують Codex у дуже просунуті способи, і це нас дуже надихає.

Водночас ми продовжували оптимізувати базові можливості делегування задач у базовому продукті (наприклад, у CLI), щоб вони працювали добре. Але ми також усвідомили: можливо, лише топові 1% інженерів працюють так. Тоді ми подумали: як зробити ці функції більш інтуїтивними? Саме тому ми розробили Codex app.

Коли ти вперше відкриваєш Codex app, це виглядає як просте вікно чату. Ти можеш одразу почати використовувати його — і воно працюватиме нормально. Але з часом ти поступово помічаєш більше можливостей: наприклад, бічну панель, здатність запускати кілька задач і легко перемикатися між задачами. У тебе відчуття, що ти стаєш неймовірно ефективним. Потім ти можеш помітити вкладку “skills” і зайти туди, щоб дослідити ще більше можливостей. Ми хочемо, щоб під час використання Codex app у користувача був майже ігровий досвід — постійно відкривалися нові можливості.

Romain:

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

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

Alex:

Якщо подивитися на еволюцію Codex, ми пройшли через два важливі “vibe shift” (зміни напряму/настрою, ключові переломні моменти). Перший — у серпні минулого року. Тоді ми запустили продукт Codex Cloud. Це була дуже класна ідея, і користувачі тоді були дуже захоплені, хоча, можливо, було трохи рано. Тож у серпні ми випустили GPT-5 — дуже вражаючу інтерактивну модель кодування — і вирішили зосередитися на задачах, які на той момент модель могла виконувати. Саме тому ми випустили Codex CLI та плагіни для IDE, і за кілька місяців кількість користувачів дуже швидко виросла у 20–30 разів — це було неймовірно круто.

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

Наше планування: короткострокове та довгострокове, без середньострокового плану

Ведучий Peter: Мене цікавить, як розробляли Codex app. Чи рік тому ви розробляли якийсь річний роудмап, наприклад: “ми плануємо запустити Codex app у певний час”? Чи, можливо, ви більше спостерігали за потребами ринку й швидко прототипували деякі ідеї?

Alex:

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

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

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

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

Як приклад, Codex app: тоді одним із наших стратегічних напрямів було звільнити користувачів від конкретного робочого простору (workspace). Традиційні інструменти розробки (наприклад, VS Code) зазвичай прив’язані до конкретного workspace: до певного checkout у codebase або до конкретної папки. Навіть якщо використовувати git worktree, за раз можна відкрити лише один робочий каталог, і CLI має подібні обмеження.

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

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

Коли ми почали розробляти цей застосунок, у нас з’явилася купа таких “роздумів про бачення” — досить абстрактних ідей. Паралельно наші інженери проводили різні прототипування. Вони казали: “Я хочу, щоб у нас був застосунок”. І тоді почали пробувати розробляти різні версії. Фактично, ми навіть проводили “hacker week” — кілька інженерів незалежно розробляли різні версії застосунку. Можливо, ти теж брав участь — я не пам’ятаю.

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

Але на той момент проєкт також мав певні суперечки: чи справді нам потрібно було розробляти застосунок? Наш плагін для IDE вже був дуже популярним — чи не варто було фокусуватися на покращенні якості плагіна? CLI теж мав потенціал. І тоді, якщо ми розробляємо застосунок — у чому його сенс? У якому напрямку нам рухатися? Саме з такими питаннями ми стикнулися на початку.

Romain:

Так, на щастя, тоді ми вже мали дуже зріле рішення для IDE-плагіна, яке ми глибоко оптимізували. Користувачі можуть використовувати ці плагіни у VS Code, Cursor, Windsurf та в інших IDE. Ми накопичили багато досвіду з codebase IDE-плагіна, і це дало Codex app дуже стабільний старт.

Alex:

Так. Насправді Codex app і IDE-плагін у нижній частині використовують багато спільного коду. Обидва вони підключаються до одного й того ж центрального Codex harness — це open-source фреймворк, написаний на Rust, і CLI теж використовує його. Ми свідомо обрали шарувату (layered) архітектуру, щоб забезпечити спільне використання коду та розширення функціональності в різних інструментах.

Ведучий Peter: Щодо процесу ухвалення рішення про те, чи розробляти Codex app… якщо дивитися назад, здається очевидним рішенням, адже Codex app значно інтуїтивніший, ніж відкривати купу термінальних вікон. Але тоді причина рішення була головно в тому, що Codex app є більш дружнім для новачків, а також є найкращим інтерфейсом для керування співпрацею кількох інтелектуальних агентів.

Alex:

Я думаю, що спосіб мислення нашої команди дуже сильно вплинув через бачення AGI (універсального штучного інтелекту). Ми весь час думали: яким буде майбутній спосіб роботи?

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

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

Romain:

Так, і аудиторія цього застосунку — не лише новачки. Насправді навіть найдосвідченіші й найдосвідченіші інженери, включно з топовими інженерами всередині OpenAI, такими як Peter, OpenClaw і Greg Brockman, вже почали використовувати Codex app як основний інструмент для розробки. Це показує, що** наше бачення “делегування розумним агентам” (agentic delegation) поступово стає реальністю.**

Alex:

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

Але минулих вихідних він написав у твіті: “Насправді цей застосунок непоганий. Я тепер його люблю”.

Alex як продакт-менеджер (PM) Codex: що саме входить у його повсякденну роботу

Ведучий Peter: Alex, ти раніше був певний час єдиним продакт-менеджером (PM) у команді Codex, так? А зараз скільки людей у команді Codex? Приблизно 50–100?

Alex:

Приблизно так, десь у цьому діапазоні. У травні у нас було приблизно лише 8 людей, я не пам’ятаю точні цифри. Але після цього команда дуже швидко виросла — і зараз вона в межах 50–100 людей.

Ведучий Peter: А як ти розподіляєш час у щоденній рутині? Як виглядає твій типо­вий робочий день? Чи взагалі немає типового робочого дня?

Alex:

Нещодавно я теж думав про це, тому що виявилося, що мені важко відповісти. Я усвідомив, що** мій робочий режим насправді поетапний,** і це, можливо, не підходить усім.

Наприклад, під час релізу Codex app,** я повністю був у режимі виконання** (execution mode). Тоді вся моя увага була на якості продукту: я намагався нічого не пропустити, зробити так, щоб кожна дрібниця була доведена до ладу. У такому режимі я витрачаю багато часу на використання інструментів Codex.

Ми використовуємо Codex, щоб отримувати фідбек: наприклад, щоб зрозуміти обговорення в Slack і фідбек від користувачів. Я прошу Codex підсумовувати це й записувати в Linear. Також я використовую Codex для аналізу якості коду й роблю невеликі правки напряму через нього. Бо інколи швидше просто обробити маленьку проблему через Codex, ніж знаходити інших людей, координувати задачі й змушувати їх пріоритизувати, — особливо коли наша ціль була випустити застосунок за 2 тижні.

У цьому процесі, звісно, є багато “людяних” задач: підтримка команди, підбадьорення людей, мотивація, водночас залишатися критичними до продукту, який ми будуємо. Насправді я бачу, чи я в режимі виконання, за тим, наскільки часто я користуюся Twitter. Я не знаю чому, але коли мені потрібно спілкуватися з людьми, я починаю частіше користуватися Twitter.

А є ще інший режим, наприклад, зараз у мене в голові дуже чітко: ми вже перейшли в новий етап. Тепер у нас дуже сильні моделі, наприклад GPT-5.4 показує дуже добрі результати. Досвід у застосунку вже перевершив очікування — він покрив усі платформи, включно з Windows. Тож зараз я думаю, що час по-справжньому повертатися до хмари та вкладати більше зусиль саме туди.

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

Ведучий Peter: Скільки вам потрібно робити кросфункціонального узгодження?

Alex:

Усередині команди нам майже не потрібно робити багато кросфункціонального узгодження — ми свідомо уявляємо себе як команду на кшталт “піратського корабля”. Навіть у команді Codex зараз лише я та два нові продакт-менеджери, які нещодавно приєдналися. Є певні відповідальні керівники, хоча до недавнього часу більшість людей фактично напряму звітували мені, але ми просуваємо проєкт радше в розмитій формі разом, тож узгоджень усередині команди не так багато.

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

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

Це розуміння змушує нас усвідомити: нам треба думати, як зробити Codex корисним не лише для розробників. А для цього потрібно більше кросфункціонального узгодження, бо в OpenAI є ChatGPT, і багато користувачів користуються ним. Тому нам потрібно дуже обережно думати, як краще поєднати ці продукти між собою.

Romain:

З мого погляду, команда developer experience зараз трохи схожа на продовження команди Codex. Основні наші зусилля — це Codex, і є кілька причин.

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

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

Найкращий спосіб розробки зараз — це мати Codex як точку входу. Якщо повернутися на рік назад або навіть влітку минулого року, коли ми щойно випустили GPT-5, нам треба було писати багато гідів і пояснювати людям, як складати prompt для GPT-5. GPT-5 — це модель із дуже сильними можливостями міркування, і вона суттєво відрізняється від GPT-4. А зараз ми намагаємося зробити так, щоб навіть у цих сценаріях розробники могли виконувати задачі через Codex і skills.

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

Alex:

Я думаю, що у способі роботи нашої команди Codex є одна дуже цікава річ — для мене це найкраща частина: взаємодія з спільнотою. Ми дуже тримаємо зв’язок із спільнотою і в онлайні, і на офлайн-подіях.

Під час релізів наша робота дуже орієнтована на реліз — ми чітко розуміємо, коли що випускаємо; а ще ми дуже орієнтовані на фідбек — коли спільнота надає зворотний зв’язок, ми швидко діємо: виправляємо проблеми й спілкуємося з ними. Тож наша команда постійно перебуває “в онлайні”, і я вважаю це дуже важливим.

Наприклад, коли ми випускали Codex app, ми дуже тісно співпрацювали з 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 та інших особистих інструментів через командний рядок (command line interface). Через ці проєкти він фактично перетворив бачення skills і командного рядка на реальність. А coding agent, яким ми користуємося сьогодні, якраз побудований на цьому баченні.

У майбутньому цей агент буде не лише інструментом для програмування — він стане будь-яким типом personal agent. Тож Peter дає нам дуже цінний фідбек у цьому процесі, тому що він уже розробив багато інструментів, які тепер стали ключовою частиною open-source екосистеми.

Ведучий Peter:

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

Alex:

До яких систем ти під’єднав це? Ти під’єднав його до всього?

Ведучий Peter:

Так. Я під’єднав його до багатьох сервісів. Наприклад, він може отримувати доступ до моєї банківської інформації, акаунту YouTube, голосового асистента, календаря та сервісів Google. Коли я лежу в ліжку, моя дружина запитує: “Ти з ким розмовляєш?” А я відповідаю: “Я розмовляю зі своїм OpenClaw-роботом”.

Втім, зараз є багато “аутсорсерів/спекулянтів”, які беруть до 5000 доларів, щоб допомогти людям налаштувати OpenClaw. Тож якщо ви зможете зробити це більш масовим, більш простим у використанні, це стане величезним проривом. Ви реально рухаєтеся в правильному напрямку.

Традиційні кар’єрні сходинки вже не підходять

Ведучий Peter: Я пам’ятаю, що ви говорили щось на кшталт: “зараз більшості команд уже не потрібно стільки PM”?

Romain:

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

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

Тому мене найбільше захоплює те, що межі між усіма кар’єрними сходинками розмиваються. Насправді кожен із нас — “конструктор (builder)”, і всі разом співпрацюють, щоб щось збудувати.

Alex:

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

Я думаю, як ти й сказав: усі ці ролі поступово зливаються. Дизайнер може зробити більше інженерної роботи, інженер може торкатися дизайну, а PM теж може брати участь у побудові. Але інженери зазвичай мають фокус на написанні коду, тому раніше вони не брали на себе сортування задач або іншу частину проєкт-менеджменту, яку робить PM.

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

Scott Belsky пропонував ідею “collapse the talent stack” (колапс кадрового стеку). Мені подобається цей погляд, і я думаю, що це справді відбувається. **Чим менше людей потрібно тримати в кімнаті, тим лег