Die vier Realitäten der KI-gestützten Softwareentwicklung

Wer heute mit Cursor, Claude Code oder ähnlichen Coding-Agenten arbeitet, kennt das Gefühl: Die ersten Iterationen laufen glatt, der Code entsteht fast wie von selbst. Doch nach einigen Dutzend Änderungen, wenn die Codebase wächst und die Anforderungen sich präzisieren, beginnt etwas zu kippen. Der Agent implementiert Features, die niemand so wollte. Architekturentscheidungen, die klar dokumentiert schienen, werden ignoriert. Non-funktionale Anforderungen verschwinden im Rauschen des Kontexts.

Das Problem liegt nicht an mangelnder Intelligenz der Modelle oder unzureichenden Prompts. Es liegt an einer fundamentaleren Herausforderung: In der KI-gestützten Entwicklung existieren mindestens vier unterschiedliche, oft divergierende Bilder davon, was die Software ist, sein soll und wie sie funktioniert. Diese Bilder sind selten in Einklang, und je komplexer das Projekt wird, desto deutlicher treten die Diskrepanzen zutage.

Die vier Realitäten

Das mentale Modell des Entwicklers ist das Bild im Kopf desjenigen, der den Coding-Agenten steuert. Es beinhaltet die Gesamtarchitektur, die Design-Entscheidungen der letzten Wochen, implizite Konventionen und die strategische Richtung des Projekts. Dieses Modell ist reich an Kontext, aber schwer zu externalisieren. Ein erfahrener Entwickler trägt Hunderte von Entscheidungen und deren Rationale im Kopf, die nie vollständig dokumentiert wurden.

Das Arbeitsbild des Coding-Agenten unterscheidet sich fundamental vom mentalen Modell des Entwicklers. Der Agent operiert auf dem, was im aktuellen Kontext verfügbar ist: die letzten Nachrichten der Konversation, ausgewählte Dateien, vielleicht eine Projektdokumentation. Dieses Bild ist explizit, aber notwendigerweise reduziert. Selbst mit Kontextfenstern von über einer Million Token kann nicht die gesamte Geschichte eines Projekts präsent gehalten werden. Der Agent „vergisst“ nicht im eigentlichen Sinne, aber sein Zugriff auf frühere Entscheidungen ist durch die Mechanik des Kontextmanagements limitiert.

Der tatsächliche Zustand des Codes ist die dritte Realität. Die Codebase entwickelt sich durch jede Iteration weiter, häuft technische Schulden an, enthält Quick-Fixes und temporäre Lösungen. Sie reflektiert nicht nur die ursprünglichen Intentionen, sondern auch alle Kompromisse, Workarounds und nachträglichen Änderungen. Der Code ist die akkumulierte Geschichte aller Entscheidungen, guter wie schlechter.

Die eigentliche Nutzererwartung ist die vierte und oft am meisten vernachlässigte Realität. Sie existiert meist nur fragmentiert in User Stories, Requirements-Dokumenten oder verbal geäußerten Wünschen. Doch was ein Nutzer wirklich will, zeigt sich oft erst beim Arbeiten mit der Software. Die initiale Spezifikation ist selten das finale Produkt.

Wo Divergenz entsteht: Konkrete Problemszenarien

Die Diskrepanz zwischen diesen vier Realitäten manifestiert sich in charakteristischen Problemmustern. Betrachten wir ein typisches Szenario aus der Praxis: Ein Team entwickelt ein Dashboard-System. Die Spezifikation fordert „Echtzeit-Updates der Metriken“. Der Entwickler hat im Kopf, dass dies durch WebSockets mit Fallback auf Polling realisiert werden soll, mit einer maximalen Latenz von zwei Sekunden. Der Coding-Agent implementiert nach mehreren Iterationen eine Lösung, die technisch funktioniert, aber die Datenbank alle 500 Millisekunden abfragt, weil die architektonischen Constraints aus dem Kontext gefallen sind. Der resultierende Code funktioniert in Tests mit wenigen simulierten Nutzern. Was der Nutzer eigentlich wollte: Wichtige Änderungen sofort sehen, alles andere kann auch einmal pro Minute aktualisiert werden.

Hier divergieren alle vier Bilder. Die Spezifikation war zu vage. Das mentale Modell des Entwicklers war detaillierter, aber nicht vollständig kommuniziert. Der Agent operierte auf einem reduzierten Kontext und traf die naheliegendste Implementierungsentscheidung. Der Code selbst ist technisch korrekt, aber ineffizient. Und die eigentliche Nutzererwartung wurde nie präzise erfasst.

