Agenten orchestrieren wie ein Entwicklungsteam

In einer langen Abendsession habe ich mir mein eigenes kleines Entwickler-KI-Team zusammengebaut. Nicht als Demo, sondern als Arbeitssetup für echte Tickets, echte Pull Requests und echte Reviews.

Wenn über KI-Agenten in der Softwareentwicklung gesprochen wird, klingt es oft so, als würde sich alles grundlegend ändern. Autonome Systeme, neue Arbeitsweisen, weniger Menschen im Prozess.

Meine Erfahrung ist anders.

Technisch hat sich viel verändert. Organisatorisch ist das Grundprinzip erstaunlich vertraut geblieben. Ich baue Automatisierung heute sehr ähnlich auf, wie ich früher Entwicklungsteams aufgebaut habe: mit klaren Rollen, eindeutigen Tickets, Reviews, Freigaben und einem Menschen, der den Überblick behält.

Der Unterschied ist nicht, dass ich Kontrolle abgebe. Der Unterschied ist, dass ich delegiere.

Automatisierung heißt für mich nicht Autopilot

Ein häufiger Denkfehler ist für mich, Agenten als Ersatz für Führung zu betrachten. Nach dem Motto: Der Agent bekommt ein Ziel, arbeitet los und am Ende wird schon etwas Brauchbares herauskommen.

So würde ich auch kein menschliches Team führen.

Ich gebe einem Entwickler nicht einfach ein vages Ziel und lasse ihn mehrere Tage im Blindflug arbeiten. Ich sorge für ein klares Ticket, einen definierten Scope, technische Leitplanken, Review-Kriterien und einen gemeinsamen Begriff von fertig.

Genau so behandle ich Agenten.

Ein Agent ist für mich kein magischer Automat, sondern ein sehr schneller Mitarbeiter mit begrenztem Kontext. Wenn der Rahmen schlecht ist, produziert er schnell viel Rework. Wenn der Rahmen gut ist, wird er zu einem verlässlichen Beschleuniger.

Mein aktuelles Setup in Rollen gedacht

Ich trenne die Arbeit bewusst in Rollen. Nicht jeder Agent darf alles. Nicht jeder Lauf hat denselben Zweck.

Typische Rollen in meinem Setup sind:

• ein Refinement-Agent, der Tickets schärft,
• ein Implementierungs-Agent, der freigegebene Tickets umsetzt,
• ein Review-Agent, der Pull Requests kritisch prüft,
• ein PR-Resolver, der Review-Kommentare und rote Builds abarbeitet,
• ein Support-Agent, der eingehende Anliegen triagiert.

Das ist keine technische Spielerei. Es ist dieselbe Rollentrennung, die auch in guten Teams funktioniert.

Jede Rolle hat ein klares Arbeitsgebiet. Jeder Lauf hat einen Anfang und ein Ende. Und jeder Agent arbeitet gegen ein explizites Ziel, zum Beispiel ein Jira-Ticket oder einen Pull Request.

Wie der Ablauf konkret aussieht

Die Bedienung läuft für mich bewusst über die Werkzeuge, die ich auch in einem menschlichen Team nutzen würde: Slack, Jira, Confluence und Bitbucket.

Der aktuelle Ablauf sieht so aus.

1) Ticket-Erstellung

Ich starte in Slack und sage einem Agenten, dass ich ein neues Ticket anlegen will. Alternativ erstelle ich das Ticket direkt in Jira.

Wichtig ist: Die Arbeit beginnt nicht mit Code, sondern mit einem sichtbaren Auftrag. So bleibt nachvollziehbar, warum eine Änderung überhaupt entsteht.

2) Refinement

Ein Agent ist nur für das Refinement zuständig. Er prüft das Ticket, stellt Rückfragen und schärft Ziel, Kontext und Akzeptanzkriterien.

Erst wenn die Definition of Ready erreicht ist, darf aus dem Ticket eine Umsetzungsaufgabe werden. Wenn noch etwas unklar ist, wird nicht geraten, sondern nachgefragt.

3) Implementierung

Der Implementierungs-Agent übernimmt die eigentliche Arbeit am Code. Er arbeitet gegen das freigegebene Ticket, erstellt einen Branch und bereitet einen Pull Request vor.

Dabei sind Quality Gates Pflicht: Unit-Tests, End-to-End-Tests, Linting und Build müssen je nach Änderung grün sein. Erst dann ist die Arbeit überhaupt reviewfähig.

4) Pull Request und Review

Ich reviewe die konkreten Änderungen zum Ticket. Nicht die Zusammenfassung, sondern den Code.

