Agentische Programmierung mit Spezial-Agenten: Warum der große Traum im Praxis-Test scheitert

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:

1. „Normaler“ Build: Claude Code / Opus 4.5 setzt das Projekt direkt um (Single-Agent/Monolith).
2. 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

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.