Фаза 9. Code review: агент-критик против агента-автора | Григорий Добряков

Григорий Добряков

Курс · AI-Driven Development Lifecycle

Фаза 9Курс ADLC

Фаза 9. Code review: агент-критик против агента-автора

Фаза 8 сдала PR-ы, и как минимум один из них таит скрытый конфликт на стыке задач. Теперь нужна вторая пара глаз — code review. И здесь курс делает нетривиальное утверждение: ценность ревьюера-человека держалась не на его уникальном взгляде, а на дефиците вторых глаз. Агентов можно поставить сколько угодно и каких угодно — а значит и «независимость взгляда» достигается не человеком, а разнообразием.

Важна тонкость, которую легко пропустить: ревью работает, только если автор и критик — не одно и то же. У людей это обеспечено автоматически (разные люди). У агентов это надо спроектировать, иначе получишь иллюзию контроля.

Роль человека сегодня

Старший инженер или коллега проверяет PR на корректность, дизайн, безопасность, читаемость. Он — вторая пара глаз и носитель стандартов команды: ловит баги, указывает на нарушения архитектуры, блокирует или пропускает мёрж. Классически — ручной ревью, комментарии, споры о стиле, роль привратника у ветки.

Разложим ценность ревьюера на части. Проверка по правилам (стандарты, линтеры, соответствие ADR, известные классы багов) — механическая. Независимый взгляд («я бы сделал иначе, и вот где это сломается») — содержательная. Дефицит («вторых глаз мало, ревью — узкое место») — организационная. Первое автоматизируется полностью, третье снимается количеством агентов, а вторая часть — та, ради которой ревью и существует, — требует не человека, а именно инакости проверяющего.

Что передаём агенту

Ревью-агент держит роль второй пары глаз. Он проверяет PR автора-агента на баги, дизайн, безопасность и — критично — на соответствие ADR из фазы 5; ведёт диалог с автором; блокирует или одобряет мёрж. При approve — мёржит.

Ключ ко всей фазе — разделение ролей. Автор и критик обязаны быть разными агентами, и лучше на разных моделях. Если ревьюер — та же модель, что и автор, они ошибаются одинаково: критик пропустит ровно те дефекты, которые сам бы допустил. Это не ревью, а самоподтверждение с лишним шагом. Инакость модели заменяет здесь инакость человека.

Архитектура агента

State-machine фазы

Входы

PR (ф.8), architecture + ADR (ф.5), стандарты и линтеры проекта, оба контракта на стыке (чтобы видеть межзадачные конфликты).

Агент держит роль

Инструменты: статический анализ; запуск тестов; security-скан; проверка соответствия ADR; генерация замечаний; право блокировать мёрж.

Артефакт

ревью с вердиктом (approve / blocked) и замечаниями; при approve — мёрж.

Передача дальше: одобренный код → Testing (ф.10) и Release (ф.11); правки → обратно автору (ф.8). Обратите внимание на вход «оба контракта на стыке». Ревьюер-агент — первая точка в контуре, которая видит больше одной задачи сразу. Автор фазы 8 заперт в своей задаче; ревьюер имеет доступ к соседним PR и к архитектуре — и потому способен поймать дрейф допущений, невидимый изнутри отдельной задачи.

Обратите внимание на вход «оба контракта на стыке». Ревьюер-агент — первая точка в контуре, которая видит больше одной задачи сразу. Автор фазы 8 заперт в своей задаче; ревьюер имеет доступ к соседним PR и к архитектуре — и потому способен поймать дрейф допущений, невидимый изнутри отдельной задачи.

Где ломается

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

Слепые зоны вкуса и горизонта. «Это пройдёт ревью, но станет болью через год» — суждение о поддерживаемости на длинном горизонте ревью-агент делает хуже человека с опытом сопровождения. Он силён на проверяемом здесь и сейчас, слабее — на «это technical debt, который выстрелит позже».

Ответственность за пропущенное. Что прошло ревью и сломало прод — вопрос ответственности, а не техники. Больше ревьюеров-агентов снижают вероятность пропуска, но не создают субъекта, с которого спрашивают за последствия.

Что остаётся человеку

Аудит выборки ревью и калибровка стандартов — чтобы контур не сошёлся в согласованную галлюцинацию, которую сам себе подтверждает. Кандидат — участие только на необратимых и архитектурно-чувствительных PR. Устойчивого остатка внутри самого ревью почти нет: инакость даёт разнообразие агентов, а ответственность уходит в governance (ф.14).

остаток человека ≈ 40%

Провокация / тезис

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

Сквозной кейс

«Витрина» на этой фазе

Ревью-агент на сильной модели (заложенной ещё в team-spec, ф.6, именно ради платёжного контура) берёт PR по идемпотентности платежей. Внутри задачи всё чисто — но у ревьюера есть доступ к соседнему PR корзины и к ADR из фазы 5. Он ловит то, что было невидимо в фазе 8: агент корзины считает заказ оплаченным до подтверждения вебхука, агент платежей — после. Это прямое нарушение ADR об устойчивости к повторам: при повторном вебхуке заказ проведётся дважды. Ревьюер блокирует мёрж, формулирует замечание со ссылкой на ADR и возвращает обоим авторам.

Заметьте, что сработало. Дефект жил на стыке двух корректных PR — его не видел ни один автор. Поймал его агент с двумя свойствами, которых не было у авторов: другой моделью (не ошибся так же) и более широким полем зрения (оба контракта плюс ADR). Ни то, ни другое не требует человека — требует правильно спроектированной инакости. Артефакт → ревью PR «Витрины», вердикт blocked.

На практике

Как это устроено — инженерные разборы

Отдельные howto из практики, где фаза показана на работающем коде и артефакте.

Читать дальше

Строите AI-driven доставку у себя?

Проектирование ADLC-контура: где агент держит роль, а где остаётся человек-принципал — под вашу команду и продукт.

Написать на почту

Движок перехода

Next Move Engine — система, которая доводит команду до автономного цикла доставки.

Next Move Engine →