Wie ein Mensch ein ganzes Team von KI-Agenten dirigiert

Wie ein Mensch ein ganzes Team von KI-Agenten dirigiert

Wenn die meisten Menschen an „mit KI arbeiten" denken, stellen sie sich ein Chatfenster vor: Frage rein, Antwort raus. Das ist ungefähr so, als würde man eine Baustelle führen, indem man immer nur einem einzigen Handwerker eine einzige Frage stellt und auf seine Antwort wartet, bevor man den nächsten ruft.

So arbeiten wir nicht. Bei größeren Aufgaben dirigiert ein Mensch ein ganzes Team von KI-Agenten, die parallel und arbeitsteilig vorgehen. Das ist kein Selbstzweck und keine Spielerei mit teurer Technik. Es ist die einzige Art, wie eine kleine Mannschaft an vielen Projekten gleichzeitig in einer Qualität arbeiten kann, die sonst ein größeres Team bräuchte. Dieser Artikel erklärt ehrlich, wie das funktioniert, inklusive der Stellen, an denen wir uns die Finger verbrannt haben.

Das Bild: Wellen statt Wasserfall

Die Grundidee heißt bei uns „Wellen". Eine große Aufgabe wird nicht von einem Agenten am Stück erledigt, sondern in mehreren Durchgängen, in denen jeweils mehrere Agenten gleichzeitig arbeiten:

• Welle 1, Verstehen. Mehrere Agenten lesen parallel die bestehende Codebasis, je einer mit eigenem Blick: Architektur, Sicherheit, Datenschutz, Betrieb, Testabdeckung. Alle nur lesend, niemand verändert etwas. Am Ende liegt eine ehrliche Landkarte des Ist-Zustands vor.
• Welle 2, Bauen. Erst jetzt wird geschrieben, wieder parallel, aber mit streng getrennten Zuständigkeiten. Jeder Agent hat seinen eigenen Dateibereich, damit sich niemand in die Quere kommt.
• Welle 3, Prüfen. Frische Augen, die den neuen Code mit Abstand begutachten, plus eine Kontrolle, ob die einzelnen Teile auch wirklich miteinander verdrahtet sind.
• Welle 4, Zusammenführen. Der dirigierende Mensch räumt die letzten Widersprüche auf, die zwischen den parallel arbeitenden Agenten entstanden sind.

Die ideale Wellengröße haben wir uns nicht ausgedacht, sondern erarbeitet. Alle gleichzeitig loszulassen, fünfzehn Agenten auf einmal, führt ins Chaos: Sie geraten sich gegenseitig in die Dateien, die Informationsflut wird unbeherrschbar. Streng nacheinander, einer nach dem anderen, dauert das Zehnfache und niemand lernt vom anderen. Der Sweet Spot liegt bei sieben bis acht parallel arbeitenden Agenten pro Welle. Das ist keine Theorie, das ist die Zahl, bei der es in der Praxis funktioniert.

Ein Ziel statt hundert Anweisungen

Der vielleicht größte Unterschied zum gewohnten Chatfenster steckt darin, wie so eine Aufgabe überhaupt beginnt. Wir tippen nicht hundert Einzelbefehle nacheinander. Wir formulieren ein einziges, durchdachtes Ziel: was am Ende erreicht sein soll, welche Regeln dabei gelten, woran sich Erfolg messen lässt. Aus diesem klaren Auftrag heraus plant die KI die nötigen Schritte selbst und arbeitet sie über die beschriebenen Wellen ab, oft über lange Strecken hinweg, ohne dass jemand daneben sitzt und jeden einzelnen Schritt freigibt.

Bei größeren Vorhaben kommt eine zweite Zutat dazu: Die KI taktet sich selbst. Statt dass ein Mensch jede neue Runde anstößt, arbeitet sie dieselbe Aufgabe in wiederkehrenden Durchgängen ab, prüft nach jedem Durchgang den eigenen Fortschritt und macht weiter, bis das Ziel wirklich erreicht ist. Der Mensch bleibt dabei der Dirigent: Er setzt das Ziel, gibt die Leitplanken vor und nimmt das Ergebnis am Ende ab. Aber er muss nicht mehr jeden einzelnen Ton selbst spielen.

Das ist der eigentliche Hebel hinter unserem Tempo: nicht, dass eine KI schneller tippt als ein Mensch, sondern dass ein gut gestelltes Ziel eine ganze Kette von Arbeit auslöst, die sonst viele Hände und viel Abstimmung gebraucht hätte.

Was das konkret leistet

Ein Beispiel aus einem unserer eigenen Produkte: Ein größerer Umbau, sechsundsiebzig Dateien, über dreizehntausend geänderte Zeilen, fünf Agenten, die gleichzeitig implementierten. Das Ergebnis: null Konflikte beim Zusammenführen. Das ist nicht selbstverständlich, sondern das direkte Resultat einer Disziplin, über die selten gesprochen wird: Bevor auch nur eine Zeile geschrieben wurde, hat eine eigene Welle den Plan gegen die echte Codebasis geprüft und gehärtet, bis er so eindeutig war, dass die Implementierer sich gar nicht erst überschneiden konnten.

Genau hier sitzt der wichtigste Hebel. Bei einem anderen Modul fand diese Plan-Prüfung im ersten Anlauf acht handfeste Blocker und elf Warnungen, allesamt „Realitäts-Drift": Der Plan war gegen vermutete Pfade geschrieben, die es so im Code gar nicht gab. Eine halbe Stunde Prüfung hat dort einen halben Tag fehlgeschlagener Implementierung verhindert. Die Reihenfolge ist die Lektion: erst den Plan gegen die Wirklichkeit prüfen, dann bauen.

