Vibe Coding mit Kiro

Die Welt der KI-Agenten entwickelt sich in einem atemberaubenden Tempo. Ich glaube ich habe dieses Jahr über Coding-Agents schon mehr Artikel geschrieben als Blog-Artikel im Jahr 2024. Nachdem ich bereits meine Erfahrungen mit diversern anderen Coding Agents hier im Blog geteilt habe, bot sich mir nun die Gelegenheit, Kiro, den Vibe Coding Agenten von Amazon, in einer 14-tägigen Beta-Phase zu testen. Kiro unterscheidet sich in seinem Ansatz grundlegend von der Konkurrenz. Statt als reaktiver Assistent in der IDE oder als asynchroner "Pull-Request-Generator" zu agieren, setzt Kiro auf einen strukturierten, mehrstufigen Prozess: Zuerst wird gemeinsam mit einem Agenten eine detaillierte Spezifikation und ein Design-Dokument erarbeitet, bevor ein zweiter Agent den eigentlichen Implementierungsplan abarbeitet. In diesem Blog-Post möchte ich meine Erfahrungen mit diesem Arbeitsmodell teilen.

Geplantes Vorgehen

Meine bisherigen Experimente mit KI-Agenten haben gezeigt, dass die Qualität des Ergebnisses stark von der Klarheit der anfänglichen Aufgabenstellung abhängt. Kiro scheint dieses Problem direkt an der Wurzel packen zu wollen. Der Prozess, den ich in meinem Test durchlief, ist in mehrere Phasen unterteilt, die sich stark an einem klassischen Software-Entwicklungsprozess orientieren.

Anstatt nur einen Prompt einzutippen verfolgt Kiro den Ansatz, dass man ganz gezielt seine Spezifikationen erstellt und dies auch an einer zentralen Stelle im Projekt immer sieht.
Kiro selbst basiert auf Visual Studio Code und wurde entsprechend mit Extension erweitert um die Spezifikation mehr in den Fokus zu bringen.

Phase 1: Die Spezifikation und das Design-Dokument

Der erste Agent ist für die Erstellung der Spezifikation zuständig. Hierbei beginnt alles mit einem einfachen Text-Prompt, ähnlich wie bei anderen KI-Assistenten. Ich formulierte meine Anforderung, für mein CLI-Tool n98-magerun2 ein neues, größeres Feature umzusetzen. Der Agent erfasste meine Anforderung und erstellte daraus eine strukturierte requirements.md und ein design.md.

Das design.md war das Herzstück dieser Phase. Es beschrieb die Architektur des neuen Features, definierte die zu erstellenden Klassen und deren Interfaces und gab einen klaren Überblick über die erwarteten Datenmodelle und die Fehlerbehandlung. Das ist ein großer Unterschied zu anderen Agenten, die oft direkt mit der Code-Generierung beginnen. Hier hatte ich das Gefühl, wirklich an der Konzeption mitzuarbeiten, anstatt nur ein fertiges Ergebnis zu erhalten, das ich dann mühsam debuggen muss.

Und so sieht ein Design-Dokument aus (Die Datei ist noch viel länger):

So ein Design-Dokument enthält Beispiel-Code für wichtige Interfaces, beschreibt Konfigurationen und auch die Architektur. Auch Diagramme wurden im Mermaid-Format in das Markdown-Dokument eingebettet.

Phase 2: Der Implementierungsplan

Nachdem das Design-Dokument abgesegnet war, ging es in die nächste Phase: die Erstellung eines detaillierten Implementierungsplans. Ein neuer Agent übernahm die Aufgabe und zerlegte das Design in eine Liste von 11 konkreten, schrittweisen Tasks.

Dieser Plan war beeindruckend detailliert (insgesamt gab es 11 Tasks) und gab mir als Entwickler die volle Kontrolle. Ich konnte jeden einzelnen Schritt überprüfen und entscheiden, ob ich ihn für die Umsetzung freigeben wollte. Kiro schaffte es, eine komplexe Aufgabe in handhabbare, logische Einheiten zu zerlegen, die man dann nacheinander abarbeiten lassen konnte. Das was man hier macht ist quasi die Arbeit eines Software-Architekten.

Die erstellten Markdown-Dateien werden im Projekt abgelegt und können auch versioniert werden.

Der praktische Einsatz: Von der Aufgabe zur Implementierung

Sobald ein Task aus dem Plan ausgewählt wurde, startete Kiro die eigentliche Implementierungsarbeit.
Die Markdown-Datei wird im Editor mit entsprechenden Links angezeigt um die Tasks zu starten.
Ich konnte beobachten, wie der Agent im Hintergrund die Code-Basis analysierte und schrittweise Code-Blöcke erstellte.

Der Agent war dabei nicht blind. In einem der ersten Tasks, in dem die grundlegenden Interfaces und Klassen für das Feature erstellt werden sollten, konnte Kiro sogar selbstständig eine Syntax-Prüfung für die generierten PHP-Dateien durchführen. Dieses proaktive Vorgehen, Fehler frühzeitig zu erkennen und zu beheben, erinnert stark an die Arbeitsweise eines erfahrenen Entwicklers und trägt zur Idee des Vibe Codings bei – der reibungslose Übergang von der Idee zum fertigen Code.

