ИИ-агенты пишут код быстрее людей, но и pull request на 1700+ строк они выдают без малейшего стеснения. GitHub предлагает решение - разбить один необъятный запрос на цепочку небольших.
Коротко о главном
GitHub описал, как через встроенную поддержку stacked pull requests разбить один гигантский pull request, сгенерированный ИИ-агентом, на аккуратную цепочку небольших, логически упорядоченных запросов. Идея stacked pull requests - разложить крупную фичу на слои: в основании стека лежит фундаментальная работа, а зависимая от неё работа выстраивается сверху, слой за слоем. Вместо одного необъятного изменения получается цепочка небольших pull request, каждый из которых можно проверять и объединять по отдельности. Чтобы агенты умели работать со стеками, GitHub предлагает установить расширение и навык gh-stack: `gh extension install github/gh-stack` и `gh skill install github/gh-stack`. В примере из статьи разные специализированные агенты берут на себя разные слои одной фичи: агент Data Modeler создаёт основу каталога данных, агент Backend строит слой API, а агенты Frontend реализуют интеграцию чата и элементы интерфейса - каждый агент инициализирует свою ветку, коммитит изменения после прохождения проверок CI и отправляет обновления, а система автоматически перестраивает (rebase) слои друг над другом при изменениях в нижних уровнях стека. По оценке Gartner, процитированной в статье, ИИ-агенты для разработки, по прогнозу, дадут 50-процентный прирост производительности на каждом этапе цикла разработки программного обеспечения к 2028 году - это прогноз аналитической компании, а не собственное измерение GitHub. Практический пример из статьи: рецензенту больше не нужно проверять один pull request размером свыше 1700 строк за один присест - вместо этого перед ним небольшие, самодостаточные цели внутри стека.
Проблема: агенты пишут код быстро, но PR получаются необъятными
ИИ-агенты умеют писать код заметно быстрее человека, но результат их работы часто выливается в один pull request, который физически тяжело проверить целиком за один присест. GitHub формулирует старую дилемму разработки одной фразой: «Один PR тяжело проверять, а много мелких PR тяжело поддерживать» - именно эту дилемму и решают stacked pull requests.
Что такое stacked pull requests
Идея в том, чтобы разложить крупную фичу не на один запрос, а на цепочку слоёв. В основании стека лежит фундаментальная работа - то, от чего зависит всё остальное. Выше по стеку выстраивается зависимая работа, слой за слоем. В результате вместо одного необъятного изменения получается несколько небольших pull request, каждый из которых можно проверить и объединить отдельно, не дожидаясь готовности всей фичи целиком.
Как агенты учатся работать со стеком - навык gh-stack
Чтобы ИИ-агент умел собирать код именно в виде стека, а не одним огромным изменением, GitHub предлагает установить расширение и навык прямо в командной строке: gh extension install github/gh-stack, а затем gh skill install github/gh-stack. После этого агент понимает структуру стека и умеет с ней работать напрямую через инструмент gh stack.
В статье приведён пример реального рабочего процесса: над одной фичей работают сразу несколько специализированных агентов, каждый отвечает за свой слой. Агент Data Modeler создаёт основу - каталог данных. Агент Backend строит слой API поверх этой основы. Агенты Frontend реализуют интеграцию чата и элементы интерфейса, опираясь уже на готовые нижние слои. Каждый агент инициализирует собственную ветку, коммитит изменения только после прохождения проверок CI и отправляет обновления - а система сама перестраивает (делает rebase) верхние слои стека, если что-то меняется в основании.
Как читать и проверять готовый стек
GitHub даёт простую рекомендацию по навигации: читать стек сверху вниз, чтобы сначала увидеть конечную цель, а затем спускаться к деталям реализации. А вот проверять его предлагается наоборот, снизу вверх - «чтобы выстраивать проверку на уже подтверждённых нижних чекпоинтах», то есть не пересматривать фундамент заново на каждом следующем слое.
Практический эффект для рецензента сформулирован прямо: вместо того чтобы «смотреть на единый pull request размером свыше 1700 строк, который нужно проверить за один присест», рецензент получает «небольшие, самодостаточные цели внутри стека» - и может проверять их последовательно, а не пытаться удержать в голове всю фичу целиком.
Прогноз Gartner - и что это значит
В статье упомянут прогноз аналитической компании Gartner: ИИ-агенты для разработки, по её оценке, дадут 50-процентный прирост производительности на каждом этапе цикла разработки программного обеспечения к 2028 году. Важно понимать, что это прогноз стороннего аналитического агентства, а не собственное измерение или гарантия результата от GitHub - относитесь к цифре как к оценке рынка, а не к подтверждённому факту.
Нужно ли вручную разбивать код на стек, или агент делает это сам?
После установки расширения и навыка gh-stack агент сам понимает структуру стека и умеет распределять свою работу по слоям - в примере из статьи разные специализированные агенты берут на себя разные слои одной фичи автоматически.
Что происходит, если изменить нижний слой стека после того, как верхние уже написаны?
Система автоматически перестраивает (делает rebase) верхние слои стека над изменённым основанием - вручную пересобирать каждый зависимый слой не требуется.
В каком порядке читать готовый стек pull request'ов?
GitHub рекомендует читать стек сверху вниз, чтобы сразу увидеть конечную цель, а проверять - снизу вверх, опираясь на уже подтверждённые нижние чекпоинты.
Можно ли доверять цифре про 50-процентный прирост производительности от ИИ-агентов?
Это прогноз аналитической компании Gartner, процитированный в статье GitHub, а не собственное измерение или гарантия самого GitHub - относитесь к нему как к рыночной оценке, а не к подтверждённому результату.
Как установить поддержку stacked pull requests для агента?
Через две команды в терминале: gh extension install github/gh-stack, затем gh skill install github/gh-stack.
Зачем вообще разбивать один PR на несколько, если фича логически цельная?
Потому что один огромный pull request физически тяжело проверить за один присест целиком, а несколько отдельных несвязанных PR тяжело поддерживать - stacked pull requests сохраняют логическую связность фичи, но делают каждый отдельный слой маленьким и самодостаточным для проверки.
← Все статьи блога