Код от модели проверяется не «внимательнее», а по-другому. Он редко бывает случайно неряшливым: имена аккуратные, комментарии на месте, обработка ошибок есть — и посередине неверное условие. Такой код проходит беглый просмотр лучше человеческого черновика, поэтому нужен порядок действий, а не усилие воли.

Порядок, а не внимательность

Четыре шага, каждый из которых ловит свой класс проблем:

  1. Дифф — что вообще изменилось, не изменилось ли лишнее.
  2. Запуск — делает ли оно то, что заявлено.
  3. Типовые ошибки — то, что запуск не показывает.
  4. Второй агент — свежий взгляд без наследования чужих рассуждений.

Порядок не случайный: каждый следующий шаг дороже предыдущего. Нет смысла звать второго агента на дифф, в котором изменены файлы, которых задача не касалась.

Шаг 1. Читать дифф, а не файлы

Единица проверки — изменение, а не итоговый файл. Открытый файл целиком выглядит связным, и глаз проскальзывает мимо новой строки; дифф показывает ровно то, что появилось.

git status
git diff

На что смотреть в первую очередь:

  • Изменённые файлы, которых задача не касалась. Самый ценный сигнал. Агент правит соседнее «заодно» и не всегда об этом сообщает.
  • Удалённые строки. Добавления читают все, удаления — нет, а именно там пропадают проверки и обработка ошибок.
  • Новые файлы. Особенно конфиги, скрипты и всё, что попадает в сборку.
  • Изменения в зависимостях. Новая строка в манифесте пакетов — это отдельное решение, а не деталь реализации.
  • Всё, что похоже на секрет. Длинные строки из букв и цифр, key, token, secret, password в значении, а не в имени поля.

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

Шаг 2. Запустить и проверить поведение

Запуск проверяет ровно одно: делает ли код то, что заявлено, в тех случаях, которые вы проверили. Это много, но это не всё.

Минимум, который стоит прогонять всегда:

  • сценарий из задачи — целиком, от начала до конца;
  • пустой ввод и отсутствующие данные;
  • повторное выполнение того же действия (двойная отправка формы, повторный запрос);
  • случай «пользователь не тот» — чужой идентификатор, чужой объект;
  • то, что работало до изменения и не должно было сломаться.

Последний пункт пропускают чаще всего, а ломается он регулярно.

Требуйте доказательств, а не отчёта. «Готово, всё работает» — не результат. Результат — вывод команды, текст падения теста и то, что стало после исправления. Прочитать доказательство быстрее, чем перепроверять всё заново, и это единственный способ доверять сессии, за которой вы не следили.

Шаг 3. Пройтись по типовым ошибкам моделей

Эти классы ошибок запуск не показывает, поэтому их проверяют отдельно и по списку.

КлассКак выглядитЧем ловить
Права и владелец эндпоинт отдаёт объект по идентификатору, не проверяя, чей он вручную запросить чужой идентификатор из другого аккаунта
Повторяемость повторный запрос списывает деньги или создаёт дубль выполнить операцию дважды подряд
Запросы к базе запрос в цикле: корректно, но пять обращений вместо одного посмотреть на цикл; спросить у агента, сколько запросов выполняется
Проглоченные ошибки try с пустым обработчиком — сбой становится невидимым поиск по диффу пустых блоков перехвата
Экранирование пользовательский текст попадает в разметку или в запрос как есть ввести в поле кавычку и угловые скобки
Размножение логики новая функция вместо использования существующей поиск по проекту похожего имени перед приёмкой
Устаревшие факты вызов метода, которого в текущей версии библиотеки нет сверка с документацией поставщика, а не с ответом модели

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

Шаг 4. Второй агент на ревью

Проверяющий должен быть другим — не той же сессией, которая писала код. Агент, видевший ход собственных рассуждений, наследует и собственную ошибку: он уже «объяснил себе», почему это правильно.

Ревьюеру нужно давать не «посмотри, всё ли хорошо», а конкретику: что проверять, против чего сверять, что считать находкой.

проверь дифф против PLAN.md: реализовано ли каждое требование,
есть ли тесты на перечисленные крайние случаи, не изменилось ли
что-то за рамками задачи. пиши только пробелы, влияющие на
корректность или на заявленные требования. стилистику не трогай.

В инструментах для этого есть готовые механизмы: у Claude Code — навык /code-review для проверки текущего диффа в отдельном контексте и /security-review для прохода по безопасности, у Codex CLI — подкоманда codex review. Схема с изолированным контекстом лучше ручного копирования замечаний между окнами: проверяющий возвращает находки прямо в рабочую сессию.

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

Что автоматизируется

Ручная проверка не масштабируется, поэтому всё повторяющееся стоит перевести в автоматику:

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

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

Если вы код вообще не читали

Ситуация обычная и не постыдная: вы не разработчик, код писала модель, читать его вам нечем. Тогда работает урезанный, но честный набор:

  1. Проверять поведение, а не текст. Ваша сила — знание того, как должно работать.
  2. Спрашивать агента, что он изменил и почему — и требовать список файлов. Несовпадение списка с диффом видно даже без чтения кода.
  3. Просить второго агента объяснить дифф простыми словами и отдельно спросить «что здесь может пойти не так».
  4. Не выкладывать наружу то, что нельзя проверить. Платежи, персональные данные, доступы — это граница, за которой нужен человек.
  5. Держать git и бэкап. Возможность вернуться отменяет большую часть последствий.

Границы применимости подхода в целом разобраны в статье про ИИ для программирования, а вопросы доступа и секретов — в безопасности вайбкодинга.

Чек-лист

  1. git status и git diff — нет ли изменённых файлов вне задачи.
  2. Удалённые строки прочитаны отдельно от добавленных.
  3. Новые зависимости — осознанное решение, а не деталь.
  4. В диффе нет ничего похожего на ключ или пароль.
  5. Сценарий задачи проверен целиком, включая повтор и пустой ввод.
  6. Проверено то, что работало раньше.
  7. Пройден список типовых ошибок: права, повторяемость, запросы, проглоченные ошибки, экранирование.
  8. Ревью сделано в отдельном контексте, а не той же сессией.
  9. Линтер, типы и тесты прогнаны автоматикой, а не глазами.

Когда проверка отстаёт от скорости генерации, параллельная работа нескольких агентов начинает работать против вас — про это отдельно в статье несколько ИИ-агентов одновременно.