🔄 SwarmForge от Дяди Боба

Uncle Bob (автор книги Clean Code) выкатил свой агентный оркестратор для разработки: локальная связка tmux, git worktree, Babashka-скриптов и файловой "почты" между агентами.

Самое необычное - проект разложен по веткам. main хранит документацию и общие скрипты, а рабочие флоу лежат отдельно:

- two-pack - быстрый цикл coder -> cleaner -> coder
- four-pack - спецификация, код, рефакторинг, архитектура
- six-pack - полный конвейер specifier -> coder -> cleaner -> architect -> hardender -> QA
- adversaries - отдельный цикл coder <-> reviewer, где ревьюер гоняет кодера до approval

Каждая роль запускается как отдельный агент в своей tmux-сессии и своем git worktree. В конфиге можно выбрать CLI для роли: codex, claude, copilot, grok. По умолчанию примеры идут на Codex.

Интересная часть - handoff-протокол. Агенты не шлют друг другу длинные сообщения в чат. Они кладут маленькие типизированные файлы в outbox: git_handoff, note, awake. Демон проверяет формат, раскладывает задачи по inbox получателей и будит нужную tmux-сессию.

По сути это не "рой агентов, которым дали общий промпт", а инженерный конвейер с ролями, очередями, коммитами, приоритетами и аудитом.

В полном six-pack чувствуется почерк Дяди Боба: Gherkin-спеки, TDD, acceptance tests, CRAP/DRY, mutation testing, архитектурные границы, финальная QA-проверка через пользовательский интерфейс.

Клевая идея рабочих деревьев под роли, а не под задачи. Агент не просто берет тикет, он живет в своей профессиональной зоне ответственности: спецификация, код, чистка, архитектура, харденинг, QA.

Интересно взглянуть на первый коммит в репозитории. Там есть md файлы, которые описывают принципы работы и разработки самого SwarmForge, для понимания, что сувать в контекст агента для кодинга, полезно.
📎 Перевод MD файлов из коммита

Как образец агентного SDLC с жесткой инженерной дисциплиной - репозиторий очень любопытный.

Чат

Очень много инфы появляется про лупы. Это топ 4 за последние дни:

📎Самоулучшающийся Kimi-сворм: 300 агентов, проверка Opus и цикл без ручного аудита

Для тех, кто экспериментирует с multi-agent research, Kimi, дешевыми массовыми прогонами и отдельной verifier-моделью. Внутри: как писать спецификацию для сворма, читать план декомпозиции до запуска, получать файлы вместо ответа в чате, прогонять результат через Opus-проверку и превращать ошибки в постоянные правила для следующих запусков.

📎Loop Engineer: как строить агентные циклы, которые работают без ручного промптинга

Для фаундеров, growth-команд и разработчиков, которые хотят запускать агентные процессы вокруг бизнеса: support, SEO, product growth, ads. Главная инфа - как устроить общий слой артефактов, контрактов и логов, чтобы разные циклы читали выводы друг друга и накапливали рабочую память компании.

📎От промптов к loop engineering: как проектировать циклы для кодинг-агентов

Для тех, кто уже пользуется Claude Code, Codex или другими кодинг-агентами и хочет перейти от ручных запросов к повторяемым циклам. Внутри: 6 частей хорошего loop - триггер, изоляция, записанный контекст, доступ к инструментам, независимая проверка и состояние на диске. Плюс примеры PR-babysitter, /goal, лимиты, стоимость и случаи, когда loop лучше не запускать.

📎Архитектура агентных циклов: loop, skill и устойчивая оркестрация

Для тех, кто думает о production-агентах: фоновые процессы, ретраи, очереди, субагенты, наблюдаемость и восстановление после падений. Аагентный loop должен жить поверх устойчивой оркестрации: каждый шаг сохраняется, ошибки повторяются с нужного места, события не теряются, а dev утром видит все запуски, inputs, outputs и ретраи.

Чат

Looper (188 ⭐️) - скилл, который помогает спроектировать loop до запуска.

Если плохо описать /goal или /loop, агент быстро сожжет токены и будет уверенно крутиться вокруг плохой задачи. Looper добавляет шаг - сначала собирает нормальный цикл, потом отдает его Claude Code или другому агенту.

Вы запускаете /looper, а он интервьюирует вас по ключевым частям:
🔵 цель и контекст
🔵 что считается готовым результатом
🔵 проверки: команда, модель-судья или человек
🔵 отдельный reviewer/судья, например Claude проверяет работу Codex
🔵 лимиты по итерациям, времени, токенам и “нет прогресса”
🔵 файлы состояния: state.json, run-log.md, loop.yaml, RUN_IN_SESSION.md

Loop становится видимым артефактом. Его можно прочитать, поправить, переиспользовать, закоммитить и только потом запускать.

чат

Как AI-агенты учатся после каждого запуска 😘

Обычно все смотрят на модель и веса. Но в продуктах быстрее работают другие слои: harness, проверки, память, навыки и действия пользователей.

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

Разбор Karpathy AutoResearch, SEAL, AlphaEvolve, Hermes, OpenClaw, Anthropic Skills и AG-UI в одной статье:

📎 Как AI-агенты учатся на практике

чат

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

В 📎статье показано, как Google Agents CLI пытается собрать это в один процесс: установка skills для coding agent, сборка RAG-агента, локальные проверки, eval suite, развертывание в Agent Runtime и публикация в Gemini Enterprise.

Если делаете внутренних ассистентов, RAG или агентов на ADK, это хороший пример того, как довести прототип до сервиса для команды.

чат