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