Головне питання: що саме ми прискорюємо

Уявіть завод. Штамп вибиває деталь за частку секунди. Але автомобіль з’їжджає з конвеєра лише після збирання, перевірки й доведення. Сперечатися про «швидкість штампа» корисно для цеху заготівок і марно для клієнта, який чекає готове авто. У розробці те саме: швидкість набору рядків легко сплутати зі швидкістю доставки зміни.

Розділимо поняття, які в розмовах про ШІ часто склеюють в одне:

• швидкість написання коду — як швидко з’являється чернетка;
• швидкість виконання задачі — скільки часу від старту до «готово» за критеріями команди;
• обсяг коду — скільки рядків чи символів вироблено (слабка метрика сама по собі);
• функціональна коректність — чи проходить приймання і тести;
• якість і підтримуваність — читабельність, узгодженість з архітектурою, ціна майбутніх правок;
• час на перевірку й виправлення — рев’ю, відкати, «кролячі нори» зневадження;
• підсумкова вартість — людино-години, інциденти, переробки.

Головна думка статті проста й жорстка: швидкість генерації коду і швидкість розробки програмного продукту — не одне й те саме. Поки ви вимірюєте лише перше, будь-які відсотки «прискорення від ШІ» виглядатимуть переконливіше, ніж вони є для релізу.

Чому потрібні експерименти, а не відчуття

Розробник після тижня з асистентом часто відчуває: «я пишу вдвічі швидше». Це відчуття правдиве як переживання потоку: менше рутини, менше порожнього екрана, більше відчуття прогресу. Але об’єктивна перевірка зобов’язана відповісти на інші питання.

Скільки часу пішло на задачу цілком? Чи був результат коректним? Чи пройшли тести? Скільки правок знадобилося після рев’ю? Чи можна прийняти зміну в бойове середовище? Як вона вбудовується в наявну систему, а не лише «збирається в мене локально»?

Звідси принцип, який варто повісити біля панелі показників: продуктивність розробника ≠ рядки коду на годину. Рядки — побічний продукт. Продукт — робоча, перевірена, супроводжувана зміна. Саме тому нижче розбираємо контрольовані й польові дослідження, а не лише відгуки в соцмережах.

Copilot на формалізованій задачі: плюс п’ятдесят п’ять відсотків

Один із найцитованіших експериментів — дослідження Microsoft Research і GitHub навколо GitHub Copilot. У контрольованій постановці брали участь 95 професійних розробників. Їх випадково розділили на дві групи, дали ту саму задачу на JavaScript — реалізувати HTTP-сервер — і заміряли час і успішність.

Група з Copilot у середньому закінчила приблизно за 1 годину 11 хвилин. Група без асистента — приблизно за 2 години 41 хвилину. Це близько 55% прискорення за часом (у публікаціях GitHub фігурує формулювання 55% faster; у довірчому інтервалі дослідження вказувало широкий розкид, але напрям ефекту стійкий). Успішне завершення задачі: близько 78% проти 70%.

Джерела: Microsoft Research, пост GitHub про продуктивність і «щастя» розробника.

Обмеження критичне для тлумачення. Задача була відносно невеликою, обмеженою й добре формалізованою: спільна мова, зрозумілий критерій готовності, автоматична перевірка. Це ближче до «штампа деталі», ніж до «випуску автомобіля». Не можна автоматично переносити висновок у формулювання «будь-який розробник тепер програмує на 55% швидше» — особливо в моноліті з п’ятнадцятирічною історією, де вузьке місце не в наборі HTTP-обробника, а в розумінні наслідків.

Якість коду: що вимірював GitHub

Окреме питання — не лише «швидше», а й «чи краще». У дослідженні GitHub 2024 року з 202 розробниками (досвід Python, випадковий розподіл доступу до Copilot, однакова задача з API-кінцевими точками, потім автотести й сліпе експертне рев’ю) дивилися на функціональність, читабельність, надійність, підтримуваність, компактність і ймовірність схвалення коду.

За повідомленнями GitHub:

• імовірність пройти всі 10 модульних тестів була вищою приблизно на 53,2% у групи з Copilot;
• у сліпому рев’ю було менше проблем із читабельністю;
• імовірність схвалення коду була приблизно на 5% вищою;
• невеликі, але статистично значущі прирости за читабельністю, надійністю, підтримуваністю й компактністю (порядку одиниць відсотків).

Джерело: Чи покращує GitHub Copilot якість коду?.

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

METR 2025: плюс дев’ятнадцять відсотків часу на реальних задачах

