Erst soll die KI ausformulieren, was gewollt ist, dann darf sie schreiben. Spezifikation verwandelt Raten in Umsetzung.

Code mit einem Modell zu schreiben stößt auf ein Problem, das sich nicht umgehen lässt: Je unschärfer man formuliert, desto weiter entfernen sich die Vermutungen. Bittet man um ein Kommentarsystem für einen Blog, kommen womöglich drei Umsetzungen in drei völlig verschiedenen Stilen zurück, und bis man sich durch alle durchrevidiert hat, weiß niemand mehr, was ursprünglich gewollt war. Kiro dreht die Reihenfolge um: die Anforderung erst als Spezifikation niederschreiben, die man prüfen kann, und dann den Agenten dagegen bauen lassen.

Kiro wird von AWS entwickelt und betrieben, erschien im Juli 2025 und ist inzwischen allgemein verfügbar. Es fasst die Sache in einen Satz: vom KI-Coding zum agentic engineering. Es ist kein chatartiges Vervollständigungswerkzeug, sondern ein Ablauf, der Anforderung, Entwurf, Aufgaben und Umsetzung aneinanderreiht.

Spezifikationsgetrieben: ein Satz wird zu drei Dokumenten

Der Kern ist spezifikationsgetriebene Entwicklung. Man liefert eine einzige natürlichsprachliche Beschreibung, und es entstehen der Reihe nach drei Dokumente. Die Anforderungsdatei zerlegt das Bedürfnis in Anwendergeschichten mit Abnahmekriterien. Die Entwurfsdatei legt Architektur, Technologiewahl und Systementwurf dar. Die Aufgabendatei ist eine nach Abhängigkeiten geordnete Checkliste. Standardmäßig liegen diese Dateien in einem Spezifikationsverzeichnis im Projekt, und die offizielle Empfehlung lautet, sie zusammen mit dem Code ins Repository zu übernehmen.

Wie die Anforderungen formuliert werden, verdient einen Hinweis. Abnahmekriterien stehen in EARS-Syntax, deren Form ungefähr lautet: Wenn eine Bedingung gilt, soll das System dies und jenes tun. Die Notation stammt aus der Luftfahrtsicherheit, und ihr Wert liegt darin, eine schwammige Beschreibung in überprüfbare Aussagen zu zwingen, sodass Randfälle schwerer verlorengehen.

Jedes der drei Dokumente hält für die eigene Zustimmung an. Man kann eine Anforderung umschreiben, einen technischen Ansatz ablehnen, die Reihenfolge der Aufgaben ändern und erst dann den Agenten einzeln ausführen lassen. Alles erscheint als Diff, annehmbar in einem Zug oder Zeile für Zeile.

Vor dem Code prüfen, ob die Anforderungen sich widersprechen

Ein Schritt ist ungewöhnlich: Bevor eine Zeile Code entsteht, sucht automatisiertes Schließen nach Konflikten und Lücken in den Anforderungen. Die offizielle Begründung ist direkt. Dass alle Tests grün sind, heißt nicht, dass der Code der Absicht entspricht, also wird zuerst die Absicht selbst geprüft.

Nach der Umsetzung folgt eine weitere Prüfschicht mit eigenschaftsbasierten Tests, einer Verwandten des Fuzzings. Gewöhnliche Unit-Tests prüfen eine Handvoll konkreter Fälle; eigenschaftsbasierte Tests behaupten Regeln, die für jede Eingabe gelten müssen, und erwischen deshalb besser den Randfall, der Unit-Tests besteht und im Betrieb bricht.

Steering und Hooks: die Regeln des Projekts festnageln

In jedem neuen Gespräch erneut zu wiederholen, dass streng typisiert wird und Tests neben dem Quellcode liegen, kostet Geduld. Dafür gibt es Steering-Dateien: Markdown-Dokumente in einem Steering-Verzeichnis, die langlebiges Wissen tragen, etwa Architekturentscheidungen, Codestandards und Namenskonventionen, und die Kiro beim Erzeugen von Code und beim Prüfen von Änderungen automatisch heranzieht. Sie laden auf drei Wegen, dauerhaft, per Dateibedingung oder von Hand referenziert, und gängige Konventionen wie AGENTS.md werden ebenfalls beachtet.

