Ваші системи вже мають сліпі зони. ШІ лише погіршує їх.

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

Тоді я думав про розростання SaaS, а не про код, згенерований ШІ. Але сьогодні моя філософія ще більш нагальна і важливіша, щоб її підтримувати.

Багато з нас прочитали звіт DORA 2025, який виявив, що, на відміну від попереднього року, впровадження ШІ тепер позитивно корелює з продуктивністю доставки. Під цим результатом стояло те, що нестабільність доставки продовжувала зростати, і вони перевіряли, чи покривають швидкісні вигоди це. Вони не покривають. Це відповідає нашому досвіду. Наша команда впровадила агентний розробковий процес і побачила 48% зростання продуктивності протягом двох кварталів, а потім 16% зростання проблем зі стабільністю. Десять людей – це невелика вибірка, але це також вибірка, з якої я можу бачити повну картину, і тенденція залишилася.

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

Розрив завжди був. ШІ лише розширив його.

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

Головне спостереження не моє. DORA підкреслює це вже два роки: ШІ підсилює все, що вже відбувається в організації, і сильні, і слабкі сторони. Команда з чистою архітектурою та здоровими практиками рев’ю працює швидше. Команда, яка лише частково впоралася з хаотичним технічним боргом, щоб випустити код, тепер виявляє, що технічний борг перетворюється на серйозну перешкоду. Однак таке формулювання не пояснює, чому це так часто вражає команди. ШІ не приховував ці слабкості; системи, на які ми покладалися, ніколи їх не виявляли.

Система тикетів і звітності, яку використовують більшість інженерних організацій, була створена для відповіді на питання, що виникають у людей, у людському темпі, людьми, які приблизно розуміли, що означає «завершено» для конкретного завдання. Це ніколи не був ідеальний запис. Це завжди була апроксимація, заповнена кимось, хто підсумовував більш хаотичну реальність під нею. Тепер ШІ додає обсяг і нові вхідні дані, які генерують нову активність. Жодна з систем (або інструментів), що використовуються для традиційних, не‑ШІ методів розробки, не була створена для цього.

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

Є справедливе заперечення. звіт ROI DORA 2026 описує J‑криву: падіння продуктивності одразу після впровадження, зумовлене кривою навчання, вартістю перевірки коду, згенерованого ШІ, та нижчестоящими процесами, які ще не наздогнали. Вони називають це «вартістю навчання» трансформації і попереджають лідерів не плутати це з провалом. Це зрозуміло. Але вартість навчання і реальна проблема виглядають однаково на панелі, створеній з тикетів. Якщо ви не можете визначити, у якій ситуації ви знаходитесь, ви не проявляєте терпіння. Ви вгадуєте.

Потрібно повернутися до основ. Пізнай себе. Пізнай свою команду. Пізнай, які проблеми ви вирішуєте.

Як за допомогою ШІ «пізнати себе»?

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

Сліпа зона 1: Театр швидкості

Більше комітів і більше PR‑ів може виглядати як прогрес, і часто це так. ШІ автоматично збільшує обидві кількості. кейс‑стаді Стенфорда показало, що впровадження ШІ підвищило кількість PR на 14%. Але те, що ви пропускаєте, — це скільки з цієї активності становить робота над функціоналом, який випускається, а скільки — технічне обслуговування, переробка або шум від рефакторингу, який не затримався.

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

Сліпа зона 2: Борг рев’ю

Здатність до перегляду не масштабується автоматично разом із обсягом виходу. Податок на верифікацію не є фазою, яку ви проходите; це частина постійних витрат на агентну розробку. A нещодавнє опитування інженерних лідерів виявило, що 80% команд витрачають принаймні 10% свого часу на перегляд, і приблизно одна з десяти — більше 40%. За такого навантаження команди коливаються між зростаючою затримкою та формальним схваленням, і жоден варіант не є справжньою відповіддю.

Обмеження випуску більше не полягає в тому, як швидко пишеться код. Це те, наскільки швидко людина може бути впевнена, що зміна правильна, те, наскільки швидко і точно можна виявляти та усувати дефекти. Слідкуйте, як навантаження на перегляд розподіляється по вашій команді; інакше ви ризикуєте перевантажити старших інженерів, затримати випуски або спричинити серйозні проблеми у продакшн‑середовищі.

Сліпа зона 3: Прихована робота

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

Щоб зрозуміти, скільки роботи фактично виконується, потрібно спостерігати, скільки змінюється в кодовій базі та в історії pull‑request’ів. Без цього ваш план пропускної здатності будується на тому, що люди запам’ятали записати, а не на тому, що вони дійсно зробили. 

Сліпа зона 4: Дрейф якості

Те саме опитування виявило, що майже половина інженерних лідерів бореться з виявленням проблем безпеки тиждень за тижнем. Складність, дублювання та залежності, які не зовсім підходять, накопичуються у великій кількості невеликих, окремо розумних змін. Жодна з них не виглядає тривожною сама по собі. У тому ж дослідженні Стенфорда якість коду впала на 9 % і її варіативність більш ніж потроїлася. Хоча середнє значення змінилося трохи, розкид (те, що ви помічаєте) змінився суттєво. При обсягах ШІ вони накопичуються швидше, ніж більшість процесів перегляду встигає їх зловити. Дрейф зазвичай проявляється у вигляді сповіщення on‑call, яке простежується до залежності, яку ніхто не пам’ятає переглядати. До того часу, як це трапляється, існує велика ймовірність, що клієнт вже помітив проблему.

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

Сліпа зона 5: Неперевірені витрати

Коли впровадження ШІ перестає бути предметом дискусії, питання витрат на ШІ та ROI стає центром уваги всіх. Фінанси хочуть знати, що можна капіталізувати, а що — операційне. Керівництво хоче розуміти, що дало інвестування. Більшість команд все ще приймає рішення щодо інструментів, місць та кількості персоналу, керуючись інтуїцією, а не доказами зв’язку між витратами та доставленою роботою.

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

Почніть з того, чого ви не бачите

Питання фінансів про капіталізовані витрати та сторінка on‑call о 2 годині ночі здаються незв’язаними, але це не так. Обидва можна «приблизно оцінити» за активністю. Але обидва дійсно піддаються відповіді з доказами, виходячи з самого коду.

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

Перший корисний крок — це не новий інструмент чи новий процес. Це чесне самопізнання і визначення, які з цих п’яти областей є сліпими зонами, де у вас бракує реальних доказів. Більшість лідерів можуть одразу ідентифікувати (і звернути увагу на) проблеми в одній з цих областей. Однак саме ті області, у яких у вас найменше інформації, найчастіше виявляються і «кусають» вас під час подальшого впровадження ШІ.