Reviewing inline edits without rubber-stamping

Кнопка Accept All — самая опасная кнопка AI-редактора не потому, что агент плохо пишет код, а потому, что она эксплуатирует слабость человека: склонность доверять автоматике (automation bias). Когда дифф выглядит аккуратно, компилируется и сопровождается уверенным объяснением, мозг охотно ставит галочку «выглядит нормально» — это и есть rubber-stamping, ревью-штамповка без чтения.

Проблема усугубляется асимметрией скоростей: агент генерирует код в десятки раз быстрее, чем вы его понимаете. Если принимать всё подряд, в кодовой базе накапливается долг понимания — код, который работает, но который никто в команде не сможет объяснить, поправить или отладить в три часа ночи при инциденте. Известный эффект обычного код-ревью здесь работает против вас вдвойне: чем длиннее дифф, тем поверхностнее его читают. На дифф в 10 строк ревьюер найдёт три замечания, дифф в 500 строк получит «LGTM».

И главное про ответственность: авторство не делегируется. В git blame будет ваше имя, на постмортеме «это написал AI» — не аргумент. Отсюда базовое правило курса: не принимайте дифф, который не готовы объяснить коллеге строка за строкой. Если объяснить не можете — вы ещё не закончили ревью, каким бы зелёным ни был прогон тестов.

Читайте AI-дифф в фиксированном порядке — это быстрее и надёжнее хаотичного скролла. Шаг один: список затронутых файлов. Ещё до чтения строк спросите: ожидал ли я каждый из этих файлов? Файл вне области задачи — первый и самый дешёвый красный флаг. Шаг два: тесты. Изменённые assertions, удалённые кейсы, ослабленные проверки — агент мог «починить» тест подгонкой под неверное поведение. Шаг три: реализация, файл за файлом, hunk за hunk-ом.

Типовые красные флаги, которые надо распознавать на автомате: пустой catch или .catch(() => {}) — проглоченная ошибка; выдуманные API и импорты из несуществующих модулей — компилятор поймает, но в динамических языках дойдёт до рантайма; заглушки вместо реализации — TODO, захардкоженный ответ, mock, оставшийся в проде; новые зависимости в package.json, которых никто не просил; «попутные» рефакторинги — переименования и переформатирования, раздувающие дифф вокруг настоящего изменения; и удаление кода, смысла которого агент не понял, — особенно обработчиков граничных случаев.

Каждый флаг — не приговор, а вопрос: либо к агенту («зачем изменён этот файл?»), либо действие — отклонить конкретный hunk, оставив остальное. Инструменты это позволяют: и Cursor, и VS Code дают принимать дифф пофайлово, а git add -p — выборочно стейджить куски.

Лучший способ упростить ревью — уменьшить то, что надо ревьюить. Размер партии — ваш главный рычаг: задача «добавь фильтр по дате в список заказов» породит обозримый дифф, задача «сделай фильтры, сортировку и пагинацию, заодно почисти стили» — простыню, которую вы физически не сможете честно прочитать. Правило: одна задача агенту — один логический шаг — один коммит после ревью.

Второе условие честного ревью — чистое git-дерево перед запуском агента. Если в рабочем каталоге уже лежат ваши незакоммиченные правки, после прогона агента вы не отличите своё от его. git status до запуска, git diff после — граница авторства всегда видна. Никогда не позволяйте агенту коммитить вперемешку с вашим WIP, и не используйте git add . после агентного прогона — стейджьте файлы поимённо.

Третий слой страховки — контрольные точки инструмента: checkpoints в Cursor с кнопкой Restore, Undo правок в VS Code. Они спасают внутри сессии, но не заменяют git: коммит после каждого принятого шага — это точка, к которой можно вернуться завтра, с другой машины, после краха редактора. Экспериментальные прогоны агента удобно делать в отдельной ветке: не понравился результат — ветка удаляется, история осталась чистой. Дёшево создать, дёшево выбросить — именно так и выглядит безопасная работа с агентом.

Агент — не только автор правок, но и бесплатный собеседник по их поводу. Используйте это. Первый приём — объяснение диффа: «пройди по диффу и обоснуй каждое изменение; отдельно объясни, зачем тронут файл X». Несостыковки в объяснении находят баги быстрее, чем чтение кода в тишине. Второй — самокритика: «найди три слабых места в своём диффе: граничные случаи, гонки, ошибки типов». Модель, переключённая из режима автора в режим критика, регулярно находит собственные огрехи. Третий — вопрос «что может сломаться в проде после этого изменения?» — дешёвый способ получить список рисков для проверки.

Сильнейший из приёмов — тест до фикса. Попросите агента сначала написать тест, воспроизводящий баг, убедитесь, что тест падает, и только потом разрешите чинить. Красный тест, ставший зелёным, — доказательство, что исправлено именно то, что было сломано, а не подогнан симптом.

И финальное правило, которое не обойти никакими приёмами: словам агента о результате не верят. «Готово, все тесты проходят» — это текст, сгенерированный моделью, а не факт. Фактом является вывод команды, запущенной вами: прогон тестов, линтер, открытое приложение. Ревью заканчивается не принятием диффа, а вашей собственной верификацией работающего поведения.