Как проверять код после Cursor, Claude Code и Codex

Кодовый агент сокращает время от задачи до diff, но не переносит ответственность за релиз. Опасность AI-кода не в особой «машинной» ошибке: он допускает обычные баги быстро, сразу в нескольких файлах и с убедительными объяснениями. Поэтому проверка должна начинаться не с другого чат-бота, а с границ изменения и воспроизводимых сигналов.

Сначала объясните себе, зачем изменён каждый файл

Попросите агента дать краткое резюме, но сверяйте его с реальным diff. Удалите случайные форматирования, обновления lockfile без причины, debug-код и изменения соседних модулей, которые не нужны задаче. Большой diff стоит разбить: схема данных, сервер, интерфейс и тесты легче проверяются отдельными логическими частями.

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

Компилятор и тесты должны высказаться раньше AI-ревьюера

Запустите форматирование, линтер, typecheck, unit и integration tests теми же командами, что в CI. Если проект не имеет таких проверок, это отдельный риск, а не повод заменить их моделью. Детерминированный инструмент точно повторяет правило; AI-рецензент оценивает вероятные проблемы и может пропустить очевидное.

Новый тест должен падать на старом коде и проходить после исправления. Тест, который сразу зелёный в обеих версиях, может не доказывать ничего. Для bugfix воспроизведите исходную ошибку; для функции проверьте основной путь, границы и отказ зависимости.

Playwright проверяет путь пользователя, а не красоту реализации

Для критичного web-сценария добавьте или обновите браузерный тест. Playwright projects позволяют прогонять разные браузеры и окружения, а trace viewer сохраняет шаги, DOM, сеть и скриншоты для диагностики CI-падения. Codegen полезен как черновик, но локаторы и ожидания нужно привести к устойчивым пользовательским признакам.

Не покрывайте E2E каждый setter. Зафиксируйте путь, потеря которого стоит дорого: вход, оплата, создание сущности, публикация, права роли. API и unit tests дешевле проверят остальные ветки.

Миграции и фоновые задачи требуют репетиции отката

Если diff меняет схему, проверьте существующие строки, null, индексы, блокировки и время выполнения. Прогоните migration на копии реалистичного объёма. Решите, совместим ли новый код со старой схемой во время rolling deploy и можно ли откатить приложение после применения миграции.

Для очередей и webhook проверьте повтор, порядок, таймаут и частично выполненную операцию. Агент легко пишет счастливый путь, в котором событие приходит один раз. Production почти всегда проверяет обратное.

Права и данные важнее подозрительной строки кода

Проследите путь недоверенного ввода до базы, файлов, shell, HTML и внешнего запроса. Проверьте авторизацию на сервере, а не только скрытую кнопку. Секреты не должны оказаться в клиентском bundle, логах, сообщении об ошибке или prompt-контексте.

Посмотрите на зависимости и generated code. Новая библиотека увеличивает supply-chain поверхность и размер сборки; похожий пакет может быть опечаткой. Для работы с персональными данными проверьте минимизацию, retention и то, не отправляются ли записи модели без разрешения.

Второй AI полезен как оппонент с узкой ролью

После обычных проверок можно дать diff отдельному reviewer-агенту. Сформулируйте задачу конкретно: найти нарушение инвариантов, недостающие тесты, несовместимость API, риск гонки или обход авторизации. Попросите указывать файл, строку и сценарий отказа. Общий запрос «проверь код» производит много стилистического шума.

Не принимайте замечание без воспроизведения. Модель может придумать несуществующий контракт или не заметить проектное правило. Полезные сервисы собраны в подборке AI-инструментов для проверки кода, а инструменты для выполнения тестов — в подборке AI для тестирования.

Release review заканчивается наблюдением после деплоя

До merge проверьте описание PR, связанные issue, документацию, флаги, метрики и план отката. После выпуска смотрите не только на 500-ошибки: конверсию шага, задержку, очередь, число отказов и бизнес-инварианты. Быстрый rollback полезнее длинной дискуссии с агентом в момент инцидента.

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