Как проверить код от нейросети: чек-лист перед тем, как принять правку

Нейросеть пишет код быстро и уверенно. Проблема в том, что уверенность не зависит от правильности: код может выглядеть аккуратно, проходить беглый взгляд и при этом ошибаться в мелочи, которая всплывёт через неделю. Об этом пишут и Cursor в руководстве по работе с агентами, и GitHub в документации по ревью ИИ-кода, и Саймон Уиллисон (Simon Willison) в своих разборах работы с языковыми моделями.

Ниже — порядок проверки, который собран из этих источников и пересказан своими словами. Он подходит для кода из Cursor, Claude Code, Copilot и любого другого агента. В конце — промты, которые можно отдать агенту, чтобы он помогал с проверкой.

Главное правило: не принимать то, что не можете объяснить#

Саймон Уиллисон формулирует это так: он не коммитит код, который не смог бы объяснить другому человеку. Если код написала модель, а вы его прочитали, протестировали и понимаете, как он работает, — это обычная разработка, просто с помощником. Если нет — это уже вайбкодинг, и он уместен только там, где ошибка ничего не стоит. Подробнее о том, где проходит эта граница, — в статье вайбкодинг простыми словами.

Второе правило из документации Claude Code: просите доказательства, а не отчёт. Не «тесты проходят», а вывод команды, которая их запустила. Не «страница работает», а скриншот. Проверить доказательство быстрее, чем перезапускать всё самому.

Шаг 1. Запустить и прогнать тесты#

GitHub в своей инструкции ставит это первым пунктом: сначала автоматические проверки, потом всё остальное.

• Код собирается? Сборка, проверка типов, линтер. Новые предупреждения тоже считаются.
• Тесты проходят? Все, а не только те, что агент написал сейчас.
• Агент не трогал тесты? Отдельно посмотрите, не удалил ли он падающий тест, не пометил ли его пропущенным и не ослабил ли проверку. GitHub выделяет это как типичную ошибку ИИ: тест убирают вместо того, чтобы исправить код.

Если тестов нет, попросите агента сначала написать тест, который описывает нужное поведение и падает, и только потом менять код. Этот приём советуют и Cursor, и Anthropic: у агента появляется цель, которую можно проверить, и он может сам повторять попытки, пока тест не пройдёт.

Шаг 2. Прочитать дифф#

Смотрите не на весь файл, а на то, что изменилось. Вопросы к диффу:

• Изменены только те файлы, которые нужны для задачи? Правки «заодно» — повод спросить, зачем.
• Нет ли закомментированного кода, отладочных выводов, временных заглушек?
• Понятны ли названия функций и переменных? Нет ли дублирования того, что в проекте уже есть?
• Не стал ли код сложнее, чем задача? GitHub советует не принимать код, который дольше переделывать, чем написать заново.

В Cursor дифф виден прямо во время работы агента, и его можно остановить, если он свернул не туда. После правки можно запустить отдельное ревью: команда /agent-review или Agent Review во вкладке Source Control, которая сравнивает все локальные изменения с основной веткой. В Claude Code для этого есть команда /code-review (она же /review), а /diff показывает изменения.

Шаг 3. Сверить с задачей#

Код может работать и при этом решать не ту задачу. GitHub предлагает спросить себя: решает ли код нужную проблему и следует ли он соглашениям проекта.

• Выполнены все пункты задачи? Агенты нередко делают основную часть и тихо пропускают ограничение вроде «без новых зависимостей» или «не меняй API».
• Учтены краевые случаи: пустой ввод, ноль, очень длинная строка, повторное нажатие, нет сети?
• Какие допущения сделала модель? Их можно прямо спросить: «какие предположения о бизнес-логике ты сделал?». Пример такого вопроса есть в документации GitHub.

Чем подробнее была задача, тем проще эта проверка. Если сверять не с чем, начните с ТЗ: шаблон — на странице ТЗ для нейросети, а режим «сначала план» помогает договориться о критериях готовности до кода — см. промт «сначала план».

Шаг 4. Проверить зависимости#

Отдельная беда ИИ-кода — пакеты, которых не существует. Модель уверенно пишет import библиотеки с правдоподобным названием, а такой библиотеки нет. Исследователи изучали это явление на большом наборе моделей и назвали его галлюцинацией пакетов (статья на arXiv). Опасность в том, что злоумышленник может зарегистрировать пакет с таким названием, и тогда вместо ошибки установки вы получите чужой код. GitHub называет эту угрозу slopsquatting.

Что делать с каждой новой зависимостью:

