Inhaltsverzeichnis:
Auf dem noch jungen YouTube-Kanal Promptgeflüster nimmt Alexander Weipprecht diesmal einen Mythos auseinander, der in KI-Entwicklerkreisen geradezu als Heilsversprechen herumgereicht wird: Multi-Agent-Programmierung. Also die Idee, dass man nicht „ein Modell“ bauen lässt, sondern gleich ein ganzes Team spezialisierter KI-Agenten (Security, DB, UX, Backend …), orchestriert von einem Master-Agenten – und am Ende entsteht besserer Code, schneller, sicherer, sauberer.
Alexander macht daraus einen praxisnahen Härtetest: ein echtes Webprojekt, wie es in Agenturen oder Inhouse-Teams regelmäßig gebaut wird – mit Login, Benutzerverwaltung, Datenbank, Charts, Demo-Daten. Und dann vergleicht er:
- „Normaler“ Build: Claude Code / Opus 4.5 setzt das Projekt direkt um (Single-Agent/Monolith).
- Agenten-Orchestrierung: Master-Agent steuert mehrere Spezial-Agenten parallel (Multi-Agent).
Das Ergebnis ist… ernüchternd.
Das Projekt: Weight-Tracking System wie im echten Leben
Die Zielanwendung ist bewusst nicht trivial, aber auch kein Mondprojekt:
Kernfunktionen
- Login & Benutzerverwaltung (Admin-Bereich + User-Bereich)
- Rollenmodell (Admin vs. User)
- Gewichtseinträge (Gewicht erfassen, Historie)
- Statistiken & Charts
- z. B. Monatsdurchschnitt, Wochenbericht
- Profilfunktionen
- Anzeigename ändern
- Passwort ändern
- Zielgewicht festlegen
- Demo-Daten automatisch erzeugen (damit man nicht alles manuell anlegt)
Stack (webbasiert)
- PHP (Backend), MySQL
- HTML/CSS/JavaScript (Frontend)
- Bootstrap (UI)
- Alles auf Basis einer Claude.md mit Code-Standards + Projektvorgaben
- Ein umfangreiches PRD (Product Requirement Document) als Markdown als Bauplan
Zwei Wege zum Ziel
Variante A: „Einfach bauen lassen“ (ohne Agenten-Orchestrierung)
Der Ablauf ist klassisch KI-Coding:
- PRD + Claude.md + DB-Config bereitstellen
- „Setze das Projekt komplett um“
Messwert im Video
- Umsetzung in ~9:31 Minuten
- kleiner Stolperer: ein fehlender Setup-/Migrationsschritt (ca. 15 Sekunden Debugging)
- danach: funktionierende Anwendung
- Admin-Login, Benutzerverwaltung, Navigation
- Gewicht eintragen
- User-Ansicht mit Dashboard & Historie
- BMI/Statistiken sichtbar
- (Passwort-Sicherheit wird kurz als Punkt erwähnt, aber insgesamt: läuft)
Kurz: fast One-Shot, produktnah, schnell.
Variante B: „Agenten-Team“ (Master + Spezialisten parallel)
Alexander baut dafür ein Agenten-Set mit Farbcode, damit man im Ablauf erkennt, wer arbeitet:
Agenten-Rollen
- Master-Agent (Orchestrator): plant, verteilt Tasks, überwacht
- DB-Agent: Schema, Migrations, Queries
- Security-Agent: Auth, Validierung, XSS/CSRF-Schutz etc.
- Backend-Agent: MVC, Services, Controller
- Design-Agent: Bootstrap, Views, CSS
- UX/JS-Agent: Flows, Interaktivität, Frontend-Logik
Erwartung: schneller durch Parallelität + bessere Qualität durch Spezialisierung.
Was tatsächlich passiert: Erstmal… fast gar nichts davon.
Der Knackpunkt: Orchestrator ≠ Orchestrierung
Ein wichtiges Learning im Video ist überraschend simpel:
Es reicht nicht, den Master-Agenten zu benennen. Man muss ausdrücklich anweisen, dass er die Sub-Agents wirklich lädt und nutzt.
Alexander merkt nach kurzer Zeit: Es arbeitet nur der Master. Keine Agenten-Calls, keine Parallelität sichtbar (Farben fehlen).
Er greift ein und ergänzt sinngemäß:
- „Nutze die Agenten orchestriert durch den Master.“
Dann startet das System tatsächlich parallel:
- DB, Security, Code, Design laufen als Background-Prozesse gleichzeitig.
Das ist der Moment, wo das Experiment „eigentlich“ beginnt.
Was schiefgeht: Kontext, Koordination, Kipp-Punkte
Mit laufenden Sub-Agents häufen sich genau die Probleme, die Alexander aus früheren Versuchen bereits kannte – und die er eigentlich überprüfen wollte, ob Opus 4.5 sie inzwischen besser löst.
1) Kontextverbrauch explodiert
Irgendwann erscheint sinngemäß: „context low“.
Das ist im Multi-Agent-Setting brandgefährlich, weil:
- jeder Agent Kontext laden muss (Docs, Regeln, Code)
- jeder Agent Ergebnisse produziert, die wieder in den Master zurückfließen
- die Gesamt-Konversation schneller „zu groß“ wird
Folge: Der Prozess hängt bzw. bricht faktisch ab.
2) Der Workflow „friert“ ein
Alexander sieht:
- keine Agenten laufen mehr
- kein Fortschritt
- kein Erfolgssignal
Er versucht Status/Resume – kommt aber nicht sauber wieder in einen stabilen Arbeitsfluss.
3) Neustart bringt zwar Bewegung, aber nicht Qualität
Er startet eine neue Session, lässt den Stand prüfen:
- System erkennt: bei einem Schritt stecken geblieben
- es folgen Security-Review, Responsive-Checks, „Final Abnahme“, Integrationstest
- es werden Syntaxfehler gefunden und „repariert“
Klingt gut – ist aber am Ende… kosmetisch.
Der Praxistest: Demo lädt – und es bricht direkt sichtbar
Beim Versuch, die Demo zu öffnen:
- 404-Fehler (Routing/Pfade falsch)
- später: CSS wird nicht geladen
- dann: Header fehlt, Code-Segmente scheinen zu fehlen
- am Ende: ein Interface ist „da“, aber funktioniert nicht zuverlässig
- Alexander bricht ab: zu viel Debugging, zu viele Brüche, kein Vorteil erkennbar
Das ist der zentrale Punkt: Multi-Agent sollte weniger Debugging erzeugen – hier erzeugt es mehr.
Vergleich: Single-Agent vs. Multi-Agent im Test
| Kriterium | Ohne Agenten (direkt) | Mit Agenten (orchestriert) |
|---|---|---|
| Time-to-first-working-demo | ~9:31 Minuten | deutlich länger (Video läuft >30 Min, real ~1 Stunde Aufwand) |
| Debugging-Aufwand | minimal (Setup/Migration) | hoch (404, CSS, fehlende Segmente, Fehlerkaskaden) |
| Stabilität des Prozesses | stabiler „durchgehend“ | bricht/hängt wegen Kontext/Koordination |
| Parallelität | nein | ja (aber teuer/fragil) |
| Qualitätsgewinn sichtbar? | „gut genug“ & lauffähig | nein, eher regressiv |
| Fazit | produktnah | experimentell / instabil |
Warum der Multi-Agent-Ansatz hier verliert
Aus dem, was man im Ablauf sieht, lassen sich drei plausible Ursachen ableiten:
A) Der „Koordinations-Overhead“ frisst den Nutzen
Multi-Agent klingt wie „mehr Hände, schneller fertig“. In Softwareprojekten ist es oft anders:
Mehr Beteiligte = mehr Abstimmung = mehr Bruchstellen.
Bei KI ist das besonders kritisch, weil Übergaben zwischen Agenten nicht „implizit“ funktionieren wie in einem Team, sondern über Texte, Kontextfenster und Codezustände.
B) Kontext ist die eigentliche Währung
Alexander sagt es sinngemäß selbst: Kontext ist das größte Problem.
Wenn das System Kontext verliert, verliert es:
- Architekturregeln
- Pfadkonventionen
- UI-Struktur
- bereits getroffene Entscheidungen
Und dann passieren genau die Fehler, die man sieht: fehlende Assets, inkonsistente Templates, „verschwundene“ Segmente.
C) „Parallel“ ist nicht automatisch „besser“
Parallel arbeitende Agenten können sich gegenseitig in die Quere kommen:
- CSS wird gebaut, aber nicht sauber eingebunden
- Routing wird angepasst, aber Frontend referenziert alte Pfade
- Security-Änderungen werden integriert, aber UI/Controller-Flow bricht
Das sind typische Integrationsprobleme – nur dass sie hier in Minuten statt Tagen passieren.
Das überraschende Zwischenfazit: Agenten als Reviewer statt als Builder
Im Video gibt es einen Punkt, der als produktive Alternative heraussticht:
Ein Security-Agent als nachgelagerter Prüfer könnte sinnvoll sein.
Denn der Multi-Agent-Prozess hat zumindest eins gezeigt:
- Security Review
- Responsive Check
- Consistency Check
- Integration Test
Das wirkt wie ein QA-/Audit-Layer. Vielleicht ist genau das der sweet spot:
- bauen: ein Modell, durchgehend, stabil
- prüfen: spezialisierte Agenten, nacheinander, kontrolliert
Also: Agenten als Qualitätssicherung – nicht als parallele Produktionslinie.
Was man als Team daraus mitnehmen kann
1) Ein gutes PRD + strenge Claude.md schlagen Agenten-Magie
Der „einfache“ Build war schnell und nahezu fehlerfrei – weil die Vorgaben sauber waren.
2) Wenn Multi-Agent, dann mit harter Disziplin
Falls man es trotzdem nutzen will, dann eher:
- Agenten sequenziell (nicht parallel)
- klare Schnittstellen: „DB fertig → Backend baut darauf → UI hängt sich dran“
- aggressive Kontext-Kompression / kurze Agenten-Briefings
- Master muss nicht „alles wissen“, sondern nur Entscheidungen & Integrationsregeln
3) Realität schlägt Hype
Agenten-Orchestrierung ist nicht automatisch „professioneller“. Ohne saubere Steuerung wird es:
- teurer (mehr Kontext, mehr Durchläufe)
- langsamer (Recovery, Restarts)
- fehleranfälliger (Integration)
Fazit: „Agentische Spezial-Agenten“ bleiben im Test ein Mythos – zumindest so
Alexander beendet das Experiment klar:
- Single-Agent: funktioniert schnell, mit minimalem Debugging
- Multi-Agent Orchestrierung: bricht am Kontext, erzeugt mehr Fehler, kein sichtbarer Qualitätsgewinn
Sein vorläufiges Urteil: Test gescheitert.
Und die entscheidende Erkenntnis: Nicht die Idee der Agenten ist tot – aber die naive Hoffnung, dass parallele Spezial-Agenten automatisch bessere Software „zaubern“, hält dem Praxisdruck nicht stand.
📺 Mehr von Alexander Weipprecht auf YouTube
Wenn du solche Live-Experimente rund um KI-gestützte Softwareentwicklung, Tool-Vergleiche (Claude vs. ChatGPT) und praxisnahe Coding-Projekte spannend findest: Auf dem YouTube-Kanal „Promptgeflüster“ gibt’s regelmäßig neue Videos, inklusive Repo-Links und nachvollziehbaren Tests aus der echten Entwicklungsarbeit.
FAQ zur Multi-Agent-Programmierung
Was ist Multi-Agent-Programmierung?
Multi-Agent-Programmierung ist ein Ansatz, bei dem mehrere spezialisierte KI-Agenten zusammenarbeiten, um komplexe Aufgaben zu lösen, anstatt ein einzelnes Modell zu verwenden.
Warum scheitert der Multi-Agent-Ansatz häufig in der Praxis?
Der Ansatz scheitert oft aufgrund von Koordinationsproblemen, hohem Kontextverbrauch und Schwierigkeiten bei der Integration der verschiedenen Agenten. Diese können zu ineffizienten Prozessen und einem erhöhten Debugging-Aufwand führen.
Was ist der Vorteil von einem Single-Agent-Modell?
Ein Single-Agent-Modell ist in der Regel schneller, stabiler und benötigt weniger Debugging, da alle Komponenten in einem kohärenten Prozess integriert sind und keine komplexe Koordination erforderlich ist.
Wie kann Multi-Agent-Programmierung trotzdem sinnvoll eingesetzt werden?
Eine sinnvolle Nutzung könnte in der Anwendung von spezialisierten Agenten als Reviewer oder Prüfer innerhalb eines fest definierten Prozesses stattfinden, um sicherzustellen, dass die Qualität der Arbeit gewährleistet ist, während ein einzelner Agent das Hauptprojekt steuert.
Welche Lektionen können aus dem Scheitern des Multi-Agent-Ansatzes gezogen werden?
Ein gutes PRD und rigorose Vorgaben sind entscheidend für den Erfolg. Wenn Multi-Agenten eingesetzt werden, sollten sie sequenziell und nicht parallel arbeiten, mit klaren Schnittstellen und kurzen Briefings, um den Kontext zu bewahren.
