Дослідження показує: AI-агенти суттєво збільшують обсяг коду, але кінцевий вихід програмного продукту майже не зростає, бо прискорення «з’їдається» людським рев’ю.
Ключові інсайти
Приріст у написанні коду не конвертується у випуск
Дослідження Гарвардської школи бізнесу на основі агрегованої аналітики Jellyfish показує, що AI-агенти справді різко піднімають «першу милю» розробки. На даних про 300 млн робочих подій і діяльність понад 700 тис. працівників у більш ніж 700 софтверних компаніях за період з 2021 року до березня 2026-го автори побачили: після впровадження AI-агентів зростають обсяги створеного коду, кількість комітів і pull request’ів. Зокрема, у середньому фіксується 30% приріст рядків коду, 20% — комітів і 23% — pull request’ів.
Для CEO це важливо не як технічна деталь, а як сигнал про розрив між локальною продуктивністю та результатом на рівні компанії. Дослідники не знайшли статистично значущого покращення в закритті Jira-issue чи epic’ів після появи AI-інструментів, і не побачили помітного зсуву в складності або розмірі цих задач. Тобто інструмент швидше збільшує обсяг створюваного артефакту, ніж кінцеву пропускну здатність продуктового потоку.
Звідси практичний висновок: якщо компанія оцінює успіх AI лише за активністю в редакторі чи кількістю згенерованого коду, вона може переоцінити ефект на бізнес. Моя управлінська інтерпретація: потрібно міряти не «скільки написали», а «скільки доставили» — через цикл від задачі до релізу, а не через проміжні показники.
Вузьке місце зміщується в рев’ю
Причина, на яку вказує дослідження, лежить у наступній ланці процесу: code review. Після впровадження AI-агентів середній час від подання pull request до злиття в кодову базу збільшується в середньому на 49%. Паралельно зростає частка pull request’ів, щодо яких просять зміни, а кількість коментарів на один pull request підвищується на 35%. Інакше кажучи, швидше створений код не проходить швидше через перевірку — навпаки, він створює нове навантаження на рев’юерів.
Це важливо не лише для інженерних менеджерів, а й для керівників, які розраховують на скорочення витрат або вивільнення людей. Автори не виявили суттєвих змін у зайнятості після врахування даних Jellyfish і LinkedIn: AI не дав переконливого ефекту на чисельність активних працівників. У відповідь на складніший потік рев’ю компанії збільшили частку співробітників, що займаються code review, на 14%. Тобто частина виграшу від генерації коду була «поглинута» не виробництвом, а контролем якості.
Для управлінського рішення це означає, що впровадження AI має оцінюватися як зміна всього ланцюга створення цінності. Моя інференція: якщо рев’ю залишається ручним і не масштабується, то інвестиції в кодогенерацію лише пересунуть чергу з написання коду на його перевірку, а не збільшать throughput компанії.
Що це означає для стратегії впровадження AI
Дослідження також показує, що AI для рев’ю поки що не компенсує дисбаланс повністю. До березня 2026 року 80% компаній у вибірці вже використовували ту чи іншу форму AI code review, але самі AI-агенти були відповідальні лише за 23,3% усіх review-коментарів і 10,8% pull request’ів. Тобто людська праця все ще домінує в найкритичнішій ділянці процесу — там, де вирішується, чи потрапить код у production і з якою кількістю виправлень.
Для CEO та COO це підказує порядок дій. По-перше, запускати AI треба разом із переглядом політик рев’ю: стандарти якості, шаблони перевірок, правила для складних і простих змін, межі допустимого автозлиття. По-друге, варто окремо відслідковувати метрики «до» і «після» в кожній ланці — generation, review, merge, issue resolution — щоб зрозуміти, де саме виникає вузьке місце. По-третє, навчання команд має бути не тільки про промпти, а й про те, які типи задач доручати агентам, а які залишати людям.
Нарешті, важливий контекст: дослідження зафіксувало ефект на даних до березня 2026 року, коли інструменти ще швидко еволюціонували, а 95% фірм у вибірці вже впровадили AI-агентів. Це означає, що сьогодні частина ефекту може змінюватися, але базова логіка лишається: AI у розробці — не просто прискорювач написання коду, а тест на зрілість операційної моделі. Якщо організація не перебудує рев’ю та прийняття рішень, виграш у швидкості створення коду залишиться частково нівельованим.
Головні тези
- AI-агенти підняли обсяг коду, комітів і pull request’ів, але не дали помітного приросту завершених задач на рівні продукту.
- Головним вузьким місцем став процес code review, який після впровадження AI помітно подовжився.
- Команди почали витрачати більше часу на перевірку, коментарі та правки, тому виграш у швидкості створення коду частково нейтралізувався.
- Це означає, що впровадження AI треба планувати разом із переробкою робочого процесу, а не лише з ліцензіями та доступами.
- Керівникам варто міряти не активність інструменту, а кінцеву пропускну здатність ланцюга створення цінності.
Що це означає для CEO
Висновок для CEO простий: AI в інженерії треба впроваджувати як зміну операційної системи, а не як надбудову над старим процесом.