ИИ-агент может выдать аккуратный diff, который выглядит убедительно, но ломает соседний сценарий. Свежие исследования по PatchFusion и репозиторной навигации дают хороший повод собрать практический чек-лист для ревью таких патчей.
Главная ошибка при работе с coding agent - принять первый зелёный diff как готовое исправление. В реальном проекте патч должен пройти те же вопросы, что и код от человека: какую проблему он решает, какие предположения делает, какие тесты это доказывают и что может сломаться рядом.
Работа PatchFusion, опубликованная на arXiv 2 июля 2026 года, формулирует проблему жёстко: pass@k в бенчмарках не равен применимому patch@1 в разработке. В пуле кандидатов может быть правильное исправление, но разработчику всё равно нужно выбрать один финальный патч. Авторы предлагают детерминированно смотреть на повторяющиеся edit atoms, а не полагаться только на ранжирование целых diff или LLM-судью.
Первый проход: смысл, а не стиль
Начните с короткой формулировки бага. Если агент не может объяснить причинно-следственную цепочку «симптом - причина - изменение», патч рано принимать. Сравните diff с ошибкой: изменён ли код, который реально участвует в stack trace или failing test? Нет ли правки, которая просто маскирует исключение?
- Попросите агента назвать минимальный сценарий, который ломался до изменения.
- Проверьте, появился ли тест именно на этот сценарий, а не на общий happy path.
- Посмотрите, не расширяет ли патч публичный контракт без миграции callers.
- Откройте соседние ветки условий: ИИ часто чинит один case и забывает симметричный.
Сравните несколько кандидатов
Если агент сгенерировал два-три варианта, не выбирайте самый короткий автоматически. PatchFusion показывает, что повторяющиеся атомарные правки между кандидатами могут быть полезным сигналом. В ручном ревью это значит: выпишите общие изменения, отдельно отметьте спорные куски и спросите, какие из них подтверждены тестами.
Хороший признак - несколько кандидатов независимо меняют одну и ту же проверку или одну и ту же нормализацию входных данных. Плохой признак - каждый вариант чинит проблему разным обходным путём: один глушит ошибку, другой меняет таймаут, третий удаляет проверку. Такой набор говорит, что агент ещё не локализовал причину.
Тесты: узкие, затем регрессионные
Запускайте сначала самый узкий тест, который доказывает исправление. Потом - тестовый набор вокруг изменённого модуля. Полный suite нужен перед merge, но он не заменяет локальное доказательство. Если проект большой, сохраните команды тестов в комментарии к ревью: следующий человек должен понимать, что именно было проверено.
Для UI и интеграций добавьте ручную проверку состояния: скриншот, fixture, пример payload или короткий лог. В исследованиях ContextSniper и DUALVIEW повторяется одна мысль: агентам нужна структурная и фактическая опора. Ревьюеру тоже.
Когда патч лучше отклонить
Отклоняйте diff, если он удаляет проверку без объяснения, меняет публичное поведение без теста, добавляет широкую обработку исключений или трогает несвязанные файлы «заодно». Ещё один тревожный знак - патч проходит тесты только потому, что тест стал слабее. Такой код потом тяжело отлавливать.