Дослідження METR особливо цікаве тим, що відходить від навчальної HTTP-задачі. Це рандомізоване контрольоване дослідження на 16 досвідчених розробниках відкритого коду, 246 реальних задачах у великих зрілих проєктах (мільйони рядків коду), з учасниками, у яких у середньому близько п’яти років досвіду саме з цими репозиторіями. У задачах — виправлення, можливості, рефакторинг. Джерело: файл METR.

Результат: дозвіл користуватися ШІ збільшив час виконання задач приблизно на 19%. До експерименту люди очікували прискорення порядку 24%. Після роботи суб’єктивно оцінювали прискорення близько 20%. Об’єктивні години показали сповільнення. В оновленні METR 2026 формулювання уточнюється як about 20% slowdown на даних початку–середини 2025 — порядок величини той самий.

Це не «ШІ марний». Це «у цьому режимі, на цих людях і задачах, підсумковий цикл став довшим». Різниця між очікуванням і секундоміром і є сюжет наступного розділу.

Ілюзія продуктивності

Коли суб’єктивна оцінка каже «я став швидшим на 20%», а вимірювання — «задача стала довшою на 19%», виникає окремий феномен: ілюзія продуктивності. Людина відчуває прогрес, бо екран рідко порожній, варіанти з’являються швидко, рутину делеговано. Але підсумковий час до прийнятої зміни зростає через перевірку, інтеграцію й зневадження чужих (для ментальної моделі) рішень.

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

Чому досвідчений розробник у великій кодовій базі може сповільнитися

Повернемося до заводу. Якщо ви вже знаєте лінію збирання напам’ять, новий автомат, який штампує «майже правильні» деталі, змушує вас частіше зупиняти конвеєр і звіряти допуски. Досвідчений автор у знайомому репозиторії якраз у такій позиції.

Контекст. Моделі треба вгадати архітектуру, домовленості, залежності, обмеження легасі й неявні правила, які живуть у головах. Чим більше прихованого контексту, тим частіше чернетка технічно правдоподібна й архітектурно чужорідна. Докладніше про межі розуміння спадщини — у розборі ШІ на 15-річному проєкті.

Перевірка. Генерація дешева. Читання, розуміння, тести й виправлення — ні. Якщо ви не написали код самі, ментальна модель системи не «проросла» разом із ним: ви купуєте швидкість набору ціною дорожчої верифікації.

Інтеграція. Власний код часто народжується вже всередині вашої картини системи. Пропозиція моделі може бути коректною локально й дорогою глобально: інший стиль помилок, інший шар абстракції, обхід наявного API.

«Кролячі нори» зневадження. Ланцюжок знайомий багатьом: генерація → тонка помилка → правка → нова помилка → ще перевірка → відкат. Довіра до правдоподібного тексту посилює пастку. Суміжний сюжет — рев’ю після патча агента: людина зобов’язана перевіряти те, що виглядає готовим.

METR 2026: вимірювання стало крихкішим, а висновки — обережнішими

У лютому 2026 METR описала, чому продовжувати той самий дизайн експерименту стало важко (оновлення дизайну експерименту). Розробники дедалі частіше не хочуть брати участь, якщо їм забороняють ШІ. З’являється зміщення вибірки: у вибірці менше тих, хто найсильніше вірить у вигоду асистента, і менше задач, які люди не хочуть робити «вручну». Частина учасників ганяє кілька агентів одразу, і облік витраченого часу стає ненадійним. Зниження оплати участі теж могло посилити відбір.

Сирі оцінки нового прогону в METR уже натякають на прискорення в частини когорт, але організація прямо пише: сигнал слабкий, істинний ефект у «відсіяних назовні» розробників і задач може бути вищим. Висновок для читача важливіший за цифру: результати початку 2025 не можна механічно переносити на інструменти початку 2026. Моделі, агенти й звички команд змінилися. Змінюється і сама можливість чесно виміряти ефект старим протоколом.

Польові експерименти Microsoft: тисячі розробників

Великий польовий зріз — робота Microsoft Research The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Три експерименти в Microsoft, Accenture і компанії з Fortune 100, сумарно 4 867 розробників. В об’єднаних даних дослідники повідомляють про приріст порядку +26% до числа виконаних задач у тих, кому дали асистента з написання коду. Ефект неоднорідний: менш досвідчені розробники частіше інтенсивніше користувалися ШІ й отримували більший приріст.

Джерело: Microsoft Research.

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

Чому дослідження сперечаються одне з одним

Центральна аналітична відповідь: вони вимірюють різне і ставлять людей у різні умови.

Додайте конфлікт інтересів у постачальників, розмір вибірки, тривалість спостереження і те, чи дозволено обирати задачі. Тоді «55% швидше» і «19% повільніше» перестають бути загадкою і стають двома точками на карті режимів роботи. Про агентний режим і платформні обмеження див. також агентну інженерію 2026 і чому агентам потрібна платформа, а не лише швидкість набору.

