AI-агенти пишуть більше коду — чому продукт не виходить швидше

Коротко: швидше написати — не означає швидше випустити

AI-агент для програмування може самостійно читати репозиторій, змінювати кілька файлів, запускати команди й готувати pull request. Це корисно, коли задача чітка. Але програмний продукт — це не сума рядків коду. Зміни ще треба зрозуміти, перевірити тестами, узгодити з вимогами, безпечно злити й побачити, що користувач справді отримав потрібний результат.

Тому правильне питання не «скільки коду створив агент?», а «скільки перевірених задач дійшло до користувача без нових проблем?». Нове робоче дослідження економістки Фіони Чен дає рідкісні дані саме про цю різницю.

Що насправді виміряло дослідження

Робоча версія дослідження Artificial Intelligence in the Firm: Bottlenecks in Software Production датована 4 серпня 2026 року. Авторка аналізує анонімізовані дані приблизно про 300 мільйонів робочих подій 725 938 працівників у 718 компаніях із січня 2021 до березня 2026 року. Компанії впроваджували AI-асистентів і автономніших агентів у різний час, що дозволило порівнювати зміни до й після впровадження.

Ці відсотки не треба читати як універсальний прогноз для кожної команди. Для асистентів статистично значущим був лише приріст комітів. Для агентів приріст активності був більшим, але оцінки завершених Jira-задач та епіків залишилися малими й статистично незначущими. Дослідження також не виявило вимірюваної зміни зайнятості у дослідженому періоді.

Де губиться виграш: рев’ю та інша «невидима» робота

Після появи агентів середній час рев’ю pull request у вибірці зріс на 49%. Запитів на зміни стало майже вдвічі більше, коментарів на один pull request — на 35% більше, а частка працівників, які займалися рев’ю, — на 14% більше. Це не доводить, що кожен AI-pull request поганий. Але показує: більший потік змін перемістив роботу з написання коду в його перевірку.

У дослідженні наведена корисна оцінка: інженери витрачають лише 30–40% часу безпосередньо на написання коду. Решта — постановка задачі, дизайн, тести, рев’ю, координація, розгортання й підтримка. Якщо прискорити тільки одну ланку, система впирається у наступну.

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

Практичний процес: від промпту до перевіреного результату

1. Почніть із поведінки, а не файлів. Запишіть, що користувач має змогти зробити після зміни. «Додати форму» — нечітко. «Відвідувач надсилає ім’я й email, бачить підтвердження, а некоректна адреса не приймається» — перевірювано.
2. Обмежте зміну. Один pull request має одну мету. Попросіть агента спершу показати план, файли й ризики. Якщо зміна торкається авторизації, платежів, міграції даних або production-секретів, залиште рішення людині.
3. Вимагайте доказ. До коду мають додаватися команди перевірки, тести або чіткий ручний сценарій. «Усе працює» не є доказом, поки команда не виконана у вашому середовищі.
4. Читайте різницю до запуску. Шукайте не лише явний баг, а й непотрібні залежності, видалені перевірки, змінені дозволи та код, якого задача не вимагала. Нерелевантну частину поверніть агенту на скорочення.
5. Перевіряйте трьома шарами. Спочатку статичні перевірки й тести, потім реальний сценарій користувача, після цього — безпека й відновлення. Для вебсторінки додайте телефон, клавіатуру, помилку мережі та пряме відкриття URL.
6. Зливайте лише зрозуміле. Якщо ви не можете коротко пояснити, навіщо потрібен критичний фрагмент, не переносіть його у production. Розбийте зміни або запросіть компетентне рев’ю.
7. Після релізу перевірте результат. Відкрийте production, повторіть головний сценарій і подивіться на реальні помилки. «Merge» — це не фініш; фініш — підтверджена поведінка для користувача.

Для pull request на GitHub використайте наш окремий гайд із Copilot Code Review. Але пам’ятайте: другий AI-рецензент не замінює тести й людську відповідальність.

Промпт, який зменшує чергу на рев’ю

Цей шаблон навмисно просить менше коду. Вставте реальну поведінку, команди вашого проєкту й межі доступу.

Що вимірювати замість кількості рядків

Малій команді не потрібна складна панель. Візьміть останні 10 AI-задач і запишіть чотири речі: час до production, час рев’ю, кількість повернень на доопрацювання та помилки після релізу. Порівнюйте однакові типи задач. Це не науковий експеримент, але краще за враження «ніби стало швидше».

Безпека, обмеження й 20-хвилинна перевірка

Не давайте агенту зайвих прав лише для зручності. Секрети мають залишатися на сервері, production-команди — виконуватися з підтвердженням, а зовнішні тексти й issue — вважатися недовіреним вводом. Перед кожним релізом перегляньте чекліст захисту API-ключів.

• 0–3 хв: перечитайте задачу й критерії готовності.
• 3–8 хв: перегляньте diff; приберіть зайві файли, залежності й рефакторинг.
• 8–13 хв: запустіть збірку, лінтер і релевантні тести самостійно.
• 13–17 хв: пройдіть основний та помилковий сценарії як користувач.
• 17–20 хв: перевірте секрети, дозволи, логування та план відкату.

Якщо ви лише починаєте, пройдіть маршрут «Що таке вайб-кодинг» або спробуйте безкоштовний зразок сайту послуги: там можна скопіювати вузький промпт і перевірити результат без покупки.