# Почему пул-реквест вашего агента отклоняют Исследователи изучили 33 000 пул-реквестов, написанных ИИ-кодинг-агентами, и около 29% так и не были смёржены. Интересно почему: в основном не потому, что код был неверным, а потому, что PR был плохим артефактом сотрудничества — слишком большим, трогал слишком много файлов, мешал несвязанные правки, валил CI и плохо себя объяснял. Добиться, чтобы код приняли, оказывается, — другой навык, чем его написать, и ровно тот навык, которого у агентов по умолчанию нет. Разбираю, что это значит. - **Author:** Фёдор Чищин - **Published:** 2026-06-10 - **Tags:** methodology, agents - **Source:** https://fedorthinks.com/ru/blog/why-your-agents-pr-gets-rejected --- Команда исследователей собрала 33 000 пул-реквестов, написанных ИИ-кодинг-агентами, и задала простой вопрос: какие мёржатся, а какие умирают? Заголовочная цифра в том, что [около 29% агентных PR не мёржатся](https://arxiv.org/abs/2601.15195). Но полезна закономерность за этим — потому что она не та, которую предполагает большинство. Рефлекс — думать, что в провалившихся PR был плохой код. Иногда. Но исследование нашло, что провалы кучкуются вокруг совсем другого: отклонённые PR [обычно включают бо́льшие изменения кода, трогают больше файлов и валят CI проекта](https://arxiv.org/abs/2601.15195), а в смежных работах функционально _верный_ код тоже отклоняют — за то, что он [слишком большой, мешает несвязанные правки и плохо себя объясняет](https://arxiv.org/pdf/2602.00164). Иначе говоря, агент часто решал задачу и всё равно получал отказ, потому что PR был плохим способом _попросить_ изменение. ## Написать код никогда не было сложной частью его мёржа Вот переосмысление. Мёрж — это не событие кода; это событие социальное. Человек-мейнтейнер должен прочитать изменение, понять его, довериться ему и взять за него ответственность. Всё, что делает это лёгким — маленький сфокусированный дифф; одно цельное изменение; проходящие тесты; описание, объясняющее что и почему, — это и есть то, что мёржит PR. Агент, выдавший верный код, но раскидистый, необъяснённый, валящий CI PR, сделал лёгкую половину и пропустил ту, что реально решает исход. И это не специфичное для ИИ правило. Мейнтейнеры отклоняют большие, расползающиеся, необъяснённые PR и от _людей_. Исследование лишь показывает, что агенты делают это чаще, быстрее и в масштабе, потому что агент оптимизирует «выдать рабочее решение», а не «выдать изменение, которое примет занятой человек». Это разные цели, и вторую и заботит кнопка мёржа. ## Подсказки, которые нашло исследование Несколько паттернов достаточно конкретны, чтобы по ним действовать: - **Размер убивает.** Самый ясный сигнал обречённого PR — он большой и трогает кучу файлов. Агенты любят зарефакторить соседнее, раз уж зашли; ревьюеры это ненавидят. - **CI — это ворота, а не пожелание.** Провальные PR чаще валят сборку. Агент, открывающий PR без предварительного прогона тестов, шлёт ревьюеру сигнал «я не проверял». - **Тип задачи предсказывает успех.** Документация, CI и правки конфигурации сборки мёржатся лучше всего; [работа над производительностью и багфиксы — хуже всего](https://arxiv.org/abs/2601.15195). Доля мёржа отслеживает, насколько изменение _проверяемо и ограничено_, — ровно того сложным фиксам и не хватает. - **Объяснение — часть работы.** PR с расплывчатыми или [несовпадающими описаниями реже принимают, и мёржатся они дольше](https://arxiv.org/pdf/2602.17084) — это [спецификация как артефакт](/blog/specs-are-the-artifact), всплывающая на ревью. Если ревьюер не может быстро увидеть, что изменилось и почему, он не может дёшево довериться, поэтому не доверяется. Есть и более тихая находка, достойная того, чтобы посидеть с ней: большинство агентных PR получают [мало реального человеческого ревью вообще](https://arxiv.org/pdf/2602.19441), а то ревью, что есть, всё чаще — другие агенты. Когда агентные PR прибывают миллионами, человеческое внимание к ревью — дефицитный ресурс, и PR, который дорого ревьюить, проигрывает тому, что дёшево, независимо от того, чей код лучше. ## Что с этим делать Если вы наводите кодинг-агентов на реальные репозитории, уроки конкретны: - **Ограничьте агента маленькими одноцелевыми PR.** Одно изменение, минимум файлов, никаких попутных рефакторов. Это та же логика [надёжность-накапливается](/blog/smarter-but-not-more-reliable) на уровне воркфлоу: маленькое изменение — то, что человек реально может проверить. - **Заставьте его проходить CI до открытия PR, а не после.** Прогон тестов — часть производства изменения, а не отдельный шаг, который делает кто-то другой. - **Заставьте его писать описание, нужное ревьюеру.** Что изменилось, почему, что проверить. Относитесь к объяснению как к результату, потому что на ревью оно им и является. - **Наводите на то, что мёржится, надзирайте на том, что нет.** Пусть идёт свободнее на документации, конфигах и маленьких ограниченных фиксах; держите крепко на производительности и заковыристых багфиксах, где правильность трудно увидеть, а доверие — заслужить. ## Суть Исследование — полезное зеркало. Мы всё меряем кодинг-агентов по тому, могут ли они писать рабочий код, и они всё больше могут. Но «работает» никогда не было тем, что мёржится, — «маленькое, протестированное, объяснённое и легко доверяемое» им является. 29%, которые проваливаются, проваливаются в основном не на правильности; они проваливаются на сотрудничестве, а это навык, под который модель не оптимизировала и который вам надо поставить. Так что когда PR вашего агента отбивают, не спрашивайте только «верен ли был код». Спросите то, что на самом деле спрашивал ревьюер: было ли это изменением, которое занятой человек мог бы быстро понять, проверить и взять за него ответственность? Заставьте агента выдавать _это_ — и доля мёржа позаботится о себе сама. Пропустите — и будете дальше отгружать верный код, который никто не принимает, а это в команде то же самое, что не отгружать вовсе.