Повний цикл: від задуму до злиття

Запропонуємо просту модель повного часу:

T_total = T_design + T_generation + T_review + T_debug + T_test + T_integration

ШІ особливо впевнено б’є по T_generation. Іноді допомагає і T_design (швидкі начерки варіантів). Але він же здатен збільшити T_review, T_debug і T_integration — особливо коли чернетка чужа за стилем і знаннями системи. Підсумок може бути додатним, нульовим або від’ємним. Оптимізувати лише генерацію — усе одно що прискорювати штамп, ігноруючи контроль якості й збирання.

Звідси практичне правило: будь-який пробний запуск асистента вимірюйте за time-to-merge, дефектами після злиття і числом ітерацій рев’ю, а не за швидкістю автодоповнення в IDE. Економіка токенів без економіки переробок обманює так само, як дешева модель без урахування повного циклу — див. сукупну вартість дешевої LLM для агента.

Підсилювач, а не заміна: junior, middle, senior

Правильна постановка порівняння — не «людина проти ШІ», а людина проти людини з ШІ. Модель сьогодні частіше грає ролі: парний програміст, генератор, помічник із рев’ю та документації, дослідник API, агент на шматку робочого процесу. Вона розширює радіус дії одного інженера: швидше вивчити незнайомий API, накидати прототип, згенерувати тести, розібрати документацію. Але зростання виробничої потужності не гарантує пропорційного зростання продуктивності всієї системи — вузькі місця зміщуються в постановку задачі, архітектуру й приймання.

Junior. Поріг входу падає: пояснення помилок, шаблонний код, варіанти реалізації. Ризик дзеркальний: прийняти код, якого не розумієш. Без наставництва й тестів «прискорення» перетворюється на борг.

Middle. Тут асистент часто дає максимум побутової користі: генерація, рефакторинг, тести, документація, розвідка. Саме ця група часто видно в польових приростах числа задач.

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

Польові нотатки про те, як сильні команди впроваджують інструменти без театру хайпу: за хайпом. Про замір агента в тестуванні — 11 тижнів із ШІ-тестувальником.

Як поставити свій A/B-тест у команді

Візьміть 20–50 реальних задач із беклогу (не навчальний HTTP-сервер). Випадково або по черзі розподіліть умови: без ШІ і з ШІ (зафіксуйте, якими інструментами й версіями). Вимірюйте час до готовності, число ітерацій, помилки, правки після рев’ю, покриття тестами, дефекти після злиття. Не порівнюйте лише рядки коду.

Мінімальний набір метрик:

• швидкість: time-to-first-working-code, time-to-completion, time-to-merge;
• якість: частка пройдених тестів, частота дефектів, інциденти, відмови на рев’ю;
• супроводжуваність: складність, дублювання, узгодженість з архітектурою;
• економіка: вартість закритої задачі, години на можливість;
• людина: когнітивне навантаження, впевненість, ефект навчання (чи розуміє автор свій же патч через тиждень).

Без такого контуру будь-який зовнішній відсоток — чужий анекдот у красивій обгортці.

Що вже можна стверджувати обережно

1. ШІ здатен сильно прискорювати деякі задачі програмування — особливо короткі й формалізовані.
2. Ефект залежить від типу задачі, тестів, знайомства з кодовою базою і режиму інструмента.
3. Прискорення генерації не гарантує прискорення всієї розробки.
4. Якість може покращуватися в контрольованих умовах, але це не автоматично переноситься в прод.
5. Досвідчені автори в зрілих репозиторіях іноді отримують менше користі, ніж очікують — аж до сповільнення.
6. Нові покоління моделей і агентів роблять знімки 2022–2025 історичними, не вічними.
7. Суб’єктивне прискорення часто розходиться з годинами.
8. Коректне порівняння — людина без ШІ проти людини з ШІ, а не людина проти моделі.

Часті питання

Що почитати далі

Поруч на сайті: ШІ і 15-річний проєкт, рев’ю коду в епоху ШІ, агентна інженерія 2026, агентам потрібна платформа, як команди впроваджують ШІ без хайпу, 11 тижнів із ШІ-тестувальником, хімія коду як рамка рішень.

Висновок

Питання «хто швидше пише код — людина чи ШІ?» погано поставлене. Модель пише чернетку швидко. Людина з моделлю може закривати задачу швидше або повільніше — залежно від того, що ви вважаєте «закритою задачею». Дослідження Microsoft, GitHub і METR не сперечаються одне з одним, якщо читати їх як карту режимів: навчальний стенд, якість у лабораторії, зрілий відкритий код, корпоративне поле, зміна поколінь інструментів.

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