Ihre KI schreibt den Code. Wer verantwortet die Entscheidungen?

Ihre Agenten treffen Architekturentscheidungen. Hält die eigentlich jemand fest?

Die wichtigsten Erkenntnisse

• Das Problem von KI-Coding-Tools ist nicht das Erzeugen von Code. Das Problem ist, dass sechs Monate später niemand mehr weiß, warum der Code so aussieht, wie er aussieht. Kiro ist bislang der konsequenteste Versuch, das zu lösen.
• Spec-driven Development bringt Overhead mit sich. Die Frage ist nicht, ob es langsamer ist – das ist es. Die Frage ist, ob Ihr Team sich die Alternative leisten kann.
• Die Schwachstellen sind real: oberflächliche Specs, falsche Präzision durch EARS-Notation, ADRs, die vollständig wirken, es aber nicht sind. Der Workflow funktioniert nur, wenn die Review-Gates auch wirklich als Gates ernst genommen werden.

KI-Coding-Tools sind richtig gut darin geworden, Code zu produzieren. Wirklich gut. Multi-Agent-Frameworks, agentische Assistenten, autonome Pipelines: Wenn die Aufgabe lautet "Mach aus dieser Idee funktionierenden Code", sind die Optionen leistungsfähig. Doch wer im Team Software entwickelt, ist vermutlich schon gegen die Wand gelaufen, die etwa zwei Wochen nach der beeindruckenden Demo auftaucht: Der Code funktioniert, niemand weiß so recht, warum er so aussieht, und wenn jemand fragt, warum ein bestimmter Ansatz gewählt wurde, lautet die ehrliche Antwort: "Ich habe den Agenten entscheiden lassen und bin mir nicht ganz sicher."

Ich habe das mittlerweile in mehreren Teams erlebt. Das Problem ist nicht, dass der Agent schlechte Entscheidungen getroffen hätte. Das Problem ist, dass nahezu jedes KI-Coding-Tool am Markt auf Task-Ausführung optimiert ist und kaum eines in die Artefakte investiert, die Teamentwicklung über die Zeit hinweg konsistent halten.

Amazons Kiro, im Juli 2025 als Preview gestartet, ist der bislang konsequenteste Versuch, diese Lücke zu schließen, den ich gesehen habe. Das hier ist kein "Kiro vs. Cursor"-Vergleich; bei der reinen Geschwindigkeit auf Einzelaufgaben sind Cursor, Claude Code und die Multi-Agent-Frameworks beeindruckend. Die eigentliche Frage ist, ob Kiros Modell des Spec-driven Development, kombiniert mit einem Architecture-Decision-Record-(ADR-)Workflow, den Sie über das Steering-System konfigurieren, Teams etwas bietet, was diese Tools nicht bieten: einen gemeinsamen, für Menschen prüfbaren Nachweis, wie und warum die Software so entworfen wurde.

Die Multi-Agent-Landschaft: leistungsfähig, aber strukturell unvollständig

Die aktuelle Generation von Multi-Agent-Frameworks (CrewAI, LangGraph, AutoGen, MetaGPT) ist ausgereift. Unternehmen wie DocuSign und PwC betreiben Multi-Agent-Pipelines produktiv im großen Maßstab. Das Argument für Kiro trägt nur dann, wenn man akzeptiert, dass die Alternative bereits gut darin ist, Code zu produzieren.

MetaGPT lohnt einen direkten Blick – es läuft seltener produktiv als LangGraph oder CrewAI, überschneidet sich aber am stärksten mit dem, was Kiro verspricht. Geben Sie eine einzeilige Anforderung ein, und es liefert strukturierte Artefakte: PRDs, Designdokumente, Schnittstellenspezifikationen, Implementierungscode. Auf dem Papier deckt das denselben Bereich ab wie Kiros Spec-driven-Workflow.

Der strukturelle Unterschied liegt nicht in der Output-Qualität. Er liegt darin, wer die Entscheidungen wann zu Gesicht bekommt.

In MetaGPT erzeugen Agenten Artefakte und reichen sie an den nächsten Agenten weiter. Der Output ist umfassend, der Prozess aber undurchsichtig: Entscheidungen des Architect-Agenten werden nicht als prüfbare Dokumente sichtbar gemacht. Es gibt kein Approval-Gate, an dem Ihr Team das Designdokument liest und einen Constraint markiert, bevor die Implementierung beginnt. Die Artefakte sind Output zum Konsumieren, keine kollaborativen Dokumente, die geprüft werden.

