Kiro einrichten: AWS-KI-IDE Tutorial [2026]

Amazon hat mit Kiro eine eigene KI-native Entwicklungsumgebung ins Rennen um GitHub Copilot, Cursor und Claude Code geschickt. Während AWS den Vorgänger Amazon Q Developer schrittweise abbaut, wandert die Entwicklung komplett in Kiro: eine Desktop-IDE mit Web- und CLI-Zugang, die auf strukturierten “Specs” statt auf reinen Chat-Prompts aufbaut. Für Entwicklerinnen und Entwickler in Österreich, die bisher mit Amazon Q Developer gearbeitet haben oder einfach eine neue Option zu Copilot und Cursor suchen, lohnt sich ein genauer Blick. Dieser Tutorial-Artikel zeigt Schritt für Schritt, wie die Installation gelingt, wie Specs, Hooks und Steering Files funktionieren und worauf man beim produktiven Einsatz achten sollte.

Der Artikel richtet sich an Entwickler mit Grundkenntnissen in Git, Kommandozeile und mindestens einer modernen Programmiersprache. Ziel ist ein lauffähiges Beispielprojekt, das am Ende komplett von Kiro mitgestaltet wurde, inklusive automatisierter Tests über Agent Hooks. Alle Preisangaben, Befehle und Konzepte in diesem Text stammen aus der offiziellen Kiro-Dokumentation sowie aktuellen Berichten zur Migration von Amazon Q Developer.

Was ist Kiro und warum jetzt darauf umsteigen?

Kiro ist AWS’ agentisches Entwicklungswerkzeug mit drei Zugangswegen: einer Desktop-IDE, einer Weboberfläche und einer Kommandozeilen-Variante. Anders als reine Autocomplete-Tools setzt Kiro auf einen mehrstufigen Workflow, bei dem eine Anforderung zuerst in Requirements, dann in ein technisches Design und schließlich in konkrete, abarbeitbare Aufgaben zerlegt wird. AWS nennt diesen Ablauf “Spec”-Workflow, und er ist der zentrale Unterschied zu klassischen Chat-basierten Assistenten.

Der Zeitpunkt für einen Umstieg ist kein Zufall. Berichten zufolge blockiert AWS ab 15. Mai 2026 neue Anmeldungen für Amazon Q Developer, bestehende Abos und IDE-Plug-ins sollen laut denselben Quellen bis 30. April 2027 weiterlaufen. Wer heute ein neues Projekt aufsetzt oder ein Team neu einrichtet, landet damit ohnehin bei Kiro. Für alle, die produktiv mit KI-Unterstützung programmieren, lohnt sich deshalb ein Blick auf die konkreten Schritte, bevor der Umstieg zum Pflichttermin wird.

Wichtig für die Einordnung: Die vorliegende Kiro-Dokumentation nennt aktuell keine eindeutige Versionsnummer im Format 1.x.y und auch keinen klaren Status wie “General Availability” oder “Public Preview”. Der Artikel verwendet deshalb bewusst keine erfundene Versionsnummer, sondern beschreibt den Funktionsstand, wie er sich aus der offiziellen Doku und den aktuellen Produktseiten ergibt.

Der grundsätzliche Trend hinter Kiro ist Teil einer breiteren Entwicklung in der Branche: Agentische Entwicklungsumgebungen, die nicht nur einzelne Codezeilen vorschlagen, sondern ganze Arbeitsabläufe planen und ausführen, haben sich in den letzten Jahren zu einem eigenen Marktsegment entwickelt. Anbieter wie Cursor, Windsurf oder Claude Code setzen dabei auf unterschiedliche Schwerpunkte, etwa auf besonders schnelle Autocomplete-Vorschläge oder auf tiefe Terminal-Integration. Kiro positioniert sich mit dem Spec-Workflow explizit als Werkzeug für nachvollziehbare, dokumentierte Entwicklung, bei der jede Änderung auf eine schriftlich festgehaltene Anforderung zurückführbar bleibt. Für Einzelentwickler mit kleinen Skripten ist dieser Mehraufwand oft unnötig, für Teams mit Compliance-Anforderungen oder hoher Personalfluktuation kann er sich dagegen schnell auszahlen.

Voraussetzungen: Was Sie vor der Installation brauchen

Bevor Sie mit der Installation starten, sollten folgende Punkte erfüllt sein. Kiro selbst stellt Installationsprogramme für die jeweilige Betriebssystem-Plattform bereit, exakte Mindestanforderungen wie RAM-Bedarf oder unterstützte Kernel-Versionen sollten Sie direkt auf der aktuellen Download-Seite von Kiro gegenprüfen, da sich diese Angaben schneller ändern als ein Tutorial-Artikel aktualisiert werden kann.

Ein Kiro-Konto (Anmeldung über die offizielle Kiro-Webseite, kostenlos möglich)
Git, mindestens Version 2.40, für Versionskontrolle und Repository-Klonen
Node.js 20 LTS oder neuer, falls Sie wie im Beispielprojekt dieses Tutorials mit JavaScript/TypeScript arbeiten
Ein Terminal mit Zugriff auf curl und bash für die CLI-Installation
Mindestens 8 GB freien Arbeitsspeicher für flüssiges Arbeiten mit IDE und Agenten parallel
Eine stabile Internetverbindung, da Kiro-Agenten und Modellaufrufe cloudseitig laufen

Zusätzlich sinnvoll, aber nicht zwingend: Erfahrung mit VS-Code-artigen Editoren, da sich Kiros Oberfläche stark an diesem Bedienkonzept orientiert. Wer bereits mit GitHub Copilot, Cursor oder Claude Code gearbeitet hat, findet sich in Kiro schnell zurecht, auch wenn der Spec-Workflow anfangs ungewohnt wirkt.

