Im letzten Beitrag haben wir beschrieben, wie aus Projektwissen ein dauerhafter Asset wird: die Library. Workflows, Prompts, Prüfschemata. Verdichtet zu Skills, ausführbar statt nur lesbar. Am Beispiel unseres Design-Reviews mit CodeAI haben wir gezeigt, wie ein einzelner Skill mit jedem Projekt klüger wird.
Aber ein Skill, der für sich allein arbeitet, ist erst die halbe Geschichte. Die eigentliche Frage lautet: Was passiert, wenn diese Bausteine anfangen, miteinander zu arbeiten?
Genau hier beginnt die nächste Verschiebung – und mit ihr die dritte Lücke.
Die dritte Lücke: Wenn der Einzelgewinn nicht ankommt
Es gibt eine Zahl, die das Problem auf den Punkt bringt. Auf der Ebene der einzelnen Aufgabe liefert KI dramatische Gewinne – bei Programmieraufgaben sehen Studien Zeitersparnisse von über 50 Prozent. Auf der Ebene der gesamtwirtschaftlichen Produktivität kommt davon bislang weniger als ein Prozent an.
Diese Lücke zwischen Mikro-Gewinn und Makro-Wirkung ist kein SHAPE-Problem. Sie ist ein globales Phänomen. Und sie hat einen Grund, den wir in der Serie schon als Nettofalle beschrieben haben – nur sitzt sie diesmal eine Ebene höher.
Wer eine Library aufgebaut hat, kennt das: Es gibt einen Skill für das Design-Review, einen für die Anforderungsanalyse, einen für die Testabdeckung, einen für das Reporting. Jeder funktioniert. Jeder spart Zeit. Und trotzdem bleibt die Wirkung hinter dem Versprechen zurück. Der Grund ist die Naht zwischen den Bausteinen. Ein Mensch muss den Output des einen Skills lesen, interpretieren und in den nächsten hineingeben. Die Einzelaufgabe ist beschleunigt, aber die Kette läuft im manuellen Takt.
Schlimmer noch: Wo KI ungebremst Output produziert, ohne dass ein System ihn auffängt, entsteht neue Last. „Workslop“ – minderwertiger Output, der hinten wieder Nacharbeit erzeugt. Permanente Kontrolle, die kognitiv ermüdet. Wissensarbeit ist eben kein Förderband, auf dem mehr Tempo automatisch mehr Ergebnis bedeutet.
Wir nennen das die dritte Lücke: Den Punkt, an dem ein Unternehmen über eine Sammlung guter Skills verfügt, diese aber noch von Hand zusammensteckt. Die Bausteine sind da. Was fehlt, ist die Orchestrierung.
Vom Operator zum Orchestrator
Schon im Beitrag zur Produktivitätslücke haben wir vom Wechsel „vom Prompting zur Orchestrierung“ gesprochen. Jetzt wird konkret, was das bedeutet. Drei Verschiebungen sind entscheidend.
Vom Befehl zum Auftrag. Ein Skill bekommt eine Anweisung und liefert ein Ergebnis. Ein Agent bekommt ein Ziel und entscheidet selbst, welche Skills er in welcher Reihenfolge aufruft, um es zu erreichen. Der Mensch beschreibt nicht mehr den Weg, sondern den gewünschten Zustand.
Von der Kette zum Netz. Einzelne Skills bilden lineare Abläufe. Ein orchestriertes System verzweigt: Es prüft Zwischenergebnisse, ruft bei Bedarf zusätzliche Skills auf, wiederholt Schritte, eskaliert an den Menschen, wenn die Unsicherheit zu groß wird. Aus einer Pipeline wird ein adaptiver Prozess.
Von der Ausführung zur Richtung. Je autonomer ein System arbeitet, desto wichtiger wird die Frage, wo der Mensch entscheidet. Verantwortung für Strategie, Qualität und Richtung bleibt bewusst beim Menschen – die Maschine liefert Tempo und Variantenvielfalt. Orchestrierung ohne klare Übergabepunkte ist kein Fortschritt, sondern ein Kontrollverlust.
Wer diesen Schritt geht, hört auf, KI als eine Reihe von Werkzeugen zu denken. Er fängt an, sie als Team zu denken – mit Aufgaben, Übergaben und einer Person, die den Takt vorgibt.
Warum sich Orchestrierung erst spät auszahlt
Eine Warnung gehört an diese Stelle. Der Aufbau eines orchestrierten Systems fühlt sich am Anfang nicht nach Gewinn an. Im Gegenteil.
Die Wertkurve von KI-Initiativen verläuft typischerweise als J: Erst sinkt der Nutzen unter die Ausgangslinie – es gibt eine Lernkurve, die Kosten der Überprüfung, den Aufwand, Abläufe überhaupt erst aufeinander abzustimmen. Diese Phase ist real und sie ist unbequem. Erst danach beginnt die Kurve zu steigen, und zwar steiler, als jede lineare Effizienz es könnte.
Genau hier trennt sich die Spreu vom Weizen. Wer in der Senke aufgibt, weil die Tools „doch keinen Unterschied machen“, bleibt in der Stagnation hängen. Wer durchhält, erreicht den Punkt, an dem die Grenzkosten jedes weiteren Projekts sinken – weil das System aus jedem Durchlauf lernt. Wert entsteht hier nicht trotz der Zeit, sondern durch sie.
Wie das in der Praxis aussieht: Vom Review zur abgesicherten Pipeline
Bleiben wir beim Design-Review aus dem letzten Beitrag. Für sich genommen prüft CodeAI, ob das implementierte Frontend dem Figma-Entwurf entspricht – Token für Token, Farbe für Abstand. Ein wertvoller, aber isolierter Schritt.
Im orchestrierten Ablauf wird dieser Skill zu einem Glied in einer längeren Kette, die das System selbst zusammenfügt. Findet das Review eine Abweichung, erzeugt der nächste Schritt automatisch ein strukturiertes Jira-Ticket mit Kontext und Schweregrad. Ein weiterer schlägt eine Korrektur im Code vor. Ein dritter prüft, ob diese Korrektur nicht an anderer Stelle eine neue Abweichung erzeugt.
Der entscheidende Unterschied zu einer simplen Automatisierung liegt in den Kontrollinstanzen, die mitlaufen. Über der produzierenden Schicht sitzt eine Governance-Ebene aus spezialisierten Prüf-Agenten – wir nennen sie Guardians. Ein Design-Guardian prüft in Echtzeit gegen die Token-Standards. Ein Architecture-Guardian hat ein Veto-Gate für die strukturelle Integrität: Weicht ein Ergebnis ab, blockiert er, statt es durchzuwinken. Erst wenn die Kette einen sauberen Stand erreicht – oder auf eine Entscheidung stößt, die ein Mensch treffen muss – meldet sich das System zurück.
Was früher ein Mensch zwischen vier Tools von Hand orchestriert hat, läuft jetzt als ein zusammenhängender, abgesicherter Prozess. Der Mensch entscheidet weiterhin, was gut genug ist. Aber er sucht nicht mehr den nächsten Schritt – er bewertet ein Ergebnis, das bereits mehrere Prüfungen durchlaufen hat.
Der Library-Effekt potenziert sich dabei. Jeder einzelne Skill wird mit jedem Projekt besser, das wussten wir schon. Neu ist: Auch die Verbindungen zwischen den Skills lernen. Welche Reihenfolge funktioniert? An welcher Stelle eskaliert das System zu früh, an welcher zu spät? Diese Erkenntnisse wandern zurück in die Library – als Pattern, das beim nächsten Projekt zur Verfügung steht. Die Pipeline als Ganzes wird mit jedem Durchlauf verlässlicher.
Ein Skill löst eine Aufgabe. Ein orchestriertes System löst einen Prozess.
Was ein funktionierendes Agenten-Team ausmacht
In der Arbeit mit orchestrierten Systemen sehen wir vier Merkmale, die tragfähige Aufbauten von beeindruckenden Demos unterscheiden.
Es hat klare Übergabepunkte. Ein gutes System weiß, wann es selbst entscheidet und wann es den Menschen ruft. Diese Grenze ist nicht statisch – sie verschiebt sich mit dem Vertrauen, das sich über die Zeit aufbaut. Aber sie ist jederzeit explizit.
Es hat Instanzen, die Nein sagen dürfen. Das gefährlichste Verhalten eines autonomen Systems ist nicht der Fehler, sondern der selbstsichere Fehler. Tragfähige Aufbauten haben Prüf-Instanzen, die bei Abweichung blockieren – ein Veto-Gate, kein höflicher Hinweis. Lieber eine Rückfrage zu viel als eine falsche Annahme weitergereicht.
Es ist nachvollziehbar, nicht magisch. Wenn ein Agent eine Entscheidung trifft, muss erkennbar sein, warum. Ein orchestrierter Ablauf, dessen Schritte niemand mehr rekonstruieren kann, ist kein Asset, sondern ein Risiko.
Es bleibt im Besitz der Organisation. Wie schon bei der Library gilt: Die wahre Stärke entsteht, wenn die Orchestrierung über Team- und Projektgrenzen hinweg wiederverwendbar ist – nicht, wenn jedes Team sein eigenes, undokumentiertes Geflecht pflegt.
Was du jetzt schon tun kannst
Der Weg zum orchestrierten System beginnt nicht mit einer großen Plattform, sondern mit der ehrlichen Betrachtung der eigenen Abläufe.
1. Finde die teuerste Naht.
Schau auf einen Prozess, in dem du bereits einzelne KI-Bausteine nutzt. Wo sitzt die manuelle Übergabe, die am meisten Zeit oder Aufmerksamkeit kostet? Genau dort liegt der erste Kandidat für Orchestrierung.
2. Verbinde genau zwei Schritte – mit einer Prüfung dazwischen.
Nicht die ganze Kette auf einmal. Nimm zwei Skills, die heute ein Mensch verknüpft, und lass das System die Übergabe übernehmen. Und definiere von Anfang an, woran das System erkennt, dass es anhalten muss. Ein funktionierendes Glied mit Notbremse schlägt eine geplante Gesamtarchitektur, die nie startet.
3. Halte die J-Kurve aus.
Rechne damit, dass die ersten Wochen mehr Aufwand als Ertrag bringen. Das ist kein Zeichen, dass es nicht funktioniert – es ist die Senke vor dem Anstieg. Wer hier zu früh aufgibt, verwechselt die Lernkurve mit dem Ergebnis.
Die Unternehmen, die im KI-Zeitalter wirklich skalieren, sind nicht die mit den meisten Skills. Es sind die, die ihre Skills zum Zusammenspielen bringen – und die wissen, wann der Mensch den Takt übernimmt.
Die richtige Frage am Ende eines Prozesses lautet nicht mehr: Welcher Schritt kommt als Nächstes?
Sie lautet: Welche Schritte muss ich überhaupt noch selbst gehen?
Dieser Beitrag wurde in Ko-Kreation zwischen Mensch und KI verfasst. Die konzeptionelle Struktur, Haltung und Inhalte stammen vom Autor, die KI unterstützte bei Feinschliff und Strukturierung.
Grafik 1 und Grafik 2 basieren auf Studien und Forschungsergebnissen von GitHub, Accenture, OECD sowie Google Cloud (DORA).
