Agentisches Engineering

SwarmForge: Was der Agentenschwarm von Uncle Bob richtig macht

SwarmForge betreibt mehrere KI-Coding-Agenten in tmux-Fenstern, jeden in einem eigenen Git-Worktree und mit genau einer Engineering-Rolle. Das Tooling ist bewusst langweilig. Interessant ist das Organigramm, das darin steckt.

Mit unserem KI-Engineering-Team sprechen KI-Entwicklungsleistungen ansehen

Was SwarmForge tatsächlich ist

SwarmForge ist ein Harness aus Shell und Babashka um drei Primitive, die die meisten Teams schon haben: tmux-Fenster, Git-Worktrees und Prompt-Dateien. Jedes Fenster betreibt einen Agenten in einer Rolle gegen einen eigenen Worktree unter .worktrees/, sodass zwei Agenten nie um dasselbe Arbeitsverzeichnis streiten. Das Verhalten kommt aus reinem Text unter swarmforge/roles/<role>.prompt, aufgesetzt auf eine gemeinsame constitution.prompt und ihre Artikel. Agenten tippen nicht in die Terminals der anderen, sondern stellen validierte Handoffs über .swarmforge/handoffs/ in eine Warteschlange, und die Nutzlast ist entweder eine zehnstellige Commit-Abkürzung oder eine Notiz mit maximal achtzig Zeichen. Backends werden pro Rolle gewählt, eine Session kann also Claude, Codex, Copilot und Grok mischen.

Der main-Branch ist dokumentarisch. Die lauffähigen Schwärme liegen auf den Branches two-pack, four-pack und six-pack: Sie holen sich den Branch mit der gewünschten Form und starten ./swarm. Voraussetzungen sind zsh, git, tmux, Babashka und eine konfigurierte Agenten-CLI.

Drei Schwarmformen

Jeder Branch ist eine andere Antwort darauf, wie viel Prozess eine Aufgabe verdient. Der Ablauf ist ein Ring, keine Warteschlange: Arbeit kommt zurück.

two-pack

coder → cleaner → coder

Ein coder, der test-first arbeitet, und ein cleaner für Aufräumarbeiten, CRAP- und DRY-Review sowie Architekturkorrekturen. Die kleinste sinnvolle Schleife: schreiben, dann an jemanden geben, der nicht daran hängt.

four-pack

specifier → coder → refactorer → architect → specifier

Gherkin-Akzeptanzspezifikationen stehen am Anfang. Ein refactorer räumt verhaltenserhaltend auf und erhöht die Coverage, ein architect prüft Struktur und Abhängigkeitsrichtung, bevor der Ring zur Spezifikation zurückkehrt.

six-pack

specifier → coder → cleaner → architect → hardener → QA

Ergänzt einen Hardening-Durchgang, der den Code mutiert, um blinde Flecken zu finden, und eine QA-Rolle mit ausführbarer Verifikation. Diese Form behandelt Qualität als getrennte Belange statt als guten Willen eines einzelnen Agenten.

Ein Agent, eine Disziplin

Die Rollen sind das Argument. Jede davon ist eine Aufgabe, die normalerweise derselben Person, in derselben Stunde, unter derselben Deadline aufgebürdet wird.

specifier

Schreibt Gherkin-Akzeptanzspezifikationen und QA-Prozeduren. Nichts betritt den Schwarm als vager Satz, und genau daran scheitern die meisten Agenten-Workflows unwiederbringlich.

coder

Implementiert test-first. Der Rollen-Prompt, nicht eine Richtlinienseite, die niemand liest, macht TDD zum Standardverhalten dieses Fensters.

cleaner

Lokales Aufräumen, Coverage, CRAP- und DRY-Review. Benennung und Duplikate bekommen einen eigenen Durchgang statt eines Review-Kommentars, den niemand umsetzt.

architect

Modulstruktur, Grenzen, Abhängigkeitsrichtung. Die einzige Rolle, die sich um die Form des Ganzen kümmern darf statt um das Ticket vor ihr.

Hardening-Rolle

Mutation Hardening: den Code verändern und herausfinden, wo die Testsuite blind ist. Eine negative Prüfung, bewusst erst dann, wenn der Code schon aufgeräumt ist.

QA

Ausführbare Verifikationsskripte und Benachrichtigungen. Verifikation ist etwas, das läuft und berichtet, nicht das Gefühl, dass die Änderung in Ordnung aussah.

Wie die Koordination funktioniert

Drei Dateien und drei Skripte tragen das ganze Protokoll. Genau das ist der Punkt: die Topologie ist Daten, und die Disziplin ist Text.

Die Topologie ist eine Konfigurationsdatei

conf

Jede Zeile deklariert ein tmux-Fenster: welche Rolle, welches Agenten-Backend, welcher Worktree und ob Arbeit pro Aufgabe oder in Batches entgegengenommen wird.

# swarmforge/swarmforge.conf
# window <role> <agent> <worktree> [task|batch] [extra-cli-args...]
window coordinator codex master
window coder       codex coder
window architect   codex architect

Handoffs werden validiert, nicht besprochen

Ein Agent stellt einen ausgehenden Handoff ein, die nächste Rolle nimmt Arbeit an, wenn sie frei ist, und das Abschließen ist ein expliziter Akt. Die Nutzlast ist ein Commit oder eine sehr kurze Notiz, also muss der Code die Bedeutung tragen.

# queue work for the next role: a commit, or a note of <= 80 chars
./swarm_handoff.sh coder 4f2a9c1b0d "boundary rule now specified"

# on the receiving side
./ready_for_next.sh      # accept the next item or batch
./done_with_current.sh   # close it out and free the window

Der Standard lebt im Prompt-Baum

text

