Von EARS-Anforderungen über technisches Design bis zum Task-Plan: Amazon Kiro führt spezifikationsgetrieben durch den gesamten AI-Driven-Development-Workflow.

Was ist Amazon Kiro?

Amazon Kiro ist eine auf Visual Studio Code basierende Entwicklungsumgebung (IDE). Kiro wird von Amazon Web Services (AWS) angeboten und zielt darauf ab, Entwickler:innen beim Umstieg auf AI-Driven Development zu begleiten. Im Gegensatz zu anderen IDEs, die zur Anbindung von AI-Agenten in der Regel zusätzliche Plugins benötigen, bringt Kiro die AI-Integration von Haus aus mit.

Das Besondere an Kiro ist sein vorgegebener, spezifikationsgetriebener Entwicklungsansatz. Entwickler:innen erstellen mit AI-Unterstützung zunächst Anforderungen in der sogenannten EARS‑Notation. Darauf gehe ich weiter unten noch detaillierter ein. Anschließend generiert Kiro ein technisches Design und einen detaillierten Implementierungsplan inklusive der abzuarbeitenden Aufgaben. Mithilfe von AI-Agenten werden die Aufgaben dann automatisiert umgesetzt. Kiro bietet zudem Funktionen wie “Agent Hooks” für ereignisgesteuerte Automatisierungen. Auf diese werde ich in diesem Post allerdings nicht weiter eingehen.

Kiro nutzt die jeweils aktuellsten Anthropic‑Modelle, die Amazon über AWS Bedrock bereitstellt. Man kann das konkrete Anthropic-Modell entweder manuell auswählen oder die Auswahl abhängig von der abzuarbeitenden Aufgabe Kiro überlassen.

