ИИ-агент Devin получил механизм, который позволяет задавать лимиты на выполнение задач и останавливать работу при их исчерпании. Бюджеты для ИИ-агентов превращают автономное программирование из эксперимента с непредсказуемым счётом за вычисления в управляемый процесс — хотя агент теперь может не дойти до финального коммита.
О появлении иерархических бюджетов для Devin сообщает The New Stack. Идея проста: организации могут ограничивать расход ресурсов не только на уровне всей команды или аккаунта, но и детализировать правила для отдельных направлений работы. Если лимит достигнут, агент прекращает выполнение задачи, даже если уже начал анализировать репозиторий, писать код или запускать проверки.
Для рынка ИИ-разработки это важный сдвиг акцента. Первые сценарии использования coding agents строились вокруг обещания: достаточно выдать агенту задачу из бэклога, доступ к репозиторию и время. Он сам разберётся в кодовой базе, предложит изменения, напишет тесты и подготовит результат к ревью. В этой модели контроль часто сводился к итоговому pull request и общему счёту за сервис. Но чем дольше агент думает, вызывает инструменты и повторяет попытки, тем заметнее становится цена одной «автономной» задачи.
Иерархия лимитов нужна именно там, где одного общего месячного потолка недостаточно. Компания может хотеть выделить определённый объём ресурсов на пилот ИИ-инструментов, команда — распределить его между проектами, а руководитель разработки — не позволить одной сложной или плохо сформулированной задаче съесть значительную часть доступного бюджета. Такой подход хорошо знаком FinOps-практикам: расходом облачных ресурсов управляют через квоты, теги, алерты и правила эскалации. Теперь похожая дисциплина приходит к агентам, которые работают с кодом.
Есть и менее приятная сторона. Лимит не понимает бизнес-ценность конкретной операции: он лишь фиксирует, что отведённый ресурс закончился. Агент может остановиться после полезного исследования, но до исправления ошибки. Он может подготовить часть изменений, не успеть завершить тестирование или оставить разработчику набор промежуточных артефактов, которые ещё нужно проверить и собрать воедино. Поэтому бюджет нельзя воспринимать как замену инженерному контролю — скорее это предохранитель от неограниченного расхода.
Для разработчиков это означает, что постановка задачи становится ещё важнее. Чем расплывчатее запрос, чем больше неизвестных в окружении и чем слабее тесты, тем выше шанс, что агент потратит лимит на обследование вместо результата. Практичный сценарий — дробить работу: отдельно исследование, отдельно план изменений, отдельно реализация и проверка. На каждом этапе проще задать приемлемый потолок затрат и решить, стоит ли продолжать. Заодно такой процесс оставляет человеку понятные точки контроля, а не только финальный ответ системы.
Для CTO и руководителей инженерных подразделений бюджеты для ИИ-агентов дают язык для разговора с финансами и безопасностью. Вопрос «можно ли дать агенту доступ к репозиторию» дополняется вопросами «на какие задачи», «с каким пределом расхода» и «что происходит после остановки». Полезно заранее определить, кто получает уведомление о достижении лимита, можно ли возобновить задачу с новым бюджетом и какие данные сохраняются для разбора неудачного запуска.
Особенно актуально это для компаний, где ИИ-агентов используют не один-два энтузиаста, а несколько команд. Без правил расходы становятся непрозрачными: один сервис оплачивает платформа, эксперимент запускает продуктовая команда, а эффект пытаются оценить по ощущениям. Лимиты сами по себе не доказывают окупаемость, но позволяют хотя бы привязать стоимость к конкретному проекту, задаче или подразделению. Это уже достаточная причина вынести агентные инструменты из категории «подписка для разработчика» в зону нормального операционного управления.
При этом экономить на каждом запуске бессмысленно, если из-за слишком жёстких ограничений агент регулярно бросает полезную работу на середине. Разумнее измерять не только расход, но и долю завершённых задач, качество кода после ревью, число повторных запусков и время инженера на исправление результата. Дешёвый запуск, после которого разработчик часами восстанавливает контекст, не обязательно выгоднее более дорогого, но завершённого.
Следующий этап для рынка — не просто выставлять потолок затрат, а научиться прогнозировать цену работы до запуска: по размеру репозитория, типу задачи, доступным инструментам и истории похожих изменений. Пока же бюджеты для ИИ-агентов фиксируют более приземлённую реальность: автономный помощник в разработке — это не бесконечный стажёр, а вычислительный ресурс, которому нужны те же правила, лимиты и ответственность, что и любому другому элементу инженерной инфраструктуры.