Planen Sie für den Einstieg außerdem etwas Zeit für die reine Umstellung ein. Wer bisher ausschließlich mit direkten Chat-Prompts gearbeitet hat, muss sich zunächst daran gewöhnen, Anforderungen vollständiger zu formulieren, statt sie in mehreren kurzen Nachfragen nachzuschärfen. Diese Umstellung dauert erfahrungsgemäß wenige Tage, zahlt sich danach aber durch weniger Korrekturschleifen aus. Für dieses Tutorial reicht ein einziger Nachmittag, um Installation, erstes Projekt und die wichtigsten Konzepte durchzuarbeiten.

Schritt 1: Kiro-Konto anlegen und Tarif wählen

Der erste Schritt ist die Kontoerstellung auf der offiziellen Kiro-Webseite. Kiro arbeitet mit einem kreditbasierten Preismodell ohne tägliche oder wöchentliche Rate-Limits, was sich deutlich von klassischen Abo-Modellen mit festen Nachrichtenkontingenten pro Tag unterscheidet. Stattdessen verbrauchen Sie ein monatliches Credit-Guthaben, das je nach Modell und Agentenaufgabe unterschiedlich schnell aufgebraucht wird.

Die folgende Tabelle zeigt die aktuellen Kiro-Tarife laut offizieller Preisseite:

Tarif	Preis pro Monat	Enthaltene Credits	Geeignet für
Free	0 US-Dollar	50	Testen und kleine Skripte
Pro	20 US-Dollar	1.000	Einzelentwickler mit regelmäßiger Nutzung
Pro+	40 US-Dollar	2.000	Intensive Solo-Projekte
Pro Max	100 US-Dollar	5.000	Mehrere parallele Projekte
Power	200 US-Dollar	10.000	Teams und große Codebasen

Der Free-Tarif ist laut Kiro-FAQ dauerhaft nutzbar, nicht nur als befristete Testphase, und bietet Zugriff auf Open-Weight-Modelle sowie auf Claude Sonnet 4.5, allerdings mit den Einschränkungen der kostenlosen Stufe. Für Teams nennt die FAQ zusätzliche Credits zum Nachkauf mit 0,04 US-Dollar pro Credit. Für den Einstieg in dieses Tutorial reicht der Free-Tarif völlig aus, da ein einzelnes Beispielprojekt selten mehr als eine Handvoll Credits verbraucht.

Schritt 2: Desktop-IDE herunterladen und installieren

Nach der Kontoerstellung laden Sie den Installer für Ihr Betriebssystem von der Kiro-Webseite herunter. Der Ablauf ist bewusst simpel gehalten und orientiert sich am Muster anderer moderner Editoren:

Installer für Windows, macOS oder Linux von der offiziellen Kiro-Seite herunterladen
Installationspaket ausführen und den Anweisungen folgen
Beim ersten Start mit dem zuvor erstellten Kiro-Konto anmelden
Ein bestehendes Projektverzeichnis öffnen oder ein neues Projekt anlegen

Nach dem ersten Login zeigt Kiro eine Oberfläche, die stark an VS-Code-artige Editoren erinnert: Seitenleiste mit Dateibaum, Editor-Tabs in der Mitte und ein Panel für den KI-Agenten am rechten Rand. Ob Kiro technisch tatsächlich auf einer VS-Code-Basis aufsetzt, ist aus der öffentlich verfügbaren Kiro-Dokumentation nicht eindeutig bestätigt, weshalb dieser Artikel hier bewusst von einer “VS-Code-ähnlichen” Oberfläche spricht statt von einem Fork.

Schritt 3: Kiro-CLI installieren

Neben der Desktop-IDE bietet Kiro eine Kommandozeilen-Variante an, die sich besonders für CI-Pipelines, Server ohne grafische Oberfläche oder für Entwickler eignet, die grundsätzlich lieber im Terminal arbeiten. Die Installation erfolgt über ein einzeiliges Skript:

curl -fsSL https://cli.kiro.dev/install | bash

Nach der Installation prüfen Sie mit einem einfachen Versionsbefehl, ob die CLI korrekt eingerichtet wurde:

kiro --version
kiro auth login

Die CLI verwendet laut Kiro dieselbe Projektkonfiguration wie IDE und Web-Oberfläche, also alle Steering Files und MCP-Konfigurationen im Verzeichnis .kiro/. Das bedeutet in der Praxis: Wenn ein Teammitglied über die Desktop-IDE Regeln für den Code-Stil festlegt, gelten diese automatisch auch, wenn ein anderes Teammitglied dasselbe Projekt über die CLI bearbeitet.

Schritt 4: Erstes Projekt anlegen und die .kiro-Struktur verstehen

Legen Sie für dieses Tutorial ein neues Verzeichnis an und initialisieren Sie ein einfaches Node.js-Projekt, das später als komplettes Beispielprojekt dient: eine kleine REST-API für eine Aufgabenliste (To-Do-API) mit Express.

mkdir kiro-todo-api
cd kiro-todo-api
npm init -y
npm install express
kiro .

Der letzte Befehl öffnet das Verzeichnis in der Kiro-IDE (sofern die CLI korrekt mit der Desktop-App verknüpft ist). Beim ersten Öffnen legt Kiro automatisch ein Verzeichnis .kiro/ an, sobald Sie erstmals Steering Files oder Hooks konfigurieren. Die Struktur sieht danach so aus:

kiro-todo-api/
├── .kiro/
│   ├── steering/
│   │   └── projekt-regeln.md
│   ├── hooks/
│   │   └── test-on-save.json
│   └── specs/
│       └── todo-api-v1/
├── src/
├── package.json
└── node_modules/

