Дослідження NBER: AI-агенти збільшили кількість комітів на 240%, релізів — на 30%

Економісти Mert Demirer, Leon Musolff і Liyuan Yang вивчили дані про використання AI-інструментів понад 500 000 розробників на GitHub і порівняли зростання активності з випуском продуктів. Як пише Хабр, з автономними агентами кількість комітів зросла на 240%, проєктів — на 80%, а релізів — на 30%. Робота NBER вийшла у травні 2026 року, переглянута версія — у вересні.

Чому комітів побільшало більше, ніж релізів

Автори роботи Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools порівняли три покоління інструментів методом matched event study. З автодоповненням кількість комітів зросла приблизно на 30%, з інтерактивними coding-агентами — на 180%, з автономними — на 240%. Якщо дивитися лише на репозиторій, прискорення вражає. Але випущені версії дають іншу картину.

Для автономних агентів дослідники простежили ефект від комітів до проєктів і релізів: приріст послідовно зменшується з 240% до 80% і 30%. Отже, додаткові зміни в коді не перетворюються на готові версії з тією самою швидкістю. Між ними є перевірка та інтеграція, яких лічильник комітів не відображає.

Дослідники пояснюють різницю принципом weak-link: результат обмежує найслабша ланка процесу. У цьому випадку нею залишається людська робота з контекстом, рев’ю та інтеграцією. За викладом Хабра, еластичність заміщення між AI і людською працею на рівні 0,23 вказує на те, що вони радше доповнюють одне одного. Швидше згенерувати код — не те саме, що переконатися в його придатності до релізу.

Порівнюючи цифри, важливо пам’ятати про перегляд роботи: початкова вибірка становила близько 100 000 розробників, а понад 500 000 з’явилися в новій версії. Давніші перекази дослідження можуть спиратися на інші дані.

Публікація застосунку — ще не вся робота

Автори також вивчили Apple App Store, Google Play, Chrome Web Store і SourceForge. Нових застосунків на цих майданчиках стало помітно більше, але сукупний рівень користування майже не змінився. Випуск продукту й залучення аудиторії виявилися різними результатами: кількість написаного коду не говорить про те, чи скористався хтось результатом.

Окремий експеримент cruxevals показує, скільки роботи залишається навіть навколо успішного автоматизованого випуску. Агент OpenClaw на Claude Opus 4.6 отримав віртуальну машину Mac, Apple Developer Account, GitHub і Gmail. Він випустив iOS-застосунок Breathe Easy в App Store 16 березня 2026 року, через десять днів після старту, але в процесі знадобилося ручне втручання. Опис експерименту опубліковано 16 квітня.

Збирання застосунку й надсилання на рев’ю зайняли близько 45 хвилин і коштували приблизно $25. Підготовка середовища потребувала ще близько восьми годин за два пробні прогони. До початку рев’ю минуло приблизно п’ять днів, до схвалення — близько дев’яти. Моніторинг під час очікування коштував приблизно $975, загальні витрати становили близько $1000. Тому «45 хвилин» описують лише один етап десятиденного процесу.

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

Що відстежувати командам і власникам продуктів

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

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

Моя думка: коміти — ще не привід святкувати

Мені, як людині, яка вчиться робити API й підключати бази даних, цифра +240% спочатку здається чудовою новиною. Потім згадую своє «швиденько додам ще одну таблицю» — і хочеться уточнити, хто перевірить зв’язки та поведінку системи. Я не проти додаткової швидкості. Просто не став би записувати її всю в графу «готовий продукт».

Я б оцінював користь інструмента за тим, що команда встигла перевірити, випустити й запропонувати користувачам. Інакше список змін росте жваво, а черга на рев’ю — ще жвавіше. Кнопку «згенерувати ще одну пару уважних очей» у цій історії поки не показали.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Коммитов +240%, релизов +30%. NBER изучил 500 000 разработчиков и нашёл, где теряется эффект AI habr.com

Про автора

Ееро Лайне

початківець бекенд-розробник

Вчуся створювати API й підключати бази даних, паралельно збираю каталог фільмів для друзів. Уже зрозумів, що «швидко додати ще одну таблицю» зазвичай звучить підозріло оптимістично.

Усі публікації автора