ИИ-ревью своего кода — 5 промптов которые ловят баги
Парадокс: ИИ написал тебе код за 5 минут. Ты его не читал, просто принял. И ровно поэтому надо попросить ИИ сделать ревью. Свежий запуск Claude (без контекста того как код писался) ловит баги которые в первом проходе пропустил. Один правильный промпт перед merge экономит часы отладки в проде. Разбираем 5 промптов под разные типы проверок.
Промпт 1 — общее ревью «прочитай как старший разраб»
Самый универсальный. «Прочитай этот код как старший разработчик с 10-летним опытом. Что бы ты сказал автору? Перечисли проблемы по приоритету: blocker (нельзя мерджить) → major (надо поправить) → minor (если будет время) → nit (стилевое). Для каждой — что и где исправить.» Этот промпт даёт сбалансированный обзор: серьёзное и косметика чётко разделены. Используй на любом готовом куске кода перед PR.
Промпт 2 — безопасность
«Проверь этот код по чек-листу OWASP Top 10. Конкретно: SQL-инъекции, XSS, injection через шаблоны, утечка секретов, неавторизованный доступ к данным, race conditions, обход валидации, открытые редиректы. Для каждой найденной проблемы — конкретный сценарий атаки и как поправить.» Это критично для любого кода который трогает БД, юзеров, пейлоад из внешнего источника, или авторизацию. Один проход безопасности перед прод-релизом — обязательно.
Промпт 3 — edge cases
«Найди edge cases которые сломают этот код. Подумай о: пустых массивах/объектах, null/undefined, нулевых и отрицательных числах, очень больших значениях, конкурентных вызовах, прерванных промисах, медленной сети, юзере с правами админа, юзере без прав, несуществующих ID. Для каждого случая — что произойдёт и как защититься.» Этот промпт ловит 80% багов которые случаются «у одного пользователя из 1000».
Промпт 4 — производительность
«Найди потенциальные проблемы производительности. Конкретно: N+1 запросы к БД, тяжёлые операции в цикле, утечки памяти (event listeners, таймеры), unnecessary re-renders в React, отсутствие кеширования, синхронные блокирующие вызовы. Для каждой — как воспроизводится при росте нагрузки и как пофиксить.» Релевантно для любого кода обслуживающего больше 100 пользователей.
Промпт 5 — читаемость и поддержка
«Прочитай этот код как разработчик который видит проект впервые. Что непонятно? Где имена переменных вводят в заблуждение? Какие комментарии нужны (а каких НЕ нужно — где код самодостаточный)? Где слишком сложная логика которую стоит разбить? Будет ли понятно через 6 месяцев?» Это ревью на «long term maintainability». Часто здесь Claude находит места где имя data или result стоит заменить на конкретное, или где функция выросла до 80 строк и должна быть разбита.
# Шаблон 1 — общее ревью ``` Прочитай этот код как senior разработчик. Перечисли проблемы по приоритету: 🔴 BLOCKER — нельзя мерджить 🟡 MAJOR — надо поправить до релиза 🟢 MINOR — желательно когда будет время ⚪ NIT — стиль/имена/мелочи Для каждой проблемы: - Где (файл:строка) - Что не так - Как исправить (с примером кода) Код: ```ts // сюда вставляешь свой код ``` ``` # Шаблон 2 — безопасность (для кода с БД/auth/API) ``` Проверь этот код по OWASP Top 10. Конкретно: - SQL injection - XSS / HTML injection - Утечки секретов - Неавторизованный доступ к чужим данным (IDOR) - Race conditions - Обход валидации на клиенте - Открытые редиректы Для каждой найденной проблемы: - Конкретный сценарий атаки (запрос/действие) - Какие данные утекают или ломаются - Как пофиксить (с примером кода) Код: ```ts // код ``` ``` # Шаблон 3 — edge cases (для логики) ``` Найди edge cases которые могут сломать этот код. Проверь: - Пустой массив / пустой объект / пустая строка - null / undefined / NaN - Отрицательные числа, ноль, очень большие числа - Конкурентные вызовы (одновременные запросы) - Прерванный fetch / network timeout - Юзер БЕЗ прав, юзер с правами админа - Несуществующий ID в запросе Для каждого случая — что произойдёт и как защититься. Код: ```ts // код ``` ```
Шаблон полного ревью — копируй и подставляй свой код