Dieselbe Lücke gibt es in Multi-Agent-Frameworks generell. Sie sind exzellente Ausführungs-Engines. Sie wurden nicht dafür konzipiert, ein gemeinsames Teamverständnis darüber zu erzeugen, warum die Software auf eine bestimmte Weise gebaut wurde. Das ist eine Designentscheidung, kein Mangel. Diese Frameworks optimieren auf Task-Erledigung. Kiro optimiert auf Lesbarkeit für das Team über die Zeit.

Was Kiro tatsächlich leistet

Kiro ist ein VS-Code-Fork, betrieben von Claude Sonnet auf Amazon Bedrock. Die vertraute Umgebung zählt: keine neue IDE, kein Kontextwechsel, und vorhandene Open-VSX-Plugins, Themes und Einstellungen lassen sich sauber übernehmen. Da es sich um eine Allzweck-IDE handelt, funktioniert Kiro über Sprachen und Frameworks hinweg, auch wenn sich der Spec-driven-Workflow am natürlichsten in der Backend- und Full-Stack-Entwicklung zeigt, wo Architekturentscheidungen am stärksten ins Gewicht fallen.

Der Unterschied liegt im Workflow, den Kiro vorgibt.

Spec-driven Development: Artefakte vor der Ausführung

Jedes Feature in Kiro beginnt mit einer Spec, einer Reihe strukturierter Markdown-Dateien, die ins Repository committet werden, bevor auch nur eine Zeile Code geschrieben wird. Der dreistufige Prozess ist bewusst gesetzt:

Phase 1: Anforderungen (requirements.md)

Das erste Gate ist genau jenes, das die meisten Teams komplett überspringen: schriftliche, geprüfte und freigegebene Anforderungen, bevor Code existiert. Sie beschreiben in natürlicher Sprache, was Sie wollen. Kiro fängt nicht an zu coden. Stattdessen erzeugt es ein formales Anforderungsdokument in EARS-Notation (Easy Approach to Requirements Syntax), einem Format, das jede Anforderung in eine eindeutige, testbare Form zwingt:

WHEN [trigger condition] THE SYSTEM SHALL [observable behavior]

Die EARS-Notation legt Annahmen offen, die sonst implizit blieben. Erzeugt Kiro ein Akzeptanzkriterium, das Sie so nicht beabsichtigt hatten, fangen Sie es hier ab – nicht im Code-Review, nicht in Produktion. Die Anforderungen werden von einem Menschen geprüft und freigegeben, bevor irgendetwas anderes passiert.

Phase 2: Technisches Design (design.md)

Das ist die Phase, in der die eigentlichen Architekturdiskussionen stattfinden sollten – und in der die meisten KI-Tools längst Code schreiben. Mit freigegebenen Anforderungen analysiert Kiro die bestehende Codebasis und erzeugt ein Designdokument: Komponentenhierarchien, Datenflussdiagramme, Datenbankschemata, API-Verträge, TypeScript-Interfaces. Das Design spiegelt Ihre tatsächliche Projektarchitektur wider.

Dieses Dokument prüft Ihr Team, bevor eine einzige Zeile Produktivcode geschrieben wird. Eine Architektin kann ein Schema infrage stellen. Ein Senior Engineer kann auf ein Skalierungsproblem hinweisen. Ein Engineer an einem parallelen Feature kann prüfen, ob das neue Design Integrationskonflikte mit seiner Arbeit erzeugt. All das passiert anhand eines schriftlichen Artefakts in einem Pull Request.

Phase 3: Implementierungs-Tasks (tasks.md)

Erst an diesem Punkt beginnt die Implementierung. Kiro erzeugt eine nach Abhängigkeiten sortierte Task-Liste, die auf die Anforderungen zurückverweist, samt passenden Unit- und Integrationstests sowie – wo sinnvoll – Loading-States und Accessibility-Aspekten. Tasks lassen sich einzeln mit expliziter menschlicher Freigabe pro Schritt ausführen oder autonom im Autopilot-Modus. Code-Diffs und der Verlauf der Agent-Ausführung sind in jedem Schritt sichtbar.

