Das Ende des „One-Prompt-Wunders" – Warum wir Agenten-Teams brauchen

Wer meine bisherigen Posts verfolgt hat, kennt die Reise: angefangen mit einfachen Chat-Prompts auf claude.ai, weiter zum Agentic-Coding mit GitHub Copilot, bis hin zur Einführung von copilot-instructions.md und AGENTS.md, um dem Assistenten endlich klare Spielregeln zu geben. Jeder dieser Schritte hat meinen Workflow verbessert – und gleichzeitig neue, tieferliegende Probleme ans Licht gebracht.

Irgendwann habe ich nämlich festgestellt, dass das eigentliche Problem nicht mit einer besseren Anweisung gelöst werden kann. Es ist systemischer Natur. In diesem Post möchte ich vier Kernprobleme beschreiben, auf die ich immer wieder gestoßen bin, und erklären, warum sie mich dazu gebracht haben, meinen gesamten Ansatz zu überdenken.

Das Versprechen von „Vibe Coding"

Der Begriff „Vibe Coding" wurde von Andrej Karpathy geprägt und beschreibt einen Entwicklungsansatz, bei dem man dem Modell eine vage Idee schildert und die KI den Rest erledigt. Man arbeitet auf einer intuitiven, schnellen Ebene – kein Architekturplan, kein Spec-Dokument, einfach prompten und schauen, was entsteht. Im ersten Moment fühlt sich das wie eine Superkraft an.

Für kleine Skripte, schnelle Prototypen oder isolierte Hilfsfunktionen funktioniert das auch hervorragend. Die Probleme beginnen, wenn die Codebase wächst, Features aufeinander aufbauen und die KI plötzlich nicht mehr weiß, was sie vorhin gebaut hat.

Meine Erfahrung nach Monaten des aktiven Einsatzes: Vibe Coding ist eine sehr gute Beschleunigung für den Einstieg, aber ein sehr schlechtes Fundament für alles, was danach kommt.

Ich bin ein gelernter Informatiker und Software-Engineer, was natürlich den Software-Engineering-Ansatz innehat. Ich möchte den Engineering-Ansatz auch mit Hilfe von KI weiterführen. Ein „Viben" beim Coden ist für mich zwar interessant, sollte aber nicht das Ziel sein. Ich möchte eine nachhaltige, wartbare Codebase aufbauen, die den Anforderungen meiner Projekte gerecht wird. Und dafür reicht es nicht, einfach nur zu „viben" – ich brauche Struktur, Planung und klare Verantwortlichkeiten.

Ich habe mich dabei immer gefragt: Wie können Menschen, vermeintlich ohne Software Engineering Erfahrung, mit diesem Ansatz Projekte bauen, die echte Nutzer nutzen und sogar dafür bezahlen? Obwohl ich es, mit einem Jahrzehnt Erfahrung in Softwareentwicklung nicht hin bekomme, dass der KI Agent mir sauberen, nicht duplizierten Code generiert. Ich war nah an der Verzweiflung, wie kann das sein, war mein jahrelanges Studium etwa umsonst, hat das gar nichts gebracht?

Ich kann alle Informatiker beruhigen, natürlich ist nicht alles Gold, was glänzt – und tatsächlich finden sich in der Entwickler-Community die gleichen Schmerzen, die ich selbst erlebt habe. Wer in den einschlägigen Subreddits liest, stößt auf ein konsistentes Bild:

