BMAD + Beads + Gas Town: Как собрать «Святую Троицу» AI-разработки и перестать кодить вручную (но это не точно) Вы уже видели скриншоты: десятки терминалов, работающих параллельно, агенты, которые сами пишут код, тестируют и мерджат. Это не магия, это оркестровка. Многие пытались повторить это, подключая агентов к Jira или Trello, но спотыкались о главную проблему: контекст. Агенты «забывают», что делали час назад, а статические задачи в таск-трекере не отражают сложную логику зависимостей. Сегодня разберем, как объединить три мощнейших инструмента в одну систему, которая работает как часы. 🏗 BMAD (Архитектор) 📿 Beads (Память) 🏙 Gas Town (Фабрика) Зачем нам три инструмента? Представьте, что вы строите дом. BMAD - это архитектор и прораб, которые решают «Что строить и почему?». Они создают чертежи (PRD), планируют этапы и следят за стандартами. Beads - это строительный журнал и склад в одном. Здесь хранятся все записи: «Что уже сделано? Что заблокировано? Где лежат кирпичи?». Это память, которая не исчезает после перезагрузки агента. Gas Town - это бригада рабочих и мастерская. Это станки, которые «делают работу». Они берут чертежи, смотрят в журнал и строят стены параллельно, не мешая друг другу. По отдельности они хороши, но вместе - это AI-фабрика. Flow рабочего процесса Шаг 1: Планирование (BMAD) Вы начинаете как обычно. Запускаете BMAD. Агенты (Аналитик, PM, Архитектор) генерируют документацию: PRD, архитектуру, списки эпиков. Ключевой момент: BMAD не просто создает markdown-файлы. Теперь эти артефакты становятся сырьем для Beads. Шаг 2: Кристаллизация задач (Beads) Это мостик между планом и исполнением. Вам (или специальному агенту-секретарю) нужно конвертировать планы BMAD в задачи Beads. Пример сценария: BMAD-агент создал эпик «Система авторизации». Вы преобразуете его в Beads: bd create "Auth System" --type epic -p 0 BMAD-агент разбил эпик на истории? Переносим их: bd create "Login Page" --type story --parent <epic-id> bd create "Password Reset" --type story --parent <epic-id> Зачем это нужно? Потому что Gas Town не понимает markdown-планы. Он понимает граф задач с зависимостями. Beads превращает ваши красивые документы в машинно-читаемую структуру. Шаг 3: Запуск производства (Gas Town) Теперь в дело вступает оркестратор. Mayor (Мэр) - главный агент Gas Town - опрашивает Beads: bd ready --json Он получает список задач, которые не заблокированы и готовы к работе. Convoy (Конвой) - Мэр объединяет задачи в пачку (конвой) для параллельной обработки: gt convoy create "Sprint 1" bd-abc12 bd-def34 Polecats (Рабочие) - создаются изолированные среды (worktrees) для каждой задачи: gt sling bd-abc12 my-project Агент начинает писать код в своей ветке, имея доступ к контексту задачи из Beads. Шаг 4: Слияние и контроль (Refinery & Witness) Пока Polecats пишут код, другие агенты следят за процессом: Refinery решает конфликты слияния, аккуратно внося изменения в main. Witness следит за «зависшими» задачами и помогает агентам, если они застряли. После успешного слияния статус задачи в Beads меняется на Closed, и BMAD-документация может быть автоматически обновлена. 🧠 В чем фишка такой связки? 1. Решение проблемы «Контекстного окна» Обычно агент «забывает» задачу, как только закрывает терминал. С Beads состояние хранится в git-backed базе данных. Gas Town перезагружает агентов, но они «помнят», на чем остановились, потому что читают состояние из Beads. 2. Разделение труда BMAD фокусируется на спецификациях (SDD - Spec Driven Development). Gas Town фокусируется на операционной деятельности. Это две разные парадигмы: BMAD имитирует человеческую иерархию (Аналитик → PM → Дев). Gas Town имитирует заводской конвейер (Мэр → Рабочий → Контролер). Вместе они закрывают весь цикл: от идеи до готового кода. 3. Масштабирование Один агент - это медленно. Gas Town позволяет запускать 20-30 агентов параллельно. Beads гарантирует, что они не наступят друг другу на пятки, правильно распределив зависимости. 👇