Малые партии кода: почему с ИИ-агентами это правило важнее, чем раньше

14 октября 2026 · 8 минут чтения

Исследовательская программа DORA (DevOps Research and Assessment, с 2018 года часть Google Cloud) больше десяти лет измеряет, какие практики отличают быстрые и надёжные команды разработки. Одна из них — работа малыми партиями. В 2025 году DORA добавила к ней наблюдение, которое прямо касается внедрения ИИ-агентов: малые партии усиливают положительный эффект ИИ на продукт, а без них ускорение превращается в нестабильность.

Эта статья пересказывает страницу DORA о малых партиях и отделяет её выводы от моей интерпретации: как это правило меняется, когда код пишет агент.

Что DORA называет малой партией

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

Для размера партии DORA даёт два ориентира:

• хорошая партия занимает от нескольких часов до пары дней;
• партия, которую нельзя завершить и проверить за неделю, слишком велика.

Для декомпозиции DORA предлагает критерии INVEST, известные из гибкой разработки. Партия должна быть независимой (её можно выпустить и проверить отдельно), обсуждаемой (её можно переформулировать после обратной связи), ценной (результат полезен сам по себе), оцениваемой, малой и тестируемой.

Крупные партии живут не из-за лени. У передачи изменения дальше по конвейеру есть высокая фиксированная стоимость: согласование, сборка, ручная проверка, релизное окно. Если каждая передача дорогая, рационально копить изменения и передавать их пачкой. Поэтому DORA связывает малые партии с непрерывной доставкой: сначала нужно сделать передачу дешёвой, иначе малые партии экономически невыгодны.

Что DORA говорит про ИИ

Здесь важно развести факт и интерпретацию. Фактическая часть, как она изложена на странице DORA:

• DORA относит малые партии к способностям, которые предсказывают производительность доставки и организации в целом, вместе с видимостью работы, командными экспериментами и видимостью обратной связи от клиентов;
• по данным DORA, внедрение ИИ часто ведёт к росту нестабильности доставки;
• работа малыми партиями усиливает положительное влияние внедрения ИИ на показатели продукта и помогает превратить нейтральный эффект ИИ на организационное трение в положительный.

DORA описывает это как корреляции в опросных данных, а не как результат контролируемого эксперимента. Насколько сильный эффект, в каких командах и при каких условиях — на странице способности не раскрывается; за этим DORA отправляет к отчёту «2025 State of AI-assisted Software Development» и к модели AI Capabilities Model. Я эти отчёты здесь не разбираю.

Дальше — моя интерпретация.

Почему агент тянет партию вверх

Исторически размер партии ограничивала скорость человека. Разработчик физически не мог за день написать фичу на две тысячи строк, поэтому крупная партия складывалась неделями, и её размер был виден всем.

Агент снимает это ограничение. Он за одну сессию делает миграцию, модель, обработчик, интерфейс и тесты. Результат выглядит завершённым, и соблазн велик: оформить это одним запросом на слияние (pull request, PR) и выпустить разом. Сама DORA отмечает этот эффект: ИИ-инструменты склонны выдавать большие законченные фичи, а крупный машинно-сгенерированный PR на строку кода ревьюить тяжелее, чем написанный человеком.

Получается ножницы. Стоимость создания партии упала почти до нуля, а стоимость её проверки осталась человеческой. Если размер партии не ограничивать специально, он вырастает до размера, который человек уже не может осмысленно проверить. Рост нестабильности, который фиксирует DORA, я читаю именно так: не агент пишет плохой код, а партия становится больше, чем ревью.

Отсюда следствие, которое DORA формулирует прямо: при работе с ИИ-ассистентами упор смещается с генерации на декомпозицию и верификацию. Думать нужно не о том, как получить от агента больше кода, а о том, как нарезать задачу и как проверить каждый кусок.

Как удержать партию малой, когда код пишет агент

Ниже приёмы DORA и то, как они выглядят в агентной разработке. Первые два пункта — пересказ DORA, остальные — мой перенос на работу с агентом.

Коммитить в основную ветку ежедневно. DORA требует интегрировать небольшие готовые к выпуску изменения в основную ветку не реже раза в день. Для агента это означает: сессия, которая не закончилась слиянием или хотя бы коммитом в основную ветку, уже подозрительно длинная.

Начинать с API, а не с интерфейса. Команда добавляет возможность в сервисный слой, проверяет её автоматическими тестами и выпускает в рабочую систему, не показывая пользователю. DORA называет это тёмным запуском (dark launching). Так фича выходит частями, каждую из которых можно откатить отдельно, а интерфейс появляется последним.

Прятать незавершённое за переключателями. Переключатель функциональности (feature toggle) — условие в конфигурации, которое включает или скрывает поведение. Вместо долгоживущей ветки, где фича зреет неделями, код попадает в основную ветку сразу, но выключенным. Для больших перестроек DORA рекомендует ветвление через абстракцию (branch by abstraction): новая реализация растёт рядом со старой за общим интерфейсом и включается по частям.

Одна задача — одна партия. Самый дешёвый способ ограничить размер партии при работе с агентом — ограничить размер задачи, которую ему выдают. Задача на день, с критериями приёмки, из которой получается один PR. В статье о start-issue я описывал механику: выбранная задача превращается в изолированную рабочую директорию для агента, и граница задачи становится границей партии.

Просить агента нарезать, а не делать. Агент хорошо декомпозирует, если его об этом попросить до начала работы: «разбей на шаги, каждый из которых можно выпустить и проверить отдельно, и начни с первого». Без такой просьбы он по умолчанию делает всё сразу. Это и есть смещение с генерации на декомпозицию, о котором пишет DORA.

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

Две типичные ошибки

DORA называет две, и обе хорошо знакомы командам с агентами.

Партии нарезаны недостаточно. Код коммитят только когда фича закончена, а фича занимает недели. Правило DORA: коммитить независимо от того, завершена ли фича, и держать фичу в пределах нескольких дней. С агентом эта ошибка выглядит как «одна сессия — одна фича — один большой PR».

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

Как это измерить

DORA не предлагает одной метрики размера партии. Вместо этого она задаёт вопросы к процессу:

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

Косвенный показатель, который легко снять из истории Git — число слитых PR в месяц на команду и на разработчика. В кейсе о переходе с 8 до 188 PR в месяц я показывал этот ряд; как собрать такой замер своей команде — в гайде о четырёх промптах для техдиректора. Число PR само по себе не говорит о размере партии: сто мелких PR и сто крупных дадут одно число. Но резкий рост PR при той же команде обычно означает, что партии стали меньше, а падение при росте объёма кода — что они растут. Для честного ответа нужно смотреть и на размер диффа, и на время от первого коммита до выпуска.

Что делать дальше

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

Автор: Данил Письменный · Дата: 14 октября 2026