• Die „Month 3 Wall": Viele Projekte funktionieren zunächst reibungslos, weil die KI jeden Prompt lokal optimiert. Nach etwa drei Monaten bricht das System dann zusammen: Es fehlt eine globale Architektur, und die App wird buchstäblich nur noch von „Duct Tape" zusammengehalten – weil niemand die übergreifende Struktur definiert hat. Der Code funktioniert im Kleinen, aber im Großen hat er sich längst vom ursprünglichen Design entfernt. (r/vibecoding)
• State Drift und Code-Duplikation: Sobald Features wachsen, verliert das Modell den Überblick über den bestehenden State. Statt vorhandene Logik zu refaktorieren, dupliziert es sie einfach – Tabellen, Funktionen, Klassen werden neu angelegt, obwohl sie bereits existieren. Ein häufig genannter Ratschlag lautet deshalb: „Freeze your code early", bevor die Duplikation unkontrollierbar wird. (r/vibecoding)
• Explodierende Token-Kosten durch Dead Code: Vibe Coding erzeugt rasch ungenutzten Code – verwaiste Typen, doppelte Funktionen, nie aufgerufene Hilfsmethoden. Dieser Ballast verstopft bei Folge-Prompts das Context Window. Das Modell benötigt dadurch immer mehr Token, während die Qualität der Ausgabe gleichzeitig sinkt. Eine Art negativer Kreislauf, der sich schleichend aufbaut. (r/cursor)
• Sicherheitsschulden im Autopilot-Modus: Im Schnellmodus ignoriert die KI standardmäßige Sicherheitsrichtlinien. Authentifizierungs-Schnittstellen werden unsauber verdrahtet, Umgebungsvariablen landen an falschen Stellen, Validierungen fehlen. Was anfangs wie ein fertiges Produkt aussieht, stapelt im Hintergrund leise Security Debt an. (r/nocode)
• Das Trugbild des fertigen v0-Prototyps: Die KI liefert schnell ein UI, das gut aussieht – und erzeugt damit die Illusion, man sei fast fertig. Die echten, teuren Probleme liegen jedoch in den 99% unsichtbarem Code darunter: Skalierbarkeit, Edge Cases, Data Compliance. Ohne strikten Plan bleiben diese Bereiche fehlerhaft. Debugging in der Produktion wird zum Albtraum. (r/vibecoding)

Das ist kein Zufall und keine Pechsträhne einzelner Entwickler. Es ist ein Muster, welches durch einen unstrukturierten Einsatz von KI-Coding-Tools entsteht. Es zeigt, dass Vibe Coding zwar eine mächtige Technik sein kann, aber nicht die richtige Herangehensweise für komplexe, langfristige Projekte ist. Auch eine KI braucht zum aktuellen Zeitpunkt ein strukturiertes Vorgehen. Vor allem bei komplexen Aufgabenstellungen ist es wichtig, die KI durch die Aufgabenstellung zu führen. Das Prinzip, das hier greift, ist uralt: Teile und herrsche – oder auf Latein: Divide et impera.

Das Muster ist konsistent: Immer dann, wenn ein Problem zu groß für einen einzigen Durchgang wurde, war die Zerlegung in fokussierte Teilprobleme die entscheidende Durchbruch-Idee. Und für den Einsatz von KI im Besonderen gilt das mehr denn je. Ein LLM hat ein begrenztes Kontextfenster. Jeder Token, der darin landet, verbraucht einen Teil der verfügbaren Aufmerksamkeit des Modells. Wer eine komplexe Aufgabe – Anforderungsanalyse, Architekturentscheidung und Code-Implementierung – in einem einzigen Prompt zusammenfasst, überlädt dieses Fenster. Das Ergebnis ist ein Modell, das sich auf zu vieles gleichzeitig konzentrieren muss und bei jedem Teilproblem an Qualität verliert. Kleine, fokussierte Aufgaben hingegen lassen das Modell in seinem Element arbeiten: präzise, konsistent, zuverlässig.

Die vier Probleme, die mich zur Umkehr gezwungen haben

1. Das Konzept-Problem: Die KI erfindet, statt zu verstehen

Das erste und grundlegendste Problem trifft einen zu Beginn fast gar nicht, weil man es für eine Stärke hält. Man beschreibt ein Feature und die KI baut es sofort – schnell, vollständig, überzeugend. Was man erst später merkt: Die KI hat sich das Konzept selbst ausgedacht.

In der Praxis sieht das so aus: Ich bitte den Assistenten, eine neue Filterfunktion für eine bestehende Listenansicht zu implementieren. Der generierte Code funktioniert auf Anhieb. Beim genauen Hinschauen fällt auf, dass das Modell eine eigene State-Management-Logik eingebaut hat – parallel zu der, die bereits im Projekt existiert. Es hat das Feature nicht in die bestehende Architektur integriert, sondern daneben gebaut.

Das liegt nicht an fehlendem Können des Modells, sondern daran, dass es keinen expliziten Architekturplan hatte, an dem es sich orientieren konnte. Es hat das Konzept improvisiert – und Improvisation führt in einer gewachsenen Codebase fast zwangsläufig zu Inkonsistenzen.

2. Das Regelverstoß-Problem: Guidelines werden ignoriert

Im Post über copilot-instructions.md und AGENTS.md habe ich beschrieben, wie man dem Assistenten projektspezifische Anweisungen gibt. Ich habe Coding-Guidelines definiert, Architekturregeln festgelegt, sogar explizit aufgeschrieben, welche Libraries zu verwenden sind und welche nicht.