Wenn Architektur, Scope oder Lösungsweg nicht passen, hinterlasse ich Anmerkungen und fordere Nacharbeit an. Ein weiterer Agent kann diese Kommentare abarbeiten, aber die Freigabe bleibt bei mir.

5) Dokumentation

Confluence nutze ich für die dauerhafte Beschreibung des Setups und der Bedienung. Jira hält die konkrete Arbeit, Confluence hält den gemeinsamen Kontext.

Auch das ist keine neue KI-Erfindung. Es ist gute Teamarbeit mit anderen ausführenden Einheiten.

Ich bleibe das Quality Gate

Der wichtigste Punkt ist: Ich bin weiterhin das Quality Gate.

Ich gebe Tickets frei. Ich entscheide, was in die Umsetzung geht. Ich reviewe den Quellcode. Ich prüfe, ob die technische Lösung zum System passt. Und ich orchestriere, welcher Agent wann welche Arbeit übernimmt.

Das ist kein Misstrauen gegenüber KI. Das ist professionelle Softwareentwicklung.

Auch bei menschlichen Teams ist Code nicht fertig, nur weil jemand ihn geschrieben hat. Er ist fertig, wenn er die fachlichen Anforderungen erfüllt, technisch tragfähig ist, getestet wurde und jemand mit Verantwortung ihn freigegeben hat.

KI ändert daran nichts. Sie erhöht nur die Geschwindigkeit, mit der Zwischenstände entstehen. Deshalb wird das Quality Gate nicht weniger wichtig, sondern wichtiger.

Was sich gegenüber menschlichen Teams kaum geändert hat

In früheren Einsätzen, unter anderem bei tonies, habe ich sehr ähnliche Strukturen aufgebaut, nur eben für Menschen.

Auch dort ging es nicht zuerst um Tools. Es ging um Zusammenarbeit.

Ein reibungsloses Team braucht:

1. klare Tickets,
2. nachvollziehbare Prioritäten,
3. definierte Verantwortungen,
4. kurze Feedback-Schleifen,
5. verbindliche Review- und Freigaberegeln,
6. sichtbare Ergebnisse.

Das klingt unspektakulär, ist aber der Kern stabiler Delivery.

Heute ersetze ich diese Struktur nicht durch KI. Ich übertrage sie auf KI-gestützte Arbeit. Der Agent bekommt die Rolle, der Prozess gibt den Rahmen und ich halte die Verantwortung.

Die Muster sind gleich geblieben. Nur die Geschwindigkeit und die Art der Ausführung haben sich verändert.

Der Senior- oder Lead-Developer-Blick bleibt zentral

Ein Senior Developer oder Lead Developer schreibt nicht nur Code. Er hält Zusammenhänge.

Er erkennt, wann ein Ticket fachlich noch unklar ist. Er sieht, ob eine Lösung lokal sauber wirkt, aber architektonisch nicht passt. Er entscheidet, ob ein Risiko akzeptabel ist oder ob nachgeschärft werden muss. Er schützt das Team vor unnötigem Rework.

Genau diese Rolle bleibt bei Agentenarbeit zentral.

Wenn ich Agenten orchestriere, mache ich im Kern Lead-Arbeit:

• Arbeit schneiden,
• Kontext bereitstellen,
• Ergebnisse prüfen,
• Risiken bewerten,
• nächste Schritte entscheiden.

Der Unterschied ist, dass die ausführenden Einheiten schneller reagieren. Das macht gute Orchestrierung wertvoller, nicht überflüssig.

Wie ich die Oberhand behalte

Für mich funktioniert Agentenautomatisierung nur, wenn Kontrolle im System eingebaut ist. Nicht als Bauchgefühl, sondern als Ablauf.

Konkret achte ich auf fünf Dinge.

1) Tickets sind der Startpunkt

Ein Agent arbeitet nicht auf Zuruf an diffusen Ideen. Er arbeitet an einem Ticket mit Ziel, Akzeptanzkriterien und Kontext.

Wenn das Ticket nicht klar genug ist, wird es nicht implementiert, sondern zuerst verfeinert.

2) Rollen sind begrenzt

Der Implementierungs-Agent soll nicht nebenbei den Prozess umbauen. Der Review-Agent soll nicht ungefragt Features ergänzen. Der Support-Agent soll nicht Architekturentscheidungen treffen.

Diese Begrenzung reduziert Chaos.

3) Pull Requests bleiben der Kontrollpunkt

Auch Agentenarbeit landet in Pull Requests. Dort sehe ich die tatsächliche Änderung, nicht nur die Zusammenfassung.

