Как делать ревью кода через агента

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

1. Как код проверяют в команде

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

Затем он попросил коллегу посмотреть код. Коллега знает язык программирования и читает, как устроено добавление, как программа выбирает запись для удаления, что происходит с остальным списком. Такой просмотр называют ревью кода, или code review, а проверяющего - ревьюером.

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

Ревьюер оставляет комментарий рядом с соответствующим участком кода: "Сейчас удаляются все покупки с этим названием. Мы разрешаем одинаковые записи? Если да, нужно удалять только выбранную". Автор уточняет требование: одинаковые записи разрешены, ведь их могли добавить для разных людей. После обсуждения он меняет способ выбора записи. Коллега смотрит исправление ещё раз и убеждается, что замечание учтено.

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

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

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

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

2. Как поручить ревью агенту

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

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

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

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

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

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

На выходе у вас понятное объяснение проблемы, результат её перепроверки и отчёт об исправлении. А если замечание оказалось ошибочным, полезный результат тоже есть: вы избежали ненужной правки.

Если хотите настроить постоянного помощника для таких просмотров, пригодится материал о создании и запуске субагента. Как подготовить ему более подробное поручение, разобрано в статье о брифе и формате результата.

Запрос 1. Проверить написанный код

Запустите Claude Code в папке проекта. Следующие три запроса отправляйте в основную сессию: главный агент сам передаёт работу помощникам. Здесь и дальше используем учебный список покупок; для своего проекта замените описание поведения.

Поручи отдельному субагенту ревью кода списка покупок
в текущем проекте. Проверь добавление и удаление записей.
Требования: одинаковые названия разрешены; удаляется только
выбранная запись; пустую покупку добавить нельзя.

Прочитай текущий код и связанные с ним части проекта.
Ищи ошибки, которые нарушают эти требования.
Код не меняй. Не добавляй новые возможности.
Для каждого замечания объясни простыми словами:
что может пойти не так, при каком действии и почему ты так решил.
Укажи место в коде для дальнейшей проверки другим агентом.
Если проблем не найдено, так и напиши. Перечисли, что проверено
и что осталось неизвестным. Сохрани отчёт в REVIEW_REPORT.md.
Я не знаю язык программирования: объясни итог без требования читать код.

Файл REVIEW_REPORT.md будет обычным текстовым отчётом. Имя мы выбрали сами, подойдёт и любое другое: оно нужно, чтобы в следующем запросе было понятно, какие замечания перепроверять. Требование "код не меняй" отделяет просмотр от исправления; запись отчёта при этом разрешена.

Полезный ответ в нашем примере мог бы звучать так: "Если добавить две покупки с одинаковым названием, удаление одной уберёт обе. Код выбирает записи по названию, поэтому затрагивает оба совпадения". Это учебный пример ответа, а не результат проверки вашего проекта.

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

3. Как перепроверить замечания

У агента-ревьюера тоже бывают ошибки. Например, он пишет: "В список можно добавить пустую покупку". Звучит убедительно. Но проверка пустого ввода уже существует в другой части программы, которую он не прочитал. Замечание описывает несуществующую проблему.

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

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

Запрос 2. Проверить отчёт ревьюера

Поручи другому субагенту перепроверить REVIEW_REPORT.md
по текущему коду проекта и требованиям из предыдущего запроса.
Передай ему эти требования явно.

По каждому замечанию выясни, существует ли описанная проблема.
Проверь связанные части кода: возможно, нужная обработка уже есть.
Не считай первый отчёт доказательством. Если для вывода нужна
проверка запуском, выполни её доступными средствами.
Код проекта не меняй.

Для каждого пункта укажи: подтверждён, опровергнут
или пока не удалось установить. Объясни основание понятным языком.
Раздели выводы по чтению кода и результаты выполненных проверок.
Не изображай невыполненную проверку как выполненную.
Сохрани результат в REVIEW_CHECK.md и кратко объясни его мне.

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

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

Повторная проверка помогает отсеивать выдуманные замечания, но не гарантирует их полного исчезновения. Два агента могут повторить одну ошибку. Поэтому в ответе нужны основания: что именно проверяющий нашёл в проекте или какой результат получил при запуске. Одного "согласен с предыдущим агентом" мало.

4. Исправление и повторное ревью

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

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

Запрос 3. Исправить и проверить результат

Исправь подтверждённую проблему из REVIEW_CHECK.md:
при удалении одной покупки исчезают все записи с таким же названием.
Нужно удалять только выбранную запись. Одинаковые названия разрешены.
Остальные предложения из ревью сейчас не внедряй.

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

Объясни мне простыми словами, что изменилось, какие проверки
выполнены и что показало повторное ревью.
Если что-то проверить не удалось, назови это отдельно.
Не расширяй задачу новыми улучшениями.

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

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

Вы также можете открыть страницу и попробовать привычные действия. Для этого знание языка не нужно. Это дополнительная проверка видимого результата; техническое ревью исправления по-прежнему выполняет агент. Если его возможностей для запуска не хватило, в отчёте останется понятное ограничение, а не обещание "всё точно работает".

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