Gemeinsame Artikel enthalten Engineering-Regeln, Handoff-Regeln und Workflow; in den lokalen Artikeln überschreibt ein Projekt sie. Rollen-Prompts sitzen darüber. Ihr Coding-Standard wird zur Eingabe der Arbeit statt zu einem Dokument darüber.

swarmforge/
  swarmforge.conf
  constitution.prompt
  constitution/articles/
    engineering.prompt
    handoffs.prompt
    workflow.prompt
    project.prompt
    local-engineering.prompt
    local-workflow.prompt
  roles/
    <role>.prompt

Was sich lohnt, auch ohne es zu betreiben

Jeder Durchgang bekommt einen Namen und eine Aufgabe

- Spezifikation, Implementierung, Aufräumen, Struktur und Verifikation in getrennte Durchgänge mit getrennten Anweisungen aufteilen
- Aufhören, einen Agenten oder einen Menschen alle fünf Belange gleichzeitig halten zu lassen
- Den Durchgang im Pull Request benennen, damit Reviewer wissen, welche Fragen schon beantwortet sind

Nicht nur den Branch isolieren, sondern den Arbeitsbereich

- Ein Git-Worktree pro Rolle beseitigt die ganze Fehlerklasse, in der zwei Agenten dieselbe Datei gleichzeitig ändern
- Isolation macht parallele Arbeit lesbar: jede Rolle hat einen Baum, den man unabhängig prüfen kann
- Derselbe Trick funktioniert für eine Person, die lokal mehrere Agenten betreibt, ganz ohne Schwarm

Handoffs schmal und validiert halten

- Eine Commit-Referenz plus eine kurze Zeile zwingt die Absicht in den Code und die Message
- Validierung an der Handoff-Grenze fängt eine fehlerhafte Anfrage ab, bevor die nächste Rolle einen Lauf darauf verschwendet
- Schmale Handoffs sind auditierbar: man kann rekonstruieren, wer was wann übergeben hat

Den Standard dort halten, wo die Arbeit passiert

- Engineering-Regeln als Prompt-Artikel werden bei jeder Aufgabe gelesen, im Gegensatz zu einer Wiki-Seite
- Gemeinsame Regeln von projektlokalen Overrides trennen, damit die Ausnahme eines Teams nicht zur Regel für alle wird
- Die Regeln mit dem Code versionieren und Änderungen daran wie Code reviewen

Wo die ehrlichen Einschränkungen liegen

Der Ring kostet, was der Ring kostet

Sechs Rollen, die sich gegenseitig reviewen, bedeuten mehrere Agentenläufe pro Änderung. Bei kleinen Aufgaben ist die two-pack-Schleife meist die rationale Wahl; das six-pack ist für Arbeit, deren Fehler teuer wären.

Achtzig Zeichen sind ein enges Rohr

Die winzige Handoff-Nutzlast ist eine Disziplin: der Commit muss sich selbst erklären. Sie bedeutet aber auch, dass das gemeinsame Verständnis des Schwarms vollständig in Spezifikationen und Code liegt. Wenn Ihr Code sich nicht selbst erklärt, behebt der Schwarm das nicht für Sie.

Rollen sind Prompts, keine Garantien

Ein Prompt, der TDD verlangt, ist ein starker Hinweis, aber kein Durchsetzungsmechanismus. Was wirklich hält, ist ausführbar: der Testlauf, der Mutationslauf, das QA-Skript. Halten Sie diese in der CI, nicht nur im Schwarm.

Jemand zeichnet weiterhin ab

Die Ausgabe des Schwarms ist ein Änderungsvorschlag, keine Release-Entscheidung. Verantwortung verteilt sich nicht über tmux-Fenster, und die Arbeit der Reviewer wird schwerer, nicht leichter, wenn die Menge plausiblen Codes steigt.

Der Workflow ist der Beitrag

Nimmt man tmux, Babashka und die Tarball-Installation weg, bleibt eine These über Software-Engineering: die Disziplinen, die Code bewohnbar halten, sind trennbar, und jede verdient ihren eigenen Durchgang mit ihren eigenen Anweisungen. Diese These galt schon vor Agenten, und genau deshalb lässt sie sich übertragen.

Lesen Sie es als Referenzimplementierung, nicht als Plattform. Übernehmen Sie die Rollenaufteilung, die Worktree-Isolation und den validierten Handoff, und Sie bekommen den größten Teil des Nutzens, ob die Arbeit von sechs Agenten, zwei Menschen oder je einem erledigt wird.

FAQ

Was braucht man, um SwarmForge zu betreiben?

zsh, git, tmux und Babashka sowie eine konfigurierte Agenten-CLI wie Claude, Codex, Copilot oder Grok. Es gibt keinen Cloud-Dienst und keine Orchestrierungsschicht aufzusetzen: der Schwarm besteht aus tmux-Fenstern, die man beobachten kann, mit einem Worktree pro Rolle auf der Platte.

Mit welchem Branch sollte ein Team starten?

two-pack. Zwei Rollen reichen, um zu spüren, ob die Handoff-Disziplin zu Ihrer Arbeit passt, und die Kosten eines vollen Rings aus sechs Rollen sind vorher schwer zu rechtfertigen.

Erübrigt ein Agentenschwarm die QA?

Nein. Er verlagert QA in eine benannte Rolle mit ausführbaren Skripten, was besser ist, als sie implizit zu lassen, aber die Verifikation muss weiterhin jemand schreiben, der versteht, was das Produkt seinen Nutzern schuldet.

Ist das produktionsreife Orchestrierung?

Behandeln Sie es als Workflow-Referenz, nicht als betriebene Plattform. Der dauerhafte Wert liegt in der Aufteilung der Engineering-Belange und im schmalen Handoff-Protokoll, und beides lässt sich unabhängig von den Shell-Skripten übernehmen.