Kiro kann zunächst ohne weitere Kosten heruntergeladen und ausprobiert werden (https://kiro.dev). Basis hierfür ist ein Credit-System, man hat also eine gewisse Anzahl an Anfragen pro Monat frei, bis die Credits aufgebraucht sind. Danach muss ein Abo abgeschlossen werden. Details dazu finden sich auf der oben verlinkten Kiro-Website.

Der Kiro‑Workflow im Überblick

Kiro kennt zwei Hauptmodi, zwischen denen man beim Starten einer neuen Session mit der AI wechseln kann: “Vibe Session” für schnelles Prototyping und “Spec Session” für strukturierte, spezifikationsgetriebene Entwicklung. Letzteres ist die empfohlene Variante für ernsthafte Projekte und bildet den Kern von Kiro. Ich gehe im Folgenden nur auf die Spec‑Sessions ein. Die Vibe-Sessions entsprechen im Wesentlichen dem bekannten AI‑Driven Development mit Plugins wie GitHub Copilot oder OpenAI Codex (siehe dazu auch meinen früheren Blogbeitrag OpenAI Codex vs. GitHub Copilot). Wer sich für einen stärker agentenzentrierten IDE-Ansatz interessiert, findet in AI-Driven Development mit Google Antigravity eine spannende Alternative.

Struktur einer Spec‑Session

Kiro gliedert den Entwicklungsprozess einer Spec-Session in drei Phasen und ordnet ihnen jeweils eine Datei im Workspace zu: Anforderungsermittlung (Requirements.md), technischer Entwurf (Design.md) und Implementierung (Tasks.md). Jede Phase baut auf der vorherigen auf, der Wechsel erfolgt explizit durch den Nutzer. Die jeweilige Datei wird hierbei automatisch generiert bzw. aktualisiert. Das eigentliche Coding erfolgt erst, wenn der Implementierungsplan in der Tasks.md‑Datei vorliegt. Dieses strukturierte Vorgehen entspricht meiner Ansicht nach den Best Practices bei der Umsetzung eines AI‑Driven‑Development‑Prozesses.

Für jede Spec-Session legt Kiro automatisch ein Verzeichnis unterhalb von /.kiro/specs/ im Workspace an. Für einfache Projekte wie meine Beispielanwendung reicht eine einzige Spec-Session aus. Bei komplexeren Projekten bietet es sich an, beispielsweise pro Jira-Epic oder sogar pro User-Story eine eigene Spec-Session anzulegen, um die Übersicht zu behalten.

Requirements.md mit EARS‑Notation

Der Kiro‑Workflow beginnt mit der Ermittlung und Dokumentation der Anforderungen in der Requirements.md-Datei. Interessant ist hierbei vor allem die Verwendung der EARS‑Notation. EARS steht für „Easy Approach to Requirements Syntax“. Die Notation wurde 2009 von Alistair Mavin bei Rolls-Royce entwickelt, um die Mehrdeutigkeit natürlicher Sprache durch eine strukturierte Syntax mit einer geringen Anzahl von Schlüsselwörtern zu reduzieren. Im Prinzip folgt eine Anforderung in EARS immer dem folgenden Muster (es gibt noch diverse Erweiterungen und Varianten, siehe auch die Originaldokumentation auf https://alistairmavin.com/ears):

WHILE "Voraussetzung" WHEN "Auslöser" THE "Systemname" SHALL "Systemreaktion"

Beispiel:

WHEN eine Administratorin oder ein Administrator eine Umfrage
  mit Titel und Ersteller:in (optional Beschreibung, Start- und Enddatum) anlegt,
THEN THE Survey_System
SHALL eine neue Umfrage mit einer generierten eindeutigen Kennung erstellen
  und alle angegebenen Metadaten speichern

WHILE und WHEN definieren die Bedingungen, unter denen die Anforderung gilt, während SHALL die erwartete Reaktion des Systems beschreibt. Im Regelfall wird entweder WHILE oder WHEN verwendet, um die Anforderung zu spezifizieren. Der Mix aus englischen Schlüsselwörtern und deutscher Sprache ist hierbei sicher gewöhnungsbedürftig. Grundsätzlich könnte man die Schlüsselwörter auch ins Deutsche übersetzen, allerdings ist EARS in der Originalsprache Englisch dokumentiert und die meisten Beispiele sind auf Englisch verfasst. Zudem ist unklar, ob Tools wie Kiro die deutsche Übersetzung korrekt interpretieren würden.

Kiro unterstützt den gesamten Spezifikationsprozess in der EARS‑Notation. Hierzu können beispielsweise vorhandene Anforderungsdokumente als Basis verwendet werden. Alternativ ist es auch möglich, zusammen mit den fachlichen Stakeholdern (und Kiro) die Spezifikation in Frage-Antwort-Form zu erarbeiten.

Ein vollständiges Beispiel für eine Requirements.md-Datei zeigt die EARS‑Notation in der Praxis.

Design.md: Technischer Entwurf

Um in die Design-Phase zu wechseln, klickt man in Kiro bei geöffneter Requirements.md auf den Button „2 - Design“ und im Anschluss auf “Generate design based on requirements”. Kiro analysiert dann die Anforderungen und erstellt automatisch ein technisches Design in der Design.md-Datei. Hier erkennt man sehr schön den Unterschied zu anderen IDEs mit AI-Integration: Kiro unterstützt aktiv bei der Strukturierung des Entwicklungsprozesses.

Allerdings hat dieser Automatismus auch seine Tücken: Kiro generiert das Design zunächst ausschließlich basierend auf den Anforderungen. Das Ergebnis war in meinen Tests durchaus okay, meine Beispielanwendung (eine Umfrage-App) ist aber auch denkbar trivial. Wie alle AI-Modelle greifen auch die Anthropic-Modelle auf Wahrscheinlichkeiten zurück, und im Ergebnis entsteht eine mehr oder weniger generische Architektur für einen Microservice mit REST-API und Datenbankanbindung. In realen Projekten gibt es allerdings immer zusätzliche Randbedingungen und Anforderungen, die im Anforderungsdokument nicht explizit genannt werden, die aber dennoch Einfluss auf das Design haben (z. B. bestehende Architekturvorgaben, spezielle nicht-funktionale Anforderungen wie Performance oder Skalierbarkeit, bevorzugte Technologien oder Frameworks etc.).

Ich empfehle daher sich vor der Generierung des Designs Gedanken über die Architektur zu machen und diese in einer eigenen Markdown-Datei zu dokumentieren. Zusätzlich sollte immer ein semantisches Datenmodell erstellt werden, um die Datenstrukturen und deren Beziehungen klar zu definieren (siehe hierzu auch meinen Blogbeitrag). Diese Vorarbeit kann man Kiro dann nochmal vorlegen, mit der Bitte, das Design entsprechend zu überarbeiten.

Unabhängig davon hat mir aber die Struktur des generierten Design-Dokuments gut gefallen. Es enthält unter anderem:

• Architekturübersicht mit den vordefinierten Schichten (REST-Controller, Services, Repositories, Entities)
• Techstack (Spring Boot 3.x, Java 21, PostgreSQL, JPA/Hibernate)
• Design-Entscheidungen (UUIDs, Validation-First, kaskadierendes Löschen, stateless REST).
• API-Spezifikationen für alle Endpunkte
• Datenmodell für die Entitäten
• Test-Setup: Kiro schlägt hier standardmäßig zusätzlich zu den klassischen Unit-Tests einen “Property-Based Testing” (PBT) Ansatz vor. PBT ist eine Technik, bei der anstelle von einzelnen Testfällen allgemeine Eigenschaften (Properties) definiert werden, die der Code erfüllen muss. Das Test-Framework generiert dann automatisch eine Vielzahl von Eingabedaten, um diese Eigenschaften zu überprüfen. Dies kann helfen, Randfälle und unerwartete Eingaben abzudecken, die in herkömmlichen Unit-Tests möglicherweise übersehen werden. PBT kommt aus der funktionalen Programmierung und wird beispielsweise in Sprachen wie Haskell oder Scala häufig eingesetzt. In der Java-Welt ist PBT weniger verbreitet, es gibt aber Bibliotheken wie beispielsweise jqwik, die diesen Ansatz unterstützen. Meines Erachtens ist diese von Kiro vorgeschlagene Teststrategie ein typisches Beispiel für die Vorteile, die ein AI‑Driven‑Development‑Prozess bieten kann: Durch die Unterstützung durch AI-Agenten können Entwickler:innen neue Techniken und Best Practices kennenlernen und in ihren Workflow integrieren, die sie sonst vielleicht nicht in Betracht gezogen hätten.

Das vollständige Beispiel für die generierte Design.md-Datei zeigt das von Kiro erzeugte technische Design.

Tasks.md: Implementierung

Sobald die Design-Phase abgeschlossen ist, wechselt man in Kiro über den Button „3 - Task list“ in die Implementierungsphase. Kiro generiert daraufhin automatisch eine Tasks.md-Datei, die einen Implementierungsplan enthält. Schön gelöst ist hier die automatische Auswahl des “richtigen” Kontexts: Kiro kennt nun Anforderungen und Design und analysiert zudem automatisch den bestehenden Code im Workspace.

Der Plan strukturiert die eigentliche Implementierung in Aufgaben und Unteraufgaben. Jede Aufgabe ist mit den entsprechenden Anforderungen verknüpft, es ist also jederzeit nachvollziehbar, warum eine bestimmte Aufgabe umgesetzt wird. Kiro priorisiert den Plan zudem automatisch nach Abhängigkeiten, sodass die Aufgaben in der “richtigen” Reihenfolge abgearbeitet werden können.

Die eigentliche Implementierung erfolgt dann, indem man direkt in der Datei auf “Start Task” klickt. Dies kann für einzelne Unteraufgaben, Aufgaben oder auch für den gesamten Plan erfolgen (im diesem Fall aber nur explizit per Aufforderung im Prompt). In der Kiro-Dokumentation empfiehlt Amazon allerdings, die Aufgaben schrittweise abzuarbeiten, da dann die Gesamtqualität besser sei. Zudem behält man so die Kontrolle über den Prozess und kann die zwingend notwendigen Reviews und Tests in kleineren Häppchen durchführen.

Die Integration in den Entwicklungsworkflow ist hier wieder sehr gut gelungen: Kiro aktualisiert die Tasks.md-Datei automatisch, sobald eine Aufgabe erledigt ist. Dadurch ist es deutlich einfacher, den Überblick über den Fortschritt zu behalten als bei herkömmlichen IDEs mit AI-Plugins.

Kiro kann die Tasks im Implementierungsplan zudem automatisch an den aktuellen Stand des Sourcecodes anpassen (z. B. weil Teammitglieder Änderungen vorgenommen haben). Hierzu genügt es, den Button “Update Tasks” zu klicken. Kiro analysiert dann den Workspace und aktualisiert den Plan entsprechend. Dies umfasst auch das automatische “Abhaken” von erledigten Aufgaben, die Kiro beim Vergleich des Codes mit dem Plan als abgeschlossen erkennt.

Die eigentliche Implementierung erfolgt analog zu herkömmlichen AI-Plugins, wie beispielsweise GitHub Copilot oder OpenAI Codex. Kiro generiert Code-Snippets basierend auf dem aktuellen Kontext (Anforderungen, Design, Aufgaben, bestehender Code) und fügt diese direkt in die entsprechenden Dateien ein. Entwickler:innen können den generierten Code dann überprüfen, anpassen und in ihr Versionskontrollsystem committen.

Fazit

Kiro ist ein spannender neuer Ansatz für AI-Driven Development. Es geht über das klassische AI-Plugin hinaus und bietet einen vordefinierten, strukturierten Entwicklungsworkflow. Besonders gut gefallen hat mir die schöne Integration des Workflows in die IDE, die Struktur und Vollständigkeit der automatisch generierten Dokumente und die klare Trennung der verschiedenen Phasen.

Als den größten Nachteil von Kiro sehe ich die Festlegung auf die EARS‑Notation für die Anforderungsdokumentation. Ich finde EARS als Notation grundsätzlich hilfreich, um Anforderungen klar und testbar zu formulieren. Allerdings ist die Lesbarkeit für Menschen meines Erachtens eher schlecht, insbesondere wenn Anforderungen auf Deutsch erfasst werden. Zudem ist der Wunsch, Anforderungen derart strukturiert zu erfassen, zwar nachvollziehbar und auch wünschenswert, aber in der Praxis nicht immer einfach umzusetzen. Man muss dann sehr aufpassen, sich nicht zwei Sets an Anforderungen einzufangen: einmal die „normalen“ Anforderungen in natürlicher Sprache und einmal die EARS‑Version. Das würde viele potenziellen Vorteile von EARS wieder zunichte machen.

Ob die Limitierung auf Modelle von Anthropic ein Nachteil ist, muss jeder für sich selbst beurteilen. Ich persönlich finde die Anthropic-Modelle sehr gut, es gibt aber durchaus auch Anwendungsfälle, in denen andere Modelle besser geeignet sind.

Zusammenfassend halte ich Kiro perfekt geeignet für einen schnellen Einstieg in das Thema AI‑Driven Development: Der vorgegebene Workflow erleichtert die Umgewöhnung deutlich. Gleichzeitig kann genau diese Struktur zum Bremsklotz werden, wenn sie nicht zu den eigenen Anforderungen und Arbeitsweisen passt. In solchen Fällen ist es oft sinnvoller, bewusst Zeit in einen eigenen AI‑Driven‑Development‑Prozess zu investieren, der besser auf die individuellen Bedürfnisse zugeschnitten ist. Umsetzen lässt sich ein solcher Prozess dann auch mit anderen AI‑Plugins und Modellen in der eigenen IDE.