Dieses Problem verschärft sich mit der Größe der Codebase. In unserer Arbeit mit modernizer-agent-Architekturen haben wir beobachtet, dass prompt-basierte Regeln hochgradig unzuverlässig werden, sobald die Codebase eine kritische Größe überschreitet. Ein Prompt, der definiert: „Nutze immer TypeScript Strict Mode, implementiere Error Boundaries für alle React Components, und halte API-Responses unter 200ms“ wird in den ersten 50 Dateien konsistent befolgt. Bei Datei 150 beginnt der Agent, diese Regeln selektiv zu ignorieren. Nicht aus Böswilligkeit, sondern weil sie im Rauschen des expandierenden Kontexts untergehen.

Kontext-Verlust: Wenn Trajectory und Regeln erodieren

Das technische Kernproblem liegt in der Natur des Kontextmanagements. Aktuelle Studien zeigen, dass selbst bei Modellen mit großen Kontextfenstern die „lost-in-the-middle“-Problematik auftritt. Informationen, die weder ganz am Anfang noch ganz am Ende des Kontexts stehen, werden mit geringerer Zuverlässigkeit berücksichtigt. Für einen Coding-Agenten bedeutet dies: Die ursprüngliche Architekturdokumentation steht am Anfang, die aktuelle Aufgabe am Ende, aber die architektonischen Entscheidungen der letzten 20 Iterationen verschwinden in der Mitte.

Das führt zu einem zweiten Problem: Trajectory Loss. Der Agent verliert das übergeordnete Ziel aus den Augen. Was als „Implementiere ein User-Management-System mit Role-Based Access Control“ begann, mutiert nach 100 Iterationen zu „Fixe den Login-Bug“ und „Füge ein weiteres Feld zum User-Modell hinzu“. Die strategische Ebene geht verloren, der Agent operiert nur noch taktisch auf der Ebene einzelner Code-Fixes.

Non-funktionale Anforderungen sind davon besonders betroffen. Während funktionale Features konkret und testbar sind, bleiben Anforderungen wie „Der Code soll wartbar sein“ oder „Performance-kritische Pfade müssen optimiert werden“ vage. Sie verschwinden zuerst aus dem effektiven Kontext des Agenten. In großen Projekten beobachten wir regelmäßig, dass Security-Best-Practices, Performance-Optimierungen oder Accessibility-Richtlinien nach einigen Hundert Codezeilen inkonsistent werden. Der Agent erinnert sich an die funktionale Logik, aber die qualitätssichernden Nebenbedingungen erodieren.

Kurze Unterbrechung in eigener Sache – danach geht’s weiter im Text.

15 Minuten für (D)ein erfolgreiches KI-Projekt

Ansatz 1: Specification-Driven Development

GitHub’s Spec-Kit adressiert diese Probleme durch einen radikalen Ansatz: Die Spezifikation wird zur single source of truth. Statt Code als primäres Artefakt zu betrachten, invertiert Spec-Kit die Hierarchie. Code wird aus der Spezifikation generiert, und wenn etwas nicht stimmt, wird nicht der Code gefixt, sondern die Spezifikation überarbeitet und der Code neu generiert.

Der Ansatz strukturiert Entwicklung in klar definierte Phasen: Specification, Plan, Tasks, Implementation. Jede Phase hat eigene Dokumente und Prompts. Eine Constitution-Datei definiert projektweite Prinzipien, die über alle Phasen hinweg gelten sollen. Die Idee: Wenn die Regeln in einem strukturierten, maschinenlesbaren Format vorliegen, können sie konsistent durchgesetzt werden.

Das löst tatsächlich einige der beschriebenen Probleme. Die Trennung von Spezifikation und Implementierung zwingt zur Explizierung von Architekturentscheidungen. Die Constitution hilft, non-funktionale Anforderungen zentral zu verankern. Und die phasenweise Struktur gibt dem Agenten ein klareres Zielbild für jeden Schritt.

Aber es entstehen neue Probleme. Das gravierendste: Der Nutzer fehlt in dieser Gleichung weitgehend. Spec-Driven Development setzt voraus, dass die initiale Spezifikation korrekt und vollständig ist. In der Realität entwickelt sich das Verständnis dessen, was benötigt wird, erst beim Arbeiten mit der Software. Der klassische agile Ansatz, schnell etwas Funktionierendes zu bauen und dann basierend auf Feedback zu iterieren, wird schwieriger. Jede Änderung muss zurück in die Spezifikation fließen, die Spezifikation muss überarbeitet werden, und dann wird neu generiert. Das ist ein heavyweight-Prozess, der schnelle Experimente bremst.

