Пока diff небольшой, в нас просыпается хранитель инженерной чистоты: мы спорим о нейминге, замечаем лишний пробел, обсуждаем, стоило ли выносить логику в helper, но когда правка разрастается до тысяч строк, строгость уступает другому подходу: CI зелёный, тесты прошли, код выглядит вроде неплохо - можно жать Approve.

С coding-агентами проблема становится более системной. Пока задача небольшая и хорошо ограничена, результат ещё можно напрямую соотнести с исходным запросом, но при асинхронной и мультиагентной работе у каждого из агентов появляются собственные подзадачи, гипотезы и хвосты незавершённых решений. Поэтому, возвращаясь в процесс, человек проверяет уже не изолированные изменения, а заново восстанавливает состояние задачи - что именно было задумано, что уже проверено, какие инварианты теперь считаются действующими и где остался риск.

И именно здесь ломается наивный human-in-the-loop, а большой diff - является лишь симптомом. Настоящее узкое место - стоимость повторного входа в контекст: формально человек остаётся в процессе, но фактически его роль всё чаще сводится к механическому одобрению, в свою очередь дефицитом становится не машинная производительность, а человеческое внимание.

В прошлой статье о контекстной инженерии для coding-агентов я писал о памяти агента. Здесь - о том, какая память и какие механизмы контроля нужны уже человеку.

1. Самая дорогая часть - не сама пауза, а восстановление контекста

Чтобы понять, почему агентная разработка так быстро съедает внимание, полезно разделить две вещи: само прерывание и возвращение к задаче. Для разработки обычно дороже второе. Проблема не столько в том, что вас отвлекли на пять минут, а сколько в том, что после этого нужно заново восстановить рабочую картину: где вы остановились, что уже проверили, какие ограничения держали в голове и почему собирались идти именно в эту сторону.

Это хорошо видно в классической работе Parnin и Rugaber: авторы проанализировали около 10 тысяч программных сессий 85 разработчиков и показали, что после возврата к задаче активное редактирование редко начинается сразу. Обычно разработчик не продолжает с места где остановился, а сначала заново собирает контекст.

Та же логика видна и в исследованиях повседневной разработки: значительная часть времени уходит не на набор кода, а на понимание системы, поиск нужного места изменений и сбор контекста. В работах Minelli и коллег и Xia и коллег на program comprehension и навигацию приходится основная доля времени, тогда как на собственно editing - лишь малая часть.

С появлением агентов эта асимметрия не исчезает, а усиливается. Генерация становится дешевле, но понимание и валидация никуда не деваются. В работе Comprehension-Performance Gap in GenAI-Assisted Brownfield Programming Copilot сокращал время выполнения brownfield-задач и повышал число пройденных тестов, но не давал прироста в понимании кодовой базы. Поэтому агенты не создают новую фундаментальную проблему: они делают старую проблему понимания и проверки доминирующей.

2. Почему главным узким местом становится ревью, а наивный human-in-the-loop - формальностью

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

Для стадии ревью это особенно заметно. В статье Code Review as Decision-Making авторы показывают, что ревью - не линейное «посмотреть diff и принять решение», а когнитивный процесс как минимум из двух фаз. Сначала идёт восстановление контекста: ревьюер заново собирает замысел и причины изменений, и лишь потом переходит к аналитической части. Когда агент возвращает крупный результат после фоновой работы, именно эта дорогая фаза и становится главным узким местом.

Похожий механизм описан и в исследованиях доверия к автоматизации. И исследование Microsoft о влиянии генеративного ИИ на критическое мышление, и систематический обзор по automation bias указывают на одну и ту же логику: когда растут доверие к системе, дефицит времени и сложность задачи, человек охотнее полагается на автоматизацию вместо полноценной проверки. В мультиагентном режиме эти условия часто совпадают: результат приходит с задержкой, живой контекст уже утрачен, а разбор накопленного состояния дорог. Поэтому содержательная проверка быстро становится дороже согласия, и одобрение превращается из решения в ритуал.

Отсюда важное уточнение. Ломается не человеческий контроль вообще и не human-in-the-loop как идея, а его наивная версия, в которой человек должен часто подтверждать шаги без достаточного контекста. Поэтому задача состоит не в том, чтобы держать человека в каждом микродействии, а в том, чтобы проектировать режим контроля так, чтобы его внимание включалось в нужные моменты и в пригодной для него форме.

Отсюда и сдвиг в governance-подходах к агентным системам: вместо идеи постоянного ручного подтверждения каждого действия всё чаще обсуждаются значимые контрольные точки, заранее заданные границы вмешательства и отдельный слой мониторинга. Singapore IMDA прямо пишет, что непрерывный человеческий надзор за всеми агентными процессами плохо масштабируется, а OpenAI добавляет, что часть наблюдения и фильтрации сигналов разумно выносить в отдельный слой мониторинга.