Ich reviewe Code, Tests, Migrationsrisiken, Seiteneffekte und Verständlichkeit.

4) Verifikation ist Pflicht

Linting, Tests, Builds und fachliche Checks sind kein Bonus. Sie sind Teil des Done-Kriteriums.

Ein Agent kann viel behaupten. Der Build und die Tests liefern die erste harte Gegenprüfung.

5) Lernen fließt zurück in die Regeln

Wenn ein Agent an einer Stelle falsch abbiegt, ist das nicht nur ein Einzelfehler. Dann prüfe ich, ob der Rahmen unklar war.

Gute Regeln werden nachgeschärft. So verbessert sich das System mit jeder Runde.

Warum das besser ist als freie Agentenarbeit

Freie Agentenarbeit wirkt am Anfang beeindruckend. Der Agent erzeugt viel Output, beantwortet Fragen, passt Dateien an und wirkt autonom.

Aber ohne klare Führung entstehen typische Probleme:

• Änderungen werden größer als nötig,
• Entscheidungen verschwinden im Chatverlauf,
• Reviews werden schwerer,
• Verantwortlichkeiten verschwimmen,
• Risiken fallen erst spät auf.

Das ist bei Menschen übrigens nicht anders.

Ein Team ohne klare Prioritäten und Reviews wird nicht dadurch besser, dass es aus erfahrenen Leuten besteht. Es braucht trotzdem Struktur.

Agenten brauchen diese Struktur noch stärker, weil sie schneller handeln.

Der eigentliche Hebel ist nicht der Prompt

Natürlich sind gute Prompts wichtig. Aber der größere Hebel liegt für mich im Betriebssystem der Zusammenarbeit.

Welche Aufgaben dürfen gestartet werden? Wer gibt sie frei? Wo landet das Ergebnis? Wer prüft den Code? Welche Tests sind verpflichtend? Was passiert bei einem Blocker? Wie werden Erkenntnisse dokumentiert?

Das sind keine KI-Fragen. Das sind Engineering-Management-Fragen.

Genau deshalb fühlt sich der Aufbau eines Agenten-Setups für mich nicht fremd an. Es ist die gleiche Disziplin, die gute technische Teams seit Jahren brauchen.

Warum ich lokal auf meinem Spark arbeite

Ein weiterer wichtiger Punkt ist der Betrieb. Das Setup läuft lokal auf meinem NVIDIA Spark.

Das hat für mich zwei praktische Vorteile.

Erstens entstehen keine laufenden Token-Kosten pro Agentenlauf. Wenn Agenten öfter arbeiten, Reviews lesen, Tickets prüfen oder mehrere Schleifen drehen, wird das Kostenmodell schnell relevant. Lokal kann ich solche Automatisierung viel freier denken.

Zweitens bleiben Code, Tickets und Arbeitskontext unter meiner Kontrolle. Gerade bei Kundencode, Zugriffstokens und internen Architekturentscheidungen ist das für mich ein zentraler Punkt. Ein lokales Setup macht DSGVO-konforme Entwicklungsautomatisierung deutlich einfacher, weil keine externen Modell-APIs in den Arbeitsfluss eingebunden werden müssen.

Aktuell starte ich die Agenten noch gezielt von Hand. Das ist Absicht. Ich will erst sehen, ob die Rollen, Quality Gates und Feedback-Schleifen im Alltag sauber funktionieren.

Wenn sich der Ablauf über ein paar Tage bewährt, ist der nächste Schritt ein dauerhafter Loop. Dann nehmen sich die Agenten passende Aufgaben selbstständig aus der Queue, aber weiterhin innerhalb ihrer Rolle und unter denselben Freigaberegeln.

Automatischer wird dann nur die Ausführung. Die Verantwortung bleibt bewusst geführt.

Fazit

Agenten verändern die Geschwindigkeit der Softwareentwicklung, aber nicht die Grundprinzipien guter Zusammenarbeit.

Wer Agenten produktiv einsetzen will, braucht nicht weniger Führung, sondern bessere Orchestrierung. Klare Tickets, feste Rollen, Pull Requests, Reviews, Tests und bewusste Freigaben bleiben der Kern.

Für mich ist das die beruhigende Erkenntnis: Es hat sich weniger geändert, als es auf den ersten Blick wirkt. Die Werkzeuge sind neu. Die Verantwortung bleibt dieselbe.

Wenn du magst, kannst du mit dem Projekt-Check prüfen, wie robust eure Architektur-, Test- und Betriebsbasis aktuell ist.