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

Агент как первый проход ревью

Агент — отличный первый проход ревью, который снимает с человека рутину:

  • ловит явное — забытая обработка ошибки, крайние случаи, нарушение стиля, подозрительные места;
  • объясняет незнакомый код и предлагает, на что посмотреть внимательнее;
  • проверяет по заданным правилам, если они у него есть (см. настройку агента и исполняемый стандарт).

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

Генерация тестов — с оговоркой

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

  • Тесты от того же агента наследуют его слепые пятна. Если агент неверно понял, как должно работать, он напишет тест, который закрепляет неверное поведение как «правильное». Такой тест зелёный — и бесполезный.
  • Тест, который ничего не проверяет, выглядит как тест. Агент иногда генерирует проверки, которые проходят всегда.

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

Проверяемый критерий важнее объёма

И для ревью, и для тестов работает одно правило: у проверки должен быть objective-критерий, а не «агент сказал, что хорошо». Тесты либо проходят, либо нет; правило стиля либо соблюдено, либо нет. Опирайтесь на то, что даёт однозначный сигнал, а не на уверенный тон модели — он не связан с правильностью.

Отдельная сила подхода — когда правила ревью вынесены в исполняемый вид (executable standard, против SonarQube): тогда агент проверяет по одному и тому же стандарту на каждом PR, а не «как получится в этот раз».

Что это значит на практике

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

Дальше

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