Дифф от агента на 900 строк: десять вопросов, которые я задаю себе до кнопки Approve

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

Почему вообще стало тяжело? Код же стал дешевле

Дешевле писать, но не проверять. Экономия на наборе кода никуда не исчезает, она переезжает к ревьюеру. В отчёте DORA за 2025 год это называют «налогом на проверку», и мне нравится слово: налог платят все, а получает его один человек.

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

Разве нельзя просто читать внимательнее?

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

Чтобы не быть пробкой, нужно менять не внимание, а устройство процесса. Дальше про это.

С чего начинать чтение: с первого файла?

Нет, с мест, где обманывают чаще всего. Я открываю в таком порядке:

1. Тесты, конфигурация CI и зависимости.
2. Новые вспомогательные функции и пакеты.
3. Один критический путь от входа до выхода.
4. Всё остальное, если ещё остались силы.

Первый пункт важнее остальных. В GitHub описывают типовые признаки агентских правок: ослабленный CI, дубли вместо переиспользования, код, который компилируется, но делает не то. Агент, которому сказали «почини красный билд», может починить его по-хамски: пропустить тест, снизить порог покрытия, проглотить ошибку. Билд зелёный, задача формально выполнена.

Зелёные тесты разве не доказательство?

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

Два приёма, которые у меня прижились. Первый: просить тест, который падает до правки. Второй: иногда ломать код руками (инвертировать условие, вернуть ноль) и смотреть, покраснеет ли что-нибудь. Если нет, тест декоративный.

Как поймать дубли?

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

Какого размера дифф считать приемлемым?

Руководство Google по ревью называет разумным изменением около сотни строк и слишком большим тысячу. Старое исследование SmartBear и Cisco: эффективнее всего смотреть 200–400 строк за сеанс, не спеша и не дольше часа. Я бы не делал из этих чисел закон: данные собраны на одной компании и до эпохи агентов, это эвристика. Но направление очевидно: чем меньше изменение, тем честнее его прочитают.

Поэтому меньше всего я люблю дифф на девятьсот строк «по одной задаче». Ограничение размера можно повесить на CI, а требование разбить работу на части записать в правила команды. Это не придирка, это защита ревьюера.

А если изменение большое и разбить нельзя?

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

Можно ли отдать первый проход другой модели?

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

Автор — агент. Относиться строже?

Ни строже, ни мягче. Мне ближе позиция, которую описывают для контрибьюторов: агентский вклад проверяют как любой другой. Не повод отклонять и не повод верить на слово. Исследователи, опросившие практиков, перечисляют, что реально влияет на решение: ограниченный объём, объяснение «зачем», проверки сверх зелёного CI и понятный владелец после слияния.

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

И как тогда не стать узким местом?

Перестать быть единственной точкой одобрения. У меня короткий список:

• у каждого агентского изменения есть человек, который запустил агента и отвечает за результат; тот, кто писал промпт, не должен быть и единственным контролёром;
• размер диффа ограничен, большое режется или идёт через план;
• автор приносит замысел и доказательства, а не только код;
• после слияния понятно, кто владеет этим куском, а из истории видно, что его писал агент (насколько строго это размечать, команды спорят до сих пор);
• ревью распределено между людьми, а не лежит на одном человеке, который «лучше всех знает кодовую базу».

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

Что в итоге, агенты делают код хуже?

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

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