Diese Struktur ist der Kern dessen, was Kiro von reinen Chat-Assistenten unterscheidet: Projektwissen, Automatisierungsregeln und Aufgabenplanung liegen als versionierbare Dateien direkt im Repository und lassen sich über Git mit dem Team teilen, statt in einem Chatverlauf zu verschwinden.

Schritt 5: Steering Files anlegen (dauerhaftes Projektwissen)

Steering Files sind laut Kiro-Dokumentation der Mechanismus, um dem Agenten dauerhaftes Projektwissen und Arbeitsregeln mitzugeben, statt sie in jedem Prompt neu zu wiederholen. Die Dateien liegen unter .kiro/steering/ und werden von IDE, Web und CLI gleichermaßen gelesen.

Für österreichische Teams sind Steering Files besonders praktisch, um projektweite Vorgaben festzuhalten, etwa zu bevorzugten Bibliotheken, Test- und Build-Befehlen oder Datenschutz- und Logging-Regeln, die im Einklang mit der DSGVO stehen sollen. Ein einfaches Beispiel für unser To-Do-API-Projekt:

# .kiro/steering/projekt-regeln.md

## Code-Stil
- TypeScript-Strict-Mode, keine `any`-Typen ohne Kommentar
- Alle Endpunkte müssen einen Zod-Validator für den Request-Body besitzen

## Tests
- Jeder neue Endpunkt braucht einen Jest-Test unter /tests
- Testbefehl: npm run test

## Datenschutz
- Keine personenbezogenen Daten in Log-Ausgaben
- Fehlermeldungen an Clients dürfen keine Stacktraces enthalten

Sobald diese Datei existiert, berücksichtigt der Kiro-Agent die Regeln automatisch bei jedem neuen Vorschlag, ohne dass Sie sie erneut in den Chat schreiben müssen. Das reduziert wiederholte Korrekturen deutlich, vor allem in Teams mit mehreren Personen, die alle mit demselben Agenten arbeiten.

Schritt 6: Den ersten Spec-Workflow starten

Jetzt kommt das zentrale Kiro-Konzept zum Einsatz: der Spec-Workflow. Statt direkt “Schreib mir eine To-Do-API” in den Chat zu tippen, klicken Sie in der Kiro-Oberfläche auf die Schaltfläche “Spec” und beschreiben die Anforderung in eigenen Worten:

Erstelle eine REST-API für eine To-Do-Liste mit folgenden Endpunkten:
- GET /todos: Liste aller Aufgaben
- POST /todos: neue Aufgabe anlegen (Titel, erledigt-Status)
- PATCH /todos/:id: Aufgabe als erledigt markieren
- DELETE /todos/:id: Aufgabe löschen
Verwende Express und speichere die Daten zunächst im Arbeitsspeicher.

Kiro wandelt diese Beschreibung nicht sofort in Code um, sondern erzeugt zunächst ein strukturiertes Requirements-Dokument, gefolgt von einem technischen Design-Dokument und einer Liste konkreter, abhakbarer Aufgaben. Diese drei Artefakte landen unter .kiro/specs/todo-api-v1/ und lassen sich vor der eigentlichen Code-Generierung noch anpassen, etwa um einen vergessenen Endpunkt zu ergänzen oder eine Anforderung zu präzisieren.

Schritt 7: Requirements und Design-Dokument prüfen

Bevor Sie Kiro mit der Umsetzung beauftragen, lohnt sich ein Blick in das generierte Requirements-Dokument. Erfahrungsgemäß ist dieser Zwischenschritt der größte praktische Vorteil des Spec-Workflows gegenüber klassischen Chat-Assistenten: Fehlinterpretationen fallen auf, bevor hunderte Zeilen Code entstanden sind, statt erst beim Testen der fertigen Implementierung.

Typische Punkte, die Sie an dieser Stelle prüfen sollten:

Sind alle Endpunkte aus Ihrer ursprünglichen Beschreibung tatsächlich enthalten?
Hat der Agent sinnvolle Annahmen zu Fehlerfällen getroffen (zum Beispiel 404 bei nicht existierender ID)?
Passt die vorgeschlagene Datenstruktur zu Ihrem tatsächlichen Anwendungsfall?
Wurden Validierungsregeln aus Ihren Steering Files berücksichtigt?

Erst wenn Requirements und Design passen, geben Sie im Spec-Panel die Freigabe zur Umsetzung der einzelnen Tasks. Kiro arbeitet die Aufgabenliste danach Schritt für Schritt ab und zeigt für jede Aufgabe einen eigenen Diff zur Kontrolle an. Wer eine einzelne Aufgabe ablehnt, kann sie gezielt neu formulieren, ohne den gesamten Spec-Workflow neu zu starten. Das unterscheidet sich deutlich von einem einzelnen langen Chat-Prompt, bei dem eine Korrektur oft dazu führt, dass der Agent auch bereits richtige Teile der Antwort erneut verändert.

Schritt 8: Agent Hooks für automatisierte Tests einrichten

Agent Hooks automatisieren Reaktionen auf Ereignisse wie das Speichern einer Datei, das Abschließen einer Spec-Aufgabe oder die Nutzung eines bestimmten Tools. Sie werden im Kiro-Panel unter “Agent Hooks” verwaltet und lassen sich in natürlicher Sprache formulieren, woraus Kiro automatisch die passende JSON-Konfiguration erzeugt.

Für unser Beispielprojekt richten wir einen Hook ein, der nach jedem Speichern einer Datei im Verzeichnis src/ automatisch die Tests ausführt. Die Formulierung im Hook-Editor lautet zum Beispiel:

