Как ревьюить ИИ-код: что автоматизировать, какую работу оставить человеку и как всё это делать системно

В 2026 году софт всё чаще пишут с участием ИИ: по данным Stack Overflow, 84% разработчиков уже используют ИИ‑инструменты или планируют начать. При этом исследователи Faros AI фиксируют парадокс: в командах с активным использованием ИИ разработчики закрывают на 21% больше задач и на 98% больше мёржат PR, но время ревью выросло на 91%. 

В статье разберём, как выстроить процесс проверки, который не съедает выигрыш от автоматизации и почему ревью ИИ‑кода нельзя полностью отдать моделям.

За консультацию при подготовке материала благодарим:

Немного контекста: как устроена разработка с участием ИИ 

ИИ‑инструменты работают как агенты: они читают код, редактируют файлы, запускают тесты и тянут документацию, часто в полуавтономном режиме внутри IDE. На практике это выглядит по-разному в зависимости от масштаба проекта. 

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

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

Один из примеров агентной разработки — Stripe. Код в компании пишут миньоны — автономные агенты-программисты, разработанные для выполнения разовых задач. Каждую неделю они создают более тысячи пул-реквестов, которые проверяет человек. Работа миньонов начинается с сообщения в Slack и заканчивается пул-реквестом, готовым к проверке. Инженеры могут запускать несколько миньонов параллельно, чтобы распределить выполнение множества задач. Миньоны используют те же инструменты, что и инженеры, и следуют лучшим практикам Stripe. Они могут получать контекст из внутренних документов, тикетов, статусов сборки и других источников. Если код не проходит тесты, миньоны могут исправить его и повторно отправить на проверку. 

Производительность на уровне отдельных задач растёт. Но чем шире возможности агентов, тем больше кода они генерируют и тем сложнее становится его проверять. Пул-реквесты стали крупнее и содержат больше ошибок.

Всё это приводит к парадоксу: чем активнее команда использует ИИ для генерации кода, тем сложнее становится ревью. Но стоит признать: для многих ревью и без ИИ было часто формальным. Разработчик смотрит на большой кусок чужой системы и думает: «Не знаю, что я ревьюирую, но вроде нормально» — и одобряет. Это распространённая практика в командах, где не выстроен процесс проверки. С появлением ИИ-кода объём пул-реквестов значительно вырос, а глубина понимания того, что в них происходит, у среднего ревьюера не изменилась. Проблема не новая — она просто стала острее. 

Какие ошибки чаще всего встречаются в ИИ-коде

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

Дублирующие решения

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

Агент работает с фрагментами и достраивает картину по вероятностям. Отсюда первый класс ошибок — дублирующие решения. Модель не знает, что в проекте уже есть validatePayment() в общем модуле, и генерирует похожую логику ещё раз — ближе к месту вызова. В итоге часть логики реализуется параллельно в нескольких местах, а потом расходится при доработках. Это прямой источник багов: при изменении требований обновляют один кусок, а второй забывают.

Зависимости

Модели обучены на коде, которому уже несколько месяцев или лет, и без явных ограничений склонны предлагать те версии библиотек, которые чаще всего встречались в обучающих данных. Например, ссылаются на несуществующие в реестре пакеты: по данным исследования USENIX Security 2025, модели придумывают их в 5–22% случаев — или на сборки с известными уязвимостями, исправленными в более свежих релизах. 

Ошибки в бизнес‑логике и доменной модели

Третий и самый трудноуловимый класс — ошибки в бизнес-логике. Агент видит код, но не знает, что за ним стоит. Разберём это на примере функции обработки платежей, в которой нельзя передавать отрицательные числа, или можно — если в системе предусмотрен кредитный лимит. Агент не может знать, какой из вариантов правильный для конкретного продукта. Он выберет наиболее вероятный исходя из обучения. 

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

Несогласованность между модулями и сервисами при мультиагентной разработке 

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

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

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

Как выстроить процесс ревью, чтобы проверка кода не тормозила проект

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

Подготовка: вложить время на старте, чтобы не терять его на финише

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

• Контекст проекта и архитектура. Что за продукт, как он устроен, какие сервисы взаимодействуют между собой, какие принципиальные архитектурные решения уже приняты и почему. Без этого агент будет определять архитектуру самостоятельно и чаще всего неверно. С инструкцией агент может спроектировать основные узлы, элементы и функции, которые потом всё равно проверит человек.

Когда мы наших агентов запускаем внутри Cursor, то там есть общий контекст. Все агенты его видят, учитывают и не теряются внутри проекта. Если проект сильно разрастается, агенты могут снова ошибаться. Тогда мы дробим задачи и выделяем субагентов. Они получают конкретный кусок проекта и дополнительный контекст: что находится вне зоны их задач. 

• Технический стек с версиями. Например, используем FastAPI 0.111, SQLAlchemy 2.0, Pydantic v2. Без явного указания агент возьмёт то, что встречалось чаще всего в его обучающей выборке.

• Бизнес-требования и доменная логика. Это самая трудоёмкая часть. Модель должна понимать не просто, что в проекте есть три кнопки, а зачем они пользователю и что делают. Важно задать и ограничения: какие правила нельзя нарушать, какие граничные случаи критичны, что считается корректным поведением системы в нестандартных ситуациях. Именно здесь живут те ошибки, которые обнаруживают в продакшене. 

• Журнал известных проблем. Список ошибок, которые агент уже совершал в этом проекте, с пояснением, как правильно. Этот документ пополняется по ходу работы и со временем становится одним из самых ценных — агент начинает реже наступать на одни и те же грабли.

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