• убедиться, что пакет существует в реестре (npm, PyPI) и это именно тот пакет, а не похожий по названию;
• посмотреть, поддерживается ли он: свежие релизы, активность в репозитории;
• проверить лицензию, совместима ли она с вашим проектом;
• прогнать аудит уязвимостей, например npm audit для Node.js или pip-audit для Python.

И главный вопрос: нужна ли зависимость вообще? Часто агент тянет библиотеку ради одной функции, которую можно написать в пару строк или которая уже есть в проекте.

Шаг 5. Секреты и безопасность#

Здесь ошибка стоит дороже всего, поэтому этот шаг нельзя пропускать даже в маленьком проекте.

Секреты. Ключи API, токены, пароли не должны лежать в коде. Агент вполне может вписать ключ прямо в файл, «чтобы заработало». Проверьте дифф глазами и поставьте сканер секретов, например gitleaks. У GitHub есть встроенный secret scanning. Ключи храните в переменных окружения, а файл .env добавьте в .gitignore.

Типовые уязвимости. Проверьте всё, что принимает данные от пользователя: формы, параметры URL, загрузку файлов. Классика — SQL-инъекции, отсутствие проверки прав, данные без экранирования. Список самых частых проблем веб-приложений ведёт OWASP (OWASP Top 10). Статический анализ вроде Semgrep или CodeQL ловит часть таких ошибок автоматически.

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

В Claude Code есть команда /security-review: она смотрит изменения в текущей ветке и ищет инъекции, проблемы авторизации и утечки данных. Это полезный второй взгляд, но не замена проверкам выше.

Деньги. Уиллисон отдельно предупреждает: будьте осторожны с кодом, который обращается к платным API без лимита расходов. Ошибка в цикле может стоить реальных денег. Ставьте лимиты в кабинете сервиса до того, как запускаете такой код.

Шаг 6. Второе мнение#

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

• откройте новый чат без истории разработки и попросите найти проблемы в диффе;
• используйте встроенное ревью инструмента (Agent Review в Cursor, /code-review в Claude Code, ревью Copilot в пул-реквестах);
• для важного кода — живой человек. Уиллисон советует новичкам показывать опытному разработчику всё, чем будут пользоваться другие люди.

Промты для проверки кода#

Эти промты можно отдать агенту после правки. Они не заменяют тесты, но помогают быстро найти слабые места.

Ревью диффа в новом чате:

Посмотри изменения: @Commit (Diff of Working State).
Задача была: [вставь задачу].
Найди: что не соответствует задаче, пропущенные краевые случаи,
ошибки в логике, лишние изменения. Ничего не правь, только список
с путями файлов и строками. Если всё в порядке — так и скажи.

Проверка допущений:

Какие предположения о бизнес-логике, данных и поведении пользователя
ты сделал в этой правке? Какие из них я должен подтвердить?

Проверка зависимостей:

Перечисли все зависимости, которые ты добавил или изменил.
Для каждой: зачем нужна, можно ли обойтись без неё,
точное название пакета в реестре.

Тесты вместо удаления:

Почему ты удалил (или пропустил) тест [название]? Предложи,
как исправить код, чтобы тест прошёл, не меняя сам тест.

Если агент зациклился на одном неудачном исправлении, нужен другой подход: собрать контекст, назвать гипотезы, уметь откатить. Для этого есть отдельный промт для исправления ошибки.

Как сделать, чтобы проверять приходилось меньше#

Проверка проще, если её заложить в работу заранее:

• Пишите задачу с критериями готовности. Как это делать в Cursor — в статье как писать промты для Cursor.
• Вынесите правила в файл. Команды тестов и сборки, запреты («не добавляй зависимости без согласования», «не трогай тесты») один раз записываются в AGENTS.md, правила Cursor (папка .cursor/rules) или CLAUDE.md для Claude Code, и агент видит их в каждой задаче.
• Маленькие шаги. Одна задача — один дифф, который можно прочитать за несколько минут. Огромную правку не проверит никто, ни вы, ни второй агент.
• Коммит после каждого удачного шага. Тогда откат — одна команда, а не археология.

Если вы ещё выбираете инструмент и хотите начать без оплаты, загляните в подборку бесплатные нейросети для программирования.

Источники: GitHub Docs — Review AI-generated code; Cursor — Best practices for coding with agents; Cursor — Agent Review; Claude Code — Best practices; Claude Code — команды; Simon Willison — Here's how I use LLMs to help me write code; Simon Willison — Not all AI-assisted programming is vibe coding; We Have a Package for You! (arXiv).