Wie arbeitet ein KI-Agenten-Team zusammen?
Wie ein kleines Entwicklungsteam — nur dass drei der vier Rollen von KI-Agenten besetzt sind: Strategie und Review im Chat, Implementierung im Repository, Code-Generierung für abgegrenzte Aufgaben. Der Mensch navigiert, entscheidet und trägt die Verantwortung. Bei mir sieht das konkret so aus: fünf parallele Terminals, jedes mit einer klaren Zuständigkeit.
Ein lokales Git Bash für alles, was ich selbst in der Hand behalte. Agent-Sessions für die Implementierung. Eine SSH-Verbindung für Server-Aufgaben. Die Disziplin dahinter klingt banal, ist aber der halbe Erfolg: Jede Anweisung benennt explizit, in welchem Terminal sie läuft und welches System sie betrifft. Sobald das schwammig wird, arbeiten Agenten am falschen Ziel — selbstbewusst und fleißig.
Der Takt ist immer derselbe: Ich beschreibe das Ziel, der Strategist zerlegt es in Etappen, der Executor implementiert, ich reviewe, dann erst geht etwas Richtung Produktion. Kein Agent überspringt eine Stufe.
Welche Rollen brauchen KI-Coding-Agenten?
Vier Rollen haben sich bewährt: ein Strategist für Produktentscheidungen und Reviews (Claude im Chat), ein Executor für die Implementierung im Repo (Claude Code), ein Code-Generator für scharf abgegrenzte Tasks (Codex) — und der Mensch als Navigator und Operator, bei dem Entscheidungen, Reviews und Deploys liegen. Die Rollen sind wichtiger als die Tools dahinter.
Der Strategist denkt in Anforderungen und Risiken: Was bauen wir, was bewusst nicht, was muss vorher geklärt werden? Der Executor arbeitet im Repository — liest Code, ändert ihn, baut, testet, verifiziert. Der Generator bekommt nur Aufgaben mit klarer Kante: eine Komponente, eine Funktion, ein Migrations-Skript. Und der Navigator — ich — hält die Fäden: Welche Etappe kommt als Nächstes, was ist gut genug, was geht live.
Damit das nicht ins Chaos kippt, gelten Spielregeln, die nicht verhandelbar sind:
- Agenten pushen und deployen nie selbst. Jede Änderung geht durch mein Review, jeder Deploy läuft über mich.
- STOP-Marker nach jeder Etappe. Der Agent liefert ab, dokumentiert den Stand und hält an — statt eigenmächtig weiterzubauen.
- Fakten-Gates. Agenten dürfen keine Quellen, Studien oder Zahlen erfinden. Fehlt ein Fakt, ist die richtige Antwort eine Rückfrage — kein plausibles Halluzinat.
- Pre-Commit-Checks. Types, Lint, Build, Secret-Scan — bevor irgendetwas committet wird.
Was kann dabei schiefgehen?
Der teuerste Fehler beim Relaunch war kein Code-Problem: Eine Umgebungsvariable lag auf der falschen Hosting-Site — der KI-Lotse lieferte live nur Verbindungsfehler, während lokal alles lief. Die Diagnose kostete mehr Zeit als jede Architektur-Frage des gesamten Projekts. Orchestrierung ersetzt kein Systemverständnis.
Die Lektion daraus: Agenten sind exzellent in dem Raum, den sie sehen können — das Repository, die Build-Ausgabe, die lokale Umgebung. Infrastruktur dahinter (Hosting-Konfiguration, DNS, Deployment-Kontexte) sehen sie nur indirekt. Genau dort braucht es den Menschen, der weiß, wie die Teile zusammenhängen, und der die richtige Diagnose-Frage stellt, statt die dritte Code-Hypothese zu testen.
Zweiter ehrlicher Beat: Ohne explizite Terminal- und Zielsystem-Disziplin produziert ein Multi-Agenten-Setup beeindruckend schnell — Konfusion. Die Spielregeln oben sind keine Theorie, sondern Narben.
Ersetzt das Entwickler?
Nein. Es verschiebt den Engpass: weg vom Schreiben des Codes, hin zum Entscheiden — Architektur, Review, Priorisierung, Verantwortung. Diese Arbeit wird nicht weniger, sie wird wichtiger. Wer sie nicht leisten kann, bekommt von Agenten nur schneller produzierte falsche Lösungen.
Jede Zeile, die ein Agent schreibt, verantworte am Ende ich. Das Review ist keine Formalie, sondern der Kern der Rolle — und der Grund, warum die Spielregeln oben so streng sind. Dazu kommt die regulatorische Ebene: Wo KI im Unternehmen arbeitet, entstehen ohnehin Dokumentations- und Kompetenzpflichten — der EU AI Act macht KI-Kompetenz ab August 2026 durchsetzbar. Ein Agenten-Setup ohne menschliche Kontrollpunkte ist auch compliance-seitig nicht haltbar.
Wie startet man damit?
Mit einem kleinen, ungefährlichen Projekt, einer klaren Rollenverteilung und der Regel, dass kein Agent je selbst deployt. Nicht mit dem Produktiv-Repository am ersten Tag. Drei Schritte, die sich bewährt haben:
- Ein Pilotprojekt mit echtem, aber begrenztem Wert wählen. Eine interne Seite, ein Skript, ein Prototyp — etwas, bei dem Fehler lehrreich statt teuer sind.
- Rollen vor Tools definieren. Wer entscheidet, wer baut, wer prüft? Erst wenn das steht, die Agenten zuordnen — nicht umgekehrt.
- Gates von Anfang an einziehen. Review-Pflicht, STOP-Marker, Fakten-Gates, Pre-Commit-Checks. Nachrüsten ist schwerer als einbauen.
Und dann beginnt der Teil, der sich nicht in drei Schritte fassen lässt: der Zuschnitt auf das eigene Team. Welche Rollen Ihre Agenten brauchen, wo Ihre STOP-Marker sitzen, welche Checks bei Ihrem Stack Pflicht sind, wie das mit bestehenden Prozessen und Verantwortlichkeiten zusammenspielt — das ist bei jedem Team anders. Genau diese Fragen sind der Unterschied zwischen einem Experiment und einem Produktionsmodell.