ИИ-агент, который спорит с вашим решением, пока не проиграет
Менеджер утверждает решение за десять минут до созвона. Кандидат понравился на собеседовании, цифры в презентации подрядчика сходятся, план сокращения объёма проекта выглядит логично на слайде. Решение принято, потому что оно почувствовалось правильным – а не потому, что кто-то попробовал его опровергнуть.
Это и есть механизм, из-за которого управленческие решения чаще проваливаются не от нехватки данных, а от преждевременного закрытия вопроса: слишком мало вариантов на столе, слишком мало доказательств, которые могли бы решение опровергнуть, слишком много непроверенных допущений. Тема не новая, но у неё появился неожиданно точный инструмент.
Почему «показалось верным» – не то же самое, что «проверено»
Осенью 2026 года в индустрии закрепился термин для практики, которая раньше не имела названия. Эдди Османи и Джеффри Хантли описали её как loop engineering: менеджер задачи перестаёт быть тем, кто вводит каждый промпт, и вместо этого проектирует цикл, который агент проходит сам – до тех пор, пока не выполнен заданный критерий готовности. По данным Pragmatic Engineer, к 2026 году подход стандартизировался до уровня отдельных команд в инструментах вроде Codex и Claude Code – /goal, /loop.
Большая часть примеров вокруг loop engineering – про разработку: агент чинит тесты, пока они не позеленеют, правит код по фидбеку линтера в кругу за кругом. Отдельно стоит автоматизация по расписанию – еженедельный дайджест, ночной отчёт по метрикам. Это тоже цикл, но не тот, о котором стоит говорить менеджеру: расписание экономит время на рутине, но не меняет качество решений.
Интереснее другое свойство того же механизма. Агент, работающий в цикле-до-цели, по определению не останавливается на первом правдоподобном ответе – он продолжает, пока критерий не выполнен. А слабое место управленческого суждения – это именно склонность остановиться на первом правдоподобном ответе. Совпадение слишком удобное, чтобы его игнорировать: инструмент, который структурно не умеет закрывать вопрос раньше времени, оказывается противоядием от привычки, которая закрывает вопросы именно так.
Дальше – три способа применить это к собственным решениям, честная граница того, где цикл бессилен, и что из вашего суждения не устареет, сколько бы моделей ни вышло в следующем году.
Агент, который спорит с вами, пока не кончатся аргументы
Возьмём решение, знакомое любому менеджеру в аутсорс-разработке: смена подрядчика. Текущая команда стабильна, но дороже на пятую часть бюджета. Новая – дешевле, с парой убедительных кейсов в вашей отрасли, но вы с ней не работали.
Обычный способ проверить такое решение – спросить коллегу или самого себя: «в чём тут риск?». Ответ обычно один, максимум два, и на этом проверка заканчивается – ровно то преждевременное закрытие, с которого начался этот текст.
Цикл работает иначе. Вы задаёте агенту цель – найти самый сильный аргумент против вашего решения – и правило продолжения: одно возражение за круг, каждое подкреплено фактом из вашего контекста или конкретным сценарием провала, а не общим тезисом про риски аутсорса. После каждого возражения агент проверяет его на прочность против тех же данных, прежде чем предложить следующее. Останавливается он тогда, когда два круга подряд не приносят ничего нового по существу – и говорит вам об этом прямо, а не тихо повторяет уже сказанное другими словами.
Ниже – рабочий пример с реальными цифрами гипотетического проекта. Запустите как есть, а затем подставьте своё решение и свой контекст.
Попросить агента поспорить с вами один раз – вы это только что сделали, и это несложно. Разница между разовым упражнением и привычкой, которая ловит слепые пятна до того, как они превратятся в дорогую ошибку, – управленческий навык, который разбирается по шагам, а не осваивается за одну статью.
Один цикл возражений вы запустили. Попробуйте ту же привычку на 9 реальных задачах менеджера – бесплатно, без регистрации.
Доступ сразу после регистрации
Ещё два места, где рано останавливаться – ошибка
Спор с решением – только один способ применить цикл-до-цели. Есть ещё два, и оба касаются не самого решения, а того, что ему предшествует.
Весь ли список вариантов на столе
Руководитель проекта режет объём перед дедлайном и обсуждает с командой два варианта: убрать модуль отчётности или сдвинуть релиз на две недели. Оба обсуждались час, оба кажутся исчерпывающими – и именно это ощущение исчерпанности стоит проверять отдельно.
Тот же принцип цикла-до-цели работает и здесь, но цель другая: не найти изъян в одном варианте, а не остановиться, пока не перечислены все жизнеспособные альтернативы. Можно сократить функциональность частично вместо полного отказа. Можно перераспределить людей с менее приоритетной части проекта. Можно договориться с заказчиком о поэтапной сдаче. Список из двух пунктов, который команда обсуждала час, оказывается списком из пяти-шести после десяти минут работы агента, которому явно сказали не останавливаться на первых предложенных вариантах.
Что должно быть правдой, чтобы план сработал
Второе место – допущения, на которых стоит план, а не сам план. Команда внедряет новый инструмент отчётности и рассчитывает сэкономить время на еженедельной подготовке метрик. План выглядит логично. Логично не значит проверено.
Здесь цикл превращается в исчерпывающий пре-мортем: не «что может пойти не так» в общем виде, а перечисление конкретных допущений, без которых план не работает, – каждое со своим уровнем уверенности и сценарием, в котором оно окажется ложным. Данные из разных систем действительно совместимы без ручной чистки. Команда действительно освоит интерфейс за неделю, а не за месяц. У ответственного за внедрение действительно есть на это время сверх текущей нагрузки. Обычный пре-мортем на летучке находит одно-два таких допущения и останавливается, когда идеи иссякают у самых активных участников. Цикл продолжает, пока не иссякнут сами допущения.
Полнота вариантов и проверка допущений – тот же навык, что и спор с решением, только раньше по времени. 9 практических задач менеджера покажут, где именно у вас разрывы – бесплатно.
Доступ сразу после регистрации
Где цикл бессилен
Здесь стоит быть честным до конца, потому что именно эта граница определяет, стоит ли вообще связываться с циклом на конкретном решении.
Цикл улучшает входные данные и стресс-тест решения. Он не взвешивает риск-аппетит, ценности команды или политические последствия – это по-прежнему делает человек, и делает в одиночку. Агент может показать, что смена подрядчика рискованна по срокам поставки; решить, что срыв дедлайна менее болезненен, чем перерасход бюджета, обязан менеджер, потому что это вопрос приоритетов, а не фактов.
Вторая граница жёстче. Когда в предоставленном контексте нет реального сигнала, цикл не молчит – он производит правдоподобные возражения из общих соображений, и они выглядят так же уверенно, как обоснованные. Единственная защита – требовать, чтобы каждое возражение ссылалось на конкретный факт из вашего контекста, а не на общий тезис о рисках. Возражение без такой ссылки не аргумент, а шум, который звучит как аргумент.
И третье: на быстром обратимом решении цикл – избыточная трата времени. Выбор формулировки в письме коллеге не нуждается в трёх кругах стресс-теста. Runtime цикла оправдан там, где цена ошибки высока, а откатить решение назад дорого или невозможно – смена подрядчика в разгаре проекта, наём на ключевую позицию, сокращение объёма перед релизом. На рутинных решениях это тот случай, когда инструмент используют потому, что он есть, а не потому, что он нужен.
Что не устареет, когда модели станут сильнее
Здесь и заключается практический вывод, ради которого стоило разбирать механизм. Пока модели становятся мощнее, а сбор информации и генерация первого черновика решения дешевеют почти до нуля, ценность смещается – не исчезает, а именно смещается – в сторону трёх вещей, которые остаются человеческими по определению.
Первая – верификация. Способность за минуту отличить возражение, подкреплённое реальным фактом, от возражения, которое звучит убедительно, но ни на что не опирается. Вторая – суждение о том, когда цикл вообще не нужен: не каждое решение заслуживает стресс-теста, и умение отличить одно от другого экономит больше времени, чем сам цикл. Третья, самая неудобная, – владение решением. Кто бы ни находил возражения, ответственность за финальный выбор всё равно несёт человек, который его подписал.
Заметьте, что именно происходит с работой менеджера: цикл не убирает суждение из процесса, он переносит его. Раньше суждение расходовалось на сбор аргументов – и именно здесь чаще всего закрадывалось предвзятое мышление, потому что человек естественным образом ищет данные, подтверждающие уже принятое решение. Теперь сбор аргументов делает агент, а суждение целиком уходит на взвешивание того, что он нашёл. Это ровно тот навык, который в программе называют критическим мышлением: не генерировать больше вариантов, а проверять уже сгенерированные на прочность за секунды, а не часы.
Есть и четвёртый архетип цикла-до-цели, который в этот текст не поместился – трассировка вторичных последствий решения на два-три шага вперёд, туда, куда обычно не хватает времени заглянуть. О нём – отдельно, в следующей статье.
Если вы в проектном треке и хотите не разово запустить такой цикл, а собрать личного агента с этой рутиной на каждый день, у нас есть отдельный премиум-модуль Personal Agent – сейчас лист ожидания, но это уже тема для другого текста.
Спор с решением – разовый приём. Проверка на прочность – навык
В Фундаменте курса есть глава «Критическое мышление и ограничения ИИ» – 60-секундная проверка любого ответа модели, систематика типичных ошибок – и урок о работе с автономными агентами: как делегировать цикл, а не только переписываться с ассистентом, и когда его вообще не стоит запускать.
Часто задаваемые вопросы
Что такое агентный цикл в контексте принятия решений?
Чем это отличается от того, что попросить ИИ покритиковать идею один раз?
Не опасно ли доверять решение агенту, который сам решает, когда остановиться?
На каких решениях такой цикл не стоит запускать?
mysummit.school
Engineering Leader в Microsoft18 лет в управлении инженерными командами. Основатель mysummit.school. 700+ выпускников в Яндекс Практикуме и Стратоплане.