Я перестал одобрять решения агента. Теперь я их наблюдаю.

Когда я строил своего первого настоящего агента, я заставил его спрашивать разрешения на всё. Каждое действие, которое он хотел совершить, всплывало запросом: собираюсь вызвать этот инструмент — одобряешь? собираюсь записать этот файл — одобряешь? собираюсь отправить это — одобряешь? Это казалось ответственным. Я был человеком в петле. Ничего не происходило без моего «да».

Понадобилось до неловкого мало времени, чтобы понять: это театр.

«Одобряешь?» «Да.» «Одобряешь?» «Да.»

К тридцатому запросу за сессию я их уже не читал. Я жал «да» так, как прокликиваешь cookie-баннер — паттерн-матчинг на «вроде нормально» и дальше. Одобрения стали рефлексом, а рефлекс — не надзор. Я построил чекпоинт и тут же автоматизировал себя до его штампования.

А заштампованный чекпоинт хуже, чем отсутствие чекпоинта. Без чекпоинта все знают, что агент действует сам, и относятся к его выводу с должным подозрением. С чекпоинтом, который я толком не читал, ошибки агента отмывались в мои решения — я же их одобрил, значит, теперь они мои, вот только я ни разу по-настоящему не посмотрел. Как прямо говорит один гайд по надзору 2026 года, плохо вовлечённый ревьюер, одобряющий дефектный вывод, хуже, чем отсутствие чекпоинта. Я стал этим ревьюером.

Два вида надзора

Для этого есть полезная терминология, и она прояснила мне мышление, как только я её узнал. Индустрия различает human-in-the-loop и human-on-the-loop:

• In the loop (человек в петле): агент останавливается перед каждым определённым действием, спрашивает и ждёт явного «да», прежде чем продолжить. Ничего не происходит без человеческого решения на каждом шаге.
• On the loop (человек над петлёй): агент действует сам в заданных границах, пока человек наблюдает за потоком того, что он делает, и может вмешаться — по ходу или после. Ты надзираешь за результатами, а не за каждым нажатием клавиши.

Я по умолчанию свалился в in-the-loop на всё — по теории, что больше ворот значит больше безопасности. На деле у меня были одни ворота, которые я перестал охранять.

Сдвиг: от «жму да» к «наблюдаю за результатами»

Так что я перевёл бо́льшую часть работы в on-the-loop. Агент работает; я наблюдаю за тем, что он делает, через лог, который реально читаю, через агрегированные результаты и через исключения, которые мне подсвечиваются, — а не через запрос «да/нет» на каждом шаге.

Ментальная модель, которая это разблокировала: так ты управляешь компетентным инженером, а не подозреваемым. Ты не одобряешь каждую написанную им строчку. Вы договариваетесь о плане, ты даёшь ему работать, а потом смотришь результат и всё странное, что всплыло. Построчное одобрение оскорбило бы его и вымотало тебя — и даже не дало бы код лучше, а дало бы бутылочное горло и менеджера, который скользит по диагонали. Надзор за способным работником всегда был on-the-loop. С агентами не иначе.

Что делает «отпустить» безопасным (вот настоящая работа)

Вот часть, которая важна, и это чистая архитектура, а не доверие. Перейти в on-the-loop ответственно только если система построена так, что наблюдения достаточно. Делают это так три вещи:

• Пороги в бизнес-терминах, а не в модельных. Не все действия равны, поэтому и обращаются с ними не одинаково. Рекомендуемое правило — задавать ворота по последствию: обратимый, малозначимый шаг (набросай это, перескажи то, переформатируй) идёт свободно; трата выше порога, доступ к привилегированным системам или что угодно необратимое всё ещё останавливается и спрашивает. Своё дефицитное внимание ты тратишь только там, где ошибка дорога, — а значит, когда запрос всё-таки появляется, ты его реально читаешь, потому что он редкий и важный.
• Наблюдаемость, прерываемость, границы. Нельзя наблюдать то, чего не видишь. Агент должен выдавать трассу, которую можно прочесть, быть останавливаемым на ходу и работать внутри жёстких лимитов, которые он не может превысить. Это та же идея ограничения-в-архитектуре, наведённая на автономию: безопасность — не в хорошем поведении агента, а в заборе вокруг него.
• Повышение заслуживается доказательствами. In-the-loop против on-the-loop — не выбор характера; это калибровка, по которой ты движешься для каждого типа задачи по мере того, как доказана надёжность. Аккуратная версия — держать агента рекомендующим-но-не-исполняющим, пока его суждение не проверено на множестве реальных решений — измеренно, так же как eval-набор говорит тебе, что штука готова, раньше пользователей. Доверие выдаётся по данным, а не по ощущениям, и только тем категориям, которые его заслужили.

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

Работа изменилась, а не исчезла

Что хочу прояснить: уход в on-the-loop — не отречение. Надзор не пропал — он поднялся на уровень выше, из труда в проектирование. Вместо того чтобы тратить внимание на каждое решение (что не масштабируется и вырождается в штампование), я трачу его на политику: какие действия обратимы, каким нужны ворота, что агент обязан логировать, как выглядит исключение и какое доказательство повышает задачу к большей автономии. Это тот же ход, что и ревью спеки вместо каждого диффа — рассуждай о системе, а не о каждом отдельном случае.

Цель надзора никогда не была в том, чтобы мои отпечатки были на каждом решении. Она была в том, чтобы по-настоящему отвечать за результаты. Одобрять всё ощущалось как контроль, а давало рефлекс. Наблюдать, с настоящими границами под низом, ощущается как «отпустить» — и это первый раз, когда я действительно контролировал то, что агенту позволено делать.