ИИ-ревью кода — это автоматическая проверка изменений моделью до того, как их посмотрит человек. Оно работает, только если замечаний мало и почти все они по делу. В октябре 2026 года это показали два случая: команда Claude Code в Anthropic сократила число раундов ревью, отсеивая сомнительные замечания и ограничивая повторные проходы, а выпуск PostgreSQL 19 сдвинули на ноябрь, потому что ИИ-рецензенты нашли больше дефектов, чем разработчики успевали разобрать. Настраивать нужно не «ум» модели, а порог, раунды, уровни риска и метрики.
Материал подготовлен AIrassvet 17 октября 2026 года по инженерному блогу Anthropic от 15 октября 2026 года о том, как команда Claude Code проверяет код, и по материалу The Register от 16 октября 2026 года о задержке PostgreSQL 19. Он адресован техническим директорам, руководителям разработки и тимлидам, которые подключают ИИ к проверке pull request. Мы не тестировали описанные инструменты и не измеряли их точность: порядок внедрения и шаблоны ниже — методика редакции. AIrassvet не аффилирован с Anthropic и проектом PostgreSQL; раздел в конце статьи описывает услуги издателя.
Содержание
- Кратко
- Почему об ИИ-ревью заговорили в октябре 2026 года
- Как устроено ревью в команде Claude Code
- Шум: почему лишние замечания опаснее пропущенных
- Бесконечные раунды и как их остановить
- Урок PostgreSQL 19: у людей ограниченная пропускная способность
- Где решение остаётся за человеком
- Как внедрить ИИ-ревью кода: 8 шагов
- Шаблон файла правил для рецензента
- Какие метрики считать
- Частые ошибки
- Частые вопросы
- Первоисточники и метод проверки
Кратко
- Узкое место — внимание людей, а не модель. Цель команды Claude Code — чтобы большинство изменений проходило максимум с одним человеком в контуре без роста откатов и инцидентов.
- Замечание публикуется, только если его подтвердили. Несколько агентов ищут ошибки, отдельная группа голосует за каждую находку, чисто стилистические замечания отбрасываются.
- Раунды нужно ограничивать. После мер по сходимости доля внутренних pull request, прошедших ревью с первого раунда, выросла с 65% до 78%, а среднее число проходов снизилось с 2,08 до 1,32.
- Порог зависит от этапа. У PostgreSQL 19 ИИ-ревью нашло длинный хвост мелких дефектов в уже написанных функциях; разобрать их до выпуска не успели, и 8–10 крупных функций перенесли в следующую версию.
- Человек решает, а не перечитывает. Люди оставляют за собой вопрос «нужно ли это делать», рискованный код, архитектуру, чтение доказательств и ответственность за результат.
Почему об ИИ-ревью заговорили в октябре 2026 года
Автоматическое ревью кода — проверка изменения моделью, которая читает дифф в контексте всего репозитория и оставляет замечания до человека или вместо части ручной проверки. Такие проверки существовали и раньше, но в 2026 году объём кода, который пишут агенты, сделал ручное построчное ревью плохо масштабируемым.
По данным Anthropic, в её монорепозитории число изменений в день выросло примерно с 2 500 в мае до более чем 30 000 в сентябре 2026 года. Сама команда Claude Code пишет, что около 90% кода продукта пишет Claude. С июня по сентябрь число слитых pull request в репозиторий Claude Code выросло более чем вдвое, а доля откатов снизилась более чем на 40% — это данные компании о собственном процессе, а не независимый замер.
Через день The Register сообщил обратную сторону: выпуск PostgreSQL 19, который планировали на конец сентября или начало октября, ожидается около 19 ноября, а 8–10 значимых функций откатили до следующей версии. Один из ведущих коммитеров проекта Петер Айзентраут частично связал это с ревью кода с помощью языковых моделей.
Вместе эти истории дают практичный вывод: ИИ-ревью — не кнопка «включить», а процесс с настройками, у которого есть пропускная способность.
Как устроено ревью в команде Claude Code
Anthropic описывает не одну проверку, а слои. Каждый ловит часть проблем, а всё, что прошло, должны быстро обнаружить и откатить.
| Слой | Что происходит | Кто решает |
|---|---|---|
| До pull request | Агент запускает тесты, сборку и линтер; второй агент проверяет дифф в свежем контексте | Автоматика |
| Обязательный CI | Линтер, типы, тесты на всех платформах, сборка; красный статус блокирует слияние | Автоматика |
| ИИ-ревью | Агенты параллельно ищут ошибки, проверяющие голосуют, находки сортируются по важности | Автоматика |
| Ревью безопасности | Отдельный проход; открытая находка блокирует слияние | Автоматика |
| Одобрение по риску | Классификатор определяет уровень риска: ноль, один или два человека | Человек по уровню риска |
| Очередь слияния и флаги | Проверки повторяются на актуальной ветке, функции выходят за флагом и сначала внутри компании | Автоматика |
| Быстрый откат | Дежурный и автор следят за выпуском, флаг выключают без деплоя | Человек |
Источник: блог Anthropic от 15.10.2026, раздел о жизненном цикле изменения.
Три правила из этой схемы стоит перенять почти любой команде:
- Каждое замечание требует ответа. Автор либо исправляет, либо закрывает обсуждение с причиной. Так закрываются и ложные срабатывания.
- Уровень риска определяет изменение, а не автор. Исправление документации и правка автообновления проходят разные маршруты; пути вроде CI и платёжной логики всегда требуют человека.
- Одобрение агента не заменяет одобрение человека. Автоматика может пропустить изменение низкого риска, но не может занять место обязательного человеческого ревьюера. Одобрение относится к конкретному коммиту: после нового пуша его нужно дать заново.
По данным Anthropic, после запуска исследовательской версии ИИ-ревью доля внутренних pull request с содержательными замечаниями выросла с 16% до 54%. Большие изменения длиннее 1 000 строк чаще всего получают находки, а маленькие — чаще возвращаются без замечаний.
Шум: почему лишние замечания опаснее пропущенных
Шум ИИ-ревью — доля замечаний, которые не приводят к исправлению: ложные срабатывания, мелочи и придирки к стилю. Поймать больше ошибок легко, если не бояться отмечать много не-ошибок. Поэтому команда Claude Code специально проверяет обратную сторону.
Как Anthropic измеряет шум:
- По реакции людей. Каждое замечание относят к одной из групп: исправили, сочли ошибочным, поведение было намеренным, решили, что неважно.
- На заведомо чистых изменениях. Рецензента запускают на pull request, про которые известно, что они корректны, и считают, как часто он сообщает о проблеме, которая подтолкнула бы к вредной правке.
- По записанному приоритету. Сначала — ловить реальные ошибки, затем — сокращать число раундов ревью.
Важная деталь: шум дороже, когда автор — агент. Человек отмахивается от придирки за секунды. Агент её исправляет, а это новый коммит и новый раунд ревью. Если код пишет агент, а проверяет другой агент, они могут занимать друг друга бесконечно.
Отсюда практичное правило: порог срабатывания — главная настройка ИИ-ревью. Рецензент, который комментирует всё подряд, быстро приучает команду закрывать замечания не читая. Тогда пропускается и важное.
| Тип замечания | Что делать | Почему |
|---|---|---|
| Ошибка, которая сломает поведение | Публиковать, блокировать слияние до ответа | Это главная ценность ревью |
| Проблема безопасности | Публиковать отдельным проходом, блокировать | Цена пропуска высокая |
| Ошибка, существовавшая до изменения | Публиковать с пометкой «уже было» | Автор не должен выглядеть виноватым за старый код |
| Мелочь, стиль, «можно чище» | Ограничить количество или не публиковать | Приучает игнорировать замечания |
| Повтор уже опубликованной находки | Не публиковать | Не даёт новой информации |
Метки «важно», «мелочь» и «уже было» Anthropic использует в своём продукте; распределение действий по строкам таблицы — методика редакции.
Бесконечные раунды и как их остановить
Anthropic приводит пример: один pull request за ночь прошёл больше 50 раундов ревью и исправлений, пока автор не остановил процесс. Анализ истории изменений показал, что около 59% того, что рецензент отмечал повторно, было кодом, существовавшим уже на его первом проходе. Рецензент почти не находил новых ошибок — он каждый раунд находил ещё несколько старых.
Команда ввела четыре меры:
- лимит раундов — после трёх раундов рецензент просит автора остановиться и пересмотреть подход;
- ревью только нового диффа после первых проходов;
- указание класса ошибки, чтобы автор исправил все её проявления, а не одну строку;
- запрет повторов уже опубликованных находок.
Результат на внутренних pull request, по данным компании:
| Показатель | До мер | После мер |
|---|---|---|
| Прошли после одного раунда ревью и исправлений | 65% | 78% |
| Потребовали пять и более раундов | 8,9% | 1,5% |
| Среднее число проходов ревью до успеха | 2,08 | 1,32 |
Источник: блог Anthropic от 15.10.2026, рисунок D. Замер внутренний, методика выборки в посте не раскрыта.
Урок PostgreSQL 19: у людей ограниченная пропускная способность
Случай PostgreSQL показывает ту же проблему с другой стороны. По словам Петера Айзентраута, некоторые откаченные функции имели серьёзные архитектурные дефекты. Но ИИ-ревью нашло и длинный хвост относительно безобидных проблем в пограничных случаях, которые раньше обнаружили бы годами позже и закрыли бы исправлениями после выпуска.
Он описывает ситуацию так: «перед вами список из сорока дефектов… даже если каждый требует в среднем трёхстрочного исправления, на каждый уходят фиксированные накладные расходы, и время заканчивается». Ключевая мысль — эффективная планка качества поднялась уже после того, как функции были написаны и приняты.
Что из этого следует для компании:
- Подключать ИИ-ревью лучше в начале цикла, а не перед выпуском. Включённый за две недели до релиза рецензент выдаст очередь находок по всему накопленному коду.
- Старый код проверять отдельным потоком. У Anthropic агенты ревью по ночам проходят по существующему коду, а находки в старом коде помечаются отдельно от нового изменения.
- Сортировать находки по важности и ограничивать очередь. Сорок мелких замечаний к одной функции — это не сорок задач на сегодня, а бэклог с приоритетами.
- Планировать время людей на разбор. Каждая находка требует решения: исправить или обосновать отказ.
Айзентраут отдельно подчеркнул, что откаты не связаны с вайбкодингом: большая часть функций писалась до того, как этот подход стал доступен.
Где решение остаётся за человеком
Anthropic называет пять зон, где решает человек:
- нужно ли это делать вообще — направление, вкус и объём работы;
- рискованный код — платежи, автообновление, CI-процессы;
- архитектура, которая задаёт образец для других;
- чтение доказательств — вывода тестов, выполненной команды, скриншота, находок рецензента;
- ответственность за результат — за каждое выпущенное изменение отвечает человек, кто бы ни набрал код.
Отдельное правило касается агентов: в pull request, написанном агентом, человек, который им управлял, считается одним из обязательных ревьюеров — так же, как если бы он набрал код сам.
Как внедрить ИИ-ревью кода: 8 шагов
Порядок ниже — методика редакции, собранная из рекомендаций Anthropic и уроков PostgreSQL 19. Он рассчитан на команду, которая начинает с одного репозитория.
- Выберите один репозиторий и зафиксируйте базовую линию. Запишите за последние 4–8 недель: число pull request, медианное время ожидания ревью, число комментариев людей, долю откатов и инцидентов.
- Дайте агенту проверяемые команды. Тесты, сборка, линтер должны запускаться одной командой, описанной в коротком файле с правилами проекта. Агент должен показывать вывод, а не писать «готово».
- Напишите файл правил для рецензента. Что считается провалом в этой части кода, какие пути пропускать, сколько мелочей допустимо, требование указывать файл и строку. Шаблон — ниже.
- Включите ИИ-ревью в режиме «только комментарии». Первые недели рецензент ничего не блокирует, а команда размечает каждое замечание: исправили / ошибочно / намеренно / неважно.
- Настройте порог по разметке. Если большая часть замечаний — «неважно», сокращайте мелочи и повышайте планку публикации. Переносите повторяющиеся замечания в правила, линтер или тесты.
- Введите обязательный ответ и лимит раундов. Каждая находка закрывается исправлением или причиной; после трёх раундов — пересмотр подхода, далее проверка только нового диффа.
- Опишите уровни риска. Какие пути всегда требуют человека, какие изменения проходят с одним ревьюером, где достаточно автоматических проверок. Начинайте строго и ослабляйте по данным.
- Соберите набор задач из инцидентов. Изменения, которые приводили к откатам и сбоям, — лучший тест для рецензента. Прогоняйте его после каждой смены модели, промпта или инструментов.
Шаг 8 повторяет подход Anthropic: каждый инцидент добавляет кейс в набор, и любое изменение рецензента оценивается по всему набору. Подробнее о сборке собственного набора задач — в статье «Свой бенчмарк для выбора LLM».
Шаблон файла правил для рецензента
Anthropic советует держать такой файл коротким. Хорошие версии описывают, как выглядит провал в этом репозитории, ограничивают мелочи, перечисляют пропускаемые пути, требуют ссылку на файл и строку вместо догадки по названию и просят начинать сводку с количества находок. Пример структуры:
# Правила ревью: сервис заказов
## Что считается провалом
- Деньги: неверная сумма, валюта или округление в заказе.
- Данные: запись в чужой заказ, потеря статуса, двойная оплата.
- API: изменение формата ответа без версии.
## Что не комментировать
- Форматирование (его проверяет линтер).
- Стиль имён, если он не нарушает соглашения проекта.
- Каталоги migrations/archive и generated/.
## Как писать находку
- Указывай файл и строку, а не предположение по названию функции.
- Не более 3 мелких замечаний на pull request.
- Помечай ошибки, которые были до изменения, как «уже было».
## Сводка
- Начинай с числа находок по важности.
- Если исправлять нечего, так и напиши.Пример условный: составьте свои пункты из реальных инцидентов и повторяющихся комментариев людей.
Какие метрики считать
Anthropic измеряет экономию человеческого времени, а откаты и инциденты использует как ограничитель: если они растут, время людей не сэкономлено, а перенесено на исправление последствий.
| Метрика | Что показывает | Тревожный сигнал |
|---|---|---|
| Одобрения людей на pull request (медиана и 95-й перцентиль) | Сколько внимания требует изменение | Растёт после включения ИИ-ревью |
| Комментарии людей | Сколько ручной работы осталось | Не снижается за несколько недель |
| Время ожидания человека | Скорость потока | Растёт из-за разбора находок |
| Доля откатов и инцидентов | Качество на выходе — ограничитель | Растёт при снижении ручного ревью |
| Раунды до прохождения ревью | Сходимость процесса | Растёт доля длинных циклов |
| Реакция на замечания | Шум рецензента | Много «неважно» и «ошибочно» |
| Находки на заведомо чистых изменениях | Ложные тревоги | Подталкивают к вредным правкам |
Первые четыре строки — метрики, которые называет Anthropic; последние три — тоже из поста, сгруппированные редакцией.
Частые ошибки
- Включить рецензента на все репозитории сразу. Без настройки правил шум одинаково ударит по всем командам. Anthropic рекомендует начинать с одного репозитория и несколько недель настраивать правила.
- Считать количество находок успехом. Больше замечаний не значит лучше: важно, сколько из них исправили и сколько ошибок дошло до пользователей.
- Разрешить агенту одобрять за человека. Это убирает ответственность из процесса.
- Не ограничивать раунды. Агент-автор и агент-рецензент без лимита тратят время и бюджет на старые находки.
- Включить глубокое ревью перед самым выпуском. Урок PostgreSQL 19: очередь находок может оказаться больше, чем команда успеет разобрать.
- Отправлять код во внешнюю модель без правил. Если код содержит коммерческую тайну или персональные данные, сначала решите, где работает модель. Варианты — в статье «ИИ-агент для разработки в закрытом контуре».
Отдельная проверка нужна, если приложение собирали в основном с помощью ИИ, — порядок описан в материале «Аудит кода после вайбкодинга». А доверять ли метке «уверен», которую модель ставит своему ответу, разбираем в статье «Можно ли доверять уверенности ИИ».
Частые вопросы
Что такое ИИ-ревью кода?
Это автоматическая проверка изменений кода языковой моделью до человека или вместо части ручного ревью. Модель читает дифф в контексте репозитория, ищет ошибки, нарушения правил и уязвимости и оставляет замечания в pull request.
Может ли ИИ полностью заменить ревью кода человеком?
Нет, если речь о рискованных изменениях. Даже в Anthropic одобрение агента не засчитывается как одобрение человека, а платежи, автообновление и CI всегда требуют людей. Автоматике можно доверить изменения низкого риска при зелёных проверках.
Почему разработчики перестают читать замечания ИИ?
Из-за шума: когда рецензент комментирует всё подряд, люди привыкают закрывать замечания не глядя. Поэтому публиковать стоит только подтверждённые находки, ограничивать мелочи и не повторять уже опубликованное.
Сколько раундов ИИ-ревью нужно?
Обычно немного. Команда Claude Code ограничила раунды и после трёх просит автора пересмотреть подход; после этого среднее число проходов снизилось с 2,08 до 1,32.
Почему из-за ИИ-ревью задержали PostgreSQL 19?
Языковые модели нашли много дефектов в уже написанных функциях, включая мелкие пограничные случаи. Разобрать их до выпуска не успели, и 8–10 крупных функций перенесли в PostgreSQL 20.
С чего начать внедрение ИИ-ревью кода?
С одного репозитория: зафиксируйте метрики, включите рецензента в режиме комментариев, разметьте реакцию команды на замечания и настройте файл правил. Блокировки и уровни риска вводите после этого.
Первоисточники и метод проверки
Метод: 17 октября 2026 года мы прочитали пост Anthropic целиком, выписали слои проверки, правила, метрики и цифры до и после изменений, затем сверили историю PostgreSQL 19 по The Register и блогу Петера Айзентраута. Собственных замеров ИИ-ревью AIrassvet не проводил; восемь шагов внедрения, таблица действий по типам замечаний и шаблон файла правил — методика редакции.
- Anthropic, 15.10.2026: «How the Claude Code team does code review» — слои ревью, шум, раунды, уровни риска, метрики.
- The Register, 16.10.2026: «Postgres 19 delayed after AI reviewers find more bugs than humans can fix» — сроки, число откаченных функций, цитаты Айзентраута.
- Блог Петера Айзентраута — пост об откатах функций из ветки PostgreSQL 19.
Ограничения: цифры Anthropic — данные компании о собственном процессе, без независимой проверки; компания продаёт описанный инструмент ревью. Опыт крупной команды с собственной моделью нельзя напрямую переносить на компанию, где каждый прогон оплачивается из бюджета команды.
Как AIrassvet помогает внедрить ИИ-ревью кода
ИИ-ревью приносит пользу, когда встроено в процесс разработки с правилами, метриками и границами доступа. На сайте AIrassvet описаны направления, которые относятся к этой задаче напрямую:
- аудит процесса разработки: где сейчас тратится время ревьюеров, какие пути кода рискованные, какие метрики собирать до запуска;
- интеграция ИИ-агентов с репозиторием и CI: проверка pull request, файл правил рецензента, обязательные ответы на находки и лимит раундов;
- развёртывание языковой модели на серверах компании, если код нельзя отправлять во внешние сервисы;
- тестирование рецензента на наборе прошлых инцидентов и обучение команды работе с замечаниями.
Первый шаг — выбрать один репозиторий, описать текущий процесс ревью, источники данных о pull request и инцидентах, ограничения по безопасности кода и критерий успеха, например меньше человеческих комментариев без роста откатов.
Итог: настраивайте внимание людей, а не только модель
Опыт команды Claude Code и задержка PostgreSQL 19 описывают одну проблему с двух сторон. ИИ-рецензент способен находить много ошибок, но каждая находка стоит времени человека. Если замечаний слишком много, их перестают читать или не успевают разобрать.
Поэтому внедрение ИИ-ревью кода — это работа с порогом, раундами, уровнями риска и метриками. Начните с одного репозитория, измеряйте реакцию на замечания и держите откаты и инциденты ограничителем. Тогда автоматика возьмёт рутину, а люди сосредоточатся на решениях, которые машина принимать не должна.
