Как проверять код от ИИ: чек-лист до merge

Модель оптимизирует «правдоподобный ответ», а не ваш прод. Она может добавить пакет, которого нет в lockfile, захардкодить токен «для примера», поменять сигнатуру функции, от которой зависят десять файлов, или удалить проверку, которую вы не просили трогать. На практике это не злой умысел - просто контекст обрезан, а задача сформулирована широко.

Я не говорю «не используйте Agent». Я говорю: Agent пишет черновик, вы - редактор с правом veto. Один merge без ревью может стоить больше, чем неделя аккуратных diff. Запрос «проверка кода ии» в поиске обычно означает именно это: как не слепо доверять генерации.

Разделяю два момента: до Apply в сессии Agent и перед merge в git. Оба обязательны, если правки затрагивают больше одного косметического файла.

До Apply в Cursor

1. 01

   Прочитайте список файлов, которые агент собирается менять - не только итоговый diff последнего шага.

2. 02

   Сверьте scope с исходным промптом: если просили «поправить валидацию email», а в списке config и deploy - Stop.

3. 03

   Отклоните правки в .env, ключах, CI-секретах, production-конфигах без явного запроса.

4. 04

   Применяйте по файлам или небольшими группами, не Apply All на 40 файлов с первого раза.

Перед merge (git)

Фрагмент .cursor/rules или project rule, который я добавляю в учебные репозитории:

```markdown

ИИ редко знает ваш полный CI. Она может написать «тесты прошли», не запуская их, или запустить урезанную команду. Единственный источник правды - скрипты из вашего package.json и pipeline.

Типичный минимум для JS/TS-проекта:

npm run lint
npm test -- --runInBand
npm run build

Для Python - ruff check, pytest, для Go - go test ./.... Главное - те же команды, что на CI, а не «что-нибудь зелёное».

Если тестов в проекте нет - честно зафиксируйте это как риск, а не как «раз ИИ сказал OK». На наставничестве первым делом добавляем хотя бы один тест на критический сценарий, иначе каждый Agent-сеанс - лотерея.

Не всё требует одинаковой глубины. Я использую матрицу, чтобы не тратить час на правку комментария и не пропустить опасный refactor.

Красная зона - всё, что трогает аутентификацию, биллинг, персональные данные, деплой на прод. Agent туда не пускаю без Plan, отдельной ветки и второго ревьюера, если работаете в паре.

Rules не заменяют diff, но сужают пространство ошибок. Если в Rules прописаны команды npm run lint, запрет на .env в коммитах и стек (Next 15, не Express), агент реже «улетает в сторону». Подробнее - в Cursor Rules.

Что я держу в Rules для учебных и клиентских репо:

{
  "scripts": {
    "verify": "npm run lint && npm test && npm run build"
  },
  "agent": {
    "never_edit": [".env", ".env.local", "secrets/*"],
    "require_tests_for": ["src/api/*", "src/lib/*"]
  }
}

Это псевдоструктура - в реальном .cursor/rules или AGENTS.md пишите текстом, как принято в вашем репо. Плюс project brief: одна страница «что это за проект, как запустить, где опасные зоны».

Перед сложной задачей в Agent я делаю Ask: «какие файлы затронет изменение X» - без правок. Потом Agent с узким промптом и списком разрешённых путей. Так diff предсказуемее.

Здесь симптом → причина → действие, как в тикетах после Agent.

Слепой Apply All. Самая частая ошибка новичков. Лечится дисциплиной: ветка agent/feature-x, Apply по частям, commit после каждого зелёного npm run verify.

Секрет в коммите. Даже если ключ «тестовый» - удалить из истории (git filter или новый commit + rotate), не пушить «ну потом уберу».

Ложная уверенность агента. Фразы «готово, всё работает» в чате - не артеfact. Артеfact - зелёный CI или ваш ручной прогон.

Проверка кода от ИИ - привычка, не разовая статья.

1. 01

   Закрепите Cursor Agent mode - матрица «что поручать агенту».

2. 02

   Напишите Cursor Rules с командами verify и запретами на секреты.

3. 03

   Один раз пройдите сценарий: ветка → Agent на маленькую задачу → diff → lint → test → merge.

4. 04

   Если ревью процесса нужно под ваш репозиторий - наставничество или Telegram.

На разборе я смотрю не «умеете ли промпт», а есть ли у вас обратимый цикл: git checkpoint до Agent, verify после, понятный rollback. Без этого любой гайд по проверке кода от нейросети останется теорией.

По теме в блоге: связка промпты для Cursor + Rules + этот чек-лист закрывает 80% рисков на маленьких задачах. Для бизнес-автоматизации с webhook и CRM - другой контур, но принцип тот же: diff, секреты, тест на реальных данных.

Проверено 2026-08-21. Источники: cursor.com/docs/agent, cursor.com/docs/agent/security, практика ревью на разборах.