Ваша команда шипає код швидше, ніж будь-коли. Графіки velocity спринтів дивляться вгору і вправо. Pull request'и — пачки змін коду, запропонованих на рев'ю — пролітають через апрув як намащені. PM дякує AI-інструментам для кодингу. Усі кивають. Життя прекрасне.

От тільки баг-тікетів стає більше. Реверти — коли ви відкочуєте зміну, бо вона щось зламала — трапляються частіше. Бєклог росте. Ніхто не з'єднує крапки, бо дашборд каже, що ви розриваєте.

30 березня 2026 року команда дослідників із Singapore Management University опублікувала найбільше емпіричне дослідження якості AI-згенерованого коду в історії. Вони проаналізували 304 362 верифіковані AI-авторські коміти (зміни коду, підтверджено створені AI-інструментами) у 6 275 GitHub-репозиторіях, охопивши п'ять основних інструментів: GitHub Copilot, Claude, Cursor, Gemini та Devin. Часовий проміжок: січень 2024 — жовтень 2025.

Те, що вони знайшли, мало б трохи притишити ваше свято velocity.

У цих репозиторіях дослідники виявили 484 606 окремих проблем. З них 89% — це code smells, тобто патерни, які працюють сьогодні, але гниють завтра. Майже 6% — runtime-баги. І 5,1% — вразливості безпеки. Від 15% до 29% AI-комітів вносили щонайменше одну проблему, залежно від інструменту. Gemini на вершині з 28,7%. Copilot набрав 17,3% — краще, але все одно кожен шостий коміт приходить із багажем.

А тепер головний удар: 24,2% цих AI-створених проблем досі живі в останній версії коду. Проблеми безпеки мали найвищий показник виживання — 41,1%. На лютий 2026 року дослідження відстежило понад 110 000 живих проблем, які AI туди заніс, а люди так і не прибрали. Дослідники сказали прямо: AI-асистенти виправляють приблизно стільки ж code smells, скільки створюють, але вони «створюють більше багів і проблем безпеки, ніж вирішують».

Днем раніше, 29 березня, Exceeds AI опублікували бенчмарк-дані, які пояснюють, чому це має значення на рівні організації. Їхній аналіз визначає безпечне співвідношення AI-коду на рівні 25–40% від загального обсягу — діапазон, у якому команди отримують реальний приріст продуктивності 10–15% без потопання в переробках. Поточний глобальний середній показник? 41–42%. Вже за лінією. Команди з часткою AI-коду понад 40% демонструють на 20–25% більше переробок. І ось парадокс продуктивності, який має переслідувати кожного інженерного менеджера: розробники відчувають себе на 20% швидшими, але фактично вимірюються як на 19% повільніші, якщо врахувати оверхед рев'ю, дебагінг і фікси.

Суб'єктивна швидкість зростає. Фактична пропускна здатність падає. Дашборд бреше.

6 квітня дослідниця Маргарет-Енн Сторі з University of Victoria дала цій проблемі назву у новій статті. Вона називає це «Когнітивний борг» (Cognitive Debt) — ерозія спільного розуміння в команді. Коли AI генерує код швидше, ніж розробники встигають його осмислити, команда втрачає здатність безпечно модифікувати власну систему. Це не просто технічний борг (брудний код, який ви виправите потім). Це борг знань — ніхто вже повністю не розуміє, що кодова база робить.

Усе це не означає, що вам треба припинити використовувати AI-інструменти для кодингу. Приріст продуктивності реальний, і джина назад у пляшку не запхнеш. Але питання, яке ваша команда має собі ставити — не «скільки коду AI може написати за нас?», а «скільки AI-згенерованого коду наш процес рев'ю і тестове покриття реально витримають, перш ніж усе посиплеться?»

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