Pepper-orchestrator собрал три пакета за 1 час 52 минуты без ручного кода

Один ИИ-агент неплохо собирает прототип, пока весь проект помещается у человека в голове. Дальше начинается знакомая боль: изменение API затрагивает соседний репозиторий, два исполнителя правят общий файл, а тесты подтверждают ровно те предположения, с которыми был написан код. Автор студии ITSalt Максим Никитин предлагает решать это не увеличением промпта, а разделением ответственности.

Его плагин pepper-orchestrator для Claude Code и Codex превращает большую цель в программу из небольших пакетов работ. Каждый пакет получает собственный контекст, ветку или рабочую копию, разрешённые пути, зависимости и проверяемые критерии приёмки. Сам оркестратор код модулей не пишет: он хранит общую картину, определяет порядок запуска и передаёт результат независимому рецензенту.

Как это выглядит на простом кейсе

В демонстрации требовалось собрать приложение для специалиста по закупкам. Пользователь загружает текстовые договоры и получает таблицу с номером, поставщиком, суммой и сроком поставки. В документах специально оставили ловушки: рядом с ценой стоял аванс, лимит «не более 600 000 рублей» выглядел как итоговая сумма, а срок оплаты можно было принять за срок поставки.

Оркестратор разложил работу на три пакета: движок разбора документов, интерфейс с дизайн-системой и пояснительную записку. Независимые части отправились в отдельные копии репозитория. Общие файлы должны были изменяться последовательно, поэтому пересечения стали видны ещё до начала работы, а не во время слияния.

Через 1 час 52 минуты все три пакета формально были закрыты. Автор при этом не писал код вручную, а принимал продуктовые решения и разрешал спорные действия. Это важное уточнение: речь идёт не об автономной фабрике софта, а о системе, где человек остаётся владельцем программы, контролирует права, слияние и публикацию.

Почему зелёных тестов оказалось мало

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

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

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

Где подход действительно полезен

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

Есть и ограничение доказательности: цифры получены автором плагина на собственном кейсе, без сравнения с обычной разработкой и без независимого замера качества. Поэтому 1 час 52 минуты нельзя считать универсальной метрикой ускорения.

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