Agent-Hooks machen aus Gewohnheiten, die man entwickeln sollte, etwas Automatisches. Man definiert ein Ereignis wie Speichern, Anlegen oder Löschen einer Datei und lässt den Agenten dann eine vorbereitete Aufgabe ausführen: die Testdatei ergänzen, sobald eine Komponente gespeichert wird, die Dokumentation nachziehen, sobald sich ein API-Endpunkt ändert, vor dem Commit nach versehentlich hinterlegten Zugangsdaten suchen. Der offizielle Vergleich ist eine lokal laufende Continuous Integration, mit dem Unterschied, dass die Logik in natürlicher Sprache steht statt in einem Konfigurationsdialekt.

Vier Formen, ein Satz Einstellungen

Kiro gibt es als IDE, als Kommandozeilenwerkzeug, als Web-Version, als mobile App und als dauerhaften Arbeitsbereich namens Kiro Crew. Die IDE baut auf einer quelloffenen Editorbasis und kann bestehende Editor-Einstellungen, Themen und Erweiterungen übernehmen, sodass der Umzug nicht schmerzt. Die Kommandozeile unterstützt bash, zsh und fish sowie mehr als fünfhundert gängige CLI-Werkzeuge und läuft kopflos in einer Pipeline, um Pull Requests zu prüfen oder Fehler zu beheben.

Web-Sitzungen laufen in einer isolierten Cloud-Sandbox, arbeiten nach dem Zuklappen des Laptops weiter und können Änderungen über mehrere Repositories hinweg koordinieren. Kiro Crew ist ein quelloffenes Projekt unter der Apache-Lizenz, läuft auf der eigenen Maschine, hält Kontext über Sitzungen hinweg und neigt zum langfristigen Entwicklungsarbeitsplatz.

Das Modell wählt man nicht

Die Standardeinstellung Auto leitet nach Aufgabenkomplexität weiter und wiegt Modellqualität, Latenz und Kosten gegeneinander ab. Man kann auch ausdrücklich ein Modell nennen, etwa aus der Claude-Sonnet-Reihe, oder in der kostenlosen Stufe offene Gewichte wie Qwen3 Coder Next nutzen. Bezahlte Stufen schalten fortgeschrittenere Modelle frei.

Die Abrechnungseinheit ist das Credit, verbraucht pro Prompt und auf zwei Nachkommastellen genau erfasst, sodass eine einfache Anfrage nicht einmal ein ganzes aufbraucht. Die IDE zeigt in Echtzeit, was jeder Prompt gekostet hat, damit die Rechnung niemanden überrascht.

Preis und Einstieg

Die kostenlose Stufe ist dauerhaft, bringt fünfzig Credits im Monat, verlangt keine Karte und gibt trotzdem Zugang zu den Hauptmodellen, genug, um den Spezifikationsablauf einmal durchzugehen. Bezahlte Stufen kosten zwanzig Dollar im Monat für tausend Credits, vierzig für zweitausend, einhundert für fünftausend und zweihundert für zehntausend. Zusätzliche Credits lassen sich für vier Cent das Stück kaufen. Team- und Unternehmenspläne ergänzen gebündelte Abrechnung, einmalige Anmeldung, Nutzungsübersichten und Rechteverwaltung.

Die Anmeldung akzeptiert GitHub, Google, AWS Builder ID oder AWS IAM Identity Center, und ein AWS-Konto ist nicht erforderlich, ein oft missverstandener Punkt. Der Desktop-Build deckt Windows, macOS und Linux ab.

Kiro will nicht, dass KI schneller Code schreibt, sondern dass der geschriebene Code der gewünschte ist. Erst die Anforderung als prüfbare Spezifikation festhalten, die in der Versionsverwaltung liegt, dann den Agenten umsetzen lassen, und die Runden aus Nacharbeit und Reibung werden deutlich weniger. Für ein Projekt, das über Jahre gepflegt werden muss, ist diese Disziplin ihr Geld wert.