Ключові висновки

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

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

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

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

ШІ підсилює наявну інженерну систему. Дослідження DORA описує ШІ як підсилювач: зріла платформа та швидкі цикли зворотного зв’язку перетворюють його на прискорення; щільно зв’язана архітектура та слабкі перевірки — на додаткову нестабільність.

Від автодоповнення до агентної розробки

Автодоповнення пропонує наступний фрагмент у відкритому файлі. Чат пояснює код і готує латку за інструкцією. Агент працює в циклі: збирає контекст, будує план, викликає інструменти, спостерігає за результатом і коригує дію.

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

Рівні автономності зручно розрізняти так:

Що вища автономність, то важливіший не «розум моделі», а якість каркаса. У короткому розборі нового життєвого циклу розробки це виражено формулою «агент дорівнює моделі з каркасом». Модель стає взаємозамінною швидше, ніж архітектура доступу, правила та перевірки.

Розробка за відчуттям та агентна інженерія розв’язують різні завдання

Розробка за відчуттям корисна, коли ціна помилки мала: перевірити ідею інтерфейсу, написати одноразовий сценарій, зібрати демонстрацію. Розробник оцінює результат візуально й продовжує, доки все «ніби працює».

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

Агентна інженерія змінює одиницю роботи. Результат — не різниця змін, а пакет зміни:

• сформульований намір і межі;
• план із припущеннями;
• мінімальна різниця змін;
• виконані перевірки;
• відомі ризики та неперевірені ділянки;
• спосіб відкату або безпечного вимкнення.

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

Що кажуть дослідження — і чого вони не доводять

Розмова про розробку із ШІ потерпає від двох крайнощів: прикладів постачальників із величезною економією часу й тези «ШІ завжди сповільнює старших розробників». Дані складніші.

У рандомізованому дослідженні METR 16 досвідчених учасників виконали 246 завдань у знайомих їм зрілих репозиторіях із відкритим кодом. З інструментами початку 2025 року вони в середньому працювали на 19% довше, хоча після експерименту вважали, що прискорилися на 20%. Це вагомий сигнал про розбіжність між відчуттям і вимірюванням. Але це не універсальний коефіцієнт: вибірка мала, учасники були фахівцями саме у своїх кодових базах, а моделі та інструменти швидко змінюються.

Звіт Google 2025 року, що ґрунтується на відповідях майже 5000 фахівців, показує інший масштаб: упровадження ШІ корелює зі зростанням пропускної здатності та продуктових показників, але досі пов’язане з погіршенням стабільності постачання. Висновок не в тому, що «ШІ корисний» або «ШІ шкідливий», а в тому, що прискорення виявляє слабкі місця подальших етапів системи.

Anthropic повідомляє, що розробники застосовують ШІ приблизно у 60% роботи, але повністю делегують лише 0–20% завдань. Це дані постачальника, їх не можна вважати нейтральним аудитом; однак вони добре ілюструють практичну різницю між використанням інструмента й передаванням відповідальності.

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

Контекстна інженерія: що агент має знати

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

Контекст складається з чотирьох шарів.

Постійні правила

Короткий AGENTS.md, правило проєкту або навичка: технологічний стек, заборонені дії, команди тестів, принципи архітектури, вимоги до відповіді. Це не енциклопедія репозиторію. Десятки сторінок постійних інструкцій займають контекстне вікно й розмивають пріоритети.

Контекст завдання

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

Контекст на вимогу

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

Зворотний зв’язок від середовища

Компілятор, тести, лінтер, сканер безпеки, попередній перегляд, метрики. Це найцінніший контекст: не думка, а спостережуваний наслідок зміни.

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

Декомпозиція завдань для агента

Погане завдання: «перепиши авторизацію, поліпши архітектуру й додай тести». Воно змішує дослідження, проєктування, міграцію та реалізацію; критерію завершення немає.

Хороше завдання вкладається в один інкремент, який можна перевірити:

1. Мета в термінах поведінки користувача або системи.
2. Дозволені каталоги та інтерфейси.
3. Незмінні контракти.
4. Команди перевірки.
5. Умови ескалації.

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

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

Коли агент має зупинитися

Заздалегідь визначте умови: конфлікт вимог, потреба в руйнівній команді, невідомий власник даних, зміна публічного API, доступ до промислового середовища, секретів або персональних даних. Ескалація — не провал автономності, а ознака правильного керування ризиком.

Цикли перевірки: тести важливіші за красномовство

Агент без зворотного зв’язку оптимізує правдоподібність. Агент із компілятором, тестами та спостережуваним середовищем може оптимізувати результат.

Хороший цикл перевірки:

1. Виконується автоматично.
2. Дає локалізовану помилку.
3. Перевіряє вимогу, а не лише синтаксис.
4. Має обмеження за часом і кількістю спроб.
5. Не дає «виправити тест», якщо тест і є контрактом.

Ієрархія доказів залежить від завдання:

• перевірка типів і лінтинг виявляють структурні дефекти;
• модульний тест підтверджує локальну логіку;
• інтеграційний тест перевіряє межі;
• наскрізний тест або перевірка у браузері — користувацький сценарій;
• сканування безпеки — відомі класи загроз;
• спостереження за метриками після канаркового розгортання — реальну поведінку.

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

Борг перевірки: новий вид технічного боргу

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

Ознаки:

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

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

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

Один агент чи кілька