Führe nach jedem Speichern einer Datei unter src/*.ts
den Befehl "npm run test" aus und zeige das Ergebnis im Chat an.

Die daraus erzeugte Konfiguration landet als JSON-Datei unter .kiro/hooks/, etwa in dieser Form:

{
  "name": "test-on-save",
  "trigger": {
    "event": "file.saved",
    "pattern": "src/**/*.ts"
  },
  "action": {
    "type": "run_command",
    "command": "npm run test"
  }
}

Ab diesem Zeitpunkt laufen bei jeder Änderung automatisch die Tests, und Fehlschläge erscheinen direkt im Agent-Panel, ohne dass Sie manuell ein Terminal öffnen müssen. Das spart in der Praxis vor allem bei kleinen, iterativen Änderungen viel Klickarbeit.

Schritt 9: MCP-Server einbinden

Kiro unterstützt das Model Context Protocol (MCP), einen offenen Standard für die Anbindung externer Werkzeuge und Datenquellen an KI-Agenten. Die MCP-Konfiguration liegt ebenfalls im Verzeichnis .kiro/ und wird von CLI, IDE und Web-Sitzung gleichermaßen verwendet. Wer bereits einen MCP-Server eingerichtet hat, kann diesen direkt weiterverwenden.

Für unser Beispielprojekt binden wir einen einfachen Dateisystem-MCP-Server ein, damit der Agent gezielt auf Projektdateien außerhalb des aktuellen Arbeitsverzeichnisses zugreifen kann, etwa auf eine gemeinsam genutzte Bibliothek:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "../shared-lib"]
    }
  }
}

Nach dem Speichern dieser Konfiguration und einem Neustart der Kiro-Sitzung erkennt der Agent den neuen Server automatisch und kann bei Bedarf auf dessen Werkzeuge zugreifen, etwa um Dateien in der freigegebenen Bibliothek zu lesen. Neben dem Dateisystem-Server gibt es im MCP-Ökosystem inzwischen Anbindungen für Datenbanken, Ticketsysteme und interne Wissensdatenbanken. Für ein wachsendes Projekt lohnt sich deshalb ein kurzer Blick, welche MCP-Server bereits im Team im Einsatz sind, bevor eine neue, redundante Anbindung für denselben Dienst entsteht.

Schritt 10: Vollständiges Beispielprojekt zusammenführen

Nach den vorherigen Schritten haben Sie ein funktionierendes Grundgerüst. Der folgende Ausschnitt zeigt, wie die von Kiro generierte Kernlogik für die To-Do-API typischerweise aussieht, nachdem Sie die Spec-Tasks abgearbeitet haben:

import express from "express";

const app = express();
app.use(express.json());

interface Todo {
  id: string;
  title: string;
  done: boolean;
}

let todos: Todo[] = [];

app.get("/todos", (req, res) => {
  res.json(todos);
});

app.post("/todos", (req, res) => {
  const { title } = req.body;
  if (!title || typeof title !== "string") {
    return res.status(400).json({ error: "Titel fehlt oder ungueltig" });
  }
  const todo: Todo = { id: crypto.randomUUID(), title, done: false };
  todos.push(todo);
  res.status(201).json(todo);
});

app.patch("/todos/:id", (req, res) => {
  const todo = todos.find((t) => t.id === req.params.id);
  if (!todo) return res.status(404).json({ error: "Nicht gefunden" });
  todo.done = true;
  res.json(todo);
});

app.delete("/todos/:id", (req, res) => {
  todos = todos.filter((t) => t.id !== req.params.id);
  res.status(204).send();
});

app.listen(3000, () => console.log("API laeuft auf Port 3000"));

Starten Sie das Projekt und prüfen Sie die Endpunkte:

npm run dev
curl -X POST http://localhost:3000/todos -H "Content-Type: application/json" -d '{"title":"Kiro-Tutorial testen"}'

Erwartete Ausgabe nach dem POST-Aufruf:

{"id":"3f2a9c1e-...","title":"Kiro-Tutorial testen","done":false}

Damit ist das Beispielprojekt vollständig: eine funktionierende REST-API, entstanden aus einem Spec-Workflow, abgesichert durch einen automatischen Test-Hook und mit projektweiten Regeln aus einer Steering File.

Schritt 11: Von Amazon Q Developer zu Kiro migrieren

Wer bereits Projekte mit Amazon Q Developer betreibt, sollte die Migration nicht bis zum offiziellen Abschalttermin aufschieben. Berichten zufolge blockiert AWS neue Anmeldungen für Amazon Q Developer bereits ab 15. Mai 2026, während bestehende Abonnements laut denselben Berichten bis 30. April 2027 weiterlaufen sollen. Diese Daten stammen aus Sekundärquellen und sollten vor einer endgültigen Planung mit der offiziellen AWS-Ankündigung abgeglichen werden, da AWS selbst in der aktuellen Kiro-Dokumentation kein festes Abschaltdatum nennt.

Praktisch bedeutet die Migration vor allem drei Dinge: bestehende IDE-Plug-in-Konfigurationen müssen durch die .kiro/-Struktur ersetzt werden, projektspezifisches Kontextwissen sollte in Steering Files überführt werden, und Team-Workflows, die bisher auf Amazon-Q-Chat-Verläufen basierten, lassen sich sinnvoller als Specs abbilden. Mehr Hintergrund zur Umstellung liefert unser Beitrag zur Migration von Amazon Q Developer zu Kiro.

