Чому більшість розробників досі майже нічого не отримують від використання кодувальних агентів.

Два дослідження 2026 року, одне від JetBrains та інше від Anthropic, наводять цифри щодо того, як інженери насправді працюють з агентами для програмування. Разом вони стверджують, що різниця між отриманням користі від агента та його „шумом“ полягає у способі делегування роботи, а не у виборі моделі.

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

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

Чому додаток для торгівлі — це гарний тест

Уявіть собі додаток для торгівлі на iOS, створений для фінансової компанії. UIKit та SwiftUI існують поруч, а зверху — MVVM та Clean Architecture. У такій кодовій базі неправильна цифра на екрані підтвердження замовлення не стає заявкою на виправлення багу. Це стає дзвінком від відділу комплаєнсу.

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

Що виявило опитування JetBrains

У період з травня по липень 2026 року JetBrains провело опитування серед понад 15 000 працюючих розробників. Дев’ятеро з десяти відповіли, що використовують AI-агентів для програмування принаймні щотижня, а 68% — щодня.

Claude Code лідирує з 39% у всьому світі та 47% у США, що приблизно вдвічі більше, ніж у GitHub Copilot з 21%, який у свою чергу впав з 29% рік тому. Codex піднявся з 3% до 16%.

У супутньому звіті наведено ще більш цікаву цифру. Розробники оцінюють, що близько 47% їхнього коду тепер пишеться повністю агентами, більше половини з них пишуть вручну менше 20% свого коду, а кожен п’ятий взагалі не пише коду без допомоги ШІ.

Досвід не стримував впровадження ШІ, а навпаки — сприяв йому. Приблизно кожен четвертий старший розробник дозволяє агентам створювати понад 80% свого коду, що є більшою часткою, ніж серед молодших розробників, які віддають перевагу допомозі на кожному рядку. Це спростовує твердження про те, що ШІ робить молодших розробників зайвими. Ті, хто має найкращий судження, передають найбільше завдань агентам, і це зовсім не випадковість.

Що показують 400 000 сеансів

Власне дослідження Anthropic охопило приблизно 400 000 інтерактивних сеансів Claude Code від близько 235 000 користувачів, зафіксованих з жовтня 2025 року по квітень 2026 року. Розподіл даних виглядає простішим, ніж це стверджує маркетинг:

• Робота, пов’язана з кодом, становила 56% сеансів: 25% — написання коду, 26% — виправлення помилок, 5% — тестування чи організація процесів.
• Керування програмним забезпеченням займало 17%.
• Планування та дослідження — 14%.
• Аналіз та написання тексту — 13%.

Найважливіший висновок стосується того, хто приймає рішення. Люди приймають близько 70% рішень щодо планування, тоді як Claude — близько 80% рішень щодо виконання. Люди вирішують, *що* робити, а агент — *як* це зробити.

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

Експертиза змінює результат

Цифри розчаровують усіх, хто вважає, що „тепер будь-хто може створювати“. Сесії оцінювалися за очевидною експертизою користувача у певній галузі за трьома критеріями: наскільки точними були інструкції, що саме користувач попросив перевірити Claude та як відбувалися корекції. Потім результати порівнювалися між собою.

Почніть з перших двох рядків. Експерти не вводять більше символів. Одна інструкція від експерта дає результат, у два рази кращий за роботу без керівництва: дванадцять дій проти п’яти у початківців, навіть якщо модель, інструмент та ціна ідентичні. Повідомлення експерта містить достатньо контексту, тож агент ніколи не змушений зупинятися та здогадуватися.

Останній рядок також має велике значення. Після того, як сесія відхилилась від курсу, близько 19% початківців здавалися, не створивши жодного коду, на відміну від 5–7% експертів. Ключовою навичкою є не формулювання запиту, а повернення відхилилої сесії на правильний шлях.

Речення зі статті підсумовує це: у початківців Claude зазвичай коригує користувача, а у експертів — користувач коригує Claude. Саме це є межею між використанням агента та керуванням ним.