Nicht jede Aufgabe braucht das teuerste Werkzeug

Ein Punkt, der bares Geld bedeutet: Es gibt nicht „die KI", sondern verschiedene Modelle mit sehr unterschiedlichen Stärken und Preisen. Ein einfacher Vergleich, ein Datei-Durchlauf, eine Formatprüfung: dafür das stärkste und teuerste Modell zu nehmen, ist Verschwendung. Wir teilen die Arbeit deshalb bewusst auf, nach einer simplen Faustregel:

• Würde ich diese Aufgabe einem erfahrenen Architekten geben? Dann das stärkste Modell.
• Würde ich sie einem erfahrenen Entwickler geben? Dann das solide Mittelklasse-Modell.
• Würde ich sie einem Praktikanten oder einer einfachen Pipeline geben? Dann das schnelle, günstige Modell.

Und noch davor steht eine andere Regel: Was ein simples lokales Skript erledigen kann, etwa zählen, durchsuchen, Daten zusammenfassen, bekommt überhaupt keinen KI-Agenten. Die intelligenteste Lösung ist oft, die teure Intelligenz gar nicht erst einzusetzen.

Misstrauen als Methode: Agenten, die einander widerlegen

KI klingt überzeugend, auch wenn sie falsch liegt. Das ist die gefährlichste Eigenschaft. Unsere Antwort darauf ist organisiertes Misstrauen. Nachdem eine Prüf-Welle eine Liste von Befunden geliefert hat, schalten wir eine zweite Welle dahinter, deren einziger Auftrag ist, diese Befunde zu widerlegen.

Das Ergebnis ist regelmäßig ernüchternd und genau deshalb wertvoll: In einem konkreten Fall wurden von neun gemeldeten Problemen sechs bei der Gegenprüfung als haltlos entlarvt. Nur drei waren echt und wurden behoben. Hätten wir die anderen sechs „repariert", hätten wir vermutlich neue Fehler eingebaut, denn ein Fix für ein Problem, das gar nicht existiert, ist selbst eine Fehlerquelle. Bei großen Architekturfragen drehen wir das Prinzip um: Lassen wir vier, fünf Audits unabhängig voneinander laufen und nennen alle denselben Hauptbefund, dann ist die Wahrscheinlichkeit hoch, dass er stimmt.

Wo wir Lehrgeld bezahlt haben

Jetzt der ehrliche Teil, denn ohne den wäre dieser Artikel wertlos.

Der Tag, an dem die Kosten explodierten. Jeder dieser Agenten kann auf einem anderen Modell laufen. Was wir lange übersahen: Wenn man das Modell nicht ausdrücklich festlegt, erbt jeder Agent stillschweigend das Modell der laufenden Sitzung. Solange das ein günstiges war, fiel nichts auf. An dem Tag, an dem eine Sitzung auf einem teuren Spezialmodell lief, liefen plötzlich alle Agenten darauf, und die Kosten schossen in einer einzigen Sitzung durch die Decke. Die anschließende Auswertung war bitter: In den vier Wochen davor waren 97,5 Prozent aller Agenten-Starts ohne ausdrückliche Modell-Wahl losgeschickt worden. Es war kein Disziplin-Problem, es war ein Standardeinstellungs-Problem. Die Konsequenz war keine Ermahnung, sondern eine technische Sperre, die jeden Agenten-Start ohne explizite Modell-Angabe von vornherein blockiert.

Der Erfolgsbericht, der keiner war. Ein Agent hat einmal eine Aufgabe abgeschlossen, einen detaillierten Erfolgsbericht abgeliefert, mit Zeilennummern, mit „alles geprüft, alles grün". Nur war die Arbeit nirgends gespeichert. Sie war schlicht verloren. Die Lehre, die heute fest verankert ist: Der Erfolgsbericht eines Agenten ist kein Beweis, dass die Arbeit auch wirklich angekommen ist. Man muss es nachprüfen, nicht glauben.

„Grün, aber misst nichts." Die heimtückischste Falle. In einem Projekt war eine bestimmte Funktion vollständig programmiert, getestet, ausgeliefert, und sah aus jeder Außenperspektive gesund aus. Trotzdem hatte sie seit dem ersten Tag kein einziges echtes Datenstück verarbeitet, weil ein Detail im Live-Betrieb jeden Vorgang aussortierte. Niemand bemerkte es, weil nichts „rot" war. Seitdem gilt: Jeder neue Verarbeitungspfad bekommt eine Prüfung, die nicht misst, ob die Funktion läuft, sondern ob sie Ergebnisse produziert. Beim allerersten echten Test schlug genau diese neue Prüfung an, fand einen realen Fehler, und eine Minute nach dem Hotfix war alles wieder gut. Das war die Investition wert.

Orchestrierung ist Disziplin, nicht Magie

Mehrere KI-Agenten zu dirigieren sieht nach Zauberei aus. Es ist das Gegenteil: penible Disziplin. Klare Zuständigkeiten, geprüfte Pläne, organisiertes Misstrauen, technische Leitplanken statt guter Vorsätze, und die feste Annahme, dass eine schöne Erfolgsmeldung erst dann zählt, wenn sie überprüft ist. Genau diese Disziplin ist es, die wir in jedes Kundenprojekt mitbringen.

Aus dem Labor ist unsere Rubrik über das, was wir selbst bauen und betreiben, bevor wir es jemandem empfehlen. Wie wir damit umgehen, dass sich die KI-Werkzeuge selbst ständig unter uns verändern, liest du in Der Boden bewegt sich, also bauen wir Leitplanken. Fragen? Schreib uns.