Drei Coding-Agenten, ein Java-Projekt. Ein Blick auf biomelab.

Zwei oder drei Coding-Agenten gleichzeitig laufen zu lassen ist inzwischen normal. Den Überblick zu behalten, welcher gerade was tut, ist es nicht. Manuel de la Peña war zu Gast, um biomelab, sein Open-Source-Dashboard genau für dieses Problem, zum ersten Mal auf meiner Maschine zu installieren. Danach haben wir drei Agenten gleichzeitig auf ein echtes Java-Projekt losgelassen, um zu sehen, ob es hält.

Co-Speaker

Manuel de la Peña

Staff Software Engineer bei Docker, Docker-Sandboxes-Team bei Docker

Core-Maintainer von testcontainers-go und Schöpfer von biomelab, einem Open-Source-Desktop-Dashboard für git worktrees und die darin laufenden Coding-Agenten. Seit 2011 in Open Source unterwegs, erst in Java, dann Go, jetzt bei Docker nach der Übernahme von AtomicJar, dem Startup hinter Testcontainers.

GitHubLinkedInXBluesky

Ein Dashboard für eine ganze Agenten-Flotte

Manuels Problem war simpel und bekannt: zu viele Terminal-Tabs, zu viele VS-Code-Fenster, kein einziger Ort, an dem sichtbar war, welcher Agent gerade woran arbeitete. Also baute er biomelab, ein tastaturgesteuertes Dashboard, das links alle registrierten Projekte auflistet und rechts die git worktrees des gewählten Projekts als Karten zeigt.

Der Name ist wörtlich gemeint, und geliehen. Biome war Dockers eigener interner Arbeitstitel für Docker Sandboxes, Manuels Team, bevor das Produkt unter seinem offiziellen Namen erschien. Er behielt ihn für sein eigenes Tool: ein Lab, in dem diese kleinen, isolierten Ökosysteme wachsen, eines pro Agent. Es ist MIT-lizenziert, und der Betrieb mit Docker Sandboxes braucht nicht mehr als einen kostenlosen Docker-Login.

Main bleibt unangetastet

Das ganze Tool ist um eine Regel herum gebaut. Jede Aufgabe bekommt ihre eigene Worktree, erzeugt mit einem einzigen Tastendruck, sodass nie versehentlich etwas auf main landet.

Ich fasse main nie an.

Das ist keine Disziplin, an die Manuel sich erinnern muss. Es ist strukturell verankert: main ist die große Karte an der Wurzel der Projektansicht, alles andere sind Worktrees, und ein Kanban-Board (umschalten mit g) verfolgt jede davon durch fünf Zustände, von "erstellt" bis "gemerged".

Eine Sandbox, nicht eine pro Worktree

Hier lag ich vorher falsch: Ich hatte angenommen, jede Worktree läuft in ihrer eigenen isolierten microVM. Tut sie nicht. Pro Projekt läuft eine Docker Sandbox, und jede Worktree-Session eines Agenten lebt in genau dieser einen Sandbox, unterschieden nur durch den Dateisystempfad.

Enlarge

100%−+

Manuels Begründung ist praktisch, keine architektonische Reinheit: Eine microVM startet in Millisekunden, aber eine pro Worktree mit jeweils mehreren GB RAM und mehreren zehn GB Speicher skaliert auf einem Laptop nicht. Der Preis dafür: Worktrees sind nicht stark voneinander isoliert, was mit ein Grund ist, warum Manuel regent erkundet, ein separates Tool, das Agenten-Gespräche auf einem eigenen Git-Branch aufzeichnet, als geteiltes Gedächtnis zwischen Sessions, die sonst nicht miteinander reden können.

Was auf Sendung schiefging

Es lief nicht glatt, und das ehrlich zu sagen gehört dazu. biomelab steht noch bei v0.7.0, weit von einem stabilen Release entfernt, ein guter Teil dessen, was jetzt kommt, gehört einfach zu diesem Stadium dazu.