Das hat geholfen – aber nicht zuverlässig.

Das Frustrierende daran: Ich konnte im Chat sehen, dass der Agent meine copilot-instructions.md als Kontext eingelesen hatte. Die Datei war aktiv, stand oben im Fenster. Und trotzdem: Eine Funktion, für die ich Pinia als State-Management vorgeschrieben hatte, wurde plötzlich mit lokalem ref-State gelöst. Eine Komponente, die ich explizit als Server-Component konfiguriert haben wollte, landete als Client-Component im generierten Code. Meine Guidelines standen direkt vor seinen Augen – und wurden ignoriert.

Kein Fehler im eigentlichen Sinne – der Code lief. Aber er lief gegen meine eigenen Konventionen. Und das Schlimmste daran: Es passierte nie beim ersten einfachen Aufruf, sondern immer dann, wenn die Anfrage komplex wurde. Je mehr Aufmerksamkeit das Modell für die eigentliche Aufgabe brauchte, desto weniger blieb für das Einhalten meiner Regeln übrig.

3. Das Duplikations-Problem: Das Rad wird jedes Mal neu erfunden

Dieses Problem hat mich am meisten Zeit und Nerven gekostet. Ich bitte die KI, eine neue Funktion zu bauen. Sie baut sie – und schreibt dabei ohne zu zögern drei Hilfsfunktionen, die bereits in meinem Projekt existieren. Utility-Methoden für Datumsformatierung, eine eigene Error-Handler-Klasse, ein benutzerdefiniertes HTTP-Client-Setup – alles schon vorhanden, alles neu implementiert.

Das Ergebnis ist Code-Duplikation im großen Stil. Ich hatte irgendwann Datenbankzugriffe auf vier verschiedene Weisen in meiner Codebase – alle funktional korrekt, alle redundant. Refactoring-Aufwand, der sich über Tage zog.

Das Modell hatte schlicht keine vollständige Übersicht über das, was bereits existierte. Es konnte zwar den direkt im Kontext mitgegebenen Code sehen, nicht aber die tieferliegende Infrastruktur. Also baute es eben seine eigene.

4. Das Fokus-Problem: Anforderung, Konzept und Code auf einmal

Das am schwierigsten zu benennende, aber vielleicht folgenreichste Problem. Wenn man einen umfangreichen Prompt schreibt, der gleichzeitig die Anforderungen erklärt, das gewünschte Konzept beschreibt und die Implementierung fordert, passiert Folgendes: Das Modell versucht, alles auf einmal zu tun.

Es analysiert die Anforderungen. Es entwirft ein Konzept. Es schreibt den Code. Alles in einem einzigen Schritt.

Klingt effizient. Ist es aber nicht. Ein konkretes Beispiel aus meiner eigenen Arbeit: Ich wollte ein bestehendes Authentifizierungsfeature um einen OAuth-Flow erweitern. Mein Prompt enthielt die fachlichen Anforderungen, eine Beschreibung des gewünschten Flows und die direkte Aufforderung, die nötigen Klassen zu schreiben. Das Ergebnis funktionierte – aber der Agent hatte im Zuge der Implementierung eine komplett eigene Session-Verwaltungsstruktur aufgebaut und meine bestehende schlicht übergangen. Er hatte alle drei Aufgaben gleichzeitig erledigt, und bei jeder davon Abkürzungen genommen, die ich erst Tage später entdeckte.

Die Anforderungsanalyse bleibt oberflächlich, das Konzept wird nicht wirklich validiert, und der Code enthält subtile Fehler, die sich aus den vorherigen Schwächen ergeben. Je mehr ich in einem Prompt verlange, desto weniger bekomme ich von jedem Einzelteil.

Warum das keine Bugs sind, sondern Architektur

Ich habe lange versucht, diese vier Probleme durch bessere Prompts, detailliertere Instructions-Dateien oder mehr Kontext im Fenster zu lösen. Ohne nachhaltigen Erfolg. Erst durch die Beschäftigung mit der Forschungsliteratur wurde mir klar: Diese Probleme sind keine Bugs, die ein Prompt-Tuning behebt. Sie sind Konsequenzen aus der fundamentalen Architektur von Language Models.

