Как управлять 30 AI-агентами: Повышение продуктивности кодинга в 10 раз с Gastown

Эра простых чат-ботов, у которых вы спрашиваете код и ждете ответа, подошла к концу. Claude Code или GitHub Copilot — отличные помощники, но они слишком медленны и линейны для внесения изменений в корпоративные системы, где переплетаются сотни файлов. Доверять всё одному AI, который теряет контекст и путается при длительных сессиях, теперь является лишь узким местом в производительности.

Наступила эпоха оркестрации агентов. Open-source проект Gastown, предложенный Стивом Йегги (Steve Yegge), нацелен на создание системы «фабрики кода», которая одновременно запускает более 30 AI-агентов для декомпозиции функций и параллельной сборки. Теперь вы должны быть не просто кодером, а оркестратором, командующим целой армией AI.

Архитектура Gastown: Идеальный результат от ненадежных исполнителей

Gastown — это не просто обертка над AI. Он использует принципы распределенных вычислений, чтобы решать проблему нестабильности отдельных агентов через структуру системы. Ключ заключается в четком разделении ролей и дроблении задач на атомарные единицы.

• Мэр (Mayor): Центральный координатор всей системы. Анализирует цели разработчика и разбивает их на мелкие рабочие единицы — биды.
• Бид (Bead): Перманентные данные об 이슈 (issue), подкрепленные Git. Это критически важный механизм, сохраняющий историю работы, даже если сессия агента аварийно завершится.
• Полевой кот (Polecat): Одноразовый рабочий, который вносит фактические изменения в код в независимом Git worktree. Он уничтожается сразу после завершения задачи, что предотвращает конфликты кода.

Суть этой структуры — в отказе от Vibe Coding (кодинга «на ощупь»). Gastown физически блокирует агентам возможность прямого коммита в основную ветку через систему хуков PreToolUse. Весь код пишется в отдельных фича-ветках и интегрируется только после прохождения строгой проверки тестами в «рафинерии» (Refinery).

Стратегия развертывания агентов в зависимости от масштаба проекта

Бросать десятки агентов на любую задачу — это пустая трата бюджета на API. Мощность должна распределяться грамотно, в зависимости от сложности задачи.

При масштабных миграциях использование 30 агентов сокращает задачу, которая заняла бы 6 часов ручного труда, до примерно 20 минут. Однако это требует оптимизации распределения моделей. Поручите высокопроизводительные модели, такие как Claude 3.5 Sonnet, Мэру, отвечающему за проектирование, а для простых реализаций или тестов назначьте Полевым котам экономичные модели, такие как Gemini, чтобы максимизировать эффективность затрат.

Практическое применение: Руководство по созданию системы JWT-авторизации

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

1. Подключение Мэра: Начните сессию командой gt mayor attach.
2. Постановка цели: "Создай систему JWT в проекте Go. Включи изменения схемы БД, API логина, middleware и интеграционные тесты".
3. Оркестрация: "Не пиши код сам, разбей задачу и делегируй Полевым котам. Проведи ревью через Refinery".
4. Мониторинг: Проверяйте прогресс каждого агента в реальном времени с помощью gt convoy list.
5. Проверка: Проверьте финальный результат, объединенный Refinery, через gt status и утвердите его.

Если работа идет не гладко, сначала проверьте окружение. Критически важно убедиться, что версия Dolt не ниже 1.82.4. Старые версии вызывают ошибки синхронизации базы данных Git, что ведет к конфликтам между агентами. Также, если есть проблемы с запуском демона, проверьте через tmux -V, что версия выше 3.0, и выполните gt doctor --fix для инициализации среды.

Новая роль старшего инженера: Системный архитектор

Запуск 30 AI-агентов одновременно означает, что вы больше не печатаете код вручную. Теперь реальное мастерство инженера заключается в том, насколько детально он фиксирует архитектурные решения в руководствах, таких как CLAUDE.md.

Агенты — прекрасные помощники, но без должного управления они подобны сверхразумным шимпанзе, способным парализовать систему. Обязательно запускайте их в изолированных экспериментальных стендах (Rig) и устанавливайте лимиты на расходы API. Чтобы не устать от проверки десятков PR вручную, назначьте дополнительного агента на роль «шерифа PR», который будет фильтровать синтаксические ошибки и непройденные тесты на первом этапе. Ваша фабрика программного обеспечения готова к запуску.