У третьому епізоді серії Builders Unscripted від OpenAI продакт-лідер Alchemy Матіас Кастелло розповідає, як команда криптоінфраструктурної компанії інтегрувала Codex у свої щоденні процеси. Від перших експериментів зі Slack до повноцінного «AI‑колеги» в рев’ю коду та спільного репозиторію навичок для продакт-менеджерів — історія Alchemy показує, як швидко AI може стати базовим шаром інженерної культури.
Перший крок: Codex у Slack замість локального запуску документації
Початок впровадження AI в Alchemy виглядав максимально прагматично. Команда не стартувала з амбітних агентів чи повної перебудови пайплайнів розробки. Першою точкою входу стала, здавалося б, дрібна, але болюча рутина — правки в розробницькій документації.
Раніше, щоб змінити кілька речень у девелоперських доках, потрібно було локально підняти сайт, пройти повний цикл збірки й деплою, дотримуючись усіх внутрішніх процедур. Для інфраструктурної компанії з технічним продуктом це не просто «редагування тексту», а повноцінна інженерна операція з усіма накладними витратами.
Приблизно за рік до інтерв’ю Alchemy підключила Codex у Slack. У внутрішньому каналі, присвяченому документації, з’явився бот, якому можна було просто написати, що саме потрібно змінити. Замість локального запуску сайту розробники й продакти почали формулювати запити природною мовою, а Codex вносив правки в доки.
Цей крок важливий не лише як зручність. Він показав кілька принципових речей.
По-перше, AI можна вбудувати в уже існуючі інструменти командної роботи, не змінюючи радикально стек. Slack залишився тим самим, просто в ньому з’явився новий «учасник».
По-друге, навіть невеликі сценарії — на кшталт редагування документації — можуть стати безпечним полігоном для перевірки можливостей моделі. Команда бачила результат, могла швидко його перевірити й відкотити, якщо щось піде не так.
По-третє, саме такі «маленькі перемоги» знімають скепсис щодо застосування LLM у професійному середовищі. Коли AI стабільно справляється з рутинними, але критичними завданнями, з’являється довіра, необхідна для наступного, значно серйознішого кроку — допуску моделі до коду.
Ретроспективне рев’ю коду: момент, коли AI довів свою цінність
Справжній перелом у ставленні до AI в Alchemy стався тоді, коли Codex уперше застосували до коду, що вже спричинив інцидент у продакшені.
Компанія пережила невеликий, але показовий інцидент, пов’язаний із масштабною міграцією, яка відбулася кількома місяцями раніше. Як це часто буває з великими змінами, у коді залишилася прихована помилка — гонка (race condition), яка врешті проявилася в продакшені.
Після інциденту команда провела внутрішній постмортем, знайшла й виправила причину. На цьому етапі хтось запропонував зробити експеримент: прогнати той самий фрагмент коду через Codex у режимі ретроспективного рев’ю й перевірити, чи зможе модель виявити проблему.
Codex знайшов ту саму race condition.
Це був не просто вдалий збіг. Експеримент повторили на інших кейсах, і результат знову виявився переконливим. Для команди це стало сигналом, що модель здатна аналізувати великий, складний код, пов’язаний із критичною інфраструктурою, і знаходити реальні дефекти, які прослизнули повз людський погляд.
Саме цей досвід Матіас називає поворотним моментом. Якщо Slack‑бот для документації був зручністю, то ретроспективне рев’ю продакшен‑інциденту показало, що AI може впливати на ключові метрики надійності — кількість інцидентів, час на їх виявлення та виправлення, стабільність платформи.
Цей кейс також підсвітив ще одну важливу зміну: AI перестав сприйматися як «іграшка для експериментів» і почав розглядатися як інструмент, який варто системно вбудовувати в інженерні процеси.
Codex як колега в pull request: нова соціальна динаміка в код-рев’ю
Після успішних ретроспективних експериментів Codex поступово перейшов у «бойовий режим» — безпосередньо в процес рев’ю pull request’ів. І тут відбулася, можливо, найцікавіша трансформація: інженери почали поводитися з AI як із повноцінним членом команди.
Матіас описує сцену, яка добре ілюструє цю зміну. Один із інженерів відкрив pull request, а в коментарях до нього з’явився тег на Codex — фактично згадка моделі як користувача. Далі розгорнувся діалог: Codex залишає зауваження, інженер вносить правки, знову викликає Codex, отримує новий раунд коментарів і повторює цикл.
Це не разовий запуск інструмента, а справжня ітеративна співпраця. Інженер не просто «запитав поради в моделі», а інтегрував її в звичний ритуал рев’ю, де зазвичай фігурують колеги по команді.
Такий сценарій змінює одразу кілька речей.
По-перше, зменшується психологічний бар’єр. Коли AI згадують у PR так само, як живого рев’юера, модель перестає бути «чорною скринькою» десь у сторонньому інтерфейсі й стає частиною командного простору.
По-друге, з’являється новий тип «парного програмування», де людина й AI по черзі пропонують зміни. Інженер зберігає контроль, але отримує постійний, структурований фідбек, який не втомлюється й не відволікається.
По-третє, це створює нову норму якості. Якщо Codex стабільно знаходить певний клас помилок або пропонує покращення, команда поступово підтягує свої стандарти до цього рівня. AI стає не лише інструментом контролю, а й носієм «колективного досвіду», який акумулюється в моделі.
Матіас підкреслює, що саме перехід до такого режиму використання Codex у рев’ю коду став справжнім трампліном для ширшого впровадження AI в інженерні робочі процеси Alchemy. Коли розробники побачили, що модель може бути надійним «товаришем по рев’ю» у великій, складній кодовій базі, скепсис щодо її професійної придатності суттєво зменшився.
Від Datadog до GPT 5.5: як AI‑рев’ю змінює картину інцидентів
Досвід Alchemy не унікальний. Подібні експерименти проводили й інші технологічні компанії, які намагалися зрозуміти, наскільки AI‑рев’ю могло б змінити їхню історію продакшен‑інцидентів.
Один із показових прикладів — Datadog. На початку року компанія проаналізувала свої минулі інциденти й оцінила, що понад один із п’яти випадків можна було б попередити, якби Codex брав участь у рев’ю коду до деплою. Це не гіпотетичні «можливі покращення», а конкретні інциденти, які вже сталися й були розібрані постфактум.
Ця цифра — понад 20% — задає важливу планку. Вона показує, що навіть на відносно ранніх етапах розвитку моделей AI‑рев’ю здатне істотно знизити кількість продакшен‑збоїв. Для компаній, які працюють із критичною інфраструктурою, це безпосередньо конвертується в менше простоїв, менше SLA‑порушень і нижчі операційні витрати.
На цьому тлі звучить оцінка, яку озвучує ведучий розмови Ромен Юе: з появою GPT 5.5 потенціал AI‑рев’ю може зрости до того, щоб виявляти більше половини інцидентів ще до продакшену, а в перспективі — до дев’яти з десяти. Формулювання залишається обережним — «можливо», «легко більше половини» — але вектор зрозумілий: зі зростанням можливостей моделей зростає й частка дефектів, які вони здатні виявити.
Це має кілька наслідків для інженерних організацій.
По-перше, змінюється економіка якості. Якщо раніше глибоке рев’ю кожної зміни вимагало значних людських ресурсів, то тепер значну частину цього навантаження може взяти на себе AI, залишаючи людям складніші, контекстні рішення.
По-друге, з’являється можливість системно переглядати історичні інциденти й будувати «AI‑фільтри» під конкретні патерни помилок, характерні для певної кодової бази чи домену.
По-третє, AI‑рев’ю поступово перетворюється з «опції» на очікуваний елемент пайплайну. Якщо є технологія, здатна запобігти значній частині інцидентів, її невикористання стає важко виправдати перед бізнесом.
Досвід Alchemy, Datadog та інших компаній показує, що питання вже не в тому, «чи варто» підключати AI до рев’ю коду, а в тому, як саме це зробити так, щоб модель органічно вписалася в існуючі процеси й не перетворилася на ще один «шумний» інструмент.
Спільний репозиторій навичок Codex: як AI стає інструментом не лише для інженерів
Попри те, що найбільш вражаючі ефекти AI видно в інженерії, в Alchemy Codex активно використовують і за межами чистого коду. Особливо це помітно в продакт‑менеджменті, де багато завдань пов’язані з текстом, аналізом і структуризацією інформації.
Матіас описує внутрішню практику створення «навичок» Codex — налаштованих сценаріїв, які допомагають виконувати типові задачі продакт‑менеджера. Серед них — написання PRD (product requirement documents), аналіз зворотного зв’язку від клієнтів, підготовка різних робочих документів.
Ключовий момент у тому, що ці навички не залишаються приватними інструментами окремих людей. В Alchemy їх збирають у спільному репозиторії, доступному різним функціям у компанії. Це створює кілька важливих ефектів.
По-перше, відбувається стандартизація. Якщо вся команда користується однаковими AI‑шаблонами для PRD, документи стають більш уніфікованими за структурою й змістом. Це полегшує читання, рев’ю та прийняття рішень.
По-друге, знижується поріг входу в продакт‑задачі для людей з інших функцій. Інженери, дизайнери чи фахівці з підтримки можуть скористатися тими самими навичками Codex, щоб підготувати, наприклад, чернетку документа або провести первинний аналіз фідбеку. AI тут виступає як «протез компетенції», який дає змогу виконувати нетипові для ролі завдання на прийнятному рівні.
По-третє, знання перестають бути прив’язаними до окремих людей. Якщо хтось налаштував особливо вдалий сценарій аналізу клієнтських відгуків, він потрапляє в спільний репозиторій і стає частиною колективного інструментарію. Це зменшує ризик «втрати експертизи» при зміні складу команди.
Фактично Alchemy будує внутрішню бібліотеку «AI‑процедур», яка доповнює традиційні гайдлайни й документацію. Якщо раніше знання описувалися переважно у вигляді текстових інструкцій, то тепер вони все частіше кодуються у вигляді налаштованих AI‑навичок, які можна викликати й перевикористовувати.
Розробник як людина й як агент: як Alchemy переосмислює свою платформу
Впровадження Codex усередині компанії неминуче вплинуло й на те, як Alchemy бачить своїх зовнішніх користувачів — розробників, які будують продукти на базі криптоінфраструктури компанії.
Матіас описує дві паралельні трансформації.
Перша стосується людських розробників. В Alchemy виходять із припущення, що сьогодні практично 100% девелоперів створюють софт із допомогою AI. Це не гіпотеза на майбутнє, а робоча аксіома, яка впливає на дизайн платформи. Документація, SDK, API, інструменти дебагу — усе має бути зручним не лише для людини, а й для її AI‑асистента, який читає, генерує й модифікує код.
Друга трансформація — поява нового типу «розробника», яким стає автономний агент. Це системи, здатні самостійно приймати рішення про інтеграцію з інфраструктурою, реєструватися на платформі, викликати API й виконувати операції в блокчейні без безпосередньої участі людини в кожному кроці.
Для таких агентів потрібні інші інструменти. Якщо людському розробнику важливі туторіали, приклади коду й UI‑консолі, то агенту потрібні чіткі, машинно‑читані інтерфейси для реєстрації, авторизації та виконання транзакцій. Платформа має бути готовою до того, що «користувачем» стане не людина за ноутбуком, а автономна система, яка діє в межах заданих політик.
Матіас формулює завдання свого продакт‑напрямку як пошук балансу між цими двома світами. З одного боку, потрібно адаптувати Alchemy до нової реальності, де кожен людський розробник працює в тандемі з AI. З іншого — закладати фундамент для сценаріїв, у яких на платформу приходитимуть уже не люди, а агенти, що діють автономно.
Поки що ці два типи «розробників» мають різні потреби, але в перспективі вони можуть зблизитися. Людські команди, підсилені AI, і повністю автономні агенти, ймовірно, працюватимуть у схожих середовищах, використовуючи однакові API й інфраструктуру. Для Alchemy це означає необхідність мислити наперед і будувати платформу, яка витримає таку конвергенцію.
Висновок: AI як новий базовий шар інженерної культури
Історія Alchemy з Codex показує, як поступово, але невідворотно AI перетворюється з допоміжного інструмента на базовий шар інженерної та продакт‑культури.
Почалося все з невеликого, але болючого фрагмента рутини — правок у документації через Slack. Потім був ретроспективний експеримент із продакшен‑інцидентом, який довів, що модель здатна знаходити реальні, складні помилки в коді. Далі — інтеграція Codex у повсякденне рев’ю pull request’ів, де AI став сприйматися як ще один «колега» в команді.
Паралельно розвивався інший фронт — створення спільного репозиторію навичок Codex для продакт‑менеджерів та інших функцій. Це дозволило не лише прискорити типові задачі, а й зробити їх доступними для ширшого кола людей, зменшивши залежність від окремих експертів.
На тлі цього внутрішнього досвіду Alchemy переосмислює й свою зовнішню роль: компанія будує інфраструктуру для світу, де кожен розробник працює з AI, а на платформу все частіше приходитимуть не лише люди, а й автономні агенти.
Усі ці зміни відбуваються без гучних декларацій про «кінець традиційної розробки». Навпаки, історія Alchemy — це радше про те, як крок за кроком, через конкретні кейси й вимірювані результати, AI вбудовується в реальні робочі процеси. І як у якийсь момент стає важко уявити, як усе це взагалі працювало без нього.
Джерело
Builders Unscripted: Ep. 3 – Matias Castello, Product Leader at Alchemy