KI-Orchestrierung: Die neue Workflow-Ebene in der Softwareentwicklung
Sobald mehrere Agenten parallel arbeiten, ist nicht mehr der Prompt das Problem. Entscheidend werden Auftrag, Übergaben und die Stelle, an der ein Mensch wieder Verantwortung übernimmt.
Vier Agenten arbeiten gleichzeitig an einem Ticket. Einer schreibt Code, einer ergänzt Tests, einer durchsucht das Repository, einer formuliert die Zusammenfassung. Nach einer Stunde liegt viel Output vor. Was oft fehlt, ist die einzige Antwort, die das Team braucht: Was genau ist jetzt wahr, was nur ein Vorschlag und wer prüft den Übergang?
Das ist kein Modellproblem. Es ist ein Ablaufproblem. Einzelne Coding-Assistenten wie GitHub Copilot, Cursor, Aider oder Claude können längst produktiv helfen. Sobald mehrere Läufe, Branches und Sessions gleichzeitig laufen, genügt aber ein guter Assistent nicht mehr. Dann braucht die Arbeit eine Choreografie.
KI-Orchestrierung ist genau diese unspektakuläre, wichtige Ebene: Sie sorgt dafür, dass eine Idee nicht als großer KI-Teppich endet, sondern als nachvollziehbare Folge aus Auftrag, Arbeitsraum, Nachweis und Übergabe.
Nicht Agenten verteilen, sondern Verantwortung schneiden
Der häufigste Fehlstart lautet: „Wir teilen die Aufgabe auf vier Agenten auf.“ Das ist noch keine Orchestrierung. Erst wenn die Grenzen der Teilaufgaben klar sind, kann Parallelität helfen.
Ein brauchbarer Auftrag ist kleiner als ein Feature-Wunsch. Er enthält ein beobachtbares Ergebnis, eine Grenze und einen Prüfweg. Zum Beispiel nicht: „Baue die neue Rechnungsansicht.“ Sondern: „Ergänze die Summenzeile in Komponente X, ändere keine Berechnungslogik außerhalb des Moduls und liefere einen Test, der den alten Fehler reproduziert.“
Mit so einem Auftrag können Agenten arbeiten, ohne stillschweigend Architekturentscheidungen zu erfinden. Und ein Reviewer kann später bewerten, ob das Ergebnis zum Auftrag passt, statt sich durch eine vermeintlich clevere Lösung raten zu müssen.
Vier Stationen, die tatsächlich helfen
Ein robuster Ablauf braucht keine Agenten-Fabrik. Er braucht vier Stationen, die jede Änderung durchläuft.
1. Der Auftrag. Ein Mensch oder ein klarer Produktentscheid schreibt auf, was sich ändern soll, was ausdrücklich nicht geändert werden soll und wie Erfolg erkennbar ist. Das ist kein Overhead, sondern die Referenz gegen halluzinierte Nebenaufgaben.
2. Der isolierte Arbeitsraum. Ein Agent verändert nicht das gemeinsame Chaos, sondern einen separaten Branch oder Worktree. Git-Worktrees sind dafür kein exotischer Trick mehr: Sie erlauben parallele Arbeitsbäume, ohne dass sich Agenten gegenseitig Dateien überschreiben. Die Git-Dokumentation beschreibt genau diesen Mechanismus.
3. Der Nachweis. Tests, Linter, Screenshots oder ein reproduzierbarer Befehl zeigen, was geprüft wurde. Ein grüner Lauf beweist nicht automatisch, dass die Aufgabe richtig gelöst ist. Aber ohne einen Nachweis bleibt selbst ein plausibler Diff bloß Behauptung.
4. Die Übergabe. Hier entscheidet ein Mensch oder eine explizite Regel, ob das Ergebnis in den gemeinsamen Arbeitsstand darf. Gute Orchestrierung verkürzt diesen Moment nicht weg. Sie macht ihn leichter, weil der Kontext, der Diff und der Nachweis beieinanderliegen.
Orchestrierung beginnt oft vor dem Framework
Frameworks wie LangChain und CrewAI helfen, Agenten, Tools und Zustände zu koordinieren. LangGraph fokussiert beispielsweise langlebige, zustandsbehaftete Agenten-Workflows; Temporal steht für robuste Workflows mit Wiederaufnahme nach Fehlern. Das sind sinnvolle Bausteine, wenn Prozesse länger laufen oder mehrere Systeme berühren.
Im Entwickleralltag ist die erste Orchestrierungsschicht aber häufig viel schlichter: ein gutes Issue, ein sauberer Branch, ein Arbeitsprotokoll und eine Review-Regel. Wer diese vier Dinge nicht im Griff hat, macht mit einem Multi-Agent-Framework nur schneller schwer nachvollziehbare Arbeit.
Die richtige Reihenfolge ist deshalb: erst Ablauf und Verantwortlichkeiten sichtbar machen, dann entscheiden, ob ein technisches Framework wirklich ein wiederkehrendes Problem löst.
Ein Beispiel: Bugfix ohne Agenten-Theater
Nehmen wir einen Fehler, bei dem ein Export bei leeren Feldern scheitert. Der erste Agent darf das Repository durchsuchen und den wahrscheinlichsten Fehlerpfad dokumentieren. Der zweite arbeitet in einem separaten Worktree an einem kleinen Patch samt Regressionstest. Ein dritter darf nur den Diff gegen den ursprünglichen Auftrag prüfen: Wurde eine Annahme hinzugefügt? Wurde zu viel umgebaut? Ist der Test wirklich rot, bevor der Fix kommt?
Das klingt nach mehr Schritten als „Agent, repariere das“. In der Praxis spart es Zeit, weil die unvermeidliche Unsicherheit früh auftaucht. Der Review wird kürzer, der Rollback klarer und die nächste Sitzung kann dort weiterarbeiten, wo die vorige aufgehört hat.
Woran man schlechte Orchestrierung erkennt
Ein paar Signale sind verlässlich: Alle Agenten erhalten denselben offenen Auftrag. Sie teilen denselben Arbeitsbaum. Ergebnisse werden nur als lange Chat-Zusammenfassung übergeben. Tests laufen irgendwo, aber niemand weiß gegen welche Erwartung. Und im Zweifel ist der Mensch nur noch dazu da, einen riesigen Diff abzunicken.
Das ist nicht Automatisierung, sondern Kontextverschiebung. Die Arbeit verschwindet nicht; sie landet später und teurer im Review.
Ein guter Flow macht das Gegenteil. Er erhöht die Zahl der kleinen, prüfbaren Entscheidungen und senkt die Zahl der großen Überraschungen. Deshalb ist Orchestrierung weniger eine Technologieentscheidung als eine Teamdisziplin.
Der nächste sinnvolle Versuch
Wähle für einen Pilotlauf eine Aufgabe, die in ein bis zwei Stunden zu prüfen ist. Definiere Erfolg und Grenzen in drei Sätzen. Lass einen Agenten analysieren, einen zweiten in einem separaten Arbeitsraum patchen und einen Menschen den Nachweis prüfen. Miss nicht nur die Dauer. Miss, ob der Reviewer schneller versteht, was passiert ist.
Wenn das klappt, kann das Team die gleiche Struktur auf längere Agentenläufe, Wiederaufnahme und mehrere Dienste übertragen. Wenn es nicht klappt, war die Lektion trotzdem wertvoll: Nicht die Zahl der Agenten muss steigen, sondern die Klarheit des Auftrags.