Чому ШІ в гнучкій розробці ПЗ зазнає невдачі: приклади та рішення для Engineering Manager

Багато CTO багато чого обіцяють від використання ШІ в agile software delivery: більше швидкості, більше автоматизації, більше output. Це часто відповідає дійсності в короткостроковій перспективі. І все ж багато команд і CTO не можуть довести, як це локальне прискорення перетворюється на користь для клієнта та додану цінність для бізнесу.

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

Ця стаття свідомо доповнює два інші наші дописи:

• ШІ в гнучкій розробці ПЗ: стан досліджень 2026 .
• Посібник для CTO та Engineering Manager щодо розробки ПЗ за допомогою ШІ .

Тут ідеться про міст між цими двома речами: чому ШІ в agile software delivery на практиці зазнає невдачі? Приклади конкретно покажуть, що можуть робити менеджери і які рішення справді працюють.

Чому ШІ в гнучкій розробці ПЗ так часто оптимізується під хибну ціль

Щойно ШІ впроваджують як важіль продуктивності, у багатьох компаніях відбувається щось дуже передбачуване: те, що можна виміряти, стає метою. Це відбивається в новому тренді Tokenmaxxing. Pragmatic Engineer про тренд Tokenmaxxing

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

Патерн старий. Раніше «Lines of Code» переоцінювали як метрику, сьогодні так само — споживання токенів або дашборди використання ШІ. В обох випадках діє одна з версій закону Гудхарта: щойно метрика стає ціллю, вона втрачає цінність як метрика. Martin Fowler про Lines of Code як проблему метрики, Wikipedia про закон Гудхарта

Для ШІ в agile software delivery це означає: той, хто максимізує короткострокову активність, часто отримує більше активності ШІ. Але не автоматично кращу agile software delivery.

Результати досліджень щодо цього протверезні: на індивідуальному рівні вже помітні значні ефекти продуктивності, натомість на рівні команди та організації покращення значно менш переконливі. Деталі ми зібрали тут: До стану досліджень 2026 року щодо ШІ в agile software development

Чотири типові приклади того, як ШІ зазнає невдачі в agile software delivery

Перша невдача банальна: команди створюють значно більше змін, але розуміють дедалі меншу їх частку.

Для менеджерів це спочатку часто виглядає добре:

• більше Pull Requests
• швидші перші імплементації
• більше «готових» сторі (stories)

Розрахунок приходить пізніше:

• рев’ю стають поверхневими
• відчуття власності (ownership) розмивається
• аналіз інцидентів триває довше
• рефакторингу уникають, бо ніхто вже не впевнений, що і де може зламатися

Kent Beck у своїй статті “Trust Factory” описує, що практики на кшталт тестів, review, рефакторингу та інкрементальної поставки насамперед будують довіру. Саме ця довіра руйнується, коли ШІ виробляє швидше, ніж команда може зрозуміти, перевірити й нести відповідальність. Kent Beck у Trust Factory про довіру в інженерії

Addy Osmani описує подібний ризик як Comprehension Debt: якщо команди дедалі більше постачають коду, який уже не розуміють активно, з кожною зміною зростає дистанція між системою та розумінням. Addy Osmani про Comprehension Debt

Це також узгоджується з ширшими висновками з практики: згідно з підсумованим у 2026 році опитуванням Sonar, більшість розробників не повністю довіряє функціональній коректності коду, згенерованого ШІ, а значна частина вважає його review навіть трудомісткішим, ніж перевірку змін, написаних людьми. Отже, проблема не лише в поганій якості, а й у додаткових витратах на верифікацію та розуміння. ITPro про опитування Sonar щодо Verification Debt

Друга невдача для керівників ще дорожча: ШІ знижує вартість виробництва, але не автоматично вартість помилки.

Коли команди погано нарізають вимоги, недостатньо їх валідують або узгодили їх лише всередині, ШІ просто прискорює неправильну роботу. Kelsey Hightower дуже прямо формулює це у своєму LinkedIn-Post: “Productivity doesn’t matter if you’re working on the wrong thing.” LinkedIn-пост Kelsey Hightower про хибну продуктивність

Саме в такому ключі також аргументує Andrew Ng у широко цитованій розмові 2025 року: ШІ сильно прискорив coding, але через це зміщується справжнє вузьке місце. Тепер головною проблемою є не реалізація, а питання продукту:

Що взагалі слід будувати, і як швидко ми вчимося на реальному відгуку користувачів?

Джерело: Розмова Business Insider з Andrew Ng про вузьке місце в product management