Die Spec-Dateien liegen unter .kiro/specs/<feature-name>/ im Projekt-Repository. Sie sind committet, versioniert, in Pull Requests prüfbar und über die Git-Historie navigierbar. Das gesamte Team sieht sie, sobald sie existieren.

Diese Sichtbarkeit verändert, wofür Senior Engineers ihre Zeit aufwenden. Statt sich in der Archäologie dessen zu verlieren, was wann und warum entschieden wurde, prüfen sie ein schriftliches Design, hinterfragen, was zu hinterfragen ist, und geben frei, bevor die Arbeit beginnt. Ihr Urteil wirkt dort, wo es den größten Hebel hat.

Die Lücke, die Multi-Agent-Tools nicht schließen: das Decision Record

Hier wird der Vergleich mit Multi-Agent-Frameworks pointiert – und hier hat die Tool-Wahl langfristige Konsequenzen, die in einer kurzen Demo nicht sichtbar werden.

Kiros Spec-Dateien dokumentieren, was das System leisten muss und wie es dafür entworfen wurde. Das ist bereits mehr, als die meisten KI-gestützten Workflows festhalten. Aber design.md sagt Ihnen, dass PostgreSQL gewählt wurde, und beschreibt das Schema. Es sagt Ihnen nicht, dass DynamoDB evaluiert und verworfen wurde, weil Ihre Zugriffsmuster Multi-Column-Filterung verlangen, die das Query-Modell von DynamoDB ohne teure Denormalisierung und doppelte Schreibpfade nicht abbilden kann. Es sagt Ihnen nicht, dass Event Sourcing erwogen und ausgeschlossen wurde, weil das Team keinerlei Betriebserfahrung mit Event Stores hat und das Latenz-Budget keine Eventual Consistency zulässt.

Genau dieser Kontext – was wurde evaluiert, warum wurde es verworfen, welche Trade-offs wurden akzeptiert – ist das, was ein Architecture Decision Record (ADR) festhält. Das Konzept wurde 2011 von Michael Nygard eingeführt und ist seitdem zu einem festen Bestandteil nachhaltiger Softwarearchitektur geworden. Die ADR-GitHub-Organisation bietet einen guten Überblick über das Format und seine Varianten, falls Sie tiefer einsteigen möchten.

ADRs sind eine etablierte Praxis. Der GOV.UK Digital Service hat während seiner AWS-Migration 39 davon veröffentlicht – Entscheidungen von der Auswahl der Hosting-Plattform über die Datenbank-Konsolidierung bis zur DNS-Architektur. Jedes ADR ist eine kurze Markdown-Datei: Status, Kontext, Entscheidung, Konsequenzen. Die Sammlung ist das Entscheidungs-Logbuch der gesamten Migration, versioniert neben der Infrastruktur, die sie beschreibt.

Der Grund, warum die meisten Teams keine ADRs pflegen, heißt Reibung. Das Erstellen konkurriert mit dem Druck, zu liefern, die Disziplin bröckelt nach ein, zwei Sprints, und die Entscheidungen, die tatsächlich erfasst werden, sind die zur Designzeit getroffenen – nicht die ebenso wichtigen, die mitten in der Implementierung auftauchen, wenn sich ein Constraint anders entpuppt als erwartet.

Kiro nimmt diese Reibung über zwei Mechanismen heraus:

Automatische ADR-Erzeugung über Steering

Kiros Steering-System erlaubt es Ihnen, persistente Anweisungen unter .kiro/steering/ zu committen, die für jede Agent-Interaktion im gesamten Team gelten. Eine einzige Steering-Datei macht die ADR-Erzeugung automatisch:

When generating or updating design.md for any spec, also create or update
a decisions/ subdirectory within the spec folder. For each significant
architectural choice — technology selection, data model, integration
pattern, security mechanism — create an ADR file following the naming
convention ADR-NNN-short-title.md.

Each ADR must include: Status, Context, Decision, and Consequences
(positive, negative, risks). Record options considered but not chosen
and the reasons they were rejected.

Einmal committet, gilt diese Anweisung für das gesamte Team. ADRs entstehen, ohne dass jemand daran denken muss, sie zu erstellen.

# ADR-001: Use PostgreSQL over DynamoDB for review storage

## Status
Accepted