Трикроковий цикл, який зазнає невдачі

Звичайна процедура виглядає так:

Bad:
Prompt → AI writes code → Accept

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

Семиступінчастий цикл, який витримує навантаження

Рутина, яка вижила після взаємодії з промисловим торговельним додатком, складається з семи етапів:

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

Інженер відповідає за перші три етапи та останні два, а агент — за те, що знаходиться між ними. Ця пропорція відповідає результатам досліджень, де спостерігається розподіл 70/30 у плануванні та 80/20 у виконанні, представлений у вигляді конвеєра. Кожен етап має свою власну вартість.

Вимога

Такий запис, як „Додати форму підтвердження до процесу замовлення“, вважається завданням. Агент може створити щось, що технічно буде правильним, але функціонально — неправильним. Вимога, яка варта уваги, містить набагато більше інформації:

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

Останнім елементом цього специфікацію є знання конкретної галузі, якого немає у жодній моделі. Саме це визначає різницю між екраном, який працює належним чином, та екраном, який стає причиною регуляторних зауважень. Це відповідає показнику „точності напрямку“ у дослідженні, і це найпростіше для виправлення.

Контекст

У ситуації, коли UIKit та SwiftUI існують разом у рамках Clean Architecture, агент створює власні шаблони, якщо жоден з них не показаний, і кожен такий вигаданий шаблон згодом стає об’єктом коментаря під час перевірки. Тому спочатку агенту наводяться реальні приклади: поточний протокол використання, одна реалізація репозиторію, ViewModel, який виконує найближче доцільне завдання, та файл CLAUDE.md модуля з його правилами структурування. Три файли та документ зі стандартами завжди ефективніші за три абзаци пояснень. Майже всі пропускають цей етап, хоча саме він приносить найбільшу користь.

План

Запросіть план ще до написання будь-якого коду — у ньому має бути перелік файлів, які змінюються, який шар приймає кожну зміну, що розкриває ViewModel та що отримує тест. Читайте його, як опис PR. Відхилення плану займає близько дев’яноста секунд. Відхилення реалізації займає двадцять хвилин та залишає diff, який потрібно ментально проігнорувати.

Приблизно третина планів змінюється, майже завжди через питання структурування — наприклад, коли агент розміщує обчислення у ViewModel, яке мало б знаходитися у use case. Виправлення цього у прозовому вигляді є дешевим, тоді як у Swift — ні.

Реалізація

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

Перевірка

Інструкція з найкращими результатами стверджує, що робота не вважається завершеною, поки код не буде скомпільований та тести не пройдуть, причому агент має виконувати обидва процеси самостійно. Дослідження описує це як те, що користувач просить Claude перевірити, і це саме те, що люди найдовше недооцінюють. Агент, здатний запустити xcodebuild та тести, закриває власний цикл. Той, хто не має такої здатності, повертає чернетку та позначає її як функцію.

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

Перевірка

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

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

Куди рухається робота

Тренд протягом семи місяців у рамках 400 000 сеансів заслуговує на увагу:

• Частка сеансів, присвятованих виправленню помилок, знизилась – з третини (33%) до 19%.
• Запуск програмного забезпечення в режимі роботи зріс до 21% після початкових 14%.
• Написання коду та аналіз даних майже подвоїлись, з приблизно десятої частини сеансів до приблизно п’ятої.

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

Вузьке місце — це цикл

Дев’ятеро з десяти розробників використовують ці інструменти щотижня, проте лише від 15 до 33% сесій закінчуються успішною перевіркою. Отже, модель ніколи не була обмеженням. Більшість людей просто використовують трьохкроковий цикл з інструментом, призначеним для семи кроків.

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

У 2026 році ті, хто отримує найбільшу користь від агентів для програмування, не пишуть найрозумніших запитів. Це все одно ті, хто вирішує, що означає „робота виконана“.