Kiro valdiert die erstellten Klassen on-the-fly. Teilweise wird Code nur für testzwecke generiert, ausgeführt und dann wieder gelöscht.

Das Ergebnis zeigte, dass alle benötigten Abhängigkeiten korrekt geladen wurden, bevor der Agent mit dem nächsten Task fortfuhr. Dieses Vorgehen demonstriert, dass Kiro nicht nur Code-Generierung, sondern auch die Verifikation und das Testen als integralen Bestandteil des Implementierungsprozesses versteht.

Nachdem ein Task abgeschlossen wurde, gab Kiro eine Zusammenfassung der Implementierung aus.

Die Zusammenfassung war detailliert und lieferte eine genaue Übersicht darüber, was in den jeweiligen Schritten erreicht wurde. Das half mir, den Überblick über die Menge des erzeugten Codes zu behalten.

Die Schattenseiten: Quota, Code-Menge und die Kontrolle

So beeindruckend der Prozess auch war, mein Test stieß an seine Grenzen. Im 9. von 11 Schritten war mein Kontingent an Anfragen aufgebraucht. Das unterbrach nicht nur den Arbeitsfluss, sondern zeigte auch eine der größten Herausforderungen bei der Nutzung solcher Agenten: die Abhängigkeit von externen Services. Das Problem lag, wie ich später erfuhr, in einer Fehlkalkulation des Kontingents seitens Amazon, aber der Effekt war derselbe: Der "Vibe" war schlagartig zerstört. Der Agent stoppte, obwohl der Task-Plan noch nicht abgeschlossen war.

Ein weiteres, bemerkenswertes Detail war die schiere Menge an Code, die Kiro in den ersten acht Schritten erzeugte. Über 60 neue PHP-Dateien, komplett mit Interfaces, Implementierungen und Test-Mocks. Als Entwickler, der gewohnt ist, den Code von A bis Z selbst zu schreiben und zu kontrollieren, war es anfangs schwierig, den Überblick zu behalten. Das Feature war zwar umfangreich, aber ich war überrascht, wie viele Dateien für die Implementierung als notwendig erachtet wurden.

Das wirft die zentrale Frage nach der Rolle des Entwicklers auf. Der Agent war in der Lage, Code zu erzeugen, der in der Gesamtheit nicht funktionierte. Das ist nicht überraschend, da die Spezifikation aus einem GitHub Issue stammt und diese niemals so perfekt sein kann, dass alle Eventualitäten abgedeckt sind. Die manuelle Überprüfung und das Fine-Tuning sind nach wie vor unerlässlich. Die Arbeit verschiebt sich vom reinen "Coder" zum "Dirigent", der die Arbeit orchestriert, die Ergebnisse bewertet und die letzten 20 Prozent der Qualitätssicherung selbst übernimmt. Auch hier arbeitet man eher in der Rolle des Software Architekten und einem Test-Manager.

Das ist genau der Punkt an dem die Vibe-Killer lauern:

• Ein großer Teil des erzeugten Codes war unnötig und musste von mir wieder entfernt werden.
• Ich musste die erzeugten Tests anpassen, damit diese überhaupt das tun, was ich mir ursprünglich vorgestellt hatte.
• Da der Agent nach einer gewissen Zeit den Context (die Arbeit des Agenten) verloren hatte und ich den Prozess neu starten musste, war es mir nicht möglich den Pull-Request mit allen Änderungen zu sehen.

Mein Fazit und Ausblick

Kiro ist ein faszinierendes Werkzeug und sein prozessorientierter Ansatz hat mich tief beeindruckt. Das gemeinsame Erarbeiten einer Spezifikation und eines Implementierungsplans ist eine intelligente Herangehensweise, die das Potenzial hat, die Zusammenarbeit zwischen Mensch und Maschine zu revolutionieren. Die Idee, komplexe Aufgaben in klare, nachvollziehbare Schritte zu zerlegen, ist wegweisend.

Dennoch gibt es, wie bei allen neuen Technologien, noch Verbesserungspotenzial. Die Abhängigkeit vom Kontingent, der Verlust des Kontextes bei einem Neustart und die Herausforderung, große Mengen an automatisch generiertem Code zu überblicken, sind Punkte, die in Zukunft adressiert werden müssen.

Für mich hat sich Kiro als wertvolles Werkzeug für die ersten, grundlegenden Implementierungsschritte erwiesen. Es hilft, den "Vibe-Killer" des leeren Code-Editors zu überwinden und schnell eine solide Basis zu schaffen. Man schreibt einen einfachen Satz und Kiro erstellt daraus erstmal einen schönen Draft mit Anforderungen.

Die darauffolgende Arbeit – das Feintuning, die Refaktorierung und die Anpassung an den spezifischen Projektkontext – bleibt weiterhin in der Hand des menschlichen Entwicklers.

Es ist klar, dass wir uns in einer Übergangsphase befinden. Die Frage ist nicht mehr, ob KI-Agenten unsere Arbeit verändern, sondern wie wir am besten lernen, mit ihnen zu arbeiten. Der Entwickler der Zukunft wird nicht nur ein Programmierer sein, sondern auch ein guter "Agent-Handler", der in der Lage ist, Aufgaben präzise zu definieren und die Ergebnisse kritisch zu bewerten. Kiro ist hierbei ein weiterer, spannender Schritt auf diesem Weg.