## Context
The review system requires complex multi-column filtering (rating, date, product).
DynamoDB's query model requires denormalized duplicates per access pattern,
increasing storage and write complexity by an estimated 3-4x.
The team has existing PostgreSQL operational experience and monitoring tooling.
DynamoDB was the initial default assumption given existing AWS infrastructure.

## Decision
Use PostgreSQL with a normalized schema. Index the columns used in the four
most common filter combinations. Accept the horizontal scaling trade-off.

## Consequences
- Positive: Query logic is significantly simpler; existing tooling applies
- Negative: Horizontal scaling requires more coordination than DynamoDB
- Risk: Revisit if read throughput exceeds 20k RPS at peak; document threshold

Hook-basierte Erfassung von Entscheidungen während der Implementierung

Die Entscheidungen zur Designzeit sind die einfach zu erfassenden. Die gefährlichen fallen während der Implementierung: eine Library, die einen folgenschweren Edge Case hat, eine Performance-Messung, die das Datenzugriffsmuster verändert. Diese werden im Gespräch oder per kurzer Code-Änderung gelöst – und nirgendwo dokumentiert.

Genau hier setzt ein Kiro-Hook auf Änderungen an design.md an. Wird das Designdokument verändert (durch einen Engineer oder durch Kiro während der Task-Ausführung), löst der Hook einen Agenten aus, der prüft, ob die Änderung eine neue Architekturentscheidung darstellt, und – falls ja – einen ADR-Entwurf zur Review erstellt. Spec und Decision Record bleiben über die gesamte Implementierung hinweg synchron, nicht nur zum Zeitpunkt des Initial-Designs.

ADRs in Multi-Agent-Pipelines: ein ergänzender Ansatz

Automatisierte ADRs sind nicht auf Kiro beschränkt; Sie können einer bestehenden CrewAI- oder LangGraph-Pipeline einen ADR-Writer-Agenten hinzufügen. Ob das resultierende ADR jedoch in einer prüfbaren Form beim Team ankommt, hängt davon ab, wie Sie den Pipeline-Output in Ihren Entwicklungsworkflow eingebunden haben. Kiro verankert das ADR in einem Workflow, in dem das Team es sieht, prüft und hinterfragt, bevor Code geschrieben wird.

Für Teams, die bereits Multi-Agent-Pipelines betreiben, koexistieren beide gut: Kiro übernimmt Design, Specs und Decision Capture; Ihre bestehende Pipeline übernimmt klar abgegrenzte Ausführungsaufgaben innerhalb der von der Spec gesetzten Constraints. Die Spec wird zum Vertrag zwischen Designphase (mit Team-Aufsicht) und Ausführungsphase (in der Agenten mit mehr Autonomie arbeiten).

Wo das Modell an seine Grenzen stößt

Ich wäre nicht ehrlich, wenn ich die Schwachstellen nicht beim Namen nennen würde, denn sie zeigen sich erst nach ein paar Sprints.

Die Spec-Qualität ist durch die Prompt-Qualität begrenzt

Kiros Anforderungs- und Designdokumente sind nur so gut wie die initiale Beschreibung, die Sie liefern. Ein vager Prompt erzeugt eine vage Spec – nur dass es jetzt eine vage Spec mit dem Anschein von Strenge ist, weil sie in EARS-Notation samt Akzeptanzkriterien formatiert ist. Das ist schlimmer als gar keine Spec, weil das Team sie prüft, die Struktur sieht und annimmt, der Inhalt sei tragfähig.

Die Gegenmaßnahme ist kulturell, nicht technisch: Behandeln Sie das Spec-Review als echtes Designreview, nicht als Formalie. Wenn die Anforderungen generisch wirken oder das Design Ihre spezifischen Constraints nicht adressiert, hinterfragen Sie es vor der Freigabe. Der ganze Sinn des Approval-Gates ist, dass es ein Gate ist – keine Pflichtübung.

EARS-Notation kann falsche Präzision erzeugen

EARS ist gut darin, Mehrdeutigkeit in einzelnen Anforderungen zu eliminieren. Was es nicht leistet, ist Vollständigkeit: Sie können zwanzig perfekt eindeutige Anforderungen haben, die zusammen das eigentlich harte Problem nicht abdecken. Ich habe Kiro EARS-Anforderungen erzeugen sehen, die technisch korrekt, operativ aber nutzlos waren, weil sie den Happy Path detailliert beschreiben und die Failure-Modes ignorieren, die in Produktion tatsächlich darüber entscheiden, ob das System funktioniert.

