У подкасті Lenny’s Podcast продакт та інженерний лід десктоп‑додатку Codex в OpenAI Ендрю Амброзіно розповідає, як виглядає продуктовий менеджмент на передовій генеративного ШІ. Один із ключових викликів, який він описує, — планування в середовищі, де моделі стрибкоподібно змінюють свої можливості за лічені місяці, а значить — змінюють і шанси функцій на успіх.
Як виглядає роадмап, коли будь‑який план на дев’ять місяців уперед ризикує стати фантазією вже наступного кварталу? І як балансувати між амбіційними AGI‑формами продукту та реальним рівнем можливостей моделей «прямо зараз»?
Хибна точність: чому детальні плани на 9 місяців — самообман
Амброзіно описує доволі просте правило, яке стало у Codex базою для всього планування: чим коротший горизонт, тим більше деталізації він потребує. І навпаки — довгі горизонти свідомо залишаються розмитими.
За його словами, для горизонту на дев’ять місяців уперед будь-яка спроба «намалювати» конкретний список фіч, термінів і залежностей перетворюється на те, що він називає «фальшивою точністю». Тобто, на видимість контролю, яка не має нічого спільного з реальністю. У приклад він наводить власний досвід: те, що команда могла б напланувати в листопаді, можливо, ще відповідало б дійсності в грудні, але вже точно не збіглося б з тим, що реально сталося потім.
Усе це — наслідок темпу розвитку моделей. На прикладних продуктах, які безпосередньо залежать від якості моделі, планування розбивається об спрогнозувати «коли саме» та «наскільки саме» покращиться модель. Будь‑яка детальна сітка Gantt на дев’ять місяців вперед в такій реальності означає витрачені зусилля на артефакт, який швидко втратить сенс.
Звідси — практичний висновок: довгострокові плани потрібні, але вони мають залишатися «туманними». Це не відмова від стратегії, а визнання того, що стратегія формується на рівні напрямів, а не точних фіч і дат.
Каталог ідей + тотальне прототипування: новий каркас роадмапу
Щоб не впасти в хаос повної імпровізації, в Codex сформували іншу опору: системне прототипування «наперед».
Амброзіно описує підхід, який він ще спостерігав у попередній компанії, коли продукти почали опиратися на моделі:
спочатку команда формувала довгий список всього, що в принципі хотіла б зробити в горизонті року‑двох. Потім — прототипувала все, що можливо. Після цього сортувала: які речі достатньо готові «на зараз», а які потрібно відкласти «дозрівати».
Це — принципово інша логіка, ніж класичні роадмапи, прив’язані до стабільності технологічних залежностей. Тут якість функції безпосередньо залежить від «розумності» моделі. І, як підкреслює Амброзіно, саме це стає головним питанням: фіча хороша чи погана часто не через саму свою форму, а через те, чи модель достатньо «розумна», щоб її витягнути.
Відкладені прототипи не викидаються. Вони лежать «на полиці» до наступного великого стрибка моделей. Кожного разу, коли відбувається помітний апгрейд, команда повертається до цього каталогу ідей, замінює під капотом модель — і знову тестує ті самі форми функцій. Міняється тільки інтелект, а не UX.
У такій системі прототип — це не крок до негайного релізу, а стратегічний актив. Він стає тестовим стендом, до якого можна повертатися знову і знову, коли змінюється базова технологія.
Codex, який би провалився: як три місяці моделей змінили долю продукту
Один із найяскравіших прикладів ролі таймінгу — сам десктоп‑додаток Codex.
Амброзіно каже прямо: він упевнений, що версія Codex, яку OpenAI випустила у лютому, якби вийшла в листопаді, «абсолютно провалилася б» на ринку. І при цьому форма продукту — те, яким він є з погляду UX та концепції — лишилася б практично тією ж. Єдина суттєва відмінність — це моделі між листопадом і лютим.
Цей кейс став для команди ключовим уроком: доля продукту може змінюватися не тому, що ви інакше намалювали інтерфейс чи змінили позиціонування, а просто тому, що модель раптом починає робити свою частину роботи достатньо добре. Ті самі сценарії, та ж сама логіка — але інший рівень інтелекту під капотом.
Звідси з’являється ще одна важлива ідея: іноді один і той самий продукт доводиться випускати не один раз. Амброзіно говорить про те, що можна опинитися в ситуації, коли один і той самий «shape» — форма фічі — буде релізитися п’ять-шість разів, поки нарешті не запрацює як слід. Може не змінитися ані структура UI, ані базова ідея — але зміниться рівень моделей і, відповідно, результат.
Це радикально відрізняється від класичної продуктології, де провал фічі інтерпретується як доказ хибної гіпотези, поганого UX або ринкового небажання. У світі LLM грає роль ще один масштабний фактор: «просто зарано для цієї моделі».
Коли надто «AGI‑pilled»: провал форми, що випередила час
Ще один приклад, який наводить Амброзіно, — ранній реліз, побудований на Codex Web. Тоді користувачу пропонували задати завдання моделі, та самостійно «десь у хмарі» завершувала роботу і повертала готовий результат. Звучить знайомо для сьогоднішніх дискусій про агентів, але практично це не запрацювало.
Проблема полягала не у відсутності амбіцій. Навпаки — саме в надмірній віри в те, що модель вже здатна виконувати задачі в такому автономному режимі. На практиці вона просто не робила свою частину роботи достатньо якісно. Амброзіно формулює це жорстко: команда була «занадто AGI‑pilled для моменту».
Контраст він проводить із іншим продуктом — локальним інструментом програмування, який працював не в хмарі, не претендував на «делегування життя» моделі, а натомість вів більш діалоговий, обережний сценарій: ставив запитання, не намагався бути «повноцінним агентом». І саме цей, менш «магічний» форм‑фактор виявився набагато ближчим до того рівня, на якому перебували моделі в той момент.
Цей досвід став для Амброзіно постійним нагадуванням: на продукті не працює логіка «на межі можливого, значить, варто запускати зараз». Є небезпека спроектувати форму взаємодії з моделлю так, ніби це вже справжній AGI, тоді як реальні можливості ще далекі від цього. У такому разі продукт буде провалюватися не тому, що ідея погана, а тому, що форма занадто випереджає момент.
Фічі «наперед»: артефакти для майбутніх моделей, а не релізи «за будь-яку ціну»
Підхід «будуємо те, що ще не працює, але спрацює пізніше» стає своєрідною нормою на стику дослідження й продукту. У середовищі OpenAI ця логіка звучить часто: варто створювати штуки, які сьогодні виглядають «недостатньо розумними», але при наступному поколінні моделей раптом стануть природною частиною робочого процесу.
Амброзіно наголошує, що головна пастка тут — плутати стадії процесу. У багатьох людей залишається м’язова пам’ять: якщо код уже написаний і все виглядає як справжній продукт, це слід випустити зовні. У новій реальності це може бути катастрофічною помилкою.
Те, що команда має працюючий код, означає лише одне: з’явився артефакт, який можна тестувати проти поточних і майбутніх моделей. Не більше. Його місія — бути точкою порівняння, еталонним сценариєм, за яким можна виміряти, наскільки нова модель «дотягується» до бажаної поведінки.
Прикладом, який він згадує, є лінія продуктів на кшталт браузера й агентних експериментів усередині компанії. Різні версії «того самого» агентського підходу з’являлися в різних продуктах — десь як оператор, десь як агенти в браузері, десь як інструмент усередині десктоп‑додатку. Концептуально це одна й та сама ідея: агент, що діє через інтерфейс. Але результати різко відрізнялися залежно від того, наскільки «розумною» була модель у конкретний момент.
Звідси виникає ще один принцип: не варто бути впевненим, що функція «погана», якщо вона не спрацьовує сьогодні. Цілком можливо, що вона просто «не готова» — і її час настане після одного‑двох поколінь моделей.
Плутанина процесу: коли виглядає як продакшен, але це ще дизайн
Ще один вимір проблеми планування — те, як ШІ змінив зв’язок між формою артефакту та стадією процесу. У «старому світі» було приблизно зрозуміло: якщо щось виглядає майже як справжній продакшен‑інтерфейс, це, швидше за все, кінець процесу. За цим стоять дослідження, дизайн, погоджена бізнес‑логіка.
Тепер цей зв’язок розірвано. Дешевизна імплементації призводить до того, що на ранніх стадіях дизайну можна мати «надто гарні» прототипи, які візуально не відрізняються від справжньої фічі у продакшені. Для менеджменту та сусідніх команд це створює небезпечне спотворення: якщо все виглядає готовим, чому б не випустити?
Амброзіно постійно повертається до потреби чітко проговорювати, НА ЯКІЙ стадії дизайн‑процесу знаходиться ця «майже готова» штука. Якщо цього не робити, прототипи починають жити як «недорелізені продукти», навколо них будуються очікування, і на них тиснуть із вимогою релізу — навіть якщо з погляду користувацьких цілей, ринку або бізнесу це ще дуже ранній етап.
Це безпосередньо впливає на планування: замість того, щоб зберігати прототип як майбутній артефакт для наступних поколінь моделей, команда може зламатися під тиском і спробувати «дотягувати» поточну модель до форми, яка їй ще не під силу.
Як планувати, коли форма стабільна, а інтелект — ні
Якщо звести разом усі історії, які Амброзіно розповідає про Codex та інші продукти, вимальовується досить чітка картина нового типу роадмапу у світі швидко прогресуючих моделей:
короткий горизонт (тижні, максимум кілька місяців) планується детально: які саме фічі, в якому порядку, які цілі якості й стабільності. У цьому вікні ще можна спиратися на більш‑менш передбачувану поведінку поточних моделей.
середньостроковий і довгостроковий горизонти описуються як набір напрямів та гіпотетичних фіч, які вже мають форми у вигляді прототипів. Вони лежать у «каталозі очікування», і план полягає не в тому, щоб вписати їх у конкретні квартали, а в тому, щоб регулярно повертатися до них після оновлень моделей.
фокус зсувається із «будемо релізити це в Q3» на «як тільки модель стане достатньо сильною для цього сценарію, у нас уже є готовий артефакт і тестова обв’язка».
Одночасно з цим зростає роль продуктового смаку, який Амброзіно часто згадує в інших частинах розмови. Потрібно вміти розрізняти: де амбіція справді доречна, а де команда ризикує знову опинитися «занадто AGI‑pilled», пропонуючи користувачам форм‑фактор, який випереджає реальні можливості моделі.
У підсумку нова реальність планування виглядає не як відмова від стратегії, а як перехід до стратегії іншого типу: менше «фіксації дат», більше роботи з формами, які живуть довше за конкретні версії моделей, та готовність запускати одні й ті самі концепції неодноразово — у міру того, як інтелект під капотом наздоганяє амбіцію продукту.
Джерело
OpenAI Codex lead on the new shape of product work | Andrew Ambrosino