Индустрия уже начала формализовывать подход Spec-Driven Development, при котором агенту на старте дают полный пакет документов о проекте. GitHub выпустил открытый инструмент Spec Kit, который за несколько месяцев собрал более 113 000 звёзд от разработчиков по всему миру. 

Ядро Spec Kit — четыре файла:

• constitution.md фиксирует принципы и правила проекта: какие библиотеки использовать, каким стандартам следовать, что считается допустимым решением, а что нет. 

• spec.md описывает, что именно строим и зачем. 

• plan.md содержит технические решения — как это устроено под капотом. 

• tasks.md разбивает проект на конкретные задачи. 

Рядом часто используют смежные инструменты:

• agents.md — файл с инструкциями непосредственно для агентов: как себя вести, на что опираться, чего избегать.

• skills.md — файл с инструкциями в Claude Code в формате Markdown, который описывает конкретный повторяющийся процесс. Например, как проводить ревью кода или как оформлять документацию по стандартам компании. Модель подгружает нужный скилл сама, когда задача подходит под её описание. Скиллы — это не замена всему пакету документов, а дополнительный слой поверх него. Как настраивать скиллы, Anthropic описали в инструкции. 

Агент читает Spec Kit в начале каждой сессии и получает контекст, который помогает ему писать код так, как принято в конкретном проекте. Это напрямую влияет на ревью: предсказуемый результат проще и быстрее проверить. 

Задача команды, которая хочет системно использовать ИИ в проекте, — разработать свой Spec Kit. Подготовка такого пакета и занимает время, и экономит его. Условно: потратили на подготовку Х времени, а время на ревью сократили на 2Х. 

Первый этап: модель проверяет модель

После того как агент написал код, его отдают на автоматическую проверку — другому агенту или той же модели в новой сессии с чистым контекстом. Этот этап не заменяет ревью человека, но сокращает объём работы для него.

Что модель на этом этапе делает хорошо: 

• находит синтаксические ошибки и нарушения стиля;

• проверяет соответствие принятым в проекте паттернам;

• выявляет устаревшие зависимости;

• проверяет, есть ли автотесты для нового кода, и пишет их при необходимости. 

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

Для ревью есть специальные модели вроде CodeRabbit, но его можно интегрировать не со всеми платформами. К тому же удобнее натренировать для ревью те же модели, которые пишут на проекте код. Они сверяются с документацией на первом этапе и так проходятся по всему проекту. Главное — скармливать не всё сразу, а по кусочкам: написали 6–7 тысяч строк кода — отдали. Так модель сможет детально рассмотреть каждый элемент и не будет галлюцинировать. По скорости разница ощутимая: ручная проверка в среднем занимает полный рабочий день минимум, автоматическая — пару часов.

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

Разработчик на этом этапе не читает весь код подряд. Он проверяет то, что модель принципиально не может проверить за него:

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

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

• Бизнес-логика. Любое место, где поведение системы определяется правилами, которых нет в открытых источниках и которые не были явно прописаны в инструкциях агента. Здесь нужен человек, который знает продукт.

• Архитектурные решения — то, как должна развиваться система. Агент хорошо работает на уровне задачи, но не удерживает долгосрочную картину. Это работа техлида или архитектора.

В командах, где этот процесс устоялся, состав участников со временем меняется. Появляются люди, которые почти не пишут код, а занимаются исключительно ревью. 

С чего начать, если процесс ещё не выстроен

Большинство команд сейчас находятся где-то посередине: ИИ-инструменты уже используются, но не системно. Разработчики пользуются Cursor или Claude Code на своё усмотрение, результаты проверяются так же, как и раньше. При этом, даже если компания считает, что проблема только с ревью кода, по факту она кроется в организации всего проекта, где часть кода уже пишут модели.

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

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

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

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

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

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

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

Для каждого такого эксперимента важно заранее определить критерии успеха. Например, «ревью одного пул-реквеста занимает на два часа меньше» или «документация обновляется в день релиза, а не через неделю». Без этого невозможно понять, работает ли подход и стоит ли двигаться дальше. Просто купить всем сотрудникам корпоративную подписку на ИИ-инструмент и объявить, что теперь все работают по-новому — это не внедрение. Будет только больше стресса, сопротивления и скептиков в команде.

А как у вас устроено ревью ИИ-кода и что реально работает?

Чтобы оставаться востребованным специалистом, нужно выходить из зоны комфорта и пробовать новое. Если всё ещё сомневаетесь, начните с чего-то небольшого и БЕСПЛАТНОГО:

• демодоступа к курсу «Нейросети для каждого» и бонусного занятия «Проверенные ИИ-инструменты для быстрого старта»;

• мастер-класса «Искусственный интеллект в разработке»;

• практического курса «ИИ в деле: ускорьте свою работу»;

• программы «Аналитика и ИИ: как принимают решения в реальном бизнесе»;

• дня открытых дверей магистратур УрФУ «Прикладной искусственный интеллект» и «Инженерия машинного обучения».

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

• на курсе «ИИ-агенты»;

• на программе «AI-архитектор с нуля до профи» с модулем по безопасной работе с данными при использовании ИИ;

• на курсе «Вайб-кодинг»;

• на программе повышения квалификации «Нейросети для бизнеса и управленцев» с бонусными модулями «Правовые аспекты ИИ» и «Промпт-инжиниринг»;

• на курсе «Специалист по искусственному интеллекту» с выбором программы под свои запросы.