Багатоагентна оркестрація виправдана не модою, а структурою роботи.

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

Кілька агентів корисні, коли:

• частини завдання справді незалежні;
• дослідження можна розпаралелити за підсистемами;
• перевіряльник отримує інший набір інструментів;
• між результатами є формальний контракт;
• інтегратор відповідає за загальний підсумок.

Робоча схема:

П’ять ролей не означають п’ять моделей у кожному завданні. Це логічний розподіл відповідальності; для простого завдання один агент може послідовно пройти всі етапи.

Безпека: права агента дорівнюють потенційній шкоді

Агент програмування читає неперевірений текст із завдань, файлів README, результатів інструментів і вебсторінок. Будь-яке з цих джерел може містити ін’єкцію в запит. Якщо той самий процес має доступ до командної оболонки, мережі й секретів, текстова атака перетворюється на дію.

Мінімальна модель безпеки:

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

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

Безпека має бути безперервною: дозвіл на читання репозиторію не означає дозволу на публікацію пакета; доступ до проміжного середовища не означає доступу до промислового. Перевіряйте повноваження під час кожної чутливої дії.

Як вбудувати агентів у життєвий цикл розробки

Не додавайте «крок із ШІ» поверх старого процесу. Подивіться на весь потік.

Дослідження та планування

Агент збирає пов’язані завдання, знаходить код і ADR, формує запитання. Людина затверджує обсяг і компроміси.

Реалізація

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

Перегляд

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

Постачання

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

Навчання

Помилки перетворюються на тест, правило, навичку або вдосконалення платформи. Файли правил слід оновлювати після реального збою, а не роздувати через теоретичні побоювання.

Практики сильних команд докладніше зібрано в розборі впровадження ШІ у життєвий цикл розробки.

Метрики: як зрозуміти, що агентна розробка працює

Кількість запитів, токенів і рядків коду — операційні дані, але не цінність. Потрібні три шари.

Потік

• Час виконання від прийнятого завдання до промислового середовища.
• Час циклу від початку реалізації до перевіреного запиту на злиття.
• Розмір пакета змін і кількість паралельних завдань.
• Час очікування перегляду та CI.

Якість

• Частота невдалих змін.
• Частка відкатів і термінових виправлень.
• Дефекти після випуску.
• Перероблення: скільки змін від ШІ суттєво переписала людина.
• Покриття вимог виконуваними перевірками.

Економіка та досвід

• Вартість запуску агента, CI та перегляду.
• Час старшого розробника на постановку й перевірку.
• Частка завдань, у яких агент зупинився коректно.
• Задоволеність розробників без підміни об’єктивних метрик.

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

Як змінюється роль розробника

Роль не зводиться до «інженера запитів». Що дешевший синтаксис, то дорожче:

• правильно вибрати проблему;
• побачити прихований контракт;
• розкласти роботу за межами;
• побудувати систему перевірки;
• оцінити ризик і радіус ураження;
• ухвалити рішення в разі конфлікту доказів.

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

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

План упровадження на 90 днів

Дні 1–30: вимірюваний пілот

Виберіть один репозиторій і два класи завдань: наприклад, модульні тести та невеликі виправлення помилок. Зафіксуйте початкові показники часу циклу, перероблень і дефектів. Надайте агенту мінімальні права, короткий файл правил і команди перевірки. Обмежте незавершену роботу.

Дні 31–60: контур якості

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

Дні 61–90: масштабування

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

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

Типові помилки

Купити ліцензії та назвати це трансформацією. Інструмент без процесу підсилює поточні вузькі місця.

Максимізувати автономність із першого дня. Спочатку вузький контур читання й запису та докази, потім розширення.

Завантажити весь репозиторій у контекст. Пошук на вимогу дешевший і точніший.

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

Вимірювати рівень упровадження замість результату. 90% активних користувачів нічого не говорять про стабільність.

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

Повністю заборонити ШІ через ризик. Тіньове використання залишиться, але без пісочниці, політики й аудиту.

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

Подальше читання

• Новий життєвий цикл розробки: розробка за відчуттям проти агентної інженерії
• Як сильні команди впроваджують ШІ в розробку
• Протокол контексту моделей у промисловій експлуатації 2026 року
• Безпека пісочниці для агентного ШІ
• Безпечна розробка корпоративного ШІ
• Спостережуваність корпоративного ШІ
• Шлях Go-розробника від початкового до старшого рівня

Зовнішні джерела: звіт Google 2025 року про розробку програмного забезпечення за допомогою ШІ, дослідження впливу ШІ початку 2025 року на продуктивність досвідчених розробників відкритого коду, Anthropic — вісім тенденцій, що визначають розробку програмного забезпечення у 2026 році.

Висновок

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

Робоча стратегія на 2026 рік проста: невеликий обсяг, контекст на вимогу, мінімальні права, виконувані перевірки, незалежний перегляд і метрики від завдання до стабільної промислової експлуатації. Автономність збільшують лише після того, як команда навчилася бачити й обмежувати її наслідки. ШІ-агент може написати зміну; інженерна система має довести, що цю зміну варто випускати.

Потрібно впровадити у себе?

Якщо потрібен продакшен-зріз — RAG, агенти, інструменти Model Context Protocol чи LLM-шлюз із бюджетами — див. послугу впровадження ШІ.

Суміжно: AI guardrails, захист від промпт-ін’єкцій, контур оцінки.