AWS Kiro prüft Anforderungen, bevor die KI Code schreibt

Der Unterschied ist entscheidend: Es geht nicht primär darum, nachträglich fehlerhaften KI-Code zu reparieren. Die Prüfung setzt bei den Anforderungen an – also an der Stelle, an der viele spätere Fehler überhaupt erst entstehen.

Parallel Task Execution

Parallel Task Execution gehört zum selben Paket. Laut SiliconAngle will AWS damit den Engpass zwischen Architekturplanung und Codeausführung verringern; die Funktion wird als Teil der Upgrades genannt, die Entwicklungsteams schneller machen sollen.

Die vorliegenden Quellen erklären allerdings nicht im Detail, wie Kiro interne Aufgaben parallel plant oder terminiert. Deshalb ist es sauberer, Parallel Task Execution als Workflow- und Geschwindigkeitsverbesserung zu beschreiben – nicht als Beweis- oder Korrektheitsmechanismus.

Quick Plan

Quick Plan wird als schlankerer Workflow eingeführt, ebenfalls mit dem Ziel, schneller von der Planung in die Umsetzung zu kommen. Zusammen gelesen ergibt sich eine klare Rollenverteilung: Requirements Analysis prüft den Plan, Quick Plan und Parallel Task Execution sollen danach Reibung aus der Umsetzung nehmen.

Warum Specs bei Kiro so zentral sind

Kiro ist laut AWS ein agentenbasierter Coding-Dienst, der Prompts in detaillierte Spezifikationen und anschließend in funktionierenden Code, Dokumentation und Tests überführen kann. Die Kiro-Dokumentation beschreibt Specs als strukturierte Artefakte für Features und Bugfixes: Sie sollen aus groben Ideen konkrete Implementierungspläne mit Nachverfolgung und Verantwortlichkeit machen.

Diese Specs können Anforderungen in User Stories mit Akzeptanzkriterien zerlegen, Design-Dokumente unterstützen und den Fortschritt über einzelne Aufgaben hinweg sichtbar machen. Auf der Kiro-Produktseite heißt es außerdem, Kiro wandle natürlichsprachliche Prompts in Anforderungen und Akzeptanzkriterien in EARS-Notation um, damit Absicht und Einschränkungen expliziter werden.

Genau hier setzt Requirements Analysis an. Kiro hatte bereits eine Spezifikationsschicht zwischen Prompt und generiertem Code; die neue Funktion soll diese Schicht stärken, indem sie Anforderungen auf Lücken und Widersprüche prüft, bevor die Implementierung beginnt.

Neurosymbolik: Was belegt ist – und was nicht

Die belastbarste Beschreibung bleibt auf hoher Ebene: Kiro kombiniert Sprachmodell-Fähigkeiten mit formalerer Prüfung. AWS schreibt, Kiro basiere auf Amazon Bedrock und nutze mehrere Foundation Models für Aufgaben. GeekWire berichtet, Requirements Analysis kombiniere große Sprachmodelle mit zusätzlicher Prüfmechanik. Ein nutzergenerierter technischer Beitrag ordnet den Ansatz als neurosymbolische KI ein – also als Verbindung von Sprachmodell-Flüssigkeit und formaler mathematischer Logik.

Vorsichtig formuliert sieht die belegbare Pipeline so aus:

1. Natürlichsprache wird strukturiert. Kiro startet mit einem Prompt und formt daraus Specs, Anforderungen und Akzeptanzkriterien.
2. EARS-Notation macht Anforderungen enger gefasst. Kiro nutzt EARS-Notation, um Absicht und Constraints expliziter zu machen.
3. Formale Prüfung braucht logische Constraints. In einer Architektur mit formaler Prüfung müssen strukturierte Anforderungen in eine solver-lesbare Darstellung überführt werden. SMT-LIB ist eine Standardsprache für die Interaktion mit SMT-Solvern, also Werkzeugen für logische Constraint-Probleme und Software-Reasoning.
4. Ein SMT-Solver kann Erfüllbarkeit prüfen. SMT-Solver können bestimmen, ob Benchmarks aus der SMT-LIB-Bibliothek erfüllbar oder unerfüllbar sind. Übertragen auf Anforderungen hieße das: Wenn die formalisierten Anforderungen nicht gleichzeitig wahr sein können, zeigt sich ein Widerspruch als unerfüllbare Constraint-Menge.
5. Mehrdeutigkeit bleibt der am wenigsten dokumentierte Teil. Die Quellen stützen das Ziel, Widersprüche und Lücken zu finden, sowie Kiros Einsatz von EARS-Notation. Einen offiziellen, vollständigen AWS-Nachweis, dass Requirements Analysis semantische Entropie als Ambiguitätssignal nutzt, liefern die vorliegenden Quellen jedoch nicht. Dieser Teil sollte daher als berichtet oder abgeleitet verstanden werden, nicht als vollständig bestätigtes Produktdetail.

Was so eine Prüfung leisten kann – und wo die Grenze liegt

Formale Analyse prüft nur die Anforderungen, wie sie repräsentiert wurden. Wenn die Übersetzung aus natürlicher Sprache in formale Constraints falsch oder unvollständig ist, kann auch ein Solver reale Probleme übersehen.

Bei direkten Widersprüchen ist die Logik vergleichsweise klar: Wenn zwei kodierte Anforderungen nicht gleichzeitig gelten können, kann die Constraint-Menge unerfüllbar werden. Bei Unvollständigkeit ist es schwieriger. Ein Checker kann fehlende Fälle nur dann sichtbar machen, wenn Zustände, Domäne und erwartete Bedingungen ausreichend modelliert sind.

Auch bei Mehrdeutigkeit sollte man nicht zu viel versprechen. Kiros EARS-Notation kann vage natürliche Sprache disziplinieren, weil sie Absicht und Einschränkungen expliziter macht. Das ist aber nicht gleichbedeutend mit einer formalen Garantie, dass jede missverständliche Anforderung automatisch erkannt wird.

Was sich für Entwicklerteams ändert

Praktisch wird der Kiro-Workflow stärker nach vorn verlagert. Statt eine KI sofort Code erzeugen zu lassen und anschließend Review, Tests und Korrekturen nachzuschieben, erzwingt Kiro mehr Struktur am Anfang: Anforderungen, Akzeptanzkriterien, Design und Aufgaben kommen vor dem Code.

Requirements Analysis fügt diesem Anfang eine Validierungsschicht hinzu. Parallel Task Execution und Quick Plan greifen anschließend dort, wo aus dem geprüften Plan konkrete Arbeit werden soll. Die Stoßrichtung ist damit doppelt: erst strengere Specs, dann schnellere Umsetzung.

Bestätigt und offen

Bestätigt ist: Kiro ist ein spec-getriebener, agentenbasierter Coding-Dienst; er kann Prompts in Specs und Implementierungsartefakte überführen; er nutzt EARS-Notation für Anforderungen und Akzeptanzkriterien; und das Update bringt Requirements Analysis, Parallel Task Execution und Quick Plan.

Offen bleibt die genaue interne Architektur von Requirements Analysis. Die Quellen stützen den groben neurosymbolischen Rahmen und die Idee formaler Prüfung, liefern aber keine offizielle AWS-Spezifikation, die LLMs, EARS-Notation, SMT-LIB-Formalisierung, semantische Entropie und einen konkreten SMT-Solver Schritt für Schritt miteinander verbindet. Bis AWS diese Ebene dokumentiert, ist Requirements Analysis am besten als neue Anforderungsprüfung mit formalem Anspruch zu verstehen – nicht als vollständig offengelegte Beweismaschine.