Почему пул-реквест вашего агента отклоняют

Команда исследователей собрала 33 000 пул-реквестов, написанных ИИ-кодинг-агентами, и задала простой вопрос: какие мёржатся, а какие умирают? Заголовочная цифра в том, что около 29% агентных PR не мёржатся. Но полезна закономерность за этим — потому что она не та, которую предполагает большинство.

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

Написать код никогда не было сложной частью его мёржа

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

И это не специфичное для ИИ правило. Мейнтейнеры отклоняют большие, расползающиеся, необъяснённые PR и от людей. Исследование лишь показывает, что агенты делают это чаще, быстрее и в масштабе, потому что агент оптимизирует «выдать рабочее решение», а не «выдать изменение, которое примет занятой человек». Это разные цели, и вторую и заботит кнопка мёржа.

Подсказки, которые нашло исследование

Несколько паттернов достаточно конкретны, чтобы по ним действовать:

• Размер убивает. Самый ясный сигнал обречённого PR — он большой и трогает кучу файлов. Агенты любят зарефакторить соседнее, раз уж зашли; ревьюеры это ненавидят.
• CI — это ворота, а не пожелание. Провальные PR чаще валят сборку. Агент, открывающий PR без предварительного прогона тестов, шлёт ревьюеру сигнал «я не проверял».
• Тип задачи предсказывает успех. Документация, CI и правки конфигурации сборки мёржатся лучше всего; работа над производительностью и багфиксы — хуже всего. Доля мёржа отслеживает, насколько изменение проверяемо и ограничено, — ровно того сложным фиксам и не хватает.
• Объяснение — часть работы. PR с расплывчатыми или несовпадающими описаниями реже принимают, и мёржатся они дольше — это спецификация как артефакт, всплывающая на ревью. Если ревьюер не может быстро увидеть, что изменилось и почему, он не может дёшево довериться, поэтому не доверяется.

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

Что с этим делать

Если вы наводите кодинг-агентов на реальные репозитории, уроки конкретны:

• Ограничьте агента маленькими одноцелевыми PR. Одно изменение, минимум файлов, никаких попутных рефакторов. Это та же логика надёжность-накапливается на уровне воркфлоу: маленькое изменение — то, что человек реально может проверить.
• Заставьте его проходить CI до открытия PR, а не после. Прогон тестов — часть производства изменения, а не отдельный шаг, который делает кто-то другой.
• Заставьте его писать описание, нужное ревьюеру. Что изменилось, почему, что проверить. Относитесь к объяснению как к результату, потому что на ревью оно им и является.
• Наводите на то, что мёржится, надзирайте на том, что нет. Пусть идёт свободнее на документации, конфигах и маленьких ограниченных фиксах; держите крепко на производительности и заковыристых багфиксах, где правильность трудно увидеть, а доверие — заслужить.

Суть

Исследование — полезное зеркало. Мы всё меряем кодинг-агентов по тому, могут ли они писать рабочий код, и они всё больше могут. Но «работает» никогда не было тем, что мёржится, — «маленькое, протестированное, объяснённое и легко доверяемое» им является. 29%, которые проваливаются, проваливаются в основном не на правильности; они проваливаются на сотрудничестве, а это навык, под который модель не оптимизировала и который вам надо поставить.

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