EVERYTHING
За даними Thenewstack, ключовим етапом у розвитку агентських систем є їхня здатність до самоверифікації. Іdo Pesok із Cognition нещодавно відзначив значний прогрес: його команда почала запускати більше Devins асинхронно — через події, розклади та інших агентів, ніж під час інтерактивних сесій. Це означає, що агенти перестали бути лише інструментом, яким керує розробник; вони стали автономними виконавцями завдань.
Обмеження генерації замінюється обмеженням верифікації
Коли розробник контролював кожен крок роботи агента, він також виконував роль верифікатора: читав диференціали (diff), запускав код у реальній системі та приймав рішення про його коректність. Вилучивши людину з цього циклу, ми виключаємо і верифікатора. Як зазначає Ido Pesok, асинхронні агенти корисні лише тоді, коли розробники можуть довіряти їхнім результатам. «Асинхронний агент, який не може самоверифікувати себе, нікому не економить час. Він відкриває PR і просить щось нижче в ланцюжку оцінити».
Чому зелений тест може бути оманливим
Автономний агент виконує реальну роботу: пише код, запускає юніт-тести та мокни (mocks), а потім повідомляє про «зелений» результат. Проблема полягає в тому, що ці мокни були написані самим агентом для відповідності його власній моделі поведінки залежностей. Тобто агент тестує свою зміну проти власних припущень.
У монолітній системі ця розбіжність невелика. Але в хмарно-нативному середовищі це єдиний ризик. Зміна не існує ізольовано; вона працює поруч із сервісами, брокерами та базами даних, на які посилається і які контролюються механізмами тайм-аутів та повторних спроб (retries). Критичні збої виникають саме на цих межах.
- Зміни в контрактах між сервісами.
- Поля, що серіалізуються інакше, ніж очікує споживач.
- Виклики нижче в ланцюжку, які перестають працювати через політику повторних спроб.
- Зміни схеми даних, які не виявляться локально.
Агент може зафіксувати бездоганний прогін, але все ж таки розгорнути зміни, що призведуть до збою сервісу на відстані 2 хлопів під час реального трафіку. Локально зелений — у продакшені зламано.
Вартість помилки залежить від місця циклу
Найдорожчим є те, що відбувається після злиття PR (Pull Request). Якщо агент виявляє помилку під час ітерації, це коштує секунди. Він запускає зміну, бачить реальну помилку, виправляє її та повторює процес. Цей процес повністю відбувається в фоновому режимі.
Натомість, якщо той самий збій виявляють після мержу PR, це коштує годин, а не годин агента. Контекст втрачається. Інженер повинен відволіктися на налагодження межового збою у коді, який він не писав і який створив агент, що не може пояснити свій процес мислення.
Таким чином, головний висновок полягає в тому, що успішне використання AI-агентів у продакшені залежить від створення складних механізмів верифікації на межах системи, а не лише від їхньої здатності генерувати код.