Acht Monate nach Kiros allgemeiner Verfügbarkeit stellt sich heraus, dass die dauerhafte Idee die Spec ist, und der am wenigsten dauerhafte Teil die IDE. Kiro erschien als agentische IDE mit dem Versprechen, dass Sie auf Spezifikationsebene arbeiten und der Agent implementieren lässt. Der Teil, der geblieben ist, ist das Artefakt: eine schriftliche Absichtserklärung, die ein Mensch prüft, bevor Code existiert. Der Teil, der still verloren ging, ist die Annahme, dass der Editor der Ort ist, an dem das passiert. Kiro brachte zur GA eine CLI heraus, fügte einen Headless-Modus hinzu, und das Terminal ist dort, wohin die interessante Nutzung ging.

Über Kiros GA habe ich Ende letzten Jahres in AWS Monthly (Dec '25): The Kiro Era Begins geschrieben, mit mehr Begeisterung als Distanz. Acht Monate sind genug Zeit, um zu sagen, welche Teile davon Bestand hatten.

Was tatsächlich ausgeliefert wurde

Kiro ging im Juli 2025 in die Vorschau und erreichte am 17. November 2025 die allgemeine Verfügbarkeit. GA war kein Stabilitäts-Release, sondern ein Scope-Release: eigenschaftsbasiertes Testen, das Testfälle aus den Akzeptanzkriterien einer Spec ableitet, Checkpointing, damit die Änderungen eines Agenten zurückgespult werden können, Unterstützung für Multi-Root-Workspaces, zentral über AWS IAM Identity Center verwaltete Team-Pläne, und Kiro CLI, das den Agenten ins Terminal brachte.

Seither war die Entwicklung konsistent und wenig glamourös. Kiro CLI bekam im April 2026 einen Headless-Modus, sodass der Agent in Pipelines läuft statt neben einem Menschen. Die CLI-Releases vom Januar 2026 drehten sich um Allow- und Blocklisten dafür, welche URLs ein Agent abrufen darf, Tastenkürzel für benutzerdefinierte Agenten, bessere Diffs. Das ist keine Roadmap, die einer Demo hinterherjagt. Es ist ein Werkzeug, das für die Produktion zugeschnitten wird, und die Form dieser Anpassung verrät, was Menschen tatsächlich damit tun.

Die Spec war die gute Idee

Kiros eigentlicher Beitrag ist, dass die Spezifikation zu einer Datei wurde. Anforderungen, Design und Aufgaben, im Repo, versioniert, prüfbar, diffbar. Das klingt nach einer Kleinigkeit neben "KI schreibt Ihren Code", und es ist der einzige Teil, den ich ohne Einschränkung verteidigen würde.

Der Grund ist, wohin es die Prüfung verschiebt. Ungesteuertes agentisches Coding erzeugt einen großen Diff und verlangt von einem Menschen, ihn im Nachhinein zu bewerten, was der denkbar schlechteste Moment ist: Die Arbeit ist fertig, der Autor ist eine Maschine ohne Erinnerung an ihre Überlegungen, und ihn abzulehnen bedeutet, etwas wegzuwerfen, das fertig aussieht. Eine Spec zu prüfen kehrt das um. Sie lesen Absicht, an dem Punkt, an dem eine Änderung einen Satz kostet. Die Ökonomie von "nein, nicht so" ist vor und nach der Implementierung komplett unterschiedlich.

Diese Eigenschaft hat nichts mit KI zu tun, und genau deshalb hat sie überlebt. Es ist Design-Review mit kürzerer Feedback-Schleife, und das gilt, egal ob der Implementierer ein Agent, ein Auftragnehmer oder Sie selbst am nächsten Dienstag ist.

Wo es nicht hielt

Drei ehrliche Fehlschläge, und sie waren alle früh sichtbar für jeden, der es bei echter Arbeit einsetzte.

Specs driften

Anforderungen und Design werden im Voraus generiert und aktualisieren sich nicht von selbst, wenn die Implementierung zeigt, dass das Design falsch war. Teams berichten genau die Dynamik, die man erwarten würde: Der Code bewegt sich, die Spec nicht, und nach ein paar Wochen ist die Spec ein Dokument, das ein System beschreibt, das es nicht mehr gibt. Das ist kein KI-Fehlschlag, es ist der älteste Fehlschlag der Softwaredokumentation, wiedereingeführt durch ein Werkzeug, das das Dokument billig zu erstellen und nicht billiger zu pflegen machte. Billig zu schreiben und teuer wahr zu halten ist genau die Kombination, die veraltete Artefakte erzeugt.

Der Aufwand passt nicht zu kleiner Arbeit

Die unverblümte Version, von Leuten, die es an einem kleinen Bugfix versucht haben: Der Spec-Workflow ist ein Vorschlaghammer für eine Nuss. Anforderungen, Design und Aufgabenaufteilung, um eine Validierungsregel zu ändern, ist schlechter, als die Validierungsregel einfach zu ändern. Die Zeremonie ist proportional zu nichts, und die meiste Engineering-Arbeit ist klein.

Die Starrheit ist real

Spec-First setzt voraus, dass Sie wissen, was Sie wollen, bevor Sie anfangen. Viel Software wird von Menschen geschrieben, die beim Schreiben herausfinden, was sie wollen. Für exploratives Arbeiten ist das Vorziehen der Spezifikation keine Disziplin, sondern eine zu einem Dokument formalisierte Vermutung, die jetzt eine Autorität hat, die sie sich nicht verdient hat. Die Kritik, dass spec-getriebene Entwicklung Wasserfall-Dynamiken reimportiert, ist nicht ganz fair, aber auch nicht ganz falsch, und der Unterschied hängt davon ab, ob Ihr Team die Spec als Vertrag oder als Entwurf behandelt.

Für wen ist es also

Das Muster, das sich herausgebildet hat, ist enger als das Versprechen und leichter zu verteidigen. Specs zahlen ihren Aufwand zurück, wenn Anforderungen mehrdeutig sind, wenn die Beteiligten so verteilt sind, dass gemeinsames Verständnis nicht vorausgesetzt werden kann, oder wenn Nachvollziehbarkeit eine Pflicht statt einer Annehmlichkeit ist. In einem regulierten Kontext ist "hier ist die geprüfte Spec, hier ist der Diff, der sie implementiert" kein Aufwand. Es ist das Audit-Artefakt, das Sie ohnehin hätten konstruieren müssen, produziert als Nebenprodukt.

Für ein kleines Team an einer gut verstandenen Codebasis ist der Aufwand größtenteils Kosten. Das ist keine Kritik an Kiro. Es ist eine Eingrenzung, die das Marketing nie machen würde.

Was KI-IDEs tatsächlich verändert haben

Hier ist die rückblickende These, und ich halte sie locker.

Die Veränderung war nicht, dass KI den Code schreibt. Das ist passiert, es ist wirklich nützlich, und es ist inzwischen unauffällig genug, dass darüber zu streiten langweilig ist. Die Veränderung ist, dass sich die Einheit menschlicher Prüfung stromaufwärts verschoben hat, vom Diff zur Absicht. Kiros Specs sind eine Umsetzung. AGENTS.md und Steering-Dateien sind eine andere. Das Muster ist dasselbe: Menschen verfassen Einschränkungen und prüfen Absicht, Agenten produzieren Implementierungen, und das Artefakt, über das Menschen streiten, hört auf, der Code zu sein.

Die zweite Veränderung ist, dass sich die IDE als nicht der richtige Container erwiesen hat. Kiros eigene CLI und der Headless-Modus verdeutlichen das besser als jeder Kritiker könnte. Wenn kein Mensch jede Änderung liest, während sie eintrifft, ist der Editor eine Oberfläche für etwas, das keine mehr braucht, und der Agent gehört dorthin, wo der Rest Ihrer Automatisierung lebt. Die IDE war die Auffahrt, nicht das Ziel.

Die Quintessenz

Acht Monate nach der GA ist Kiros bleibender Beitrag die Spezifikation als prüfbare, versionierte Datei, die menschliches Urteilsvermögen an den Punkt verschoben hat, an dem es am günstigsten anzuwenden ist. Die Kosten sind real und spezifisch: Specs driften, weil ihre Erstellung billig und ihre Pflege es nicht ist, und die Zeremonie passt nicht zu kleiner oder explorativer Arbeit. Nutzen Sie es dort, wo Mehrdeutigkeit oder Nachvollziehbarkeit den Aufwand rechtfertigen, und lassen Sie es dort weg, wo das nicht der Fall ist. Und beachten Sie, dass die nützlichste Ausgabe der agentischen IDE eine CLI war, was die Branche Ihnen sagt, wohin das führt.

Weiterlesen

Die Pipeline-Seite des Betriebs von Agenten in CI, Runner, Zugangsdaten und Wirkungsradius, findet sich in den Field Notes auf ercan.cloud. Der Hub ist unter ercanermis.com.