Если система слишком часто просит человека что-то одобрить, она почти неизбежно превращает контроль в ритуал.

Отсюда и практический вопрос: как устроить работу так, чтобы содержательный контроль не растворялся в ритуале одобрений?

3. Что с этим делать на практике

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

3.1. Контролировать нужно не каждый шаг, а риск и переход системы в новое состояние

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

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

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

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

3.2. Нужны память задачи, пакет проверки и пакет эскалации

Здесь полезно развести три слоя.

Первый - память задачи: внешний набор артефактов, на которых держатся работа агента и общий ход проекта. Большая задача не должна жить только в чате. Ей нужны внешние документы вроде PLAN.md, DECISIONS.md, EVIDENCE.md, STATUS.md и RISKS.md.

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

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

3.3. Больше quality gates, меньше ручной проверки «на глаз»

Если проверка плохо масштабируется в голове разработчика, её нужно выносить в автоматические барьеры: unit- и integration-тесты, e2e-сценарии, визуальные регрессии для UI, линтеры, static analysis, policy checks и явные условия остановки. Всё, что даёт однозначный pass/fail и способно остановить merge или deploy, здесь работает как quality gate.

Это не отменяет человеческого решения: quality gates не ревьюят вместо разработчика, а сужают объём того, что ему приходится валидировать вручную.

В том же отчёте Sonar 57% разработчиков говорят, что используют static analysis именно для проверки AI-кода. Практическая логика здесь простая: чем больше надёжных quality gates мы ставим на пути агента, тем реже разработчику приходится принимать решение «на глаз» по сырому контексту.

4. Рабочая матрица автономии для мультиагентного режима

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

Режим	Критерий	Что можно отдавать агенту	Что должен видеть разработчик
Автономно	Действие обратимо, локально, не затрагивает внешние контракты и хорошо покрыто автоматическими проверками	Документация, генерация и обновление тестов, локальные рефакторинги, исследовательские подзадачи, безопасные внутренние улучшения	Итоговый статус, артефакты и краткая сводка по завершении
Контрольная точка	Риск умеренный, меняется состояние задачи, но цена ошибки и отката ещё контролируема	Завершение этапа реализации, заметный `diff`, архитектурная развилка, изменение внутреннего поведения без внешних последствий	Пакет проверки и явное решение по дальнейшему направлению
Обязательное согласование	Ошибка дорога, действие затрагивает внешние контракты, права, данные, продакшен или трудно откатывается	Публичные интерфейсы, миграции базы данных, права доступа, чувствительная конфигурация, внешние интеграции, необратимые действия	Пакет проверки уровня `go/no-go`: что изменится, какие риски остаются, чем это покрыто и как откатиться
Эскалация	Есть аномалия, нарушение, конфликт или выход за пределы заданного коридора	Упавшие тесты, нарушение политики, конфликт между агентами, высокая неопределённость, слишком большой `diff` без сжатой сводки, выход за рамки задачи	Пакет эскалации: что сломалось или вышло за рамки, где это произошло, кто и что уже сделал, какие проверки упали, насколько безопасен откат и какое решение требуется прямо сейчас

Эта модель хорошо согласуется с IMDA: человеческий контроль нужен там, где цена ошибки высока, эффект трудно откатить или действие выходит за заранее согласованные границы. А данные Sonar подсказывают и более прагматичное правило: автономию лучше давать не «вообще», а по классам задач и уровню риска.

Важно только не переоценивать сам по себе размер diff. Здесь он полезен не как объяснение проблемы, а как дешёвый операционный индикатор: если изменения стали слишком большими для быстрого входа, системе нужен не ещё один лог, а лучшая упаковка состояния и более жёсткая контрольная точка.

Заключение

Ключевой вопрос в агентной разработке сегодня не только в качестве генерации. Куда важнее другое: насколько дёшево разработчик может повторно войти в текущее состояние задачи и принять по нему решение. Если архитектура этого не решает, рост числа агентов лишь ускоряет накопление чужого контекста и тормозит разработку.

Отсюда и практический вывод. Системе недостаточно производить изменения; она должна упаковывать их в форму, пригодную для проверки, приёмки и безопасного продолжения работы. Для этого нужны изоляция ролей и контекста, общая память задачи вне чата, облегчённые пакеты проверки и эскалации, а также наблюдаемость вместе с quality gates.

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

Именно поэтому human-in-the-loop так легко превращается в формальность: не потому, что человек безответственный, а потому, что система слишком часто просит его принимать дорогие решения без живого контекста. Мы уже научились строить память для модели. Следующий шаг - научиться строить память и контроль для человека. Иначе мультиагентная разработка упрётся не в интеллект агентов, а в пределы человеческого внимания.

Цена контекста в агентной разработке: почему bottleneck — не код, а внимание человека