Zudem verschiebt es das Alignment-Problem nur: Statt dass das mentale Modell des Entwicklers und das Arbeitsbild des Agenten divergieren, divergieren nun die formale Spezifikation und das, was tatsächlich benötigt wird. Die Spezifikation wird zum neuen Bottleneck.

Ansatz 2: Multi-Agent Orchestration mit ClaudeFlow und SPARC

ClaudeFlow und die SPARC-Methodik (Specification, Pseudocode, Architecture, Refinement, Completion) versuchen das Problem durch Aufgabenteilung zu lösen. Statt einem monolithischen Agenten, der alles machen soll, orchestriert ClaudeFlow spezialisierte Agenten: Ein Queen-Agent koordiniert, Worker-Agents übernehmen spezifische Aufgaben wie Spezifikation, Architektur, Testing oder Deployment.

Die Theorie ist bestechend: Jeder Agent hat ein fokussiertes Bild seiner Domäne. Der Spezifikations-Agent konzentriert sich auf Requirements, der Architektur-Agent auf Systemdesign, der Test-Agent auf Qualitätssicherung. Die Coordination-Logik sorgt dafür, dass die Outputs zwischen den Agenten fließen und am Ende ein kohärentes Ganzes entsteht.

In der Praxis vervielfacht dieser Ansatz jedoch das Bild-Problem. Jetzt gibt es nicht mehr nur die Diskrepanz zwischen Entwickler-Modell, Agent-Bild, Code und Nutzererwartung, sondern zwischen den mentalen Modellen verschiedener spezialisierter Agenten. Der Spezifikations-Agent hat ein Bild der Requirements, der Architektur-Agent ein Bild der Systemstruktur, der Code-Agent ein Bild der Implementierung. Diese Bilder müssen nun synchronisiert werden.

Aus unseren Erfahrungen mit Swarm-Architekturen: Die Übergabe von Aufgaben zwischen Agenten ist hochgradig unzuverlässig. Ein Agent erstellt eine Spezifikation, übergibt sie an den Architektur-Agent, dieser erstellt einen Plan, übergibt ihn an den Code-Agent. Bei jedem Handoff gehen Nuancen verloren. Der Code-Agent versteht eine architektonische Intention anders als sie gemeint war, weil der Kontext der ursprünglichen Diskussion nicht vollständig mitgegeben wurde.

Noch kritischer: Die Trajectory über mehrere Agent-Schritte hinweg ist schwierig zu erhalten. Der Spezifikations-Agent hatte ein klares Bild des Gesamtziels. Nach mehreren Übergaben durch Architektur-, Code- und Test-Agent ist dieses Bild fragmentiert. Jeder Agent hat seinen Teil bearbeitet, aber niemand hat mehr das Gesamtbild. Es entsteht das klassische Problem verteilter Systeme: Konsistenz-Garantien zwischen unabhängigen Akteuren sind teuer und fehleranfällig.

Die Antwort von ClaudeFlow darauf ist ein persistentes Memory-System mit SQLite-Datenbanken und geteiltem State. Doch das verschiebt das Problem nur auf eine andere Ebene: Jetzt muss entschieden werden, welche Informationen im Shared State landen und wie sie strukturiert werden. Zu viele Information, und das System wird langsam und unübersichtlich. Zu wenige, und kritische Kontexte gehen verloren.

Ansatz 3: Context Engineering und die Illusion großer Kontexte

Die jüngsten Entwicklungen in der KI-Entwicklung adressieren die Probleme auf Modell- und Tooling-Ebene. GPT-5 Codex, Gemini 2.5 Pro und Claude Sonnet 4.5 bringen massiv erweiterte Kontextfenster (über eine Million Token bei Gemini), verbesserte „Reasoning“-Fähigkeiten und explizite Mechanismen für multi-step planning.

Context Engineering wird als eigenständige Disziplin etabliert. Techniken wie hierarchical summarization, selective context pruning und intelligent memory systems versuchen, das Kontextproblem zu managen. Claude Code implementiert beispielsweise auto-compaction: Bei 95 Prozent Kontextauslastung wird die gesamte bisherige Trajectory zusammengefasst, wobei architektonische Entscheidungen und ungelöste Probleme priorisiert werden.

Diese Ansätze zeigen messbare Verbesserungen. Die Benchmark-Zahlen sind beeindruckend: GPT-5 erreicht 74.9 Prozent auf SWE-bench Verified, ein komplexes Testset basierend auf realen GitHub-Issues. Das sind deutliche Fortschritte gegenüber früheren Modellen.

