Veröffentlicht am 2026-09-01 · 4 Min. Lesezeit
Eine spezialisierte Multi-Agenten-Pipeline für die Softwareentwicklung — warum sie erschreckend gut funktionierte und warum ich sie trotzdem verworfen habe.
KI ist aus dem Arbeitsumfeld nicht mehr wegzudenken. So viele Bereiche, auf die KI Einfluss nimmt, so viele Wege gibt es, KI sinnvoll und effektiv einzusetzen. Was ich hier teile, ist also weder richtig, noch möchte ich mich — wie es heutzutage auf LinkedIn üblich ist — selbst darstellen und zeigen, welche tollen AI-Buzzwords ich kenne. Dementsprechend schreibe ich meine Logs bewusst oberflächlich und ohne technischen Deep Dive.
Diese Logs sind einfach eine Momentaufnahme. Es ist ein vergangener Ansatz für meinen speziellen Aufgabenbereich, mit einer immer schneller werdenden Entwicklung von KI in der Softwareentwicklung umzugehen und dies sinnvoll als performantes Werkzeug in meinen Arbeitsalltag zu integrieren.
Ich erhoffe mir einen Austausch und die Möglichkeit, andere Herangehensweisen kennenzulernen, einfach voneinander zu lernen — denn nie war Lernen und Weiterbildung so relevant wie in der heutigen Zeit.
In den letzten Monaten habe ich, wie jeder von uns, viel experimentiert. In größeren Projekten wurde die zunehmende Komplexität und der damit einhergehende Kontextverlust zum Kernproblem: Modelle halluzinierten, bauten syntaktisch valide, aber fachlich falsche Tests für fehlerhaften Code, produzierten schlechte Softwarearchitektur — und erzählten uns gleichzeitig zum x-ten Mal, nun hätten sie das gesamte Bild verstanden.
Um dem entgegenzuwirken, entwickelte ich eine strukturierte Orchestrierungs-Pipeline mit spezialisierten Agenten: ein vollständiges Dev-Team aus Agents mit fest zugeschriebenen Aufgaben, das teilautonom reale Aufgaben bearbeitet. Die Module dieses Systems lassen sich grob wie folgt zusammenfassen.
Jira-Tickets wurden über MCP-Schnittstellen (Model Context Protocol) angebunden und ausgelesen. Ein vorgelagerter Triage-Agent analysierte und bereinigte die Rohdaten — filterte irrelevante Kommentare, Formatierungsreste und Altlasten heraus — und bewertete Komplexität, grobe Zielbereiche, Abhängigkeiten sowie die betroffenen Domänen (Frontend, Backend, Security).
Ich vergleiche diesen Agent immer mit der Rezeption in einer Notaufnahme: Der Patient kommt mit einem blutenden, gebrochenen Bein herein, die Rezeption filtert und dokumentiert die Probleme und schickt ihn in den für ihn passenden Bereich.
Der Workflow wurde als gerichteter Graph (DAG) beziehungsweise State Machine modelliert. Je nach Teilaufgabe — Spezifikation, Test-Erstellung, Implementierung — und Komplexitätsgrad ordnete ein dynamisches Routing das passende LLM zu: schlankere, schnellere Modelle für Standardaufgaben, Flagship-Modelle nur dort, wo tiefes Reasoning nötig war.
Meine Erfahrung zeigt, dass für kaum einen Task wirklich die teuersten Flagship-Modelle benötigt werden, solange die Vorarbeit geleistet wurde.
Ein spezialisierter Test-Agent leitete aus den Akzeptanzkriterien konkrete Test-Suiten ab. Der nachgelagerte Entwickler-Agent erhielt sowohl diese Tests als auch die bereinigten fachlichen Anforderungen — um ein reines Overfitting auf isolierte Assertions zu verhindern und sicherzustellen, dass die Fachlogik erfüllt wird und nicht nur die Test-Suite.
Bevor Code an den Menschen ging, durchlief der Output eine automatisierte Prüfschleife: statische Typanalyse, Linter, Testläufe. Fehlermeldungen gingen direkt zurück an den Entwickler-Agenten zur Selbstkorrektur. So musste der reale Entwickler als Human-in-the-Loop nicht als Debugger für Syntaxfehler herhalten, sondern konnte sich rein auf fachliche Architektur- und Code-Reviews konzentrieren.
Das klingt auf den ersten Blick wirklich gut, und es war tatsächlich erschreckend, wie gut und zuverlässig dieses System funktionierte. Mit steigenden Tokenkosten und wachsender Erfahrung nahmen die Probleme jedoch zu.
Das Kernproblem wurde erst mit steigenden Tokenkosten wirklich deutlich: der enorm explodierende Token-Overhead und Context-Drift. Jeder Agenten-Wechsel erforderte das Serialisieren und Weiterreichen des bisherigen Systemzustands. Endlose Markdown-Protokolle, unkomprimierte Terminal-Ausgaben (yarn test, Stacktraces, Compiler-Logs) und redundante Datei-Snapshots blähten das Context Window exponentiell auf. Frühere wichtige Aufforderungen gingen durch den Context Drift faktisch verloren — und die Kosten pro tatsächlicher Umsetzung stiegen im gleichen Maße.
Ein weiterer Punkt waren die kaskadierenden Latenzen. Ein Workflow aus vier bis sechs sequenziell geschalteten Agenten-Schritten summiert sich schnell auf mehrere Minuten Wartezeit pro Ticket. Fehlte an einer frühen Stelle ein Detail, pflanzte sich der Fehler durch die gesamte Kette fort.
Der entscheidende Punkt, der mich meinen Ansatz hat überdenken lassen, war aber vor allem das Gefühl, ein immer fragiler werdendes Kartenhaus aus Abhängigkeiten, Kosten und Abstimmungen zu bauen.
Das wichtigste Learning aus den letzten Monaten war, Dinge noch aggressiver auszuprobieren — und vor allem genauso aggressiv zu verwerfen. Ein „Trial & Error auf Steroiden“, denn genau das ermöglicht mir KI.
Genau diese Herangehensweise führte mich zu meinem aktuellen Ansatz (Stand September 2026), den ich Control-Layer-Orchestrierung nenne. Er besteht im Kern aus zwei Bereichen: einem deterministischen Control Layer — also deterministischem Code, der entscheidet, wann was laufen darf — und einem stochastischen Data Layer, der austauschbare spezialisierte Einheiten durch Schemata definiert. Den neuen Ansatz dokumentiere ich detailliert in einem Folgeartikel.
Viel Kommunikation zwischen vielen Agents ist eine wunderbare Methode, sein Ziel zu erreichen und gleichzeitig enorm viel Geld zu verbrennen.
Wenn ihr ähnliche architektonische Ehrenrunden gedreht habt: Schreibt mir, lasst uns ins Gespräch kommen.
KI · Orchestrierung · Multi-Agenten