Один AI-агент релизит каждый день. Другой неделю проверяет инварианты: в этом и есть агрессивность

Термин агрессивность агента описывает release tempo и допустимый уровень риска. Один агент быстро пилит фичи, быстро выкатывает и спокойно живет с тем, что что-то может сломаться. Другой за ту же неделю успевает меньше, зато подробно фиксирует инварианты, покрывает систему тестами, проверяет edge cases и строит контур так, чтобы он работал по-настоящему надежно.

Постановка вопроса

Когда говорят об AI-агентах, обычно обсуждают качество кода, автономность или то, сколько задач агент может закрыть без человека. Но в продуктовой разработке это не главный вопрос. На практике гораздо важнее понять, в каком темпе агент поставляет изменения в прод и какую цену команда готова платить за этот темп.

Один режим ближе к стартапу: быстро сделали, быстро выкатили, сломалось - починим. Другой ближе к big tech: агент медленнее двигается по фичам, зато подробно описывает инварианты, пишет много тестов, проверяет краевые случаи и строит систему так, чтобы она не развалилась на следующем повороте.

Именно эту разницу мы и называем агрессивностью агента. Этот термин описывает скорость релизного цикла и допустимый уровень инженерного риска.

Определение

Под агрессивностью агента мы понимаем насколько быстро он двигает продукт к релизу и насколько охотно жертвует запасом надежности ради скорости. Чем выше агрессивность, тем быстрее агент выпускает новые фичи, тем меньше времени тратит на формализацию инвариантов и тем спокойнее относится к тому, что часть проблем будет поймана уже после релиза.

Высокая агрессивность: режим стартапа

Агрессивный агент нужен там, где задача команды - максимально быстро двигаться по новым фичам и релизам. Он не будет неделями закрывать все теоретические риски. Он скорее быстро соберет рабочий модуль, доведет сценарий до релиза и позволит рынку показать, стоило ли вообще тратить на это время.

Это логика стартапа: лучше быстро выпустить пять гипотез и убить четыре, чем месяц шлифовать одну идеально. Здесь приемлем сценарий, в котором после релиза что-то ломается, если цена этой поломки ниже, чем цена медленного движения.

Низкая агрессивность: режим устойчивости

Слабо агрессивный агент ведет себя иначе. Он может за ту же неделю сделать только один-два модуля, зато подойти к ним так, как это принято в зрелой инженерной среде: расписать инварианты, покрыть код тестами, пройтись по edge cases, убрать хрупкие места и сделать систему устойчивой.

Такой режим медленнее по внешней скорости релизов, но он нужен там, где ошибка слишком дорога. В платежах, безопасности, критичных user flow, нагруженных системах или в любом месте, где “сломалось и пофиг” на самом деле превращается в потерю денег, пользователей и доверия.

Как выбирать режим

Практическое правило простое: чем дешевле ошибка и чем важнее скорость, тем выше можно поднимать агрессивность. И наоборот: чем дороже ошибка и чем длиннее горизонт жизни функции, тем менее агрессивным должен быть агент.

Что это меняет для команды

Главная ценность термина в том, что он дает команде нормальный язык управления агентом. Вместо абстрактного “сделай хорошо” появляется конкретная постановка: нужно ли нам сейчас быстро релизить или нужно почти железобетонно не ломаться.

• Если команда живет как стартап, агенту нужно разрешать высокий темп и не заставлять его вести себя как отдел reliability в big tech.
• Если продукт уже дорогой и чувствительный, агенту нельзя позволять гнать релизы ценой скрытых поломок и недоисследованных краев.
• Если контекст смешанный, агрессивность надо задавать по слоям: фичи можно релизить быстрее, а критические контуры держать в более осторожном режиме.

Поэтому проблема почти никогда не в том, что агент “слишком медленный” или “слишком дерзкий” сам по себе. Проблема в том, что ему дают не тот уровень агрессивности для конкретной задачи и конкретной цены ошибки.

Итог

Агрессивность агента - это скорость релизов, помноженная на допустимый риск. Высоко агрессивный агент ближе к стартапной логике: быстро сделать, быстро выкатить, быстро учиться на последствиях. Низко агрессивный агент ближе к логике big tech: медленнее двигаться, но строить систему так, чтобы она выдерживала нагрузку, края и долгую эксплуатацию.

Это не спор о том, какой режим “правильный”. Правильный режим тот, который соответствует стадии продукта. Одним командам нужен агент, который релизит сегодня. Другим нужен агент, который не даст этим релизом сломать завтра.