У розмові на подкасті Lenny’s Podcast продуктово‑інженерний лідер Codex у OpenAI Ендрю Амброзіно пояснює, навіщо команда взагалі взялася за окремий десктоп‑додаток, як він використовується всередині компанії і чому має стати «домашньою базою» для будь‑якої знань‑роботи — від коду до відеомонтажу. Це не історія про ще один «чатбот у віконці», а про поступове перетворення Codex на центр тяжіння для всіх інструментів, якими користується людина на комп’ютері.
Від «писати код у Codex» до «керувати продуктом у Codex»
Особиста планка Амброзіно на старті була максимально конкретною: Codex мав стати його основним середовищем розробки.
Він описує свою ціль так: зробити додаток «тою річчю, якою я пишу код», настільки хорошим у розробці, щоб можна було «будувати сам Codex у Codex». На ранньому етапі це був передусім інструмент для розробників: фокус на коді, вузький сценарій, швидкий «догфудинг» — коли ти одночасно розробляєш продукт і працюєш у ньому щодня.
Але як тільки додаток отримав внутрішній продуктовий fit серед інженерів та дослідників, роль і продукту, і самого Амброзіно почала змінюватися. Йому довелося менше писати код і більше займатися управлінням командою, дослідженням продукту, координацією роботи.
Відповідно змінився і спосіб використання Codex: замість того, щоб просто «писати код у додатку», він почав використовувати його для того, щоб «робити більше продуктового дисквері», будувати «правильні лупи» для того, щоб бачити, над чим працює команда, і «стирати речі, які збиваються з курсу». Codex із вузького дев‑інструмента непомітно перетворюється на робочу консоль керівника продукту.
Автоматизація релізів: Slack, pull request’и та «Codex для майже всіх»
Ключовим моментом став реліз, який усередині команди сприймають як «Codex для майже всіх». Саме тоді у додатку з’явилися вбудований браузер, «computer use» і можливість створювати артефакти — тобто не тільки писати код, а й працювати з іншими програмами та файлами.
Амброзіно згадує координацію цього релізу як перший випадок, коли він відчув себе «на вістрі» нової моделі продуктового менеджменту. Замість того, щоб вести реліз вручну в таблицях і документах, він:
- автоматизував збір оновлень зі Slack‑каналів;
- тягнув статуси з pull request’ів;
- оновлював трекер статусів через Codex.
Цей досвід він описує як «на той момент я відчував, що перебуваю на передньому краї того, як керувати продукт‑релізом». Сьогодні такі конфігурації вже починають сприйматися як буденність, але для команди це була точка переходу: Codex уперше став не просто інструментом для створення продукту, а власне інструментом управління життєвим циклом релізів.
Ранок із Codex: дайджест 3000 Slack‑каналів і «п’ять запитань»
Ще один шар використання — особистий робочий день керівника. Амброзіно детально описує, як виглядає його ранок із Codex.
Він «прокидається, бачить щоденний бриф» — стиснений огляд із «усього з 3 000 Slack‑каналів», у яких він формально присутній, але фізично не може прочитати вручну. Codex показує, які речі «потребують його уваги». Далі Амброзіно просто пише додатку: «Добре, дай мені п’ять запитань, і я відповім». На основі кількох відповідей модель вже коригує пріоритети й фокус на наступний день.
Технічно це реалізовано як набір автоматизацій і задач за розкладом. Він створює «scheduled task», де описує, через які Slack‑канали пройти і «які речі його цікавлять і є найважливішими». Перші кілька запусків потребують «кермування» — Codex треба пояснити, що було пропущено, що переоцінено, які типи подій мають більшу вагу. Але замість того, щоб лізти в налаштування і шукати, де змінити інструкції, достатньо написати в чаті: «Гей, наступного разу, коли це запускатиметься, можеш, будь ласка, більше перейматися ось цим» або «ця подія не потрапила в бриф, додай такий патерн». Модель оновлює шаблони і змінює спосіб, яким формує майбутні дайджести.
За словами Амброзіно, поки що це швидше фаза продуктового відкриття: він як лідер команди має «час і мотивацію» налаштовувати такі сценарії, бо це безпосередньо впливає на розвиток самого продукту. Але для зовнішніх користувачів, які не працюють в OpenAI, не є прийнятним витрачати години на майстрування таких лупів. І саме тут зіштовхуються два світи: гнучкість «чистого» агента і потреба у простому, зрозумілому UX.
«Скажи додатку, що тобі потрібно»: як Codex сам налаштовує конектори
Амброзіно наполягає: мінімум, який має дати такий додаток, — це можливість «просто запитати його», якщо користувач не знає, як щось зробити. Цей принцип поширюється і на підключення зовнішніх сервісів.
Якщо користувач каже: «Хочу автоматизацію, яка щоранку дивиться мій Slack і робить ось це», Codex не лише пише потрібний код або конфігурацію, а й сам пропонує додати необхідні інтеграції. Амброзіно наводить типовий сценарій: додаток каже «У мене немає Slack‑конектора. Можу додати Slack‑конектор?» — користувач тисне «Так», і далі Codex сам все налаштовує.
«Найменше, що ми можемо зробити, — це зробити так, щоб якщо ви не знаєте, як щось зробити в додатку, ви могли просто запитати про це», — пояснює Амброзіно. Він одразу додає: цього «недостатньо» як кінцевого UX, але це базовий поріг, нижче якого опускатися не можна.
Ця логіка суттєво відрізняє Codex від традиційних «конструкторів автоматизацій», де користувач змушений знати існування тригерів, вебхуків, OAuth‑клієнтів і так далі. Тут завдання формулюється природною мовою, а «рутинна» частина — додавання конекторів, налаштування доступів, створення тасків — делегується самому додатку.
Від CLI до десктопу: чому всі тікали з інших продуктів назад у Codex
Характерна риса еволюції Codex — те, як внутрішні користувачі компанії самі голосували «ніжками» за його форму.
Початково Codex існував як CLI‑інструмент. Потім команда вирішила створити окремий додаток. Сам Амброзіно зізнається, що ставилися до нього «з певною невизначеністю»: бачили потенціал як девелоперського інструмента, але не як повноцінного середовища на кшталт IDE. Візія полягала в «правильно розміреній поверхні»: «щось на кшталт чат‑бота, але більше, ніж чат‑бот», з можливістю бачити код, але без прямого редагування.
Поки цей новий Codex тестували всередині, він швидко знайшов «внутрішній PMF» серед інженерів і дослідників. І тут сталося несподіване: співробітники з маркетингу, комунікацій, фінансів, юридичного відділу — «фактично кожна дисципліна» — почали активно користуватися цим інструментом, попри те, що він був «активно ворожий» до їхніх сценаріїв. Інтерфейс показував код, просив підтвердити запуск складних дій, у кожній дрібниці був «заточений» під девів, але саме цим додатком користувалися всі.
Реакція менеджменту була логічною: якщо Codex такий корисний, треба «принести його у правильні поверхні» для інших ролей — в десктопний клієнт ChatGPT, в Atlas‑браузер тощо, конвертувати це в «загальний інструмент для знань‑роботи». Але найнеприємніша (і найпоказовіша) проблема полягала в тому, що «ніхто не хотів залишати Codex‑додаток» заради інших інтерфейсів, «нібито призначених» для їхніх персон.
У підсумку це привело команду до переконання: форма, яку вони випадково знайшли для Codex, — «правильна» не лише для розробників. У ній настільки вдало поєднуються агенти, код і робота з іншими застосунками, що на її основі можна розгортати й «глибокі вертикальні сценарії» для нефахових технічних ролей — фінансів, науки, юридичної роботи.
Ключ, на думку Амброзіно, — у правильних «примітивах розширюваності» та загальній моделі: якщо вони спроєктовані грамотно, «з цим можна зробити все, що завгодно».
Codex як «домашня база» для всіх ваших застосунків
Ця впевненість виявляється у візії майбутнього: Codex має бути не просто «ще одним додатком», а саме «домашньою базою».
Амброзіно описує її так: це «чудове місце, щоб тримати в голові всі речі, які вам потрібно зробити, по різних поверхнях». Частину завдань користувач виконує прямо в Codex, частину — додаток робить, «відкриваючи інші застосунки». Після завершення завдання сторонні програми можна закрити: Codex вже «поговорив» з ними, зробив потрібне і оновив загальну картину справ.
Показовий приклад — інтеграція з Microsoft Excel. У Codex є власний редактор таблиць, але команда чесно визнає: «чи достатньо цього для людей, які роблять фінансове моделювання для залучення мільярдів доларів? Швидше за все, ні». Тому Codex «розмовляє безпосередньо» з аддіном Excel на десктопі: відкриває документ, вносить зміни, після чого користувач може закрити Excel і повернутися в основне середовище. З точки зору користувача, все, що має значення, — це те, що робота почалася, завершилася й автоматизувалася в одному місці.
Ця логіка поширюється і на веб‑додатки, і на важкі професійні інструменти. Codex не намагається замінити собою кожен спеціалізований софт, але прагне стати шаром, який:
- розуміє, що саме ви робите в тому чи іншому інструменті;
- може брати на себе частину роботи всередині цих застосунків;
- з’єднує фрагменти діяльності в цілісний, керований потік.
Відеоредактор, який навчив Codex будувати свої розширення
Напевно, найяскравіша ілюстрація цієї моделі — історія внутрішнього відеографа OpenAI Брента, який отримав завдання змонтувати ролики про Codex, зняті у тій самій студії, де записувався подкаст.
Почалося все з простої цікавості: чи зможе Codex допомогти у відеомонтажі. Формально «Codex не є відеоредактором», в ньому немає жодного відповідного UI. Але модель швидко зрозуміла, що Брент використовує Premiere Pro, і змогла робити частину правок, безпосередньо редагуючи файли, які стоять «під капотом» того, що видно в інтерфейсі Premiere.
Цього вистачило не на все. Тоді стався принциповий стрибок: «природним чином», каже Амброзіно, Codex вирішив побудувати для себе розширення, яке можна встановити в Premiere Pro, і з яким додаток надалі міг би спілкуватися. Далі сценарій виглядав так: Codex каже своєму ж розширенню «гей, розширення Premiere Pro, будь ласка, зміни цей маркер усередині Premiere Pro» — і отримує доступ до функцій, які раніше були лише у ручного користувача.
Для команди це був показовий момент: додаток, який формально «уміє писати код», спочатку використовує готову екосистему (файли Premiere), а потім, натрапивши на обмеження, розширює її під себе — створює плагін, з яким уже може працювати як з рідним інтерфейсом.
Амброзіно називає це «крутою моделлю»: замість того, щоб будувати «кращий відеоредактор», Codex стає інструментом, який:
- вміє «безшовно взаємодіяти» з наявними спеціалізованими програмами;
- делегує їм власне доменно‑специфічний інтерфейс;
- але сам бере на себе логіку, автоматизацію й інтеграцію між ними.
Той самий підхід застосовується і до веб‑додатків, якими пропонує керувати з Codex інший гість подкасту, і до настільних програм. Десь Codex «втягує» сторонній продукт в себе, відкриваючи його в браузері під власним контролем, десь, навпаки, «виходить назовні», підключаючись через конектори, computer use або написані ним же розширення.
Що це означає для майбутнього десктопу
Коли Амброзіно говорить про мету «зробити Codex найкращим десктоп‑додатком, який коли‑небудь існував», за цим стоїть не реклама, а досить чітке розуміння місця цього продукту в екосистемі:
- Codex не хоче замінити всі інші інструменти, але хоче знати, як із ними працювати.
- Він прагне бути першим вікном, яке ви відкриваєте, сідаючи за комп’ютер, і останнім, яке закриваєте наприкінці дня.
- Він розмиває межу між «чатботом», «IDE», «менеджером завдань» і «панеллю керування комп’ютером», але не скасовує жоден із цих класів додатків.
Важливий нюанс: усе це поки що ще не «готовий світ майбутнього», а радше низка конкретних експериментів і робочих звичок всередині OpenAI. Але набір історій — від ранкових брифів по Slack і автоматизації релізів до Excel‑моделей і Premiere Pro — показує, як уявлення про десктопний додаток поступово зміщується від «однієї програми серед інших» до «узагальненого агента, який знає ваш робочий ландшафт краще за вас самих».
Як швидко ця модель вийде далеко за межі OpenAI — питання вже не до Амброзіно. Але судячи з того, що всередині компанії «майже сто відсотків» співробітників щотижня користуються Codex, і це давно не лише інженери, десктоп як «домашня база» для агентів уже перестав бути теоретичним сценарієм.
Джерело
OpenAI Codex lead on the new shape of product work | Andrew Ambrosino