Kiro vs. Vibe Coding: Warum Spec-Driven Development der Schlüssel für nachhaltigen Enterprise-Code ist
Beim Tauchen schätze ich vor allem zwei Dinge: absolute Ruhe und fehlerfreie Präzision. Genau diese Präzision hat mir beim reinen "Vibe Coding" mit generativer KI immer gefehlt, besonders wenn es um sichere Enterprise-Architekturen geht.
Letzten Dienstag, 24. Februar, war ich in Frankfurt und habe AWS Kiro einem Kreis von Kollegen vorgestellt. Die Gesichter haben Bände gesprochen.
Das war der Moment, in dem ich wusste: Ich muss das aufschreiben.
Die Illusion des Vibe Codings und die Enterprise-Realität
"Einfach drauf los zucoden und der generativen KI blind zu vertrauen, bringt uns vielleicht kurzfristig schnell ans Ziel. Aber der entstandene Code ist am Ende oft ein unwartbarer Albtraum, der architektonisch in einer Sackgasse endet."
Das ist nicht Theorie. Das ist der Befund nach Wochen intensiver Arbeit mit generativer KI im Enterprise-Kontext.
Vibe Coding, das Prinzip, eine KI durch natürlichsprachliche Prompts Code generieren zu lassen ohne feste Spezifikationen, funktioniert für Prototypen, Demos und Skripte. Der Weg zum lauffähigen Code ist kurz. Das Feedback-Loop ist schnell. Man sieht Ergebnisse.
Aber Enterprise-Code trägt andere Anforderungen: Sicherheit, Auditierbarkeit, Wartbarkeit, klare Verantwortlichkeiten zwischen Komponenten. Ein Compliance-Tool für Cloud-Infrastrukturen kann es sich nicht leisten, auf einem architektonischen Flickenteppich zu stehen. Wer mit generativer KI ohne Struktur baut, bekommt Code, der heute funktioniert und morgen niemand mehr versteht, geschweige denn anpasst.
Das Gegenstück dazu ist Spec-Driven Development. Und genau das macht AWS Kiro zum anderen Werkzeug.
Die Architektur: Ein echter Härtetest (3-Tier-Monorepo)
Ich habe keine Spielzeugprojekte gebaut. Das Produkt ist ein AWS Compliance Snapshot Tool, ein SaaS-Produkt für Cloud-Sicherheits-Compliance. Gebaut allein, ohne Entwicklungsteam, ab dem 27. Januar 2026.
Die Architektur ist ein 3-Tier-Monorepo:
- Infrastruktur: Terraform mit 18 Modulen
- Backend: Python AWS Lambda Functions (10 in Phase 1, 19 gesamt geplant)
- Frontend: Next.js-Applikation
- CI/CD: GitLab Pipeline mit 1.167 Zeilen
Das ist kein Prototyp. Das sind echte Schichten, echte Abhängigkeiten, echte Sicherheitsanforderungen. Terraform-Module müssen aufeinander abgestimmt sein. Lambda-Funktionen müssen sauber voneinander getrennt bleiben. Die Pipeline muss deterministisch sein.
Genau an dieser Komplexität scheitert Vibe Coding. Je größer die Architektur, desto schneller verliert ein unkontrollierter Agent den roten Faden. Er halluziniert Abhängigkeiten, überschreibt Konfigurationen, bricht Schnittstellen. Die Korrektheit des Outputs eines einzelnen Prompts sagt nichts über die strukturelle Kohärenz der Gesamtarchitektur aus.
Das ist der Härtetest, den ich Kiro ausgesetzt habe: Kann ein KI-Agent eine Produktionsarchitektur dieser Komplexität über Wochen konsistent und korrekt weiterentwickeln? Die Antwort hängt fast ausschließlich an der Methode, nicht am Modell.
Der Paradigmenwechsel: Spec-Driven Development erklärt
"Kiro zwingt einen dazu, nachzudenken, bevor auch nur eine Zeile Code geschrieben wird."
Das ist der zentrale Unterschied. Und er ist tiefgreifend.
In Kiros Spec Mode erstellt man vor jedem Feature eine strukturierte Spezifikation unter .kiro/specs/. Jede Spec besteht aus drei Dateien: requirements.md, design.md und tasks.md. Die Requirements werden in EARS-Notation formuliert: "WHEN [Bedingung] THE SYSTEM SHALL [Verhalten]". Das ist keine akademische Übung. Es ist das Handwerk, das Mehrdeutigkeiten herausschneidet, bevor sie zu Code werden.
Das Design-Dokument beschreibt die technische Umsetzung auf Komponentenebene: welche Datenstrukturen, welche Interfaces, welche Abhängigkeiten. Die Tasks-Datei unterteilt das Design in atomare, ausführbare Arbeitseinheiten.
Das Resultat: Der Agent hat für jeden Task genau das richtige Kontextwissen.
"Wenn der Agent einen spezifischen Task ausführt, sucht er sich direkt das dazugehörige Design. Er weiß exakt, was er tun muss, ohne den gesamten Projektkontext in den Speicher laden zu müssen."
Das ist architektonisch elegant. Große Codebases haben große Kontextfenster-Probleme. Wer den Agent mit dem gesamten Projektkontext lädt, kämpft gegen Drift, Halluzinationen und inkonsistente Entscheidungen. Wer den Kontext pro Feature kapselt, behält Kontrolle. Die Spec ist die Grenze. Der Agent arbeitet innerhalb dieser Grenze präzise.
33 Specs habe ich in den ersten vier Wochen erstellt. Jede davon ist ein dokumentierter Entscheidungsraum, der nachvollziehbar bleibt, auch wenn der Agent längst zum nächsten Feature übergegangen ist.
Langzeitgedächtnis und Automatisierung: Steering, Skills & Hooks
Specs lösen das Feature-Level-Problem. Aber ein Projekt über Wochen konsistent zu halten braucht mehr als Feature-Spezifikationen. Es braucht persistentes Projektwissen.
Kiro löst das mit Steering Files unter .kiro/steering/. Bei mir sind das drei Kerndokumente: product.md (Was ist das Produkt, welche Entscheidungen wurden warum getroffen), tech.md (Technologie-Stack, Konventionen, Verbote), structure.md (Wie ist das Repo aufgebaut, welche Schicht gehört wohin). Diese Dateien laden automatisch bei jeder Session. Der Agent vergisst keine Entscheidung, die einmal dokumentiert wurde.
Darüber hinaus gibt es Skills: modulare Instruktionspakete für wiederkehrende Aufgaben. Einen Skill für das Erstellen von Lambda-Funktionen. Einen für das Schreiben von Terraform-Modulen. Einen für die Test-Generierung. Der Skill definiert, wie die Aufgabe aussehen soll. Der Agent führt sie konsistent nach diesem Standard aus.
Hooks sind ereignisgesteuerte Automatisierungen: "When X, Then Y". Wenn eine neue Datei erzeugt wird, führe diesen Check aus. Wenn ein Task abgeschlossen wird, schreibe das Changelog. Diese Trigger laufen im Hintergrund, ohne dass ich jeden Schritt manuell anstoßen muss.
Das Zusammenspiel dieser drei Mechanismen macht den Autopilot Mode möglich:
"Es kam vor, dass ich einen massiven Task komplett vorspezifiziert, auf 'Go' geklickt und mich schlafen gelegt habe. Der Agent hat zweieinhalb Stunden autonom gearbeitet."
Das ist kein Marketingversprechen. Das ist der normale Workflow nach vier Wochen Kiro. Der Kontext ist sauber. Die Steering Files sind vollständig. Der Scope ist in der Spec definiert. Der Agent braucht keinen Babysitter.
Wer mehr über Best Practices im Umgang mit diesen Mechanismen erfahren möchte, findet Material in diesem Repository: github.com/awsdataarchitect/kiro-best-practices
Transparenz durch harte Daten: Git-Historie nach 4 Wochen
Nach 19 aktiven Arbeitstagen, Phase 1 von 27. Januar bis 19. Februar 2026, sieht die Git-Historie so aus:
- 175.000+ Netto-Codezeilen
- 305 Commits
- 16,1 Commits pro Tag im Durchschnitt
- 60+ Frontend-Komponenten
- 143 generierte Test-Dateien
- ca. 80% Testabdeckung
- 33 Kiro Specs
Diese Zahlen interessieren mich nicht als Leistungsnachweis. Sie interessieren mich als Validierung der Methode. 305 Commits über 19 Tage bedeuten: der Fortschritt ist granular, dokumentiert, reversibel. 33 Specs bedeuten: jede dieser Commit-Serien hat einen dokumentierten Entscheidungsraum hinter sich. 143 Testdateien bedeuten: der Code ist nicht nur entstanden, er ist auch geprüft.
Das ist der Unterschied zwischen Vibe Coding und Spec-Driven Development in Zahlen.
Qualitätssicherung: Property-based Tests
80% Testabdeckung allein sagen wenig. Was zählt, ist, was die Tests testen.
Für Backend und Infrastruktur nutze ich Property-based Tests. Statt fixer Eingaben definiert man Eigenschaften, die der Code für jede gültige Eingabe erfüllen muss. Das Testsystem generiert Hunderte von Testfällen automatisch und versucht, die Eigenschaft zu widerlegen. Diese Methode findet Edge Cases, die klassische Beispieltests systematisch übersehen.
Der Kiro Agent generiert diese Tests aus den EARS-Anforderungen in den Specs. Weil die Anforderungen präzise formuliert sind, können die Tests präzise sein. Die Spezifikation ist das Fundament der Testqualität.
Darüber hinaus entsteht durch die 33 Specs ein Testplan, der nicht nachträglich ergänzt wird, sondern von Anfang an Teil der Feature-Spezifikation ist. Tests sind keine Nacharbeit, sie sind Teil des Designs.
143 Test-Dateien für 19 Arbeitstage bedeuten: durchschnittlich mehr als 7 neue Test-Dateien pro Tag. Das ist kein manuell erreichbarer Rhythmus. Es ist das Ergebnis einer Methode, die Qualitätssicherung als ersten Schritt behandelt, nicht als letzten.
Die kognitive Realität: Ein völlig neuer Entwickler-Alltag
Was sich wirklich verändert hat, ist nicht die Geschwindigkeit des Code-Outputs. Es ist mein Arbeitstag.
Ich bin kein Code-Writer mehr. Ich bin "Intent Steerer" und "Code Auditor". Ich beschreibe präzise, was das System tun soll. Ich überprüfe, ob der Agent das korrekt umgesetzt hat. Und ich treffe architektonische Entscheidungen, für die meine 10 AWS-Zertifizierungen und meine Erfahrung als Cloud Security Architect entscheidend sind, nicht meine Fähigkeit, Python zu tippen.
Das klingt nach weniger Arbeit. Es ist mehr.
Ein Tag als Intent Steerer und Code Auditor ist kognitiv anspruchsvoller als ein Tag als Developer. Man liest mehr Code als man je selbst schreiben würde. Man trifft mehr Entscheidungen pro Stunde. Man muss jeden Output des Agents verstehen und bewerten, bevor man ihn merged. Ein grüner Build ist kein Freifahrtschein.
Das ist die mentale Verschiebung, die viele unterschätzen, wenn sie über KI-gestütztes Coding sprechen. Das Modell schreibt den Code. Aber jemand muss den Code verstehen. Und dieser jemand muss tiefer verstehen als je zuvor, weil er Verantwortung für Code trägt, den er nicht Zeile für Zeile selbst formuliert hat.
"Wir bauen nicht nur schneller, sondern sicherer und wartbarer."
Aber das gilt nur, wenn die Person, die den Intent steuert, weiß, was sicher und wartbar bedeutet. Die KI kann Konventionen folgen. Den Unterschied zwischen einer sicheren und einer komplizierten Architektur versteht sie nur dann, wenn man ihr das Wissen in den Steering Files, Specs und Skills bereitgestellt hat.
Setzt ihr in euren Teams bereits Agentic AI ein? Wie geht ihr mit der massiv gestiegenen kognitiven Belastung des ständigen "Code-Reviewens" um? Und glaubt ihr, dass "Spec-Driven" das "Vibe Coding" im Enterprise-Sektor vollständig ablösen wird?