Die Lösung: Prüfen Sie beim Review von requirements.md nicht nur, ob jede einzelne Anforderung wohlgeformt ist. Prüfen Sie, ob die Menge der Anforderungen die Failure-Cases, Edge Cases und operativen Aspekte (Monitoring, Alerting, Rollback) abdeckt, die für Ihr System zählen. Falls nicht, ergänzen Sie sie vor der Freigabe.

Auto-generierte ADRs können oberflächlich bleiben

Eine Steering-Datei mit "Erzeuge ADRs für signifikante Architekturentscheidungen" wird ADRs erzeugen. Ob diese ADRs nutzbare Begründungen enthalten, hängt davon ab, wie viel Kontext Kiro zu Ihren Constraints hat. Ein ADR mit "Wir haben PostgreSQL gewählt, weil es relationale Queries unterstützt" ist technisch korrekt und vollkommen wertlos; das weiß jeder Senior Engineer ohnehin. Der Wert liegt in den verworfenen Alternativen und den konkreten Gründen, warum sie verworfen wurden.

Feintunen Sie Ihre Steering-Datei so, dass sie explizit macht, was erfasst werden soll. Statt "signifikante Entscheidungen festhalten" lieber: "Dokumentiere für jede Technologie-Auswahl mindestens zwei evaluierte Alternativen, den konkreten technischen oder operativen Grund für die Ablehnung jeder einzelnen sowie die Bedingungen, unter denen die Entscheidung neu zu bewerten ist." Je präziser die Anweisung, desto nutzbarer der Output.

Spec-Drift bleibt standardmäßig unbemerkt

Kiro erkennt nicht automatisch, wenn die Implementierung vom Design abweicht. Die Spec ist eine Momentaufnahme der Absicht zur Designzeit. Wenn ein Engineer (oder ein Agent im Autopilot-Modus) eine Änderung vornimmt, die dem Design widerspricht (eine andere Datenbank-Engine, ein zusätzlicher API-Endpunkt, ein verändertes Datenmodell), aktualisieren sich die Spec-Dateien nicht von selbst.

Das lässt sich mit Hooks lösen, wie oben beschrieben, ist aber nicht das Standardverhalten. Wer Kiro einführt, sollte das Aufsetzen von Drift-Detection-Hooks zur initialen Konfiguration zählen, nicht zu etwas, das man nachzieht, wenn das Problem bereits aufgetreten ist.

Governance endet an der Designgrenze

Im Dezember 2025 hat ein Kiro-Agent eine Live-AWS-Produktivumgebung gelöscht und damit einen 13-stündigen Ausfall des AWS Cost Explorer in einer China-Region verursacht (The Register, Feb 2026). Amazon führte den Vorfall darauf zurück, dass die Rolle des Engineers weitreichendere Berechtigungen hatte als beabsichtigt. Unabhängige Berichterstattung beschrieb, dass Kiro autonom entschieden habe, die Umgebung zu löschen und neu anzulegen, statt einen gezielten Fix anzuwenden – eine Darstellung, der Amazon widersprach.

Beide Versionen führen zur selben Lehre: Ein Team kann geprüfte Specs, freigegebene Designs und dokumentierte ADRs haben und dennoch einen katastrophalen Ausfall erleiden, weil niemand geprüft hat, was zwischen freigegebenem Design und Produktiv-Deployment passiert ist.

Kiros Governance-Modell deckt die Designphase gründlich ab. Was es nicht abdeckt, ist die Ausführungsgrenze: der Moment, in dem ein Agent mit echten Berechtigungen auf echter Infrastruktur handelt. Der Autopilot-Modus ist nützlich, verlangt aber dieselbe Disziplin wie jede CI/CD-Pipeline: Deployment-Review, eingegrenzte Berechtigungen und einen Menschen in der Schleife, bevor Änderungen die Produktion erreichen. Der Spec-Workflow lässt leicht den Eindruck entstehen, Governance sei abgehakt. Das ist sie nicht – es sei denn, Ihr Team führt diese Disziplin über den Punkt hinaus, an dem Kiros Workflow endet.

Was sich für das Team ändert

Design entsteht im Sichtbaren, nicht in privaten Agent-Sessions

