Jedes andere KI-Coding-Tool konkurriert auf derselben Achse: mehr Code, schneller, aus kürzeren Prompts. Kiro, die agentische IDE von AWS, setzt auf das Gegenteil. Das Tool weigert sich, Produktionscode zu schreiben, bevor eine Spezifikation vorliegt. Diese Spezifikation umfasst ein Anforderungsdokument, ein Design-Dokument und eine Aufgabenzerlegung, alles generiert aus einer einzigen User Story. Das Ergebnis: KI-gestützte Entwicklung, bei der die KI versteht, was sie baut und warum, bevor sie eine einzige Zeile anfasst.
Das ist kein kosmetischer UX-Unterschied. Es ist eine grundlegend andere Theorie darüber, wie KI Software schreiben sollte. Und nach Monaten realer Nutzung zeigt sich: Für neue Features in Teams, die Vorhersagbarkeit über Geschwindigkeit stellen, produziert Kiros Ansatz messbar weniger Nacharbeitszyklen als Prompt-und-Hoffen-Alternativen.
Was Kiro wirklich ist (und was nicht)
Kiro ist ein VS Code Fork mit tiefer KI-Integration, gebaut von AWS. Wer Cursor oder Windsurf kennt, findet sich sofort zurecht: gleiche Editor-Oberfläche, gleiches Extension-Ökosystem, gleiche Tastenkürzel. Bestehende VS Code Extensions funktionieren ohne Anpassung.
Der Unterschied ist architektonisch. Wo Cursor KI auf einen Editor schraubt, baut Kiro drei Abstraktionsebenen zwischen Absicht und generiertem Code:
- Specs: Strukturierte Dokumente, die Anforderungen, Designentscheidungen und Implementierungsaufgaben festhalten
- Hooks: Ereignisgesteuerte Automatisierungen, die bei Dateiänderungen feuern (Tests ausführen, Doku generieren, Typen aktualisieren)
- Steering Files: Markdown-Dateien in
.kiro/steering/, die Projektkontext, Codierungsstandards und Tech-Stack definieren
Das sind keine optionalen Features, die man in einem Einstellungsmenü entdeckt. Sie sind der Kernworkflow. Wenn man Kiro bittet, ein Feature zu bauen, beginnt es mit einer Spezifikation, nicht mit Code.
Die zugrundeliegenden KI-Modelle kommen von Amazon Bedrock. Das gibt Kiro Zugriff auf Claude, Amazons eigene Modelle und weitere Foundation Models über eine einzige Integration. Man wählt nicht manuell ein Modell; Kiro routet Anfragen basierend auf der Aufgabe.
Was Kiro nicht ist
Kiro ist kein universelles KI-Coding-Speedtool. Wer in 20 Minuten einen Prototyp zusammenklicken will, ist mit Cursor oder Claude Code schneller bedient. Kiros Spec-Workflow kostet Vorlaufzeit. Die Wette: Diese Zeit zahlt sich aus durch weniger Debugging, weniger Nacharbeit und weniger “funktioniert, aber das war nicht gemeint”-Momente, die beim Vibe Coding ständig passieren.
Spezifikationsgetriebene Entwicklung: Anforderungen vor Code
Die Kerninnovation in Kiro ist Spec-Driven Development, eine dreiphasige Pipeline, die eine User Story über strukturierte Zwischendokumente in funktionierenden Code überführt.
So sieht das in der Praxis aus. Man beschreibt ein Feature in natürlicher Sprache:
“Füge einen Warenkorb hinzu, der Mengenänderungen und Artikelentfernung unterstützt und über localStorage sitzungsübergreifend persistiert.”
Kiro fängt nicht an, React-Komponenten zu schreiben. Stattdessen generiert es drei Artefakte, wobei jedes auf dem vorherigen aufbaut:
Phase 1: Anforderungsdokument
Eine strukturierte Aufschlüsselung funktionaler und nicht-funktionaler Anforderungen, Grenzfälle und Akzeptanzkriterien. Für das Warenkorb-Beispiel enthält das Punkte wie “Warenkorb muss gleichzeitige Tab-Updates handhaben,” “Menge muss auf verfügbaren Bestand begrenzt sein” und “Warenkorb-Status muss Browser-Refresh überleben.”
Man prüft und bearbeitet dieses Dokument. Fehlende Anforderungen ergänzen. Nicht zutreffende entfernen. Hier fängt man Missverständnisse ab, bevor sie zu Code werden.
Phase 2: Design-Dokument
Basierend auf den genehmigten Anforderungen generiert Kiro ein technisches Design: Komponentenarchitektur, Datenstrukturen, API-Verträge und State-Management-Ansatz. Für den Warenkorb könnte das ein React Context Provider mit useReducer-Pattern vorschlagen, einen localStorage-Sync-Hook mit Debouncing und TypeScript-Interfaces für CartItem und CartState.
Phase 3: Aufgabenliste
Das Design wird in diskrete, geordnete Implementierungsaufgaben zerlegt. Jede Aufgabe ist klein genug, dass Kiro sie in einer einzelnen Agenten-Aktion ausführen kann, mit klaren Eingaben, Ausgaben und Verifikationskriterien.
Erst nach Freigabe aller drei Dokumente beginnt Kiro mit dem Codeschreiben. Und weil jede Aufgabe auf Design und Anforderungen verweist, ist der generierte Code nachvollziehbar: Man sieht, warum eine bestimmte Implementierungsentscheidung getroffen wurde.
Das ist das Gegenteil von Vibe Coding. Wo Vibe Coding sagt “beschreib einfach, was du willst, und vertrau der KI,” sagt spezifikationsgetriebene Entwicklung “definiere präzise, was du willst, überprüfe, ob die KI es verstanden hat, dann lass sie ausführen.”
Hooks: Ereignisgesteuerte Automatisierung für konsistenten Code
Kiros Hook-System ist der Punkt, an dem die IDE vom “KI-Assistenten” zum “KI-Teammitglied” wird. Hooks sind ereignisgesteuerte Automatisierungen, die bei bestimmten Ereignissen im Projekt feuern. Konzeptionell ähnlich wie Git Hooks, aber sie operieren auf Datei-Ebene und werden von KI-Agenten gesteuert.
Praktische Beispiele:
- Beim Speichern: Automatisch Unit-Tests für die geänderte Datei generieren oder aktualisieren
- Bei neuer Komponente: Entsprechende Typdefinitionen und Storybook-Stories generieren
- Bei API-Routenänderung: OpenAPI-Spec und clientseitige Typen aktualisieren
- Bei Dependency-Update: Sicherheitsaudit und Kompatibilitätsprüfung ausführen
Hooks werden in der Projektkonfiguration definiert und laufen im Hintergrund. Die entscheidende Designentscheidung: Hooks arbeiten autonom, produzieren aber sichtbare, überprüfbare Änderungen. Man sieht genau, was der Hook getan hat, und kann seine Ausgabe akzeptieren, ändern oder ablehnen.
Das löst ein reales Problem in der KI-gestützten Entwicklung. Bei Tools wie Cursor schreibt man Code und bittet die KI dann separat, Tests zu schreiben. Bei Kiro-Hooks erscheinen die Tests automatisch beim Speichern. Die Dokumentation aktualisiert sich, wenn sich der Code ändert. Typen bleiben synchron ohne manuelles Prompting.
Steering Files: Persistenter Kontext für KI-Verhalten
Steering Files sind Markdown-Dokumente in .kiro/steering/, die Kiros KI-Agent mitteilen, wie er sich im konkreten Projekt verhalten soll. Sie definieren:
- Produktkontext: Was die Anwendung tut, wer sie nutzt, welche geschäftlichen Randbedingungen gelten
- Codierungsstandards: Teamkonventionen für Benennung, Fehlerbehandlung, Logging und Architekturmuster
- Tech-Stack-Details: Welche Bibliotheken verwendet werden, welche vermieden werden sollen, Versionsbeschränkungen und Integrationsmuster
Steering Files funktionieren wie ein persistenter System-Prompt, der für jede KI-Interaktion im Projekt gilt. Statt bei jedem Prompt “verwende Tailwind, nicht styled-components” zu wiederholen, schreibt man es einmal in ein Steering File, und Kiro hält sich bei allen Specs, Hooks und Chat-Interaktionen daran.
Für DACH-Unternehmen ist das besonders relevant: DSGVO-Anforderungen, teamspezifische Architekturrichtlinien oder Vorgaben des BSI zur sicheren Softwareentwicklung lassen sich direkt in Steering Files kodifizieren. Die KI berücksichtigt sie dann automatisch, ohne dass jeder Entwickler sie bei jedem Prompt erwähnen muss.
Kiro vs. Cursor vs. Claude Code: Unterschiedliche Wetten auf dasselbe Problem
Diese drei Tools lösen KI-gestütztes Coding mit fundamental unterschiedlichen Architekturen. Die Wahl zwischen ihnen ist keine Frage von “besser” oder “schlechter,” sondern welche Wette zum eigenen Workflow passt.
| Kiro | Cursor | Claude Code | |
|---|---|---|---|
| Kernthese | Bessere Specs produzieren besseren Code | Geschwindigkeit und Flow-Zustand zählen am meisten | Terminal-native Autonomie mit vollem Codebase-Kontext |
| Workflow | Spec → Design → Aufgaben → Code | Prompt → Code → Iterieren | Kommando → Agent führt aus → Diff prüfen |
| Ideal für | Neue Features, Team-Standardisierung | Rapid Prototyping, edit-intensive Workflows | Komplexe Refactorings, Multi-File-Änderungen |
| Preis | Kostenloser Tarif, Pro ab 19 $/Monat | 20 $/Monat (Pro), 40 $/Monat (Business) | Nutzungsbasiert über Anthropic API |
| Modellzugang | Bedrock-Modelle (Claude, Amazon Nova) | Multi-Modell (GPT-4.1, Claude, Gemini) | Claude Opus 4.6, Sonnet 4.6 |
| Alleinstellungsmerkmal | Hooks + Steering Files | Tab-Vervollständigung + Multi-File-Edits | Agent Teams, 1M Token Kontext |
Wo Kiro gewinnt: Projekte, bei denen Vorhersagbarkeit wichtiger ist als Geschwindigkeit. Enterprise-Teams, die Features gegen eine Produktspezifikation bauen. Codebases, in denen Konsistenz durch Konventionen erzwungen wird. Szenarien, in denen “die KI hat etwas Unerwartetes gemacht” ein ernstes Problem ist.
Wo Kiro verliert: geschwindigkeitskritische Workflows. Wer an einer UI iteriert und Änderungen in Sekunden sehen will, den bremst Kiros Spec-Pipeline aus. Für schnelle Bugfixes oder kleine Patches fühlt sich ein Anforderungsdokument für eine Zwei-Zeilen-Änderung übertrieben an.
Das Review des Graphite-Teams bringt diesen Tradeoff auf den Punkt: “Kiros Specs-Feature ist für größere Features wirklich innovativ, aber für schnelle Edits lohnt sich der Overhead nicht.”
Für wen Kiro wirklich sinnvoll ist
Kiro passt am besten zu drei Profilen:
Teams mit starken Konventionen, die die KI befolgen soll. Wer einen Style Guide, Architekturmuster und Code-Review-Standards hat, kann diese Regeln einmal in Steering Files kodieren. Jede KI-Interaktion respektiert sie dann automatisch. Das ist günstiger, als Konventionsverletzungen im Code Review zu fangen.
Entwickler, die Features gegen Produktspezifikationen bauen. Wer ohnehin PRDs oder User Stories schreibt, bevor er programmiert, findet in Kiros Spec-Pipeline eine direkte Abbildung des bestehenden Workflows. Die KI generiert den technischen Implementierungsplan aus den Produktanforderungen, was den Übersetzungsverlust zwischen Produktwunsch und Engineering-Umsetzung reduziert.
AWS-affine Unternehmen auf Bedrock. Kiros tiefe Integration mit Amazon Bedrock AgentCore bedeutet: IDE, KI-Modelle und Cloud-Infrastruktur teilen sich Authentifizierung, Abrechnung und Governance. Für Organisationen, die bereits in AWS investiert sind, vereinfacht das Compliance und Kostenverfolgung erheblich. Gerade für DACH-Unternehmen mit strengen Anforderungen an Datenverarbeitung innerhalb der EU ist das ein relevanter Vorteil.
Wer sich in keinem dieser Profile wiederfindet, ist mit Cursor oder Claude Code wahrscheinlich besser bedient. Kiro ist ein fokussiertes Werkzeug, das in seinem Einsatzbereich hervorragend funktioniert, kein universeller Ersatz für jeden KI-Coding-Workflow.
Häufig gestellte Fragen
Was ist Kiro IDE und wer hat es entwickelt?
Kiro ist eine spezifikationsgetriebene KI-IDE von Amazon Web Services (AWS). Es ist ein VS Code Fork, der strukturierte Spezifikationen (Anforderungsdokumente, Design-Dokumente und Aufgabenlisten) generiert, bevor Code geschrieben wird. Es nutzt Amazon Bedrock für den KI-Modellzugang und ist mit einem kostenlosen Tarif verfügbar.
Ist Kiro IDE kostenlos?
Ja. Kiro bietet einen unbegrenzten kostenlosen Tarif, der agentischen Chat, Autovervollständigung, Inline-Edits, Agent Hooks, Specs, Steering Files und MCP-Unterstützung umfasst. Ein Pro-Plan ist ab 19 Dollar pro Monat mit zusätzlichen Features und höheren Nutzungslimits verfügbar.
Was ist spezifikationsgetriebene Entwicklung in Kiro?
Spezifikationsgetriebene Entwicklung ist Kiros Kernworkflow, bei dem die KI drei strukturierte Dokumente generiert, bevor Code geschrieben wird: ein Anforderungsdokument, ein Design-Dokument und eine Implementierungs-Aufgabenliste. Jede Phase baut auf der vorherigen auf, und man prüft und genehmigt jedes Artefakt vor dem nächsten Schritt. Das reduziert Nacharbeit, indem Missverständnisse erkannt werden, bevor sie zu Code werden.
Wie schneidet Kiro im Vergleich zu Cursor ab?
Kiro und Cursor verfolgen unterschiedliche Ansätze. Cursor optimiert für Geschwindigkeit und Flow mit schneller Tab-Vervollständigung und Multi-File-Edits. Kiro optimiert für Vorhersagbarkeit und Korrektheit durch spezifikationsgetriebene Entwicklung, Hooks und Steering Files. Cursor eignet sich besser für Rapid Prototyping. Kiro für strukturierte Feature-Entwicklung, bei der Konsistenz und Nachvollziehbarkeit zählen.
Was sind Kiro Hooks und Steering Files?
Hooks sind ereignisgesteuerte Automatisierungen, die automatisch bei Projektereignissen laufen, etwa Tests beim Speichern generieren oder Typen aktualisieren, wenn sich eine API-Route ändert. Steering Files sind Markdown-Dokumente in .kiro/steering/, die Projektkontext, Codierungsstandards und Tech-Stack definieren. Sie wirken wie persistente Anweisungen, die alle KI-Interaktionen im Projekt leiten.