Ein praktischer Tipp für die Übergangsphase: Führen Sie beide Werkzeuge nicht dauerhaft parallel, sondern legen Sie einen festen Stichtag pro Repository fest. Ein Team, das in einem Projekt weiter mit Amazon Q Developer arbeitet und im Nachbarprojekt schon auf Kiro umgestellt hat, verliert schnell den Überblick, welche Konventionen wo gelten. Sinnvoller ist ein repository-weiser Umstieg, bei dem mit dem Umzug gleich auch die Steering Files aus den bisherigen Q-Developer-Notizen destilliert werden. Das kostet am Anfang etwas Zeit, verhindert aber, dass Wissen aus alten Chatverläufen beim Wechsel einfach verloren geht.

Team-Workflows: Wie mehrere Entwickler gemeinsam mit Kiro arbeiten

Sobald mehr als eine Person an einem Projekt mit Kiro arbeitet, wird die Struktur unter .kiro/ zum eigentlichen Koordinationswerkzeug. Weil Steering Files, Hooks und Spec-Verläufe als normale Dateien im Repository liegen, funktionieren die gewohnten Git-Mechanismen: Pull Requests, Code-Reviews und Merge-Konflikte lassen sich auf diese Konfigurationsdateien genauso anwenden wie auf Anwendungscode.

In der Praxis hat sich ein einfaches Muster bewährt: Ein Spec-Verzeichnis pro Feature-Branch. Wenn ein Entwickler einen neuen Branch für ein Feature anlegt, startet er im selben Zug einen neuen Spec-Workflow, dessen Requirements- und Design-Dokumente direkt im Pull Request mitgeprüft werden. Reviewer sehen dadurch nicht nur den fertigen Code-Diff, sondern auch die ursprüngliche Anforderung und die Designentscheidung, die zum Code geführt hat. Das erleichtert Reviews besonders bei Teammitgliedern, die den fachlichen Hintergrund einer Änderung nicht im Detail kennen.

Bei Steering Files empfiehlt sich eine klare Eigentümerschaft: Legen Sie fest, wer Änderungen an projektweiten Regeln freigeben darf, ähnlich wie bei einer CODEOWNERS-Datei für kritische Konfigurationsdateien. Ohne diese Regel passiert es leicht, dass eine Person eine Regel ergänzt, die einer anderen Konvention im selben Team widerspricht, und der Agent in der Folge widersprüchliche Vorschläge liefert. Ein kurzer Abstimmungsprozess vor dem Merge einer neuen Steering File spart hier mehr Zeit, als er kostet.

Für verteilte Teams über mehrere Zeitzonen hinweg, wie sie in vielen österreichischen Firmen mit internationalen Niederlassungen üblich sind, lohnt sich zusätzlich eine kurze Namenskonvention für Spec-Verzeichnisse, etwa mit Datum und Kürzel der verantwortlichen Person. Das erleichtert es, offene Specs schnell dem passenden Ansprechpartner zuzuordnen, wenn eine Rückfrage außerhalb der eigenen Arbeitszeit auftaucht.

Kiro in bestehende CI/CD-Pipelines einbinden

Weil die Kiro-CLI dieselbe Projektkonfiguration liest wie IDE und Web-Oberfläche, lässt sie sich grundsätzlich auch in automatisierte Pipelines einbauen, etwa um bei jedem Pull Request eine automatische Code-Review-Zusammenfassung durch den Agenten erzeugen zu lassen. Wichtig dabei: Für den nicht-interaktiven Einsatz braucht die CLI ein Zugangs-Token, das nicht im Klartext im Repository landen darf, sondern über die Secret-Verwaltung der jeweiligen CI-Plattform eingebunden werden sollte.

Ein vereinfachtes Beispiel für eine GitHub-Actions-Konfiguration, die nach jedem Push die Kiro-CLI für eine automatische Zusammenfassung offener Spec-Tasks aufruft:

name: kiro-spec-check
on: [pull_request]
jobs:
  spec-summary:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Kiro CLI installieren
        run: curl -fsSL https://cli.kiro.dev/install | bash
      - name: Spec-Status pruefen
        env:
          KIRO_TOKEN: ${{ secrets.KIRO_TOKEN }}
        run: kiro specs status --project todo-api-v1

Dieser Ansatz eignet sich vor allem für Teams, die Transparenz über offene Spec-Aufgaben direkt im Pull-Request-Workflow wollen, ohne die Kiro-Oberfläche manuell zu öffnen. Für sicherheitskritische Projekte gilt trotzdem: Automatisierte Agentenaufrufe in der Pipeline sollten nie ungeprüften Schreibzugriff auf den Hauptbranch erhalten. Änderungen, die aus einem Spec-Workflow entstehen, gehören weiterhin in einen regulären Pull Request mit menschlicher Freigabe, nicht in einen automatischen Merge ohne Review.

Häufige Fehler und wie Sie sie vermeiden

Beim Einstieg in Kiro tauchen einige Stolpersteine immer wieder auf. Die folgende Liste fasst die häufigsten Fehler aus der Praxis zusammen:

Spec-Schritt überspringen: Wer direkt “schreib den Code” fordert statt den Spec-Workflow zu nutzen, verliert den größten Vorteil von Kiro, nämlich die Kontrolle über Requirements vor der Implementierung.
Steering Files zu allgemein formulieren: Vage Regeln wie “schreibe guten Code” bringen keinen Mehrwert. Konkrete Vorgaben zu Bibliotheken, Testbefehlen und Namenskonventionen wirken deutlich zuverlässiger.
.kiro/-Verzeichnis nicht versionieren: Wird das Verzeichnis versehentlich in die .gitignore aufgenommen, gehen Steering Files und Hooks bei jedem Klon des Repositories verloren.
Credits falsch einschätzen: Größere Spec-Workflows mit mehreren Design-Iterationen verbrauchen deutlich mehr Credits als einzelne Chat-Anfragen. Für Teams lohnt sich ein Blick auf den tatsächlichen Verbrauch vor dem Wechsel in einen höheren Tarif.
Agent Hooks ungetestet lassen: Ein Hook, der bei jedem Speichern einen teuren Build-Prozess anstößt, kann Credits und Zeit unnötig verbrauchen. Hooks sollten gezielt und sparsam eingerichtet werden.
MCP-Server ohne Berechtigungsprüfung einbinden: Ein MCP-Server mit Schreibzugriff auf sensible Verzeichnisse sollte nur nach genauer Prüfung der Konfiguration aktiviert werden.
Migration von Amazon Q Developer zu spät angehen: Wer bis zum offiziellen Enddatum wartet, riskiert Zeitdruck bei der Übertragung von Team-Konventionen und Kontextwissen.

Troubleshooting: Die häufigsten Probleme bei Kiro

Auch bei sorgfältiger Einrichtung tauchen typische Probleme auf. Die meisten davon lassen sich in wenigen Minuten beheben, wenn man weiß, wo man ansetzen muss. Die folgende Übersicht ordnet die häufigsten Fehlerbilder ihren Lösungen zu, sortiert nach der Häufigkeit, mit der sie in der Praxis auftreten:

Problem	Ursache	Lösung
CLI-Installation bricht ab	Fehlende Schreibrechte im Zielverzeichnis	Installationsskript mit angepassten Berechtigungen oder in einem Nutzerverzeichnis ausführen
kiro auth login schlägt fehl	Abgelaufenes Browser-Session-Cookie	Browser-Cache für die Kiro-Domain leeren und Login erneut starten
Steering File wird ignoriert	Datei liegt nicht unter .kiro/steering/	Pfad und Dateiendung .md prüfen, Kiro-Sitzung neu laden
Agent Hook löst nicht aus	Pattern im Trigger passt nicht zum tatsächlichen Dateipfad	Pattern testen, z.B. mit einem breiteren Glob wie src/*/
Spec-Dokument wirkt unvollständig	Ursprüngliche Anforderung war zu knapp formuliert	Anforderung mit konkreten Beispielen und Randfällen ergänzen
MCP-Server wird nicht erkannt	Konfigurationsdatei falsch formatiert oder Sitzung nicht neu gestartet	JSON-Syntax mit einem Linter prüfen, Kiro neu starten
Credits werden schneller verbraucht als erwartet	Große Spec-Workflows mit vielen Design-Iterationen	Anforderungen präziser formulieren, unnötige Wiederholungen vermeiden
CLI und IDE zeigen unterschiedlichen Projektstand	.kiro/-Verzeichnis wurde nicht committet oder gepullt	Verzeichnis versionieren und vor der Arbeit git pull ausführen
Tests im Hook schlagen dauerhaft fehl	Testbefehl im Hook stimmt nicht mit package.json überein	Befehl im Hook-JSON mit dem tatsächlichen npm-Skript abgleichen

Fortgeschrittene Tipps für den produktiven Einsatz

Sobald die Grundeinrichtung steht, lohnt sich der Blick auf ein paar fortgeschrittene Kniffe. Erstens: Legen Sie für größere Projekte mehrere Steering Files nach Themen getrennt an, etwa eine Datei für Architekturentscheidungen und eine separate für Test-Konventionen, statt alles in eine einzige lange Datei zu packen. Das erleichtert spätere Anpassungen erheblich.

Zweitens: Nutzen Sie Specs auch für Refactorings, nicht nur für neue Features. Der Requirements-Schritt zwingt dazu, den gewünschten Endzustand klar zu formulieren, bevor der Agent Dateien anfasst, was bei größeren Umbauten Fehlinterpretationen deutlich reduziert.

Drittens: Kombinieren Sie Agent Hooks mit Spec-Task-Ereignissen, etwa um nach Abschluss jeder Spec-Aufgabe automatisch einen Commit mit aussagekräftiger Nachricht zu erzeugen. So entsteht eine nachvollziehbare Historie, in der jede Änderung auf eine konkrete Anforderung zurückführbar ist. Viertens: Prüfen Sie regelmäßig den Credit-Verbrauch pro Spec, um bei Teamnutzung frühzeitig zu erkennen, ob der aktuelle Tarif noch passt, bevor ein Wechsel unter Zeitdruck nötig wird.

Fünftens: Nutzen Sie separate Specs für unabhängige Teilprobleme, statt eine einzige, sehr große Anforderung zu formulieren. Ein Spec, der gleichzeitig eine neue Datenbankanbindung, eine Authentifizierung und ein neues Frontend-Modul umfasst, führt fast immer zu einem unübersichtlichen Requirements-Dokument und macht die Review vor der Umsetzung deutlich schwerer. Kleinere, klar abgegrenzte Specs lassen sich schneller prüfen, schneller umsetzen und im Fehlerfall leichter isoliert zurückrollen. Sechstens: Bewahren Sie abgeschlossene Specs bewusst auf, statt sie nach der Umsetzung zu löschen. Sie dienen später als Dokumentation, warum eine bestimmte Entscheidung getroffen wurde, und ersetzen in vielen Fällen ein separates Architekturentscheidungsprotokoll.

Laut dem 2025 Stack-Overflow-Developer-Survey nutzen oder planen bereits 84 Prozent der befragten Entwickler den Einsatz von KI-Tools im Entwicklungsprozess, ein Anstieg gegenüber 76 Prozent im Jahr davor. Gleichzeitig gaben in derselben Befragung 46 Prozent an, der Genauigkeit der Ausgaben von KI-Tools grundsätzlich nicht zu vertrauen. Genau hier setzt der Spec-Workflow von Kiro an: Durch das explizite Requirements- und Design-Dokument vor der Code-Generierung lässt sich dieses Misstrauen zumindest teilweise durch nachvollziehbare Zwischenschritte auffangen, statt der Ausgabe blind zu vertrauen.

Kiro im Vergleich zu anderen KI-Coding-Werkzeugen

Ein direkter, unabhängig belegter Benchmark-Vergleich von Kiro gegenüber GitHub Copilot, Cursor oder Claude Code liegt aktuell nicht in ausreichend belastbarer Form vor, weder zu SWE-bench-Werten noch zu Bearbeitungszeit oder Kosten pro gelöster Aufgabe. Die folgende Tabelle beschränkt sich deshalb bewusst auf offiziell bestätigte, strukturelle Unterschiede statt auf unbelegte Leistungsvergleiche:

Merkmal	Kiro	Klassische Chat-Assistenten (z.B. Copilot Chat)
Workflow-Struktur	Spec: Requirements → Design → Tasks	Direkter Chat-Prompt ohne Zwischenschritte
Persistentes Projektwissen	Steering Files unter .kiro/steering/	Meist projektspezifische Konfigurationsdateien je Tool
Ereignisbasierte Automatisierung	Agent Hooks unter .kiro/hooks/	Unterschiedlich je nach Tool, oft über separate CI-Konfiguration
Preismodell	Monatliches Credit-Kontingent ohne Tages-/Wochenlimit	Variiert stark, oft feste Nachrichtenanzahl pro Zeitraum
Zugangswege	Desktop-IDE, Web, CLI mit gemeinsamer .kiro/-Konfiguration	Meist IDE-Plug-in oder eigenständige App

Für Teams, die bereits stark in ein bestehendes Werkzeug wie GitHub Copilot investiert sind, ist ein vollständiger Wechsel selten die erste Priorität. Wer jedoch neu startet oder ohnehin von Amazon Q Developer migrieren muss, profitiert vom expliziten Spec-Workflow, besonders bei Projekten mit mehreren Beteiligten, die sonst leicht unterschiedliche Annahmen in denselben Chat-Assistenten eingeben. Ein gemischter Ansatz ist ebenfalls möglich: Manche Teams nutzen Copilot oder Cursor weiterhin für schnelle, kleine Änderungen im laufenden Editor und greifen erst bei größeren, mehrstufigen Aufgaben auf Kiros Spec-Workflow zurück. Diese Kombination vermeidet den Aufwand eines vollständigen Werkzeugwechsels und nutzt gleichzeitig die Stärken beider Ansätze dort, wo sie den größten Effekt haben.

Kiro in bestehende, gewachsene Projekte einbinden

Die meisten Teams starten nicht mit einem leeren Repository, sondern wollen Kiro in eine bereits gewachsene Codebasis integrieren. Der Ablauf unterscheidet sich hier in einem wichtigen Punkt vom Beispielprojekt in diesem Tutorial: Statt direkt mit einem Spec für ein neues Feature zu beginnen, lohnt sich zuerst ein Onboarding-Schritt, bei dem der Agent die bestehende Struktur analysiert und die Ergebnisse in einer ersten Steering File festhält.

Praktisch bedeutet das: Öffnen Sie das bestehende Projekt in Kiro und lassen Sie den Agenten zunächst eine Zusammenfassung der Architektur erstellen, etwa mit einer Anfrage wie “Analysiere die Ordnerstruktur und beschreibe die verwendeten Muster für Datenzugriff und Fehlerbehandlung”. Die daraus entstehende Beschreibung dient als Grundlage für die erste Steering File und verhindert, dass der Agent bei der ersten echten Aufgabe Konventionen erfindet, die dem Rest der Codebasis widersprechen.

Bei sehr großen Monorepos mit mehreren unabhängigen Diensten hat es sich bewährt, pro Dienst ein eigenes Unterverzeichnis mit eigener .kiro/steering/-Konfiguration anzulegen, statt eine einzige, alles umfassende Steering File für das gesamte Repository zu pflegen. Ein Zahlungsdienst hat andere Anforderungen an Fehlerbehandlung und Logging als ein internes Reporting-Tool, und diese Unterschiede lassen sich mit dienstspezifischen Steering Files klarer abbilden als mit einer einzigen, immer länger werdenden Regelliste.

Ein weiterer Punkt, der bei Migrationsprojekten oft übersehen wird: Bestehende Tests sind die beste Kontrolle für die Qualität generierten Codes. Bevor Sie Kiro größere Refactorings an Bestandscode überlassen, sollte die Testabdeckung der betroffenen Module bekannt sein. Fehlt sie, lohnt sich ein erster Spec-Workflow, dessen einziges Ziel das Nachziehen fehlender Tests ist, bevor der Agent an der eigentlichen Funktionalität arbeitet.

Gerade bei älteren Codebasen mit historisch gewachsenen Abhängigkeiten empfiehlt sich außerdem ein schrittweises Vorgehen statt eines einmaligen, großen Umbaus. Beginnen Sie mit einem klar abgegrenzten, risikoarmen Modul, etwa einer internen Hilfsbibliothek ohne direkten Kundenkontakt, und sammeln Sie dort Erfahrung mit dem Zusammenspiel von Spec-Workflow und Bestandscode. Erst wenn dieses erste Modul zuverlässig funktioniert, lohnt sich die Ausweitung auf kritischere Teile der Anwendung. Dieses Vorgehen mag langsamer wirken, reduziert aber das Risiko, dass ein einzelner fehlerhafter Refactoring-Schritt gleich mehrere produktionsrelevante Komponenten gleichzeitig betrifft.

Sicherheits- und Datenschutzaspekte bei Kiro

Wie bei jedem cloudbasierten KI-Coding-Werkzeug gilt auch bei Kiro: Code und Projektkontext werden zur Verarbeitung an Modelle in der AWS-Cloud übertragen. Für Teams in Österreich und der EU ist deshalb relevant, welche Daten in Steering Files landen. Personenbezogene Daten, Kundendaten oder Zugangsschlüssel gehören grundsätzlich nicht in Steering Files oder in Spec-Beschreibungen, sondern sollten über Umgebungsvariablen und Secret-Manager außerhalb des von Kiro eingesehenen Kontexts verwaltet werden.

Ein zusätzlicher Punkt für Teams mit mehreren MCP-Servern: Jeder eingebundene Server erweitert die Angriffsfläche, da er potenziell Lese- oder Schreibzugriff auf Dateisysteme oder externe Dienste erhält. Vor der Aktivierung eines MCP-Servers lohnt sich deshalb ein Blick auf dessen Berechtigungsumfang, ähnlich wie bei der Prüfung von Drittanbieter-Paketen in package.json.

Für regulierte Branchen, etwa Finanzdienstleister oder Gesundheitsunternehmen in Österreich, empfiehlt sich zusätzlich eine interne Freigabeliste, welche MCP-Server im Unternehmen überhaupt genutzt werden dürfen. Ohne eine solche Liste installiert im schlimmsten Fall jedes Teammitglied eigene, unterschiedlich vertrauenswürdige Server, was eine einheitliche Sicherheitsbewertung praktisch unmöglich macht. Ebenso wichtig: Agent Hooks, die automatisch Befehle ausführen, sollten niemals mit uneingeschränkten Systemrechten laufen. Ein Hook für Testläufe braucht keinen Zugriff auf Produktionsdatenbanken oder Cloud-Zugangsschlüssel, selbst wenn diese im selben Terminal verfügbar wären.

Häufig gestellte Fragen zu Kiro

Ist Kiro komplett kostenlos nutzbar?
Der Free-Tarif von Kiro ist laut offizieller FAQ dauerhaft verfügbar und umfasst 50 Credits pro Monat, inklusive Zugriff auf Open-Weight-Modelle und Claude Sonnet 4.5 mit den Einschränkungen der kostenlosen Stufe. Für regelmäßige, produktive Nutzung reicht das meist nicht aus.

Was passiert mit meinem Amazon Q Developer Abo?
Berichten zufolge blockiert AWS neue Anmeldungen für Amazon Q Developer ab 15. Mai 2026, bestehende Abonnements sollen laut denselben Berichten bis 30. April 2027 weiterlaufen. Prüfen Sie die offizielle AWS-Ankündigung für Ihren konkreten Vertrag, da diese Angaben aus Sekundärquellen stammen.

Brauche ich für Kiro zwingend die Desktop-IDE?
Nein. Kiro bietet neben der Desktop-IDE auch Zugriff über eine Weboberfläche und eine CLI, die alle dieselbe .kiro/-Projektkonfiguration nutzen.

Wie unterscheidet sich ein Spec von einem normalen Chat-Prompt?
Ein Spec zerlegt eine Anforderung in Requirements, technisches Design und konkrete Tasks, die Sie vor der Umsetzung prüfen und anpassen können. Ein normaler Chat-Prompt führt dagegen meist direkt zu generiertem Code ohne zwischengeschaltete Prüfschritte.

Kann ich Agent Hooks auch für Deployment-Schritte nutzen?
Grundsätzlich lassen sich Agent Hooks für beliebige Kommandozeilenbefehle konfigurieren, die auf definierte Ereignisse reagieren. Für produktive Deployment-Pipelines empfiehlt sich dennoch eine Kombination mit einer dedizierten CI/CD-Lösung statt einer alleinigen Abhängigkeit von IDE-Hooks.

Unterstützt Kiro das Model Context Protocol?
Ja. Kiro liest MCP-Konfigurationen aus dem Verzeichnis .kiro/ und verwendet denselben Kontext über IDE-, Web- und CLI-Sitzungen hinweg.

Gibt es unabhängige Benchmarks, die Kiro mit Cursor oder Copilot vergleichen?
Aktuell liegen keine ausreichend belastbaren, unabhängigen Benchmark-Daten vor, die Kiro etwa anhand von SWE-bench-Werten seriös mit Konkurrenzprodukten vergleichen. Bewertungen sollten deshalb auf Basis eigener Tests im jeweiligen Projektkontext erfolgen.

Wie versioniere ich die Kiro-Konfiguration im Team richtig?
Das Verzeichnis .kiro/ mit Steering Files, Hooks und Spec-Verläufen sollte regulär in Git eingecheckt werden, damit alle Teammitglieder dieselben Regeln und Automatisierungen nutzen, unabhängig davon, ob sie über IDE, Web oder CLI arbeiten.

Eignet sich Kiro auch für bestehende, große Codebasen?
Ja, allerdings lohnt sich vor dem ersten produktiven Spec-Workflow ein Onboarding-Schritt, bei dem der Agent die bestehende Architektur analysiert und die Ergebnisse in einer Steering File festhält. Ohne diesen Schritt orientiert sich der Agent zunächst an allgemeinen Konventionen statt an den tatsächlichen Mustern Ihrer Codebasis.

Was kostet ein typischer Spec-Workflow an Credits?
Der genaue Verbrauch hängt vom gewählten Modell und vom Umfang der Anforderung ab und wird von Kiro nicht pauschal veröffentlicht. Kleinere, klar abgegrenzte Specs verbrauchen erfahrungsgemäß deutlich weniger Credits als ein einziger, sehr breit formulierter Auftrag, der mehrere unabhängige Funktionsbereiche gleichzeitig abdeckt.

Kiro einrichten: AWS-KI-IDE in 11 Schritten [2026]