• Lost in the Middle: Forschende aus Stanford und Berkeley haben gezeigt, dass die Leistung von LLMs erheblich sinkt, wenn die relevanten Informationen in der Mitte eines langen Kontexts stehen (Liu et al., 2024). Wenn deine Coding-Guidelines und der bestehende Code das Kontextfenster füllen, „vergisst" die KI die Regeln in der Mitte, sobald sie sich auf die komplexe Logik am Ende konzentrieren muss.
• Context Rot und Redundanz: Eine Analyse von über 33.000 Agent-verfassten Pull Requests auf GitHub hat gezeigt, dass abgelehnte PRs systematisch größere Codeänderungen, mehr veränderte Dateien und mehr Duplikationen aufweisen (Ehsani et al., 2026). Die Studie identifiziert explizit „doppelte PRs und unerwünschte Feature-Implementierungen" als typische Symptome von Agent-Misalignment – also genau das, was ich als Duplikations-Problem erlebt habe.
• Halluzinationen durch fehlenden Projektkontext: Forschende haben drei Hauptkategorien von Code-Halluzinationen identifiziert, wobei Projektkontextkonflikte für 24,56% aller Fehler verantwortlich sind (Hallucination in LLM-based Code Generation, 2024). Dazu kommen Anforderungskonflikte (43,53%) – das Modell generiert Code, der nicht dem entspricht, was wirklich gefordert wurde. Beides sind keine Flüchtigkeitsfehler, sondern strukturelle Schwächen, die auftreten, wenn das Modell zu viele Unbekannte auf einmal auflösen muss.

Das Muster ist überall dasselbe: Die Modelle performen gut, solange der Kontext klein, klar und fokussiert ist. Sobald Aufgaben wachsen, Kontexte länger werden und mehrere Verantwortlichkeiten in einem einzigen Prompt zusammenfließen, bricht die Qualität systematisch ein.

Der Weg, der sich mir gezeigt hat

Wenn das Problem systemisch ist, braucht es eine systemische Lösung. Mehr Prompt-Text löst ein Attention-Problem nicht – es verschlimmert es. Was wirklich hilft, ist das Gegenteil: den Kontext aufteilen, die Verantwortlichkeiten trennen, den Fokus eines jeden Schrittes eng halten.

In meinem neuen Workflow trenne ich konsequent drei Phasen voneinander, die ich bisher in einem einzigen Prompt zusammengefasst hatte:

1. Die Analyse: Was soll gebaut werden? Welche Anwendungsfälle gibt es?
2. Das Konzept: Wie soll es gebaut werden? Was ist die technische Architektur?
3. Die Umsetzung: Schreib den Code – streng nach Plan.

Jede dieser Phasen bekommt einen eigenen, spezialisierten Agenten mit einem kleinen, präzisen Kontext. Kein Agent muss alles wissen. Jeder Agent tut genau das, worin er am besten ist.

Das klingt nach mehr Arbeit – und das ist es anfangs auch. Aber es ist die Art von Mehrarbeit, die langfristig massiv Zeit spart, weil Code-Duplikation, Architekturbrüche und Regelverstöße gar nicht erst entstehen oder im schlimmsten Fall dramatisch reduziert werden.

Wie dieses Setup im Detail aussieht, welche Agenten welche Rollen übernehmen und wie der Handoff zwischen ihnen funktioniert, beschreibe ich in den folgenden Posts dieser Serie.

Fazit

Vibe Coding ist kein Fehler. Es ist ein mächtiges Werkzeug – für die richtige Aufgabe in der richtigen Phase. Für schnelle Experimente, isolierte Funktionen oder Prototypen ist es kaum zu schlagen.

Aber für das, was ich täglich tue – komplexe Features in einer gewachsenen Codebase mit klaren Architekturvorgaben entwickeln – ist es unzureichend. Die vier Probleme, die ich beschrieben habe, sind keine Bugs im System. Sie sind Eigenschaften eines Systems, das zum aktuellen Zeitpunkt ein beschränktes Kontextfenster hat und umfangreiche Aufgabestellungen in einem Prompt nicht sauber erledigen kann.

Die Konsequenz, die ich gezogen habe: Ich denke nicht mehr in Prompts, sondern in Prozessen. Und Prozesse brauchen Rollen – spezialisierte Agenten, die genau eine Sache sehr gut machen, statt viele Dinge mittelmäßig.

Im nächsten Post dieser Serie stelle ich die ersten beiden Agenten vor, die in meinem Workflow die Planung übernehmen: den Business Analysten und den Solution Architect.