Как ловить ошибки в коде, сгенерированном ИИ, до того как он попадёт в продакшен

ИИ-ассистент может за секунды выдать функцию, которая выглядит рабочей. Сложность теперь не в том, чтобы сгенерировать код, — а в том, чтобы понять, можно ли ему доверять. ИИ-модели уверены в себе, даже когда ошибаются, они выдумывают несуществующие API и с радостью «чинят» падающий тест, удаляя проверку. Если вы выкатываете всё, что вам выдаёт агент, вы на самом деле не разрабатываете софт — вы играете в азартную игру.

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

1. Читайте дифф, а не чат

Самая ценная привычка: смотрите на реальные изменения файлов, а не на резюме ИИ о них. Такие инструменты, как Claude Code, Cursor и Copilot, показывают дифф перед тем, как вы примете изменения. Пробегитесь по нему с тремя вопросами:

• Затронул ли он файлы, которых я не ожидал? Агенты иногда «услужливо» правят конфиг, удаляют тесты или переписывают не относящиеся к делу функции.
• Не выдумал ли он импорт или API? Тревожный сигнал — вызов метода библиотеки, который вы никогда не видели. Убедитесь, что он существует, прежде чем ему доверять.
• Не ослабил ли он что-нибудь? Удалённая обработка ошибок, ослабленный тип, закомментированная проверка или тест, который теперь почти ничего не проверяет.

Этот 30-секундный просмотр отлавливает большинство ситуаций «ИИ сделал какую-то глупость».

2. Пусть машина проверяет машину

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

• Линтер (ESLint, Ruff и т. п.) для стиля и распространённых ошибок.
• Проверка типов (TypeScript, mypy) — чтобы отловить класс багов с выдуманными API и неверной формой данных.
• Запуск тестов для проверки поведения.

Хитрость в том, чтобы сделать всё это необязательным для отключения, встроив в pre-commit-хук, чтобы оно запускалось перед любым коммитом. Вот минимальный пример с Husky в JavaScript-проекте:

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

Теперь, если код ИИ не проходит линтер, ломает типы или валит тест, коммит просто отклоняется. Ошибка агента никогда не попадёт в вашу ветку. (В Python аналог — фреймворк pre-commit, запускающий ruff, mypy и pytest.)

3. Заставьте ИИ писать — и запускать — тесты

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

«Напиши тесты для этой функции, покрывающие пустой ввод, основной сценарий и один граничный случай. Не изменяй саму функцию».

Затем запустите тесты сами или в CI и убедитесь, что они действительно проверяют реальное поведение. Тест вроде expect(result).toBeDefined() — это театр; expect(addTax(100, 0.2)).toBe(120) — настоящая проверка. Прочитайте хотя бы одну проверку, чтобы убедиться, что она второго рода.

4. Добавьте контроль качества в CI

Локальные хуки защищают вашу машину; проверка в CI защищает проект от всех (включая вас-будущего усталым вечером). Добавьте workflow, который заново запускает линтер, типы и тесты на каждом pull request, и настройте ветку так, чтобы слияние блокировалось, пока проверка не пройдёт. Это ровно та идея, которую крупные платформы сейчас продают как продукт — GitHub Code Quality, выходящий в общий доступ в июле 2026 года, добавляет гейты, блокирующие слияние, когда падает поддерживаемость или покрытие, а Cursor переосмыслил свою команду /review как pre-commit-гейт ранее в этом году. 80% пользы можно получить бесплатно обычной задачей в GitHub Actions или GitLab CI.

5. Оставьте человека в контуре для рискованных 5%

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

Простое эмпирическое правило

Чем больше автономии вы даёте ИИ, тем крепче должны быть ваши гейты. Если вы аккуратно принимаете по одному изменению за раз, быстрого прочтения диффа может хватить. Если вы даёте агенту работать десять минут без присмотра, вам нужны линтер, типы и тесты, стоящие между ним и вашей основной веткой. Постройте сетку один раз — и сможете дать ИИ двигаться быстро, не давая ему тихо ломать всё за вашей спиной.