Ось чому ШІ в agile software delivery може бути успішним лише за умови справжньої близькості до клієнта. Якщо шлях від prompt до code стає швидшим, але шлях від code до feedback користувачів залишається повільним, зростають лише output і обсяг змін.

Також дослідження з agile-роботи над продуктом показує точно таку саму закономірність на іншому рівні: у Industry-Case-Study про Agile Epics дослідники описують, що нечітко визначені вимоги призводять до churn, затримок, проблем із якістю та зайвих витрат. ШІ не може магічно усунути такі вузькі місця. Він може хіба що швидше їх матеріалізувати. Дослідження в ArXiv про Agile Epics і якість вимог

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

Багато образів майбутнього ШІ в agile software delivery виглядають привабливо, бо елегантно роблять відповідальність невидимою: один агент аналізує відгуки користувачів, наступний пише requirements, наступний реалізує, наступний тестує, а наступний розгортає.

Технічно багато з цього можливо. Організаційно це швидко стає розмитим.

Особливо в агентній розробці ПЗ старе управлінське питання треба ставити жорсткіше: Хто вирішує? Хто перевіряє? Хто несе наслідки? IBM формулює базову проблему в гідному уваги огляді про AI decision-making: відповідальність залишається за людиною, особливо коли системи готують або прискорюють рішення. IBM про відповідальність у AI decision-making

Також AI Agile Manifesto тут задає правильний контрапункт: більше машинного інтелекту без людського судження — це не прогрес, а хибний шлях. AI Agile Manifesto в оригіналі

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

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

Так відбувається, коли кожен локально оптимізує з допомогою ШІ, але майже ніхто не зміцнює систему в цілому:

• Принципи архітектури застосовуються непослідовно
• ті самі проблеми паралельно розв’язуються кілька разів
• системи review і test проходять “переїзд”
• delivery-pipelines стають місцем затору
• зростають incident-load і доопрацювання

Birgitta Böckeler у своїй розмові в InfoQ про Harness Engineering описує, чому вища автономія завжди означає і вищі ризики та чому їх потрібно обмежувати за допомогою відповідних feedforward- і feedback-механізмів. Подкаст InfoQ з Birgitta Böckeler про Harness Engineering

Те, що це не є теоретичним ризиком, показують кілька випадків, які стали публічними. За повідомленнями, у 2026 році Amazon посилила свої внутрішні guardrails після серій серйозних інцидентів, у яких як співфактор також називали агентні або близькі до ШІ системи. Висновок із цього був показовим: більше задокументованих змін, більше погоджень, більше “controlled friction” у критичних системах. Іншими словами: не кожне локальне прискорення покращує всю систему. Іноді воно лише швидше робить її вразливості видимими. Звіт Business Insider про посилені AI-guardrails в Amazon

Ще одну, іншу форму тієї самої ентропії видно в так званому Vibe Coding із підтримкою ШІ. Axios у 2026 році, посилаючись на дослідників безпеки, повідомив про сотні тисяч загальнодоступних артефактів, зокрема тисячі з чутливими корпоративними даними. Тут провалюється не передусім один окремий промпт, а вся система зі стандартів, доступів, дефолтів, розуміння безпеки та governance. Звіт Axios про Vibe Coding та загальнодоступні артефакти

Коротко: чим автономніший ШІ, тим важливішими є організаційні та технічні рамки, у яких він працює.

Чому короткострокова продуктивність і tokenmaxxing — це хибна AI-стратегія

Деякі керівники реагують на новий важіль впливу ШІ простою логікою: тоді нам треба лише якомога швидше примусити до якомога більшого використання ШІ.

Це саме та управлінська реакція, яка є хибною.

Чому?

Бо в цьому контексті «short term productivity» зазвичай означає лише таке:

• більше згенерованого коду
• більше AI-сесій
• більше витрати токенів
• більше задач, розв’язаних локально

Але все це майже нічого не каже про питання, які для ШІ в agile Software Delivery насправді є вирішальними:

• Чи була розв’язана правильна проблема?
• Чи команда розуміє зміну?
• Чи можна безпечно розгорнути цю зміну?
• Чи система після зміни краща, чи крихкіша?
• Чи організація вчиться швидше, чи лише метушиться?

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

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

Що натомість працює: Чотири надійні рішення для ШІ в agile-розробці програмного забезпечення

1. Явно залишати відповідальність за людиною

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

Практично це означає:

• чіткі власники архітектури, безпеки та рішень, важливих для продукту
• жодних метрик успіху, які просто винагороджують AI-активність
• явні правила рев’ю та затвердження для змін, згенерованих ШІ

