PM werden im KI-Zeitalter 09 | Vom Ausführer zum Orchestrator: dein neuer Job ist, eine Flotte von Agents zu dirigieren

Schau dir zuerst an, wie die fähigsten Leute heute arbeiten.

Sie fahren mehrere Agents gleichzeitig — jeder mit eigenem Kontextfenster, jeder für einen eigenen Bereich zuständig, jeder mit seinem eigenen Dateibereich, alle asynchron am Laufen; der Mensch oben schneidet die Arbeit zu, verteilt sie und kommt nach einer Weile zurück, um abzunehmen, statt einer einzelnen KI zuzusehen, die Satz für Satz in Echtzeit Code umschreibt. Addy Osmani unterscheidet diese beiden Arbeitsweisen sehr klar: die eine ist der Dirigent — du arbeitest mit einem Agent in Echtzeit, und dein eigener Kopf ist die Obergrenze; die andere ist der Orchestrator — du hast eine Flotte von Agents in der Hand, du planst, verteilst, kommst in Abständen zurück und prüfst, und die Produktivität hängt nicht mehr an der Bandbreite eines einzelnen Menschen.

Für Produktmanager ist das eine gute Nachricht. Denn „Orchestrieren” ist genau das alte Handwerk des Produktmanagers — ein großes Ziel in Aufgaben zerlegen, sie an verschiedene Leute verteilen, die Grenzen jedes Blocks im Blick behalten und am Ende abnehmen und zusammenführen. Nur hast du früher Menschen orchestriert, jetzt kommt eine Flotte von Agents dazu. Den mechanischen Teil der Koordination (Termine hinterhertreiben, Anforderungen wiederholen, Formate abgleichen) übernehmen die Agents, das orchestrierende Urteilsvermögen bleibt bei dir — und wird sogar wertvoller. Hier sind vier Handgriffe, die du direkt umsetzen kannst.

1. Begleite nicht länger einen Agent von Anfang bis Ende

Die häufigste Verschwendung ist, die KI wie einen Praktikanten zu behandeln, den du die ganze Zeit im Auge behalten musst: einen Satz absetzen, warten, bis er fertig ist, kurz draufschauen, den nächsten Satz absetzen. Deine Aufmerksamkeit ist seine Obergrenze, und du kannst immer nur eine Sache vorantreiben.

Der Orchestrator macht es umgekehrt: Lässt sich eine Aufgabe in drei voneinander unabhängige Blöcke zerlegen, startest du drei Agents gleichzeitig, gibst jedem einen Block und lässt sie parallel laufen. Du wechselst von „einen in Echtzeit begleiten” zu „nach einer Weile drei einsammeln”. Beim ersten Mal fühlt sich das ungewohnt an, weil du die fixe Idee loslassen musst, „bei jedem Schritt dabei sein zu müssen” — aber genau hier vervielfacht sich deine Produktivität.

2. Zerlege die Arbeit in überschneidungsfreie parallele Blöcke

Die erste Kunst des Orchestrierens ist das Zuschneiden. Wie gut du zuschneidest, entscheidet direkt darüber, ob dir diese Flotte von Agents hilft oder Ärger macht.

Ein Block, den du parallel weggeben kannst, muss zwei Bedingungen erfüllen: voneinander unabhängig (A muss nicht auf das Ergebnis von B warten) und überschneidungsfreie Grenzen (zwei Agents ändern nicht gleichzeitig dasselbe und geraten sich in die Quere). Baust du zum Beispiel eine Funktion, kannst du sie in „Backend-Schnittstelle”, „Frontend-Seite” und „Tests für diesen Teil” zerlegen und an drei Agents verteilen; aber „erst die Datenbank entwerfen, dann die davon abhängige Schnittstelle schreiben” lässt sich nicht parallelisieren, das muss hintereinander laufen. Frag dich vor dem Zerlegen: Lassen sich diese beiden Blöcke jeweils unabhängig fertigstellen? Wenn nicht, zwing sie nicht in die Parallelität.

3. Gib jedem Block eine klare spec

Das ist der heikelste Punkt beim Orchestrieren und zugleich die aufgeblasene Version dessen, worum es im fünften Teil ging. Addy Osmani sagt es direkt: Ein vager Befehl wird zum Fehler einer ganzen Agent-Flotte aufgeblasen; ein präziser Befehl wird zu einer ganzen Flotte präziser Umsetzungen.

Wenn du einen einzelnen Agent führst und der Befehl unscharf ist, geht eines schief, und du kannst es sofort korrigieren. Schickst du fünf gleichzeitig los, jeder mit demselben unscharfen Befehl, sind das fünf Fehltritte, und wenn du zurückkommst, um einzusammeln, musst du fünf davon nacharbeiten. Also wende vor dem Verteilen das Vorgehen aus dem fünften Teil an — Adjektive durch Zahlen ersetzen, Zustände vollständig ausschreiben, Grenzen und „was nicht getan wird” klar auflisten — und schicke sie erst dann einzeln los. Je mehr du verteilst, desto stärker vervielfacht die Präzision deiner spec sich — in die richtige oder in die falsche Richtung.

4. Dein Job wird zu Zuschneiden, Abnehmen und Zusammenführen

Wenn die Agents das „bau es” übernehmen, bleiben dir drei schwerere Dinge: am Anfang die Arbeit richtig zuschneiden, in der Mitte klare Grenzen setzen, am Ende die Blöcke wieder einsammeln, abnehmen und zu einem Ganzen zusammenführen.

Der häufigste Fehler hier ist, aus Ungeduld selbst loszulegen und etwas zu tun, das ein Agent eigentlich könnte — sobald du in die Umsetzungsdetails eines Blocks versinkst, steht die gesamte Orchestrierung still. Der Orchestrator muss „oben” bleiben: darauf achten, ob jeder zurückgelieferte Block stimmt (mit dem Vorgehen aus dem achten Teil — lass ihn erst offenlegen, dann nimmst du ab), und sie zusammenfügen, um zu sehen, ob das Ganze aufgeht. Dein Wert bemisst sich nicht daran, welchen Block du eigenhändig geschrieben hast, sondern daran, ob das, was diese Flotte von Agents zusammen abliefert, Bestand hat.

Eine Sache, die du heute tun kannst: Such dir eine Aufgabe aus, die du gerade angehen willst und die sich zerlegen lässt, versuch, sie in zwei bis drei voneinander unabhängige Blöcke zu schneiden, und starte für jeden einen Agent — du tust nur drei Dinge: zerlegen, spec geben, einsammeln. Erlebe zuerst einmal, worin sich „drei Sachen gleichzeitig vorantreiben” von „eine nach der anderen hintereinander abarbeiten” unterscheidet.

Weiterführende Links

• Addy Osmani „The future of agentic coding: conductors to orchestrators” (Dirigent vs. Orchestrator, präzise spec vervielfacht sich): https://addyosmani.com/blog/future-agentic-coding/
• Teil 05 dieser Serie „Kannst du die Anforderung nicht klar sagen, dichtet die KI sie dir zusammen” (die Präzision der spec): /de/blog/say-it-clearly/
• Teil 08 dieser Serie „Das echte Problem zu finden kann die KI dir nicht abnehmen” (vor der Abnahme erst offenlegen lassen): /de/blog/find-the-real-problem/