Ein Agent ist nett.
Neun sind ein Team.

Entwicklerarbeit in mehreren Projekten — orchestriert mit herdr

Susi MoogTYPO3camp Berlin · 30 Minuten

Ausgangslage

Neun Projekte, ein Backlog

MR-Reviews — 3 offen
Composer-Updates — 4 testen, mergen
Projekt-Scaffolds — mit CI
Content-Strukturen & Seeder — TCA, Templates
wöchentliche Update-Runde — 9 Repos, freitags

Das Werkzeug

herdr — ein Terminal-Workspace-Manager

Workspaces → Tabs → Panes
erkennt Coding-Agenten — 22 Agent-CLIs: claude, codex, cursor, pi …
Lebenszyklus als API — nicht Screen-Scraping

herdr.dev

Agent-Zustand

Vier Zustände, als API-Ergebnis

working idle blocked done

idle → wartet auf den nächsten Auftrag
blocked → Agent fragt — ich entscheide
done → Ergebnis liegt in der Datei

Steuerung

Eine kleine API pro Agent

herdr agent start a11y --kind pi --pane <id>
herdr agent prompt a11y "<auftrag>"
herdr agent wait a11y --until done
herdr agent read a11y

Abgrenzung

herdr-Agenten vs. Subagenten

Subagent

innerhalb meiner Session
Ergebnis füllt meinen Kontext
erbt Modell & Regeln
gebunden an meine Laufzeit

herdr-Agent

eigene Session, eigenes cwd
eigene Projekt-AGENTS.md
beliebiger Agent-Typ je Pane
Zustand & Ausgabe als API

Feature

Git-Worktrees pro Agent

talk-Repo

eine Codebasis, ein Remote

wt-talk-a11y

Agent a11y
Kontraste gegen WCAG 2.1 AA

wt-talk-script

Agent scripter
Sprechskript überarbeiten

herdr worktree create --branch wt-talk-a11y

Weitere Features

Maschinen, Benachrichtigungen, Handy

Maschinen-Forwarding — dieselben Befehle über SSH auf entfernter Maschine
Notifications — herdr notification show, wenn ein Agent fertig ist oder fragt
Vom Handy — per SSH, z. B. mit Moshi: die ganze TUI unterwegs bedienen

Drei Dinge, die aus dem lokalen Werkzeug etwas Größeres machen: Maschinen-Forwarding: herdr steuert über SSH verbundene Maschinen — gleiche Befehle, entfernter Rechner. Ich leite so meine Befehle an meine zwei Demo-Maschinen weiter — der Agent arbeitet direkt dort, wo das jeweilige Projekt läuft. Notifications: herdr notification show meldet sich, wenn ein Agent fertig ist oder auf eine Freigabe wartet. Vorher habe ich zwanzig Minuten auf neun Terminals gestarrt und den einen Moment trotzdem verpasst — heute werde ich gerufen, wenn es etwas zu entscheiden gibt. Und ich muss dafür nicht am Schreibtisch sitzen: Ich verbinde mich vom Handy per SSH — zum Beispiel mit Moshi — und bediene das Ganze von dort. Dieselbe TUI, dieselben Agenten. Wenn mich unterwegs eine Notification ruft, antworte ich direkt vom Handy.

Weitere Features

Was herdr sonst noch kann

Läuft weiter

Hintergrund-Server — Agenten laufen weiter, wenn die Verbindung weg ist
Sessions — detach, reattach, Restore, Agent-Resume
Live-Handoff — herdr update --handoff, ohne Agenten zu stoppen

Passt sich an

Plugins — eigene Workflows mit Manifest & Event-Hooks
Maus oder ctrl+b — für tmux- und zellij-Hände
macOS, Linux, Windows — Apache 2.0

Noch ein paar Dinge, die herdr mitbringt — und die im Alltag mehr ausmachen, als man denkt. Erstens: Es läuft weiter. Die Terminals leben in einem Hintergrund-Server, nicht in meiner Shell. Verbindung weg, Terminal zu — die Agenten arbeiten weiter. Sessions kann ich trennen und wieder anhängen, und nach einem Neustart stellt herdr sie wieder her; die Agenten setzen ihre eigene Session fort. Sogar Updates gehen per Live-Handoff, ohne dass ich laufende Agenten stoppe. Zweitens: Es passt sich an. Eigene Workflows baue ich als Plugins, mit Manifest und Event-Hooks — und teilen geht über ein GitHub-Topic. Bedienen lässt es sich mit der Maus oder mit ctrl+b für alle, die tmux oder zellij in den Fingern haben. Und es läuft auf macOS, Linux und Windows, Open Source unter Apache 2.0.

Video 1 · Agenten auf Worktrees

Die Landschaft

Neun Repos, sieben Systeme

TYPO3hinter TCA — MCP: typo3-dev-companion
StrapiREST-API, maschinenlesbare Doku
PayloadREST/GraphQL, OpenAPI-Schema
PimcoreREST-API
StoryblokManagement-API + Doku-Schema
ContentfulREST/GraphQL, OpenAPI
MagnoliaREST-API

Der Sonderfall

Warum TYPO3 anders ist

Die Daten liegen hinter TCA-Definitionen — nicht hinter einem JSON-Endpunkt
Der DataHandler validiert, was reingeht — Tabelle, PID, Sprache, Versionierung
Die Konventionen stehen im Core — Translation-Domains, TCA-Formen, Changelog-Regeln

Ein reiner API-Agent weiß davon nichts — er bräuchte Schemata, Datensätze, Regeln.

MCP in Aktion

Was der typo3-dev-companion liefert

typo3_schema_lookup → Spalten & Typen hinter der TCA
typo3_record_lookup → echte Datensätze
typo3_translation_domain_lookup → Label-Referenzen wie im Core
typo3_changelog_lookup "14" → Deprecations je Version
typo3_forge_lookup / _gerrit_lookup → offene Issues & Patches

herdr orchestriert die Agenten — MCP macht sie wirksam.

Video 2 · Die Update-Runde, parallel

Resultat

Die Update-Runde in Zahlen

9Repos · 2 Batches (5 + 4)

60 minvorher, nacheinander

11 minheute, gesamt

4,5 mindavon aktiv

Max. 5 parallele Prompts — ein API-Limit, nicht eines von herdr.

Der Workflow

Ein Agent pro Aufgabe

ein Agent pro Aufgabe — Review, Update, Scaffold, Seeder
Batches von 5 — dann die nächsten
Ergebnis in eine Datei — Antworten sind keine Schnittstelle
Audit bei mir — Berichte lesen, mergen oder liegen lassen

Qualität

Der Review-Loop: coder baut, brain prüft

coder entwickelt — Modell-Profil fürs Schreiben
brain reviewt in frischer Session — anderes Profil, ohne Entstehungskontext
Befunde zurück an coder — berechtigt → Fix, unberechtigt → Begründung
Orchestriert mit herdr — ich kann in jede einzelne Session eingreifen

herdr agent prompt brain "Reviewe den letzten Commit …"

Video 3 · Der Review-Loop in Aktion

Video 3, 57 Sekunden: der Review-Loop am Repo dieses Talks. Die Steuer-Session startet coder und brain, jeder in einer eigenen Session. 0:00 — agent start brain mit --model brain: zweites Modell-Profil, eigene Session. ⏸ ~0:16 — coder hat die Kontraste geprüft: alles schon AA-konform. Er committet bewusst nichts, statt einen Fix vorzutäuschen. ⏸ ~0:24 — Rechts brains Review des letzten Commits als nummerierte Liste; links prüft coder jeden Befund gegen den aktuellen Stand. ~0:32 — Vorschlag „Historie umschreiben“: abgelehnt, mit Begründung — drei Worktrees arbeiten parallel auf dem Repo. ~0:40 — Ein Teil war berechtigt: toter Code, ein Player, den nichts mehr lädt — gelöscht. Ein Teil war schon erledigt. So soll es laufen: nicht alles annehmen, nicht alles ablehnen.

Stolpersteine

Was schiefgeht

Concurrency-Limit 5 — Agent Nr. 6 bekommt ein 429
Pane-Output — keine Schnittstelle; Dateien, immer Dateien
unvorsichtige Agenten — machen echte Git-Historie; Regeln in der AGENTS.md
paralleles Fehlverhalten — falscher Kontext × 9 = 9 falsche Ergebnisse

Qualität

Meine Quality Gates

Test-first, wörtlich — Test reproduziert den Bug, rot gesehen, dann Produktionscode
Unit-Tests immer — Vitest/Jest für TypeScript, PHPUnit für PHP
Playwright pro Umgebung — lokal in ddev und auf jedem Zielserver
Coverage misst nicht Prüfung — 98 % sagen nichts über die Assertions
Stop-Punkte beim Menschen — Push, Merge, Audit: meine Entscheidung

Weil parallele Agenten auch parallel fertig werden, brauche ich Quality Gates. Erstens Test-first, und zwar wörtlich: Jeder Bugfix beginnt mit dem Test, der den Bug reproduziert. Ich sehe ihn rot, erst dann fasse ich Produktionscode an. Der Test ist der Vertrag, der das Modell an die Realität bindet. Unit-Tests immer: Vitest und Jest für TypeScript, PHPUnit für PHP. Verändertes Verhalten ohne Test geht nicht raus, auch nicht aus einem Agenten. Fürs Frontend Playwright, mit einem Project pro Umgebung: lokal in ddev und auf jedem Zielserver. Smoke-Tests prüfen das Deployment, Task-Tests das Ergebnis redaktioneller Änderungen. Coverage ist dabei kein Maß: 98 Prozent sagen nichts über die Assertions. Und die Stop-Punkte bleiben bei mir: Push und Merge entscheide ich — eine frühere Freigabe gilt nicht für neue Commits. Mehr Prozess braucht eine Person mit neun Agenten nicht.

Verträge

Was in meiner AGENTS.md steht

Commit-Identität pro Remote — per Repo-Config, nie per --author
glab statt curl — MRs, Pipelines, API über ein Werkzeug
Worklog pro Aufgabe — eine Zeile in ~/worklog, vom Agenten gepflegt
herdr-Regeln — ein Agent pro Projekt, Pane-IDs aus der JSON-Antwort, Batches von 5

Fazit

Drei Sätze

Orchestrierung über Schnittstellen, nicht über Intelligenz — Zustand, Prompt, Ausgabe
Worktrees für Parallel-Arbeit — ein Agent pro Branch, eine Codebasis
Die Verträge schreibt man selbst — AGENTS.md, Limits, Audit

Ausblick

Über den Code hinaus: Worklogs automatisch

~/worklog

was die Agenten pro Aufgabe notieren

Exchange-Kalender

Termine, per Sync

Microsoft Copilot

Chats

→

custom MCP
+ herdr-Agent

selbst gebaut

→

Worklog

Basis der Zeiterfassung

Dasselbe Muster: herdr orchestriert, MCP macht wirksam — diesmal für den Arbeitsalltag.

Ausblick

Gleiches Muster für Ticketsysteme

der gesamte Workflow — vom Ticket bis zum MR
Zugriff über API oder custom MCP — wie bei den CMS: API, wo sauber; MCP, wo nötig
Tickets lesen — Kontext für den Agenten vor dem Start
kommentieren & pflegen — der Agent schreibt zurück ins Ticket

Euer Start

Neun sind ein Team. Fangt mit drei an.

1herdr installieren — herdr.dev
2drei separate Tickets, drei Worktrees — je ein Agent, je ein Branch
3Der Merge-Button bleibt eurer — drei Agenten arbeiten, die Teamleitung seid ihr

Danke! · Slides: talk.shinyhappypages.de/t3camp2026 · look@susi.dev
Entwicklerin bei team neusta · team-neusta.de

Ein Agent ist nett.Neun sind ein Team.

Ausgangslage

Neun Projekte, ein Backlog

Das Werkzeug

herdr — ein Terminal-Workspace-Manager

Agent-Zustand

Vier Zustände, als API-Ergebnis

Steuerung

Eine kleine API pro Agent

Abgrenzung

herdr-Agenten vs. Subagenten

Feature

Git-Worktrees pro Agent

Weitere Features

Maschinen, Benachrichtigungen, Handy

Weitere Features

Was herdr sonst noch kann

Video 1 · Agenten auf Worktrees

Die Landschaft

Neun Repos, sieben Systeme

Der Sonderfall

Warum TYPO3 anders ist

MCP in Aktion

Was der typo3-dev-companion liefert

Video 2 · Die Update-Runde, parallel

Resultat

Die Update-Runde in Zahlen

Der Workflow

Ein Agent pro Aufgabe

Qualität

Der Review-Loop: coder baut, brain prüft

Video 3 · Der Review-Loop in Aktion

Stolpersteine

Was schiefgeht

Qualität

Meine Quality Gates

Verträge

Was in meiner AGENTS.md steht

Fazit

Drei Sätze

Ausblick

Über den Code hinaus: Worklogs automatisch

Ausblick

Gleiches Muster für Ticketsysteme

Euer Start

Neun sind ein Team. Fangt mit drei an.

Ein Agent ist nett.
Neun sind ein Team.