Агентный контур разработки: как я ускорил поставку в несколько раз без потери качества

Почти в каждой команде, где я работал, медленная поставка объяснялась одинаково: «мало людей». На практике людей почти всегда хватало. Не хватало другого — короткого и предсказуемого пути от идеи до продакшена. Задача неделю ждала уточнений, два дня — ревью, ещё день — пока кто-то вспомнит, как её проверять.

Когда LLM-агенты стали достаточно хорошо писать код, у меня возник соблазн просто «дать всем Copilot» и ждать ускорения. Это не работает. Агент, которому дали размытую задачу, быстро производит много размытого кода — и узкое место переезжает с написания на ревью и исправление багов.

Поэтому я подошёл к этому как к инженерной системе, а не как к инструменту. Ниже — как устроен контур, который у меня в итоге получился, что он дал и где у него границы.

Проблема: время уходит не на код

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

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

Вывод простой: если ускорять только написание кода, общий TTM почти не изменится. Ускорять нужно весь контур — и в первую очередь те места, где задача ждёт или возвращается.

Система: агентный контур поставки

Контур состоит из пяти шагов. Каждый шаг оставляет артефакт в репозитории — это ключевое решение, к нему я вернусь ниже.

1. Спецификация

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

Спека живёт в репозитории рядом с кодом (docs/specs/…). Это дешевле, чем кажется: одна-две страницы, 20–40 минут работы. Зато дальше ни у человека, ни у агента нет вопроса «а что вообще нужно сделать».

2. План

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

План — это контракт между человеком и агентом. Я ревьюю план, а не тысячу строк диффа. Ошибку в плане исправить в десятки раз дешевле, чем ошибку в коде.

3. Реализация небольшими шагами

Агент выполняет план по одной задаче: реализация → проверка → коммит. Небольшие шаги дают две вещи. Во-первых, если агент ушёл не туда, откатывается одна задача, а не день работы. Во-вторых, история коммитов читается как план — ревьюеру проще.

4. Автоматическая проверка

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

Принцип: агенту нельзя верить на слово. «Готово» означает «зелёный CI и выполненные критерии», а не «агент сказал, что готово».

5. Ревью человеком

Финальное ревью остаётся за человеком. Но оно другое по сути: ревьюер уже видел спеку и план, поэтому проверяет решения и риски, а не угадывает намерения автора. Ревью становится короче и содержательнее.

Что это дало

Я смотрел на три группы метрик: скорость, качество и нагрузку на людей.

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

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

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

Где это не работает

Честный список ограничений:

Исследовательские задачи. Если непонятно, что строить, спека не пишется — сначала нужен прототип или спайк. Агент здесь полезен как ассистент, но не как исполнитель контура.
Слабая тестовая база. Контур держится на автоматических проверках. Если в проекте нет тестов и CI, первым делом надо строить их, иначе вы просто быстрее производите непроверенный код.
Размытая ответственность. Агент не отвечает за продакшен. Отвечает человек, который утвердил план и принял ревью. Это нужно проговорить явно, иначе качество начинает «никому не принадлежать».
Перегруженный контекст. Большие задачи агент делает хуже. Если задача в плане не помещается в один осмысленный коммит — её надо дробить.

Что я бы вынес для CTO

Если вы строите инженерную функцию или выбираете того, кто будет её строить, вот что я считаю главным:

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

Агентная разработка — это не про то, чтобы заменить инженеров. Это про то, чтобы убрать из процесса ожидание и неопределённость и отдать людям ту работу, где они действительно нужны. В моём опыте именно так получается кратно сократить TTM и не заплатить за это качеством.

Если хотите обсудить, как это устроено на практике, — пишите в Telegram @pp_java.