Reviewing Diffs You Did Not Write

Агент генерирует тысячу строк за десять минут; честное построчное ревью этой тысячи занимает часы. Классические индустриальные данные о ревью (исследования SmartBear на кодовой базе Cisco) говорят: эффективность обнаружения дефектов резко падает после 400 строк за сессию и после часа непрерывного чтения. Человек, «читающий» дифф на 2000 строк, на самом деле читает первые 300, а остальное скроллит. Это худший вариант: ревью формально проведено, доверие поставлено, дефекты остались.

Вывод не «читать внимательнее», а перестать читать равномерно. Построчное чтение — стратегия для диффов, написанных человеком, где плотность смысла примерно одинакова. AI-дифф устроен иначе: в нём много механического обвеса (импорты, типы, шаблонные тесты, форматирование) и несколько критических решений, спрятанных в неожиданных местах. Задача ревьюера — за фиксированный бюджет времени найти именно решения, а не проверить каждую строку.

Второе следствие асимметрии: перегенерация дешевле доводки. Если дифф структурно плох — не тот подход, лишняя зависимость, размазанная логика — не нужно вычитывать его до конца и писать двадцать комментариев. Дешевле сформулировать одно структурное возражение и вернуть задачу агенту. Ревьюер человеческого кода бережёт усилия автора; ревьюер AI-кода бережёт только своё внимание — усилия автора бесплатны.

Рабочая стратегия — три прохода с разной целью.

Проход 1 — намерение (5 минут). Не открывая код: описание PR, список затронутых файлов, git diff --stat. Вопросы: решает ли дифф поставленную задачу? Почему затронуты именно эти файлы? Ожидал ли я миграцию/новую зависимость/изменение конфига в этой задаче? Если список файлов не совпадает с ментальной моделью задачи — это первый кандидат на возврат.

Проход 2 — контракты (15–20 минут). Читаются только границы: публичные сигнатуры, схемы БД и миграции, форматы API-ответов, обработка ошибок, новые зависимости, тесты. Это места, где живут тихие изменения контрактов из прошлого урока и где цена ошибки максимальна. Google в eng-practices рекомендует начинать с главного файла изменения — ядра дизайна; для AI-диффов ядро почти всегда граница, а не внутренности функций.

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

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

В отличие от человеческого PR, у AI-диффа автор доступен мгновенно, бесплатно и без обид. Это меняет технику ревью: часть работы можно снять вопросами.

• Начинай с тестов. Тесты — это утверждение о том, что код должен делать. Если по тестам непонятно, что изменилось в поведении, — дифф уже не в порядке, независимо от качества реализации.
• Проси карту диффа. «Перечисли по файлам, что и зачем изменено, отдельно отметь изменения публичных контрактов» — агент строит оглавление, ревьюер проверяет его против реального диффа. Расхождение между картой и диффом — само по себе находка.
• Спрашивай про решения, а не про строки. «Какие альтернативы ты рассматривал? Почему новая зависимость, а не стандартная библиотека? Что сломается у вызывающего кода?» Ответы дешёвы, а враньё в них проверяемо.
• Требуй нарезку. Дифф на 2000 строк — это несколько логических изменений. Попроси переразбить на PR по одному изменению: перегенерация дешёвая, а ревью маленьких диффов кратно эффективнее.

Важное ограничение: объяснения агента — не доказательства. Модель уверенно объясняет и несуществующие решения. Ответы агента сужают зону поиска, но каждое утверждение о контракте или совместимости проверяется по диффу и документации, а не принимается на слово.

Список сигналов, каждый из которых переводит PR из «быстрое ревью» в «глубокое ревью или возврат»:

• Затронуты файлы вне области задачи — агент «попутно улучшил» соседний модуль. Попутные правки — главный источник тихих изменений контрактов.
• Новая зависимость под тривиальную задачу — пакет ради трёх строк кода. Проверка: существует ли пакет, кто автор, когда обновлялся.
• Удалённые или ослабленные тесты — агент «починил» падающий тест, поменяв ожидание под фактическое поведение. Каждое изменение assert требует ответа: почему старое ожидание было неверным?
• Шум форматирования — переформатированные сотни строк, среди которых спрятаны три семантических изменения. Требуй отдельный PR для форматирования.
• Изменения конфига/CI в feature-PR — отключённый линтер, ослабленный tsconfig, закомментированный шаг pipeline. Классический способ агента «добиться зелёного» без починки причины.
• Закомментированный код и мёртвые ветки — след незавершённых итераций агента.
• Подозрительно большой дифф для маленькой задачи — либо задача понята неверно, либо в диффе есть незапрошенная работа.

Красные флаги — не приговор, а маршрутизация внимания. Их проверка занимает минуты на первом проходе и экономит часы на третьем. В капстоуне курса именно эти флаги станут основой протокола triage.