У любого diff есть слепое пятно: его хуже всего видит тот, кто его сделал. Это верно и для вас, и для агента, который писал код, - оба уже приняли набор решений и склонны их же и оправдывать. Свежий, ни к чему не привязанный взгляд ловит то, что автор рационализирует и пропускает.
Наивный ход - прочитать собственный diff один раз и закоммитить, а если код писал агент, то положиться на то, что он заодно написал и тесты. Кажется, что двойная работа лишняя: изменения на виду, тесты зелёные, что тут ещё смотреть. Ровно на этом самоуспокоении в репозиторий и въезжают регрессии.
Ломается это на природе авторской слепоты. Тот же контекст, что породил ошибку, её же и ревьюит: агент, написавший код, оценивает его теми же допущениями, из которых баг и вырос. Тесты, написанные вместе с кодом, проверяют то, что автор считал важным, - и молчат ровно там, где он не подумал. Проверка изнутри собственного контекста систематически не видит определённый класс промахов.
Профессиональный механизм - Quick Review: выделенный review-субагент, доступный для агента Devin Local и не поддержанный в legacy Cascade. Он запускает агентное ревью локальных изменений, анализирует diff и отдаёт отзыв прямо в редакторе. Запускать его стоит после вашей собственной проверки и до commit или PR. Дайте ему контекст цели и отдельно попросите искать регрессии, проблемы безопасности, недостающие тесты и лишний scope - тогда взгляд будет не абстрактным, а нацеленным. Отзыв ложится прямо в редакторе рядом с изменениями, так что каждый пункт привязан к конкретному месту diff, а не висит отдельным списком.
Почему отдельный агент, а не ещё один проход тем же. У review-субагента свежий контекст и нет ставки в этом коде: он не защищает принятых решений, потому что не он их принимал. Вдобавок для ревью можно выбрать другую модель, чем писала код, - второй взгляд оказывается ещё и вторым мнением, а не эхом первого. Это дешёвая форма разнообразия: два разных механизма ошибаются по-разному, и то, что пропустил один контекст, с большей вероятностью заметит другой.
Выбор модели ревью - живой источник, и относиться к нему надо как к снимку. На дату среза документация перечисляла три варианта в выпадающем списке: SWE-check - быстрая лёгкая модель под типовые проблемы, бесплатная; GPT 5.5 и Opus 4.7 - фронтирные модели для глубокого агентного ревью, с оплатой по токенам. Каталог и биллинг могут измениться, поэтому реальный список всегда смотрят в самом селекторе, а не в этой строке. И биллинг конкретной модели сверяют перед запуском, а не считают известным по памяти.
Отсюда и цена. Лёгкая бесплатная модель уместна на частых мелких проверках и ловит распространённые issue; фронтирная стоит токенов и оправдана на сложном или рискованном diff, где глубина важнее скорости. Гонять дорогую модель на правке в одну строку - это плата за глубину там, где её не о чем применять. Разумная опора - лёгкая модель по умолчанию, а фронтирную включать точечно, когда цена ошибки в этом diff выше цены токенов.
Оправдан Quick Review на нетривиальном diff перед commit или PR, особенно если изменения затронули публичный контракт, безопасность или края, о которых легко забыть. На однострочной правке с очевидным эффектом он избыточен - там дешевле прочитать diff глазами. Как и с выбором поверхности, мощность ревью соразмеряют с тем, что реально изменилось. Отдельный смысл ревью появляется там, где diff писал агент: свежий взгляд компенсирует то, что автор и проверяющий здесь - один и тот же процесс.
Проверять надо не только код, но и сам статус ревью, потому что ревью не является gate само по себе. Любой finding - это гипотеза, которую подтверждают кодом или тестом, а не приговор; и наоборот, отсутствие findings не доказывает корректность, а лишь говорит, что этот взгляд ничего не заметил. Quick Review добавляет линзу, а не выдаёт зелёный свет, и решение о готовности остаётся за человеком и проверками. Практически это значит: finding сначала воспроизводят, потом чинят, а зелёный прогон после правки и есть доказательство, которого само ревью не даёт.
Типичные провалы отсюда и растут. Первый - принять "findings нет" за доказательство корректности и закоммитить непроверенное. Второй - броситься чинить по finding, не воспроизведя проблему, и потратить время на ложную тревогу или сломать рабочее. Третий - выбрать дорогую модель на тривиальном diff и заплатить за глубину, которой некуда приложиться. Признак всех трёх один: результат ревью приняли за вердикт, а не за подсказку, которую ещё предстоит заземлить.