Генерация кода стала дешёвой, чтение — нет. Пул-реквест на восемьсот строк создаётся за десять минут, а вычитывается час, и именно здесь у большинства команд теперь копится очередь.

Хуже того, привычные приёмы ревью работают слабее. Человеческий код подсказывает, где смотреть: сбитый стиль, странное имя, комментарий «временно, потом поправлю». Сгенерированный ровный от начала до конца, и глаз не цепляется ни за что. Ниже — что проверять по списку и какие рубежи должны ловить типовые дефекты без участия человека.

Что показывают данные

Три независимых среза 2025–2026 годов складываются в одну картину.

Безопасность не улучшается. Veracode в мартовском обновлении 2026 года прогнала более 150 моделей по 80 задачам на Java, JavaScript, C# и Python: проверку на безопасность проходит 55% сгенерированного кода, то есть в 45% случаев остаётся известная уязвимость. По языкам разброс огромный: Python — 62%, Java — 29%. По классам дыр всё ещё резче: инъекция в SQL отрабатывается прилично (82%), а межсайтовый скриптинг проходит проверку в 15% случаев, логирование без экранирования — в 13%. За два года цифра не сдвинулась.

Код дублируется вместо переиспользования. GitClear в исследовании 2026 года отмечает рост дублирующихся блоков с 40,3 на миллион изменённых строк в 2023 году до 73,0 — рекорд за всё время наблюдений. Параллельно рефакторинг-перемещения упали на 70%, а межфайловые вызовы, признак повторного использования, — на 35%. Агент охотнее скопирует блок, чем вынесет его в общее место: у него нет боли от будущей поддержки.

Инструмент усиливает то, что уже есть. Отчёт DORA 2025 года (около 5000 респондентов) фиксирует 90% использования ИИ в разработке при расколотом доверии: 24% доверяют сильно или очень сильно, 30% — слабо или совсем нет. Главный вывод отчёта — ИИ работает как усилитель: команда с крепкими процессами ускоряется, команда со слабыми быстрее производит проблемы.

Ощущения врут. В контролируемом эксперименте METR 2025 года опытные разработчики на своих же репозиториях выполняли задачи с ИИ на 19% дольше, а по опросу после эксперимента считали, что стали быстрее на 20%. Сама METR помечает этот результат как исторический: он снят на инструментах первой половины 2025 года и сегодняшние агенты работают иначе. Ценность тут не в конкретной цифре, а в разрыве между ощущением скорости и фактом — именно он усыпляет внимание на ревью.

Чек-лист ревью

Порядок не случайный: сверху то, что чаще всего ломается и дороже всего чинится потом.

1. Границы задачи

Первым делом сверьте дифф с задачей. Типовое поведение агента — сделать чуть больше: заодно причесать соседний модуль, добавить «полезный» флаг, поменять сигнатуру функции, которая мешала. В человеческом ревью это редкость, здесь — норма.

Вопросы: всё ли в диффе относится к задаче; не появились ли новые публичные интерфейсы; не изменилось ли поведение по умолчанию там, где его никто не просил менять.

2. Дубли и переиспользование

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

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

3. Краевые случаи и ошибки

Проверяйте пустой ввод, ноль, отрицательное число, дубликат, отмену, таймаут, потерю сети. Отдельно — как обрабатываются ошибки: проглоченное исключение с пустым except или catch, ошибка, превращённая в логирование и продолжение работы, ответ «успех» при неуспешной операции.

Здесь же — идемпотентность. Если операция может выполниться дважды (ретрай, повторный вебхук, двойной клик), спросите, что произойдёт.

4. Безопасность

С учётом цифр Veracode это не паранойя, а арифметика. Минимальный набор:

  • вывод в HTML и шаблоны — экранируется ли пользовательский ввод;
  • запись в лог — не утекают ли туда токены, персональные данные и не подставляется ли ввод без очистки;
  • запросы к базе — параметризованы или собраны конкатенацией;
  • права и проверка доступа — не полагается ли новый обработчик на то, что «сюда всё равно не попадут»;
  • секреты — не оказался ли ключ в коде, тесте или примере конфигурации.

Отдельная новая проблема — выдуманные зависимости. Модель может предложить пакет, которого не существует, а под такое имя злоумышленники заранее публикуют свой. Любую незнакомую зависимость в диффе проверяйте вручную: существует ли, кто автор, когда обновлялась.

5. Данные и миграции

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

6. Тесты

Проверяйте не наличие тестов, а их способность падать. Сломайте реализацию и прогоните: если зелено, тест бесполезен. Типичные симптомы — мок ровно на том месте, где живёт логика, проверка «функция была вызвана» вместо проверки результата, тест, повторяющий реализацию строчка в строчку.

7. Производительность и запросы

Запрос в цикле, выборка всей таблицы с фильтрацией на стороне приложения, отсутствие индекса под новый фильтр, ненужная сериализация в горячем пути. Модель оптимизирует читаемость, а не план запроса.

8. Зависимости

Каждая новая строка в манифесте — вопрос: она правда нужна или это способ не писать двадцать строк самому. Плюс лицензия и живость проекта.

Как встроить это в процесс

Читать глазами всё перечисленное на каждом пул-реквесте невозможно. Большая часть списка должна отрабатываться автоматикой, а человеку остаётся то, что автоматика не понимает: смысл задачи и инварианты системы.

Автоматические рубежи:

  • линтер и форматтер в pre-commit, типы в строгом режиме;
  • тесты и покрытие критичных путей в CI;
  • статический анализ безопасности (SAST) на каждый пул-реквест;
  • детектор дублей — jscpd, SonarQube или встроенный в вашу платформу;
  • проверка зависимостей: аудит уязвимостей и алерт на новые пакеты;
  • сканер секретов в диффе.

Организационные рубежи:

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

Значительная часть правок снимается ещё раньше — договорённостями проекта, записанными в файл правил для агента: какие библиотеки под запретом, где лежит общий код, что нельзя трогать. Как это устроено в Claude Code, Cursor и Copilot, разбираем в статье про правила для AI-агента.

Чего делать не стоит

  • Ревьюить тысячу строк за раз. Внимание падает после нескольких сотен, дальше ревью превращается в проставление галочки.
  • Верить опрятности. Ровный стиль и подробные комментарии не связаны с корректностью, а работают как маскировка.
  • Пропускать по зелёному CI. Тесты, сгенерированные вместе с кодом, проверяют ровно то, что этот код делает, включая его ошибки.
  • Ставить AI-ревьюера последним рубежом. Две модели подряд склонны соглашаться друг с другом, и человек в этой цепочке нужен именно потому, что он не соглашается.
  • Считать скорость по объёму диффа. Строки перестали быть мерой работы раньше, чем появились агенты, а с ними это стало совсем очевидно.

С чего начать на этой неделе

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

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

В IT-ХОЗЯЕВА мы разбираем такие процессы на еженедельном воркшопе по vibe coding: участники приносят свои пул-реквесты и настройки, разбираем, что поймала автоматика и что пропустила. Практический контекст — в разборе вайбкодинга на практике, а выбор самого инструмента — в сравнении Cursor, Claude Code и Windsurf. Если хочется разобрать процесс на своём проекте предметно, это можно сделать с ментором из тарифа ХОЗЯИН за 2000 ₽/мес.