2. Будувати engineering-harness, а не лише інструменти ШІ

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

До надійного harness для ШІ в agile Software Delivery, наприклад, належать:

• добрі специфікації
• невеликі, перевірювані пакети роботи
• автоматичні тести
• статичний аналіз
• контрольовані пісочниці
• чіткі архітектурні контексти
• швидкий зворотний зв’язок із CI, Delivery та продакшену

Якщо ця думка тобі цікава, то OpenSpec і GitHub Spec Kit також є корисними орієнтирами на тему роботи з ШІ на основі специфікацій: OpenSpec для розробки продуктів на основі специфікацій, GitHub Spec Kit для spec-driven розробки

3. Зробити зворотний зв’язок від клієнтів швидшим за виробництво коду

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

Конкретно це означає:

• менші релізи
• більше експериментів із реальними петлями зворотного зв’язку з клієнтами
• послідовніший аналіз даних про використання функцій
• швидший аналіз сигналів від підтримки та користувачів

Той, хто лише підвищує швидкість кодування, але не швидкість і якість зворотного зв’язку, будує не AI-native організацію, а лише швидшу “Feature Factory”, як це описує John Cutler. Див.: 12 Signs You’re Working in a Feature Factory

4. Сприймати ретроспективи та цикли навчання серйозно

Якщо ШІ в agile Software Delivery зазнає невдачі, причини часто є системними. Тоді мало користі лише оптимізувати окремі промпти чи інструменти.

Командам потрібні ритуали, у яких вони роблять видимими повторювані патерни та системно їх розв’язують:

• Де ми втрачаємо розуміння?
• Де зростає черга на рев’ю?
• Де ШІ створює більше переробки, ніж користі?
• Де ми оптимізуємо локальну швидкість ціною всього системного цілого?

Саме тому ретроспективи залишаються актуальними. Не як ритуал із минулого Scrum, а як механізм організаційного навчання в середовищі з вищою частотою змін.

Висновок: ШІ в agile Software Delivery рідко зазнає невдачі через надто малу кількість ШІ

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

Вони плутають короткострокову продуктивність зі сталою створюваною цінністю та покращенням delivery-системи. Вони плутають споживання токенів із створенням цінності. Вони плутають автономну генерацію коду з організаційною зрілістю.

Тож краще керівне запитання звучить не так: “Як змусити наші команди використовувати ще більше ШІ?”

А радше:

• За яких умов ШІ справді покращує наш delivery?
• Де ШІ саме зараз створює нові вузькі місця в ланцюгу створення цінності?
• Де ШІ виявляє системні недоліки, які нам потрібно виправити?
• Які організаційні здібності нам потрібно посилити, щоб прискорення не перетворювалося на ентропію?

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

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

FAQ про ШІ в гнучкій delivery програмного забезпечення

Чому ШІ дає моїй команді більше output, але не кращий delivery?

Тому що більше output не означає автоматично кращий delivery. Якщо рев’ю, тести та зворотний зв’язок не встигають, передусім зростає складність.

Що означає Tokenmaxxing у розробці програмного забезпечення з підтримкою ШІ?

Tokenmaxxing означає зробити метою використання ШІ або споживання токенів. Це вимірює активність, але не цінність.

Що мають робити Engineering Manager замість того, щоб просто розганяти продуктивність ШІ?

Вони мають посилювати відповідальність, тести, рев’ю та петлі зворотного зв’язку. Лише це робить ШІ корисним у довгостроковій перспективі.

Чи потрібні командам із великою підтримкою ШІ взагалі ще agile-ритуали?

Так, але з іншим фокусом. Менше статус-менеджменту, більше зворотного зв’язку, навчання та безперервного покращення.

Як мені, як Engineering Manager, виміряти, чи справді ШІ дає користь у розробці програмного забезпечення?

Вимірюй Lead Time, обсяг витрат на рев’ю, частоту помилок і користь для клієнта. Самого лише обсягу недостатньо.

Чому моя команда працює з ШІ швидше, але результати не кращі?

Бо більше коду не автоматично дає кращі результати. Без якісних рев’ю, тестів і зворотного зв’язку зростає лише ентропія.

Які KPI мені справді варто відстежувати для ШІ в розробці програмного забезпечення?

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

Як мені запобігти тому, щоб згенерований ШІ код пізніше гальмував мою команду?

Тримай зміни невеликими, ретельно тестуй їх і наполягай на чіткому рев’ю. ШІ може прискорювати, але не замінювати розуміння.