Запитай десять розробників, наскільки AI їх пришвидшує, і отримаєш одинадцять відповідей. Найсвіжіші дані 2026 року, побудовані не на самозвітах, а на реальній телеметрії з Git і CI/CD систем тисяч розробників, показують чому: AI одночасно і реально пришвидшує роботу, і реально накопичує технічний борг - причому обидва ефекти вимірювані й суттєві.
Наймасштабніше й найсвіжіше дослідження
Opsera проаналізувала дані понад 250 000 розробників із понад 60 підприємств станом на квітень 2026. Результат: AI скорочує час до створення pull request'у на до 58%. Але ті самі AI-згенеровані PR чекають на рев'ю в 4.6 раза довше, ніж звичайні, і містять на 15-18% більше вразливостей безпеки.
Ще один показовий результат цього дослідження: старші інженери отримують майже вп'ятеро більше приросту продуктивності від AI, ніж молодші - розрив, який поглиблюється, а не звужується. Водночас 21% ліцензій на AI-інструменти в компаніях просто не використовуються.
Незалежна телеметрія дає ще детальнішу картину
Code Ninety проаналізувала git-коміти й CI/CD-пайплайни 84 організацій і понад 14 200 розробників за період з першого кварталу 2025 по перший квартал 2026 (дослідження оновлене в серпні 2026). Важлива методологічна деталь: це дані прямої телеметрії систем, а не опитування розробників - тобто менше схильні до ефекту завищеної самооцінки, який показало дослідження METR нижче.
Результати: індивідуальний lead time PR скоротився на 32.4%. Але паралельно рівень внесених дефектів зріс на 50% (з 3.2 до 4.8 багів на 1000 рядків коду), churn коду протягом 30 днів зріс на 67.8%, прапорці вразливостей безпеки зросли на 61.1%, а час рев'ю PR зріс на 41.5%. Автори підсумовують чесно: приріст продуктивності реальний. Технічний борг, який він створює, - теж реальний, і компенсується тільки якщо в компанії достатньо зрілі інженерні процеси, щоб його вчасно ловити.
Дослідження, яке започаткувало серйозну наукову дискусію
У липні 2025 некомерційна організація METR опублікувала рандомізоване контрольоване дослідження - золотий стандарт наукової доказовості, той самий метод, що й у клінічних випробуваннях ліків. 16 досвідчених розробників відкритого коду виконали 246 реальних задач у власних репозиторіях (середній розмір - понад мільйон рядків, середній досвід роботи з проєктом - 5 років).
Результат здивував самих авторів, які прямо писали, що очікували побачити позитивний ефект: розробники з дозволеним AI витрачали на задачі на 19% більше часу. При цьому до початку роботи вони прогнозували пришвidшення на 24%, а після завершення - попри реально виміряне сповільнення - все одно вважали, що AI пришвидшив їх на 20%. Розрив між відчуттям і виміряною реальністю становив 39 відсоткових пунктів.
У лютневому оновленні 2026 року METR сама пише обережно: "на основі розмов з учасниками ми вважаємо ймовірним, що розробники зараз пришвидшуються більше, ніж на початку 2025. Однак через ефекти самовідбору наші дані є лише слабким доказом розміру цього збільшення". Розробники неохоче погоджувались працювати без AI й уникали подавати саме ті задачі, де AI допоміг би найбільше - це систематично викривлює вибірку. Для учасників, які брали участь в обох раундах, оцінка становила приблизно 18% сповільнення з дуже широким довірчим інтервалом. Це важливий контраст із набагато масштабнішими телеметричними дослідженнями вище - METR науково найточніша, але й найменша й найбільш методологічно "затиснута" вибірка з усіх наведених тут джерел.
Наскільки серйозна проблема безпеки насправді
Тут дані з кількох незалежних джерел збігаються тривожно послідовно. Veracode протестувала понад 100 LLM на 80 задачах з кодування і виявила, що 45% AI-згенерованого коду містить вразливості з переліку OWASP Top 10. CodeRabbit незалежно виявила, що AI-згенерований код має у 2.74 раза більше вразливостей безпеки, ніж написаний людиною. А звіт Black Duck OSSRA 2026 зафіксував зростання кількості відомих вразливостей на кодову базу на 107% рік до року - із середніх 280 до 581 вразливості на проєкт.
Мартін Фаулер, відомий інженер і автор, сформулював це образно: до кожного шматка AI-згенерованого коду варто ставитись як до pull request'у від "доволі сумнівного колаборатора, який дуже продуктивний у сенсі кількості написаних рядків, але якому не можна довіряти в жодній із його дій".
Хто виграє більше - джуни чи сеньйори? Дослідники самі не згодні
Тут наявна пряма суперечність між свіжими джерелами, і чесно показати її - важливіше, ніж вдавати єдину відповідь. Opsera (250 000+ розробників) стверджує, що сеньйори отримують у 5 разів більше приросту продуктивності, ніж джуни. А польове дослідження на вибірці 4867 розробників від дослідників MIT, Прінстона, Вортона й Microsoft натомість виявило, що розробники з досвідом вищим за медіанний взагалі не показали статистично значущого приросту продуктивності від AI-інструментів.
Логічне пояснення цього протиріччя, яке пропонують деякі дослідники: люди, здатні використовувати AI найефективніше, - це ті самі люди, які найкраще вміють помітити, де AI помилився, і виправити це. Тому інструменти можуть працювати краще саме для джунів на простих задачах, ніж для сеньйорів на дійсно складній роботі - хоча "простіші задачі" й "легше виміряти приріст" тут можуть частково пояснювати одне одного.
Масштаб прийняття станом на середину 2026
Для контексту - наскільки широко це взагалі вже використовується. 84% розробників використовують чи планують використовувати AI-інструменти, 51% професійних розробників - щодня. GitHub Copilot має понад 20 мільйонів користувачів за весь час і 4.7 мільйона платних підписників станом на січень 2026, а весь ринок AI-інструментів для коду сягнув $8.5 млрд у 2026. AI-згенерований код становить від 22% до майже 27% усього коду, що потрапляє в продакшн, залежно від джерела даних - і ця частка зростає щоквартально.
Що з цього робити практично
Загальна картина, яка складається з усіх цих досліджень одночасно: AI-асистенти дають вимірюваний, реальний приріст швидкості на рівні окремого PR чи задачі - це вже не предмет серйозної суперечки в 2026 році. Суперечка тепер точиться навколо іншого: чи цей приріст швидкості компенсує зростання дефектів, вразливостей і технічного боргу, який накопичується паралельно, і чи взагалі правильно вимірювати "продуктивність" виключно швидкістю написання коду.
Найпрактичніший висновок з усього масиву даних: відстежуй не тільки швидкість (time-to-PR, кількість змержених PR), а обов'язково і якість - дефекти на тисячу рядків, час рев'ю, кількість спрацювань статичного аналізатора з часом. Компанії й команди, які вимірюють обидва виміри одночасно, послідовно показують кращі результати за ті, що женуться тільки за швидкістю. І, як і рік тому, головний урок дослідження METR лишається актуальним: власне відчуття "стало швидше" - вкрай ненадійний індикатор, який варто перевіряти реальними цифрами, а не довіряти йому на слово.