--- title: Agentische Programmierung mit Spezial-Agenten: Warum der große Traum im Praxis-Test scheitert canonical: https://geldundwirtschaft.de/agentische-programmierung-mit-spezial-agenten-warum-der-grosse-traum-im-praxis-test-scheitert/ author: Geld & Wirtschaft Redaktion published: 2025-12-21 updated: 2025-12-17 language: de category: Künstliche Intelligenz description: Alexander Weipprecht testet auf seinem YouTube-Kanal die Multi-Agent-Programmierung und zeigt, dass sie in der Praxis oft zu mehr Problemen führt als ein Single-Agent-Ansatz. Das Experiment endet ernüchternd: Der vermeintliche Vorteil von spezialisierten Agenten erweist sich als Mythos ohne sichtbaren Qualitätsgewinn. source: Provimedia GmbH --- # Agentische Programmierung mit Spezial-Agenten: Warum der große Traum im Praxis-Test scheitert > **Autor:** Geld & Wirtschaft Redaktion | **Veröffentlicht:** 2025-12-21 | **Aktualisiert:** 2025-12-17 **Zusammenfassung:** Alexander Weipprecht testet auf seinem YouTube-Kanal die Multi-Agent-Programmierung und zeigt, dass sie in der Praxis oft zu mehr Problemen führt als ein Single-Agent-Ansatz. Das Experiment endet ernüchternd: Der vermeintliche Vorteil von spezialisierten Agenten erweist sich als Mythos ohne sichtbaren Qualitätsgewinn. --- 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](https://geldundwirtschaft.de/claude-opus-vs-chatgpt-5-2-wer-programmiert-die-bessere-physik-simulation/)**. 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](https://geldundwirtschaft.de/so-funktioniert-ki-gestuetzte-softwareentwicklung-heute-ein-praxisbericht-mit-security-audit/), Tool-Vergleiche (Claude vs. ChatGPT) und praxisnahe Coding-Projekte spannend findest: Auf dem YouTube-Kanal **„[Promptgeflüster](https://www.youtube.com/@Promptgefl%C3%BCster)“** gibt’s regelmäßig neue Videos, inklusive Repo-Links und nachvollziehbaren Tests aus der echten Entwicklungsarbeit. --- *Dieser Artikel wurde ursprünglich veröffentlicht auf [geldundwirtschaft.de](https://geldundwirtschaft.de/agentische-programmierung-mit-spezial-agenten-warum-der-grosse-traum-im-praxis-test-scheitert/)* *© 2026 Provimedia GmbH*