Я вже подивився один і той самий фільм у кількох компаніях. Керівництво купує ліцензії на AI-інструменти для коду на весь інженерний відділ. Через шість тижнів адопція розколюється на два табори: інженери, які спробували інструмент двічі, отримали посередню підказку і тихо повернулися до старого workflow, — та інженери, які генерують ним половину своїх діфів і пушать їх у рев’ю швидше, ніж будь-хто встигає читати. Обидва табори скажуть вам, що rollout вдався. Не має рації жоден.
Різниця між командами, які отримують від цих інструментів компаундну цінність, і командами, які отримують хаос, — не в інструменті. Вона в rollout. А rollout — це інженерний проєкт, з тими самими модами відмови, що й будь-який інший: неясні вимоги, немає критеріїв приймання, немає вимірювання, і ніхто ним не володіє.
Чому rollout’и AI-інструментів провалюються?
Більшість rollout’ів AI-інструментів для коду провалюються, бо до них ставляться як до закупівлі, а не як до інженерії. Ліцензії роздаються, виходить анонс у Slack, і кожен залишається відкривати інструмент наодинці. Без спільних конвенцій, guardrails у рев’ю та чесного вимірювання команда розколюється на не-користувачів і над-користувачів — а code review тихо вбирає збиток.
Цей збиток — та частина, яку ніхто не закладає в бюджет. Рев’юер, який раніше читав 200-рядковий діф, написаний колегою, тепер читає 600-рядковий діф, написаний моделлю і проглянутий колегою по діагоналі. Соціальний контракт рев’ю — «я перевірив це, перш ніж надіслати тобі» — ламається беззвучно. Якщо ви читали мої правила про те, коли НЕ використовувати AI-інструменти, ви вже знаєте мою позицію: ці інструменти — чудові слуги і жахливі працівники без нагляду.
П’ять мод відмови достатньо передбачувані, щоб планувати проти них:
| Мода відмови | Як це виглядає на землі | Чого це вам насправді коштує |
|---|---|---|
| Тихе неприйняття | Інженери спробували інструмент двічі, отримали посередню підказку, повернулися до старого workflow | Ліцензії горять, а організація доходить висновку «AI не працює на нашій кодовій базі» — і перестає питати чому |
| Над-довіра | 600-рядкові згенеровані діфи йдуть у рев’ю швидше, ніж будь-хто встигає їх читати | Рев’ю деградує до штампування; дефекти потрапляють у main з двома апрувами |
| Непозначена генерація | Ніхто не може сказати, який код написано, а який згенеровано | Рев’юери застосовують хибний рівень прискіпливості до обох, і презумпцію довіри отримує не той |
| Витік у промпт | Креденшели, дані клієнтів або неопубліковані показники, вставлені в промпт, щоб «дати йому контекст» | Compliance-інцидент, який ніхто не залогував, виявлений пізніше кимось ззовні |
| Немає baseline | Вимірювання спроєктоване після rollout — або ніколи | Ви не можете сказати, чи спрацювало, тож рішення розширювати чи закривати ухвалюється на відчуттях |
Що треба оцінити перед вибором інструменту?
Оцінюйте на власній кодовій базі, а не на демо. Візьміть три реальні задачі з минулого спринту — багфікс, невелику фічу, рефакторинг — і проженіть їх через кожен інструмент-кандидат із двома-трьома інженерами різної сеньйорності. Оцініть результати за вашою власною планкою рев’ю: коректність, відповідність стилю, якість тестів. Інструмент, який блищить на greenfield-застосунку зі списком справ, може сильно спіткнутися об ваш дванадцятирічний моноліт.
Оцінка важлива і з другої причини: вона виробляє ваших перших внутрішніх експертів. Інженери, які її провели, тепер можуть сказати перед командою: «він по-справжньому добрий у X, він небезпечний у Y» — з прикладами з вашого власного репозиторію. Ця довіра варта більше за будь-який вендорський бенчмарк, і це база, на якій будується мій курс із Claude Code, коли вчить конфігурації раніше за використання: інструмент, який судять за несконфігурованим досвідом, завжди програє.
Куди ставити guardrails?
Guardrails належать code review, а не кроку генерації. Ви не можете контролювати, що виробляє модель, але ви повністю контролюєте, що мержить ваша команда. Три правила покривають більшість: згенерований код позначається як такий в описі PR; діфи вище порога розміру розбиваються до рев’ю; і автор мусить уміти пояснити будь-який рядок, про який спитає рев’юер, — «це написала модель» відповіддю не є.
Правило пояснюваності — несуче. З мого досвіду, воно ще й тихо лагодить табір над-користувачів, бо пояснювати 600-рядкову згенеровану зміну рядок за рядком — більше роботи, ніж самому написати 200-рядкову. А це рівно той стимул, який потрібен.
Хто надіслав діф, той і володіє діфом. Одна ця фраза, реально проведена в рев’ю, робить для адопції AI-інструментів більше, ніж будь-який конфігураційний файл.
Зауважте: ці guardrails — процес, а не технологія. Промптова сторона — як отримати вихід, що проходить вашу планку рев’ю з першого разу, а не з третього, — це навичка, якої можна навчитися, і саме для неї існує курс із prompt engineering. Але процес іде першим; вправний промптинг усередині зламаного процесу просто виробляє поганий код швидше.
Що має бути в політиці?
Придатна AI-політика вміщується на одній сторінці і відповідає на три питання: що можна генерувати (бойлерплейт, тести, міграції — так; security-чутливі шляхи — з підписом іменованого рев’юера), що ніколи не має потрапляти в промпт (креденшели, дані клієнтів, неопубліковані фінансові показники) і як рев’юїться згенерований код (guardrails вище). Усе, що довше за сторінку, — документ, з яким люди погоджуються не читаючи.
Розділ «що ніколи не має потрапляти в промпт» — той, який хвилює ваших юристів, і той, який інженери порушують випадково, а не зі злого наміру. Зробіть його конкретним: назвіть реальні системи і класи даних вашої компанії. «Будьте обережні з чутливими даними» не захищає нікого; «ніколи не вставляйте нічого зі схеми billing» — захищає.
Як виміряти, чи це працює?
Вимірюйте метрики, які вже відстежуєте, до і після — cycle time, швидкість обороту рев’ю, defect escape rate, частоту ревертів. Утримайтеся від винаходження нових AI-специфічних метрик у перший квартал: «прийняті підказки» — вендорська метрика марнославства, яка нічого не каже про те, чи вартий був код прийняття. Якщо інструменти працюють, нудні метрики доставки зрушать; якщо не зрушили — ви дізналися щось чесне.
Дизайн «до/після» важливіший за вибір метрики, і зняття baseline — саме той крок, який команди пропускають. Зніміть baseline на фазі оцінки, до широкого rollout, — інакше вам не буде з чим порівнювати. Це найчастіша помилка вимірювання, яку я бачу. І відзвітуйте про результат у будь-якому разі. Rollout, який не показав вимірного ефекту за квартал, — це не провал звітності; це знахідка, за якою варто діяти.
Послідовність, яка працює
Якщо стиснути все вище в послідовність: оцініть на власному коді малою групою, напишіть односторінкову політику, поставте guardrails у рев’ю, зніміть baseline, потім розкатуйте команда за командою з внутрішнім експертом, прикріпленим до кожної хвилі. Шість тижнів від оцінки до повного rollout — реалістично для організації у 20–50 людей. Стрибок одразу до «ліцензію отримують усі» заощаджує ці шість тижнів і коштує вам року низькодовірливої адопції, який іде за ним, — як це виглядає зсередини, я писав у моїх шести місяцях Claude Code у продакшені.
Це ж рівно та робота, яку ми робимо з командами як сервіс: оцінка на вашому стеку, guardrails, відкалібровані під вашу культуру рев’ю, політика і дизайн вимірювання — дивіться AI tools enablement, якщо волієте провести rollout з тим, хто вже робив це раніше. У будь-якому разі ведіть його як інженерний проєкт. Ваш процес рев’ю — і рік адопції після нього — скажуть вам дякую.