Die erste Worktree-Erstellung scheiterte komplett: Das Demo-Repo hatte noch keinen initialen Commit, also gab es kein main, von dem aus man hätte branchen können (Issue #80). Diese Lücke hat Manuel in biomelab selbst nach der Session behoben.

Dann, speziell auf meiner Maschine, öffnete sich beim Öffnen eines Worktree-Terminals das Fenster und schloss sich sofort wieder, immer und immer wieder, und blockierte jeden Fortschritt (Issue #81). Das ist ein Windows-spezifischer Bug in biomelabs Terminal-Fokus-Handling. Auf Manuels Maschine trat er kein einziges Mal auf, und genau dorthin sind wir gewechselt: Wir haben mein Setup komplett aufgegeben und den Rest der Session von seinem Bildschirm aus bestritten. Ich habe live gewitzelt, dass sie sich den falschen Typen für eine Live-Demo ausgesucht hätten, und ich hatte recht damit. Eine mildere Version desselben Bugs tauchte auch dort noch auf: Enter zu drücken öffnete manchmal ein neues Terminal statt das bereits laufende zu fokussieren, ein Bug, den Manuel live während des Streams meldete (Issue #84).

Auch das Mergen ist noch nicht verdrahtet: biomelab öffnet Pull Requests, kann sie aber nicht mergen, also wurde der erste PR direkt auf GitHub gemerged statt aus dem Dashboard heraus (Issue #83).

Später scheiterte auch mein erster Pull Request beim Push, weil der Git-Remote der Sandbox auf SSH stand und ich das Signing-Kit für dieses Repo nicht installiert hatte. Ich habe Claude einfach gesagt, den Remote auf HTTPS umzustellen, und er hat es richtig gemacht, ohne dass ich selbst einen Git-Befehl angefasst habe.

Drei Agenten, ein Java-Projekt

Nach den ersten Kanten haben wir eine kleine Spring-Boot-App registriert, die deutsche Katastrophenereignisse trackt, und sie wirklich laufen lassen: ein Scaffolding-Agent baute die App, ein zweiter Agent entwarf einen "Product Owner"-Skill, dann arbeiteten drei weitere Agenten parallel je ein eigenes GitHub-Issue ab, alle in derselben Sandbox.

Docker Sandboxs Netzwerk-Policy erwischte einen davon mitten im Lauf und blockierte per Deny-all-Standard eine ausgehende Anfrage an Maven Central. Bemerkenswert war nicht der Block selbst, sondern dass der Agent selbst erkannte, wo er lief, und aktiv darum bat, die Anfrage freizugeben, bevor er weitermachte.

Das ist perfekt, weil er einen gewissen Kontext davon hat, was eine Sandbox ist.

Wir haben die Anfrage freigegeben, die Aufgabe war fertig, und die Tests des gemergten Pull Requests liefen durch. Zwischendurch habe ich live eine Idee eingebracht: Ein Agent, der schon in einer Worktree läuft, soll biomelab selbst anweisen können, mehrere weitere zu erzeugen, eine pro Issue, statt dass ein Mensch das von Hand macht. Manuel gefiel die Idee so gut, dass er dafür live, mitten im Gespräch, ein GitHub-Issue eröffnete.

Kein Kollaborations-Tool

Das ist der eigentliche Punkt. GUI-Tools zum Verwalten von Coding-Agenten gibt es längst, und die meisten KI-Anbieter liefern inzwischen ihre eigenen: GitHub Copilot hat eine App mit einer ähnlichen Projektliste, und andere Anbieter haben ihre eigenen Session-Ansichten. Der Unterschied bei biomelab ist, dass es egal ist, welchen Harness man nutzt. Es ist um die Worktree herum gebaut, für Isolation an Docker Sandbox angebunden, und funktioniert unabhängig davon, ob der Agent darin Claude, Codex oder etwas ganz anderes ist.

Was es ausdrücklich nicht ist: ein Kollaborations-Tool. Es läuft auf einer Maschine, verfolgt die Aufgaben einer Person, und koordiniert nichts im Team. Wenn deine Arbeit ohnehin schon in der Cloud läuft, brauchst du es vielleicht nicht, und Docker Sandbox vielleicht auch nicht. Aber wenn du lokal arbeitest und eine Agenten-Flotte willst, die nicht an die Desktop-App eines einzigen Anbieters gebunden ist, ist genau dafür das Tool gebaut.

Fazit

Wenn du bereit bist, ein bisschen zu experimentieren, und eine leichtgewichtige Art suchst, Coding-Agenten lokal zu orchestrieren, ist das einen Versuch wert. Es ist Open Source, und Lücken, die du findest (eine hat Manuel selbst live, mitten in der Aufzeichnung, behoben), sind nur einen Pull Request oder ein Issue entfernt.

Eine der Sachen, die ich in dieser KI-Welt gelernt habe: Man muss erkunden. Übernimm kein Tool nur, weil es gerade jemand promotet. Erkunden, experimentieren, selbst machen, scheitern, und wenn das, was du zum Lernen der Grundlagen baust, nicht funktioniert, nimm etwas anderes.

Nützliche Links

• biomelab.dev
• Docker Sandbox Docs
• regent, geteiltes Agenten-Gedächtnis über git