In einer Multi-Agent-Pipeline fällt die Designentscheidung innerhalb der Pipeline. Wenn ein Teammitglied sie zu sehen bekommt, ist sie entweder bereits implementiert oder in einer Output-Datei festgehalten, die es vielleicht in einen Pull Request schafft – vielleicht auch nicht. Mit Kiro ist das Designdokument der erste committete Output im Repository, bevor die Implementierung beginnt. Das Team sieht und prüft das Design, während es entsteht, nicht erst danach.

Das verändert das Code-Review unmittelbar. Code ohne Spec zu reviewen heißt, die Absicht aus der Implementierung abzuleiten – langsam und mit Hang zu Style-Kommentaren statt Substanz. Code gegen eine Spec zu reviewen heißt, zu prüfen, ob die Implementierung die festgelegten Anforderungen erfüllt und ob die Wahl mit der dokumentierten Begründung übereinstimmt. Reviews werden schneller und substanzieller.

Parallele Arbeit deckt Konflikte früh auf

Multi-Agent-Pipelines arbeiten typischerweise auf einem einzigen Task-Kontext. In einem Team, in dem mehrere Engineers parallel bauen, jeweils mit eigenen Agent-Sessions oder eigenen Pipelines, gibt es keinen Mechanismus, um zu erkennen, dass zwei Features widersprüchliche Architekturannahmen treffen. Kiros Specs, vor der Implementierung committet, liefern den gemeinsamen Bezugspunkt, der diese Konflikte zum richtigen Zeitpunkt sichtbar macht – bevor der widersprüchliche Code geschrieben wird.

Wissen überlebt personelle Wechsel

Wenn ein Engineer ein Team verlässt, das per Vibe Coding oder unstrukturierten Agent-Pipelines arbeitet, geht der Kontext mit ihm. Ich habe das oft genug erlebt, um zu wissen, wie es ausgeht: Drei Monate später reverse-engineert jemand einen Service, den niemand vollständig versteht. Die ADRs und Specs im Kiro-Modell hängen am Repository, nicht an Personen. Die Begründung jeder relevanten Entscheidung steht für alle bereit, die nachkommen – ob ein Engineer in drei Monaten einsteigt oder ein Team das System in drei Jahren übernimmt.

Die ehrliche Frage

Hier die ehrliche Frage an Teams, die Multi-Agent-Pipelines betreiben: Ihre Pipeline produziert Code. Wissen Sie, warum er so entworfen wurde? Weiß es Ihr Team? Wird es das in sechs Monaten noch wissen? Wenn die Antwort auf eine dieser Fragen unsicher ist, häufen Sie Wissensschulden an, die sich aufaddieren werden.

Diese Schulden folgen einem vorhersehbaren Muster: Velocity sinkt, Onboarding wird langsamer, und irgendwann schlägt jemand den Rewrite vor – weil das Modifizieren eines Systems, das niemand mehr versteht, riskanter wirkt als ein Neuanfang.

Kiro ersetzt Ihr Multi-Agent-Tooling für klar abgegrenzte Task-Ausführung nicht. Es liefert die strukturelle Schicht (Specs, ADRs, Hooks, team-sichtbare Artefakte, vor der Implementierung committet), die KI-generierten Output in Software verwandelt, die Ihr Team tatsächlich verantworten kann.

Die Frage des Overheads

Der Spec-Workflow fügt Planungszeit vor der Implementierung hinzu. Für ein kurzlebiges Skript oder eine eng begrenzte Automatisierungsaufgabe rechtfertigt sich dieser Overhead nicht. Manche Teams empfinden Kiros strukturierten Ansatz als Überspezifikation einfacher Probleme, und die Approval-Gates erzeugen bei Änderungen mit geringem Risiko Reibung, die sich unnötig anfühlt.

Martin Fowlers Team hat Tools für Spec-driven Development (darunter Kiro) untersucht und kam zu dem Schluss, dass der meinungsstarke Single-Workflow-Ansatz vermutlich "nicht für die Mehrzahl realer Coding-Probleme geeignet" sei. Da ist etwas dran. Das Tagesgeschäft im Engineering ist überwiegend Modifikation bestehender Systeme, Bugfixes und inkrementelle Änderungen – Arbeit, bei der ein vollständiger Spec-Zyklus mehr Reibung als Wert erzeugt. Das Argument für Spec-driven Development ruht auf der Teilmenge an Arbeit, in der Architekturentscheidungen getroffen werden und falsche Entscheidungen teuer sind. Diese Teilmenge ist kleiner, als dieser Artikel vielleicht nahelegt – aber genau dort passieren die folgenschwersten Fehler.

