Как обучить Claude на истории PR: создание персонального ИИ-ревьюера для команды

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

В материале рассматривается эволюция инструмента, который прошел путь от простого чек-листа до сложной мультиагентной системы. Разработчики HoneyBook поделились опытом использования Claude для анализа тысяч комментариев к пул-реквестам (PR), что позволило создать индивидуальные профили ревьюеров. Это решение не только повысило качество кода еще до начала человеческой проверки, но и потребовало серьезной архитектурной оптимизации для снижения затрат на токены.

Проблема производительности: когда ИИ пишет код быстрее, чем его проверяют

Активное использование Claude Code и аналогичных инструментов привело к тому, что генерация программных решений перестала быть трудозатратной задачей. Однако скорость код-ревью осталась на прежнем уровне, создавая «узкое место» в производственном цикле. Пул-реквесты накапливались, а программистам приходилось постоянно переключаться между глубокой работой над задачами и проверкой чужих изменений. Чем активнее команда выпускала код, тем больше времени уходило на его верификацию.

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

Недостатки универсальных решений в автоматизации ревью кода

Первая версия инструмента, получившая название /t2a-review, представляла собой навык для Claude Code, который сверял изменения в коде с общим списком правил. Несмотря на положительный первый отзыв, быстро выяснилось, что такая система избыточна. Большинство выявляемых проблем и так фиксировались стандартными линтерами, а специфические для команды нюансы оставались за бортом.

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

Переход к персонализации: использование истории комментариев

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

Процесс создания персонализированного ревьюера разделили на несколько этапов:

• Сбор всех комментариев конкретного разработчика через GitHub API.
• Анализ массива данных с помощью Claude для выявления повторяющихся закономерностей и стиля замечаний.
• Формирование индивидуальных Markdown-профилей (например, adi.md или amit.md), содержащих характерные правила со ссылками на исторические PR.
• Интеграция этих профилей в общий процесс проверки.

Такой подход позволил системе выдавать замечания в манере конкретных коллег. Например, инструмент научился понимать, что один разработчик блокирует PR из-за любого комментария TODO, а другой обязательно заметит отсутствие await в асинхронном методе.

Архитектура системы и вопрос стоимости токенов

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

Однако высокая точность привела к экономическим проблемам. Проверка PR объемом менее 500 строк с использованием модели Claude 3 Opus для всех агентов обходилась примерно в 20 долларов за один запуск. При ежедневном использовании всей командой такие расходы становились неоправданными. Потребовалась переработка архитектуры с разделением задач между моделями разных классов (model tiering).

Оптимизация через детерминированную обработку

Чтобы снизить затраты, разработчики внедрили предварительный этап анализа кода без использования ИИ. Обычный скрипт определяет тип изменений (frontend, backend или mixed) и пути файлов. На основе этой информации система автоматически отбрасывает нерелевантные разделы профилей ревьюеров. Если правки касаются только стилей, правила для работы с базами данных не передаются в модель. Это значительно сокращает объем контекста и ускоряет работу.

Распределение ролей между моделями Claude

В финальной архитектуре (версия 2.1) нагрузка была распределена следующим образом:

• Claude 3 Haiku: используется для широкого поиска потенциальных проблем в больших объемах текста. Это самая дешевая и быстрая модель в линейке.
• Claude 3.5 Sonnet: применяется для анализа и обобщения результатов, полученных от разных агентов. Она обладает оптимальным балансом между способностью к рассуждению и стоимостью.
• Claude 3 Opus: задействуется только в роли агента-скептика для финальной верификации, когда требуется максимальный уровень интеллекта для исключения «галлюцинаций».

Такая оптимизация позволила снизить стоимость одной проверки с 20 до 3 долларов, сохранив и даже улучшив качество поиска ошибок за счет более точного фокуса агентов.

Ключевые выводы по внедрению ИИ-инструментов в разработку

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

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

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