Інженерні команди, які оцінюють агентів для написання коду, зазвичай починають із неправильного запитання. Вони хочуть знати, наскільки автономним може бути агент. Яку частину конвеєра він може взяти на себе? Чи може він написати специфікацію, відредагувати репозиторій і випустити код у продакшн, нікого не турбуючи? Демонстрації підживлюють цю одержимість. Ви бачите відшліфований робочий процес, де один промпт запускає каскад правок і розгортань, і інстинктивно хочете впровадити таку ж можливість у своїй організації. Але гламур — це поганий принцип проектування. Кращі запитання набагато менш захопливі: хто надав цій штуці повноваження, до яких систем вона насправді може мати доступ і що станеться, коли вона неминуче припуститься помилки?
Пастка автономії
Захоплива автономія — це пастка. Вона привчає нас святкувати ботів, які генерують специфікації, змінюють репозиторії та розгортають код, спокійно заявляючи, що завдання виконано. Це не інженерія. Це «стрибок у довіру» з доступом до shell. Сама робота стає майже занадто легкою у виконанні. Будь-яка модель може за лічені секунди видати код, документацію або плани архітектури. Але справжньою ціною в розробці програмного забезпечення ніколи не була швидкість друку. Це завжди була валідація, рев'ю та обережне рішення сказати «так, це правильно і безпечно для релізу». Згенерована робота коштує дешево. Схвалення коштує дорого. Компанії, які зрозуміють, як організувати процес схвалення чисто та послідовно, будуть тими, хто насправді випускає надійні системи.
Чому самоперевірка не працює
Ризики проявляються за передбачуваними сценаріями. Модель складає план, а потім оцінює, чи є цей план хорошим. Агент редагує ваш кодовий базис і пояснює вам, чому його зміни безпечні. Інструмент виконує команду і просить вибачення замість дозволу. Кожен із цих випадків представляє одну й ту саму фундаментальну помилку. Якщо агент створює специфікацію, щось поза межами цього агента має її затвердити, перш ніж вона стане істиною. Якщо агент змінює код, окремий процес має перевірити diff. Дозволити генератору виступати власним валідатором — це не скорочення шляху. Це структурний баг, замаскований під зручність.
Промпти — це не системи дозволів
Ви не зможете захистити агента за допомогою хитромудрих формулювань. Порада моделі бути обережною або запитувати перед видаленням чогось не створює меж. Промпти — це не системи дозволів. Перш ніж підпускати агента до продакшну, вам потрібен чесний інвентар його можливостей. Чи може він прочитати весь репозиторій? Чи може він виконувати shell-команди? Чи може він відкрити браузер? Чи може він витягнути дані клієнтів у своє контекстне вікно? Більшість команд не знають повних відповідей. Вони припускають, що інструмент обмежений пісочницею, тоді як насправді він має доступ на запис до критично важливих шляхів. Спочатку опрацюйте поверхню атаки. Потім будуйте стіни.
Побудуйте багаторівневу систему контролю
Щойно ви зрозумієте, що може агент, спроектуйте систему контролю, яка співвідносить ризик із рівнем перешкод. Дії з низьким ризиком, як-от оновлення внутрішньої документації або форматування коду, можуть виконуватися автоматично. Дії середнього ризику, наприклад рефакторинг модуля або додавання нової залежності, мають проходити через контрольний пункт, де людина або перевірений набір тестів підтверджують дію. Дії з високим ризиком — розгортання в продакшн, зміна інфраструктури або доступ до конфіденційних даних — потребують окремого схвалювача, який не брав участі в генерації. Кожна дія повинна залишати аудит- слід. Ви повинні мати можливість відтворити, які саме файли були прочитані, які інструменти викликані та які рішення прийняті. Агентна розробка — це не ліцензія на ігнорування рев'ю. Нудна перешкода — це функція. Належний шлюз схвалення діє як автоматичний вимикач, коли щось починає йти не так.
Відповідність меж ризику
Калібруйте свої межі відповідно до реальної небезпеки. Перетворення кожної дрібниці з форматування Markdown на церемонію відповідності стандартам зупинить роботу вашої команди. Але вважати дії з високими ставками нешкідливими лише тому, що агент виглядає впевненим, — так само безглуздо. Мета — пропорційний контроль, а не театральні обмеження.
Тримайте артефакти малими та спостережуваними
The most useful agent systems do not try to wow you with massive autonomous runs. They produce small, reviewable artifacts. A tight plan. A focused diff. A readable log. Giant autonomous executions are nightmares to debug. When something breaks after a fifty-file agent session, you have to untangle intent, execution, and side effects all at once. Keep the blast radius small. Insist on knowing which files the agent read and which tools it called. Observable systems are maintainable systems. Black-box autonomy is just technical debt with better marketing.
Six Questions Before You Grant Access
Before you hand an agent any real responsibility, pressure-test your setup with six hard questions.
- What capabilities does the system actually have?
- Which actions are denied by default, blocked at the infrastructure level rather than discouraged by a polite sentence in the system prompt?
- Which actions require explicit approval?
- Which artifacts get frozen before the agent consumes them, so it cannot silently manipulate its own inputs?
- Which validator, entirely separate from the generator, judges the final output?
- Which log proves, without ambiguity, what actually happened?
This is basic engineering hygiene. Separate the generator from the validator. Keep human authority at the boundary.
The Real Test
There