Die Begeisterung über generative KI in der Softwareentwicklung ist groß. Slogans wie “now anyone can be a builder”1 erwecken den Eindruck, dass die Erstellung von Software durch generative KI-Assistenten zu einer trivialen Nebentätigkeit schrumpft. Doch in der Praxis mittlerer und großer Unternehmen zeigt sich das fundamentale Missverständnis, nämlich die falsche Annahme, dass das reine Schreiben von Code der Haupttreiber für Kosten und Zeitaufwand in der Softwareentwicklung sei.
Wenn die reine Erzeugung von Code durch KI-Agenten nahezu augenblicklich erfolgt, werden die eigentlichen Engpässe im Software Development Life Cycle (SDLC) sichtbar und treten in den vor- und nachgelagerten Phasen deutlich in Erscheinung. Diese Dynamik beschreibt auch der DORA-Report 2025: “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses.”2 KI ist im SDLC kein Ersatz für organisatorische Leistungsfähigkeit. Schlechte Prozesse werden durch KI nicht optimiert, sondern in ihrer Ineffizienz verstärkt.
Zu den entscheidenden Schlüsseldisziplinen gehören folglich umso mehr Business Analysis, Requirements Engineering, Domänenmodellierung, das Treffen von Architekturentscheidungen und die Validierung der generierten Artefakte, um nur einige Beispiele zu nennen.
Die Validierung risikobehafteter Änderungen am Quellcode durch manuelle Code-Reviews wird meines Erachtens auch weiterhin der wichtigste Schritt im SDLC bleiben. Hier sind tiefgreifende Erfahrung in der Softwareentwicklung unerlässlich, denn letztlich muss zwingend ein Mensch die Verantwortung (Accountability) für die generierten Artefakte übernehmen.
Und so offenbart sich ein kritisches Paradoxon. Es stellt sich unweigerlich die Frage, wie die nächste Generation die notwendigen Kompetenzen für die Validierung komplexer Systeme erlangt, wenn die handwerkliche Lernphase, also z.B. das jahrelange Schreiben von Code, mittels KI-Agenten übersprungen wird.
Doch dieser Frage werde ich mich in einem zukünftigen Artikel widmen. Im Folgenden betrachte ich stattdessen die Spezifikationen als wichtiges Fundament des SDLC und als Teil des Kontextes, ohne den Code nicht sinnvoll validiert werden kann.
Warum KI-Agenten an klassischen User Stories scheitern
In der agilen Softwareentwicklung werden User Stories bewusst vage formuliert, um Entwicklungsteams ausreichend Freiraum bei der Umsetzung zu lassen. In der Zusammenarbeit mit autonomen KI-Agenten stößt dieses Vorgehen jedoch schnell an seine Grenzen.
Was früher durch Kommunikation (“individuals and interactions”) während der Implementierung geklärt werden konnte, muss nun im Vorfeld zu Papier gebracht werden. Dies erfordert ein höheres Maß an abstraktem Denkvermögen sowie die Fähigkeit, komplexe Sachverhalte so strukturiert zu beschreiben und mit dem relevanten Kontext anzureichern, dass ein KI-Agent sie in das gewünschte Ergebnis übersetzen kann.
Erschwerend kommt hinzu, dass schwammige Spezifikationen zu einem erhöhten Bedarf an kostspieligen Kompensationsstrategien der KI-Agenten führen. Fehlt die nötige Präzision, versuchen KI-Agenten die Unklarheit durch unkoordinierte Kontext-Exploration zu kompensieren. Sie lesen irrelevante Dateien, geraten in Schleifen und produzieren Artefakte, die von der eigentlichen Anforderung abweichen, was wiederum entsprechenden Mehraufwand nach sich zieht.
Der Paradigmenwechsel zu “Spec-First”
Aus dieser Erkenntnis ergibt sich eine zentrale These: Der erfolgreiche Einsatz von KI-Agenten im Enterprise-Umfeld erfordert den Übergang zu strukturierten, spezifikationsgetriebenen Methoden. Anstatt Code ad hoc zu generieren, muss jede Änderung systematisch an einer Spezifikation verankert werden (Spec-first & Spec-anchored).
Existierende Ansätze für Spec-Driven Development (SDD) wie Kiro, Spec-Kit oder Tessl versuchen solche Herausforderungen zu lösen, erweisen sich jedoch bei kleineren Änderungen oft als zu komplex. Sie führen zu einem unverhältnismäßigen Overhead an Markdown-Dokumenten, die validiert und synchron gehalten werden müssen. Gleichzeitig bleibt die Balance zwischen globalen Systemanweisungen und Projektkontext, wie er z.B. in einer AGENTS.md definiert wird, und aufgabenspezifischen Details im Prompt eine Herausforderung.
Ein Lösungsansatz, der Prompts nicht länger als administrativen Overhead, sondern als werthaltige architektonische Assets begreift, ist das Structured-Prompt-Driven Development (SPDD) mit dem REASONS-Canvas, wie es von Thoughtworks-Autoren beschrieben wird.3 Hierbei werden Prompts als versionierte, wiederverwendbare Artefakte behandelt, die Anforderungen, Domänenentitäten, Lösungsansatz, Struktur, konkrete Operationen sowie Normen und Sicherheitsleitplanken (Safeguards) formalisieren.
In meinen eigenen praktischen Projekten hat sich dieses Paradigma als essenziell erwiesen. Ich folge dabei dem Grundsatz: “Passe zuerst die Spezifikation an, und generiere erst danach den Code.” Wenn sich Anforderungen im Verlauf der Entwicklung ändern oder Fehler in der Implementierung auftreten, wird nicht der Code direkt korrigiert, sondern die Spezifikation angepasst und der Code daraus neu abgeleitet. Dies zwingt dazu, die eigentliche logische Absicht sauber zu dokumentieren und verhindert das schleichende Auseinanderdriften von Dokumentation und Code.
Fazit und Ausblick
Der Übergang zu spezifikationsgetriebenen Ansätzen verdeutlicht, dass im KI-Zeitalter das Schreiben von Code nicht länger zu den wertvollsten Disziplinen gehört. Neben der Validierung der generierten Artefakte ist auch die präzise Formulierung der Absicht dahinter entscheidend. Für eine wirksame Governance im Enterprise-Umfeld müssen Spezifikationen und Quellcode als untrennbare Einheit gemeinsam im Code-Repository versioniert werden. Nur so bleibt die dokumentierte Absicht synchron mit dem tatsächlichen Zustand der Software.
Doch selbst präzise Spezifikationen stoßen an eine unüberwindbare Grenze: Der inhärente Nicht-Determinismus von LLMs lässt sich systembedingt nicht auflösen und führt unweigerlich zu abweichenden Implementierungen. Strukturierte Prompts allein reichen nicht aus, um die Risiken dieser Varianz zu mitigieren. Es braucht robuste Kontrollmechanismen und eine engmaschige Validierungsebene.
Die Industrie hat diese Herausforderung erkannt. Was als Prompt Engineering begann, also die Kunst, einzelne Anweisungen zu optimieren, entwickelt sich gerade zu einer umfassenderen Disziplin: dem Context Engineering4. Nicht der einzelne Prompt entscheidet über die Qualität des Ergebnisses, sondern der gesamte Kontext, in dem ein KI-Agent operiert. Wie sich dieser Paradigmenwechsel konkret auf die Prozesse und Rollen im Enterprise-SDLC auswirkt, werde ich in einem Folgeartikel untersuchen.