Dennoch ist die Hoffnung, dass große Kontextfenster das Problem fundamental lösen, eine Illusion. Das Problem ist nicht nur die Kompression. Selbst wenn alle Regeln, alle Architekturentscheidungen, alle Anforderungen im Kontext präsent sind, werden sie nicht zuverlässig befolgt. Studien zur „lost-in-the-middle“-Problematik zeigen: Informationen, die nicht am Anfang oder Ende des Kontexts stehen, haben deutlich geringeren Einfluss auf die Modellantwort. Eine Constitution mit 50 Regeln im Kontext zu haben bedeutet nicht, dass alle 50 bei jeder Entscheidung berücksichtigt werden. Der Kontext ist präsent, aber kognitiv nicht wirksam.

In der Praxis äußert sich das darin, dass prompt-basierte Regeln mit wachsendem Kontext zunehmend ignoriert werden. Nicht weil sie nicht mehr im Kontext sind, sondern weil sie im Rauschen untergehen. Ein Prompt, der fordert „Nutze immer TypeScript Strict Mode, implementiere Error Boundaries für alle React Components, halte API-Responses unter 200ms, schreibe Tests für alle Public APIs, dokumentiere alle Exported Functions“ wird anfangs befolgt. Nach 200 Files werden einzelne Regeln selektiv vergessen. Nach 500 Files ist die Befolgung weitgehend zufällig, selbst wenn die Regeln technisch noch im Kontext sind.

Das größere Problem: Bessere Modelle und besseres Context Management lösen nicht die Diskrepanz zwischen formaler Spezifikation und tatsächlicher Nutzererwartung. Sie helfen dem Agenten, seine Aufgabe besser zu erfüllen, aber sie helfen nicht dabei zu erkennen, ob es die richtige Aufgabe ist. Ein Agent, der perfekt eine falsch verstandene Requirement umsetzt, ist nicht besser als einer, der es imperfekt tut.

Was gelöst wurde, was bleibt

Betrachten wir die Fortschritte nüchtern. Die folgende Übersicht zeigt, welche Probleme durch die diskutierten Ansätze adressiert wurden und wo fundamentale Herausforderungen bestehen bleiben.

Die Bilanz ist gemischt. Technische Probleme wie Kontextverlust und Trajectory-Management werden besser adressiert. Die fundamentale Alignment-Herausforderung zwischen den vier Realitäten bleibt jedoch weitgehend ungelöst. Specification-Driven Development bringt Struktur, macht aber den Feedback-Loop zum Nutzer schwerfällig. Multi-Agent-Orchestration verteilt die Komplexität, führt aber neue Koordinationsprobleme ein. Bessere Modelle und Context Engineering erhöhen die technische Zuverlässigkeit, ändern aber nichts an konzeptionellen Missverständnissen.

Adaptive Systems statt Perfect Automation

Die Zukunft der KI-gestützten Entwicklung liegt vermutlich nicht in perfekter Automatisierung, sondern in adaptiven Systemen, die die Divergenz zwischen den vier Realitäten explizit machen und Mechanismen zu deren Abgleich bieten. Statt zu versuchen, alle Informationen in einen perfekten Kontext zu packen, brauchen wir Tools, die Inkonsistenzen erkennen und thematisieren.

Ein Coding-Agent, der merkt, dass die aktuelle Implementierung von der dokumentierten Architektur abweicht, und dies explizit anspricht. Ein System, das erkennt, wenn non-funktionale Anforderungen in den letzten 50 Commits ignoriert wurden, und den Entwickler darauf hinweist. Tools, die die Lücke zwischen Spezifikation und beobachtetem Nutzerverhalten transparent machen.

Die technischen Bausteine dafür entstehen gerade. Verbesserte Reasoning-Modelle können Meta-Fragen stellen. Persistent Memory Systems können historische Entscheidungen nachvollziehbar machen. Multi-modale Systeme können Code, Dokumentation und Nutzerfeedback zusammenführen. Doch der entscheidende Shift ist konzeptionell: Weg von der Illusion perfekter Spezifikation und vollautomatischer Umsetzung, hin zu Systemen, die mit Unsicherheit und Ambiguität produktiv umgehen können.

Bis dahin bleibt die Arbeit mit Coding-Agenten eine Gratwanderung: Genug automatisieren, um produktiv zu sein. Genug menschliches Urteil einbinden, um nicht in subtile Fehlentwicklungen abzudriften. Und vor allem: Die vier Realitäten der Software nicht aus den Augen verlieren, selbst wenn der Agent mit beeindruckender Geschwindigkeit Code produziert. Denn am Ende müssen sie konvergieren – und das können die besten Modelle noch nicht allein leisten.