Wie wir Coding-Agenten wie ein kleines Team führen: Planung als Markdown-Board im Repository, Subagenten mit eng geschnittenem Kontext, Skills als wiederholbare Prozeduren und Hooks als feste Leitplanken.
Die meisten Teams starten Agentic Coding als einen langen Chat. Ein Fenster, eine Aufgabe, immer mehr Kontext. Nach zwanzig Schritten hat der Agent den ursprünglichen Plan halb vergessen, liest beim Aufräumen die .env mit und produziert Code, den niemand mehr sauber reviewen kann. Aufgaben, die eigentlich parallelisierbar wären, arbeitet der Agent sequentiell ab. Dabei vermischen sich getrennte Wissensbasen, etwa Frontend und Backend. Der Output wird teurer, schlechter und am Ende muss man trotzdem nochmal händisch nacharbeiten.
Wir bei CALEO richten Agentic Coding deshalb von vornherein weitsichtiger ein, als kleines Team. Der Orchestrator plant, spezialisierte Subagenten übernehmen gleichzeitig Implementierung, Tests und Dokumentation, jeder mit eng geschnittenem Kontext. Der Entwickler behält die Übersicht in einem Markdown-Kanban-Board im Repository, und das Kontextfenster bleibt für die eigentliche Arbeit frei. Hooks ketten die Agenten an Regeln, die ein Modell sonst nur gelegentlich befolgt. Die eigentliche Aufgabe des Orchestrators ist Kontextmanagement. Wir arbeiten mit Claude Code; das Muster überträgt sich aber auf jede Umgebung, die Subagenten, Skills und Hooks kennt.
Das Board besteht aus mehreren Markdown-Dateien, eine pro Aufgabe. Jede Datei trägt in ihrem Kopf die Eigenschaften der Karte: die Spalte (Backlog, In Arbeit, Review, Erledigt), die Akzeptanzbedingung und Abhängigkeiten wie blocked by. Der Zustand des Boards ergibt sich aus der Summe dieser Dateien.
Drei Eigenschaften machen dieses Format für maschinengetriebene Planung stark:
Jira oder Linear leisten dasselbe auf der Oberfläche, verlangen aber API-Zugriff, Authentifizierung und einen Roundtrip pro Lese- oder Schreiboperation. Dateien im Repository sind schneller, diffbar und brauchen keine Integration.
Den Status pflegt ein Planner-Agent. Er legt für jede Aufgabe eine Datei an, schneidet sie klein, setzt Abhängigkeiten über blocked by und verschiebt die Karten zwischen den Spalten. Über blocked by weiß er, welche Aufgabe frei ist und welche noch auf eine andere wartet; ein Subagent bekommt so nie eine blockierte Karte. Der Planner arbeitet im Wechsel aus Überlegung und Aktion, verfolgt den Fortschritt und passt die Karten an, wie es das ReAct-Muster für Agenten beschreibt (Yao et al., 2023). Editiert werden die Dateien über ein Skill, das die Struktur kennt, die Felder einheitlich formatiert und beim Statuswechsel keine Abhängigkeit zerreißt.
Der Planner orchestriert, er schreibt selbst keinen Code. Für die Arbeit delegiert er an drei Subagenten: einen für die Implementierung, einen für Tests, einen für die Dokumentation. Jeder läuft in seinem eigenen Kontextfenster, bekommt genau eine Aufgabenkarte und gibt ein Ergebnis zurück.
Diese Isolation ist der eigentliche Hebel für Qualität und Kosten. Ein Implementierungs-Subagent, der nur seine Karte und die relevanten Dateien sieht, ertrinkt nicht in der Historie unzusammenhängender Schritte. Dass schon eine einzige irrelevante Information die Genauigkeit deutlich senkt, ist gut belegt (Shi et al., 2023), ebenso, dass Modelle langen Kontext schlecht ausnutzen, vor allem in der Mitte (Liu et al., 2024). Das Fenster bleibt klein, die Tokens günstig, die Ausgabe fokussiert. Gleichzeitig bleibt das Fenster des Orchestrators frei für Koordination, statt sich mit Implementierungsdetails zu füllen.
Die Aufteilung folgt der Verantwortung:
Klar getrennte Rollen erzeugen klar trennbare Diffs, und das macht den Review für Menschen wieder machbar. Spezialisierte Rollen entlang eines Software-Workflows, wie sie MetaGPT aus menschlichen Standardabläufen ableitet, erhöhen die Kohärenz mehragentiger Lösungen (Hong et al., 2024).
Ein Skill ist eine festgeschriebene Prozedur, die ein Agent aufruft, statt sie jedes Mal neu zu erfinden. Das Kanban-Skill von oben ist das einfachste Beispiel: es kennt das Spaltenlayout und hält das Board konsistent, egal welcher Agent es bewegt. Derselbe Mechanismus trägt bei uns von SAP-spezifischen Konventionen bis zu den Schreibregeln für genau diese Blogartikel.
Besonders interessant wird es, wo Tests und Dokumentation zusammenfallen. Wir haben ein Skill, das die Anwendung über Playwright fernsteuert. Es klickt sich durch ein Feature, erstellt Screenshots der relevanten Zustände und schreibt aus demselben Durchlauf End-to-End-Tests. Beides landet direkt in der Dokumentation. Der E2E-Test belegt, dass das Feature läuft, der Screenshot zeigt, wie es aussieht, und die Doku ist aktuell, weil sie aus der laufenden Anwendung entsteht und nicht von Hand gepflegt wird.
So schließt sich die Lücke zwischen einem veralteten Screenshot im Wiki und dem realen Stand der Software. Test, Bild und Beschreibung stammen aus einer Quelle.
Skills schlägt der Agent vor, Hooks laufen automatisch. Ein Hook ist Code, der an ein Ereignis gebunden ist und bei jedem Auftreten ausgeführt wird, unabhängig davon, was das Modell gerade für sinnvoll hält.
Unser konkretes Beispiel ist ein Hook für .env-Dateien. Er greift, bevor ein Tool Dateien liest, und blockiert jeden Zugriff auf Secrets. Wenn der Agent beim Aufräumen oder bei der Fehlersuche zu dem Schluss kommt, er müsse die .env einsehen, lehnt der Hook ab. Die Entscheidung hängt nicht an der Tagesform des Modells. Sie ist deterministisch.
Das ist der entscheidende Unterschied zwischen einer Anweisung im Prompt und einem Hook. Eine Anweisung befolgt das Modell mit hoher Wahrscheinlichkeit, ein Hook mit Sicherheit. Programmierbare, vom Modell unabhängige Leitplanken zur Laufzeit sind genau als solcher Kontrollmechanismus für LLM-Anwendungen beschrieben (Rebedea et al., 2023). Secrets bleiben so aus dem Kontextfenster und aus den Logs. Nach demselben Prinzip hängen bei uns weitere Hooks: Formatierung beim Schreiben einer Datei, ein Test-Gate, bevor eine Karte auf Erledigt wandert.
Eine Aufgabe wandert einmal quer durchs Board. Der Planner legt die Karte „Export-Endpunkt für Reklamationsquoten" an, schneidet sie auf eine klare Akzeptanzbedingung zu und schiebt sie auf In Arbeit. Der Implementierungs-Subagent schreibt den Endpunkt. Während er eine Konfiguration sucht, will er die .env lesen; der Hook blockt, der Agent greift auf den dokumentierten Konfigurationsweg zurück. Der Test-Subagent startet das Playwright-Skill und erzeugt E2E-Tests samt Screenshots. Der Dokumentations-Subagent schreibt beides in die Doku. Die Karte landet auf Review, ein Mensch sieht einen kompakten Diff plus aktuelle Screenshots und gibt frei.
Dieses Setup hat Overhead. Board, Subagenten, Skills und Hooks wollen eingerichtet und gepflegt werden, und für eine kleine Einmaländerung ist ein einzelner Chat schlicht schneller. Der Aufwand zahlt sich ab einer gewissen Komplexität aus: mehrere zusammenhängende Schritte, Code, der in Produktion geht, ein Feature, das jemand reviewen und später warten muss.
Der gemeinsame Nenner über alle vier Bausteine ist Kontext. Das Board hält den Plan außerhalb des Fensters, Subagenten halten jeden Zuschnitt klein, Skills halten Prozeduren stabil, Hooks halten die Regeln fest. Das Modell wird mit jeder Version besser. Eine saubere Umgebung darum herum brauchen Sie trotzdem.