Kiro bietet sowohl Spec-driven- als auch Vibe-Coding-Modi in derselben IDE, und beide koexistieren gut: Vibe Coding für Exploration und Wegwerfarbeit, Specs für alles, was gepflegt wird. Die schwierigere Frage ist, ob Teams dieses Urteil treffsicher anwenden. Meiner Erfahrung nach ist die Versuchung groß, für alles den schnellen Pfad zu wählen und sich einzureden, das Feature sei einfacher, als es tatsächlich ist. Ein Großteil der Wissensschulden in Codebasen ist der akkumulierte Niederschlag genau dieser Entscheidung – vielfach wiederholt.

Eine pragmatische Heuristik: Nutzen Sie den Spec-Modus, wenn eine der folgenden Bedingungen zutrifft – das Feature berührt ein Datenmodell, führt eine neue externe Integration ein, überquert eine Sicherheitsgrenze oder wird von mehr als einem Engineer bearbeitet. Nutzen Sie für alles andere Vibe Coding. Die Kosten einer falschen Architekturentscheidung summieren sich über jeden folgenden Sprint; die Kosten der Überspezifikation eines Wegwerfskripts sind eine Stunde Ihrer Zeit.

Für Teams, die den Spec-Modus zum ersten Mal einführen, reduziert ein stufenweises Vorgehen den Widerstand. Beginnen Sie mit einem neuen Feature, das mindestens zwei der oben genannten Heuristik-Bedingungen erfüllt – komplex genug, damit die Spec Wert liefert, aber nicht so überwältigend, dass die erste Erfahrung erdrückt. Führen Sie das Spec-Review als echtes Design-Meeting: Beauftragen Sie jemanden damit, das Anforderungsdokument vor der Freigabe zu hinterfragen, nicht nur zu lesen. Nach dem Ausliefern des ersten Features lohnt eine kurze Retrospektive: Hat die Spec etwas aufgedeckt, das sonst erst später aufgefallen wäre? Genau dieser eine Datenpunkt – "wir haben das Schemaproblem im Designreview erwischt, nicht in Produktion" – überzeugt ein skeptisches Engineering-Team mehr als jedes Prozessargument.

Fazit

Die aktuelle Generation von KI-Entwicklungstools hat das Problem der Code-Erzeugung weitgehend gelöst. Die Tools verwandeln Anforderungen in natürlicher Sprache mit einer Geschwindigkeit in funktionierende Implementierungen, die vor drei Jahren als unrealistisch gegolten hätte.

Was die meisten von ihnen nicht gelöst haben, ist das Teamproblem: Wie baut eine Gruppe von Engineers gemeinsam Software, mit KI-Unterstützung, sodass geteiltes Verständnis entsteht – und nicht geteilter Output, den niemand wirklich verantwortet? Wie beantworten Sie "Warum wurde es so entworfen?", wenn das Design innerhalb einer Agent-Session entstanden ist, die niemand sonst gesehen hat?

Kiros Antwort ist strukturell: Erzeuge die Artefakte, die diese Fragen beantwortbar machen, bevor der Code existiert, als Standardbestandteil des Workflows. Spec-Dateien geben dem Team Einblick in die Designabsicht. ADRs, erzeugt über eine Steering-Datei, die Sie konfigurieren, und über Hooks aktuell gehalten, geben dem Team Einblick in die Entscheidungsbegründungen. Beides lebt im Repository und wandert wie jedes andere Code-Artefakt durch Pull Requests.

Für Teams, die bereits Multi-Agent-Frameworks für Ausführungsaufgaben einsetzen, ist Kiro kein Ersatz. Es ist die Schicht, die diese Tools nicht liefern: ein prüfbarer, team-sichtbarer Workflow, der Entscheidungen festhält und KI-generierten Code in Software verwandelt, die ein Engineering-Team pflegen kann.

Das Ausführungsproblem ist weitgehend gelöst. Das Teamproblem ist es nicht. Genau dieses Problem lohnt die Arbeit – und genau auf dieses Problem hat der Rest der Tooling-Industrie noch nicht gesetzt.