Die Retro für den Vibe-Coding-Kater

Irgendwo in Ihrer Codebasis gibt es ein Modul, das niemand anfassen möchte. Es wurde im März ausgeliefert, schnell, wobei ein KI-Assistent den Großteil der Eingabe übernahm. Es funktionierte in der Demo. Es wurde seitdem zweimal neu geschrieben, taucht in Incident-Timelines auf, und der Entwickler, der es „geschrieben" hat, kann es nicht vollständig erklären.

Dieses Modul hat jetzt einen Namen. Die Branche stritt 2025 darüber, ob KI-Coding-Tools Teams schneller machen. 2026 ist die Debatte vorbei und die Rechnung ist eingetroffen — nicht in Dollar, sondern in Churn, Review-Warteschlangen und Incident-Channels. Autonoma nennt es die „90-Tage-Abrechnung": der Punkt, an dem die Geschwindigkeit von Monat eins zur Schuld von Monat drei wird. Gizmodo berichtete letzten September, dass Unternehmen Entwickler speziell einstellen, um vibe-codierte Fehler zu beheben. Eine ganze Aufräum-Ökonomie entsteht um ein Problem, das die meisten Teams selbst hätten erkennen können, vier Sprints früher, in einer Zeremonie, die sie bereits im Kalender haben.

Dieser Beitrag handelt davon, diese Zeremonie richtig durchzuführen.

Der Kater ist messbar

Der Peitschenschlag ist kein Gefühl. Faros AIs 2026 AI Engineering Report — zwei Jahre Telemetrie von 22.000 Entwicklern aus mehr als 4.000 Teams — lieferte Zahlen für beide Hälften: die Beschleunigung, die alle feierten, und die Verschlechterung, die ihr downstream folgte.

Quelle: Faros AI, „AI Engineering Report 2026", April 2026.

Lesen Sie die oberen zwei Zeilen und KI funktioniert. Lesen Sie die unteren fünf und Sie sehen den Kater in Echtzeit entstehen: Code wird fast neunmal so oft verworfen, Incidents pro PR haben sich mehr als verdreifacht, und fast ein Drittel mehr Änderungen erreichen Production, ohne dass ein einziger Mensch sie gelesen hat.

Der DORA-Report 2025, jetzt umbenannt in „State of AI-Assisted Software Development", fand dieselbe Form im Survey-Maßstab: 90% der Entwickler nutzen KI bei der Arbeit, gegenüber 76% im Vorjahr, und KI-Adoption ist jetzt positiv mit Durchsatz verknüpft. Aber sie „hat weiterhin eine negative Beziehung zur Stabilität der Software-Auslieferung". Schneller und wackeliger, gleichzeitig, branchenweit.

Dies ist ein Prozessversagen, kein Tool-Versagen

Die KI hat genau das getan, worum sie gebeten wurde. Sie produzierte plausiblen Code in einem Tempo, für das kein Review-Prozess ausgelegt war. Was versagte, war alles drumherum: Niemand entschied, wie viel Verifikation ein maschinell geschriebener Diff verdient, welche Batch-Größe Reviews ehrlich hält oder wer Code besitzt, den kein Mensch geschrieben hat.

Das sind Working Agreements. Working Agreements sind Prozess. Und die Evidenz sagt, dass Prozess genau dort ist, wo der Hebel liegt. DORAs AI Capabilities Model identifiziert sieben Bedingungen, die bestimmen, ob KI ein Team verstärkt oder seine Dysfunktion verstärkt — und sie sind alle organisatorisch: eine klare und kommunizierte KI-Haltung, starke Versionskontroll-Praktiken, Arbeiten in kleinen Batches, gesunde Daten-Ökosysteme. Keine einzige davon ist „kaufen Sie ein besseres Modell".

DORAs 2026 ROI-Report fügte die Kostenseite hinzu. Teams, die KI einführen, treffen auf eine J-Kurve (Produktivität sinkt, bevor sie steigt), und ein Haupttreiber ist das, was der Report die Verifikationssteuer nennt: die menschlichen Stunden, die für die Überprüfung von Maschinen-Output aufgewendet werden. Stack Overflows 2025-Umfrage unter 49.000+ Entwicklern erklärt, warum diese Steuer so hoch ist. Das Vertrauen in KI-Genauigkeit fiel von 40% auf 29% in einem Jahr, und die Frustration Nummer eins, genannt von 45% der Befragten, sind „KI-Lösungen, die fast richtig sind, aber nicht ganz". Fast-richtiger Code ist die teuerste Art. Falscher Code scheitert schnell; fast-richtiger Code besteht das Review und scheitert in Production.

Ein Tool-Problem hätte eine Tool-Lösung. Ein Working-Agreement-Problem hat genau einen Ort, an dem Teams neu verhandeln, wie sie arbeiten.

Was ist eine Vibe-Coding-Kater-Retro?

Eine Vibe-Coding-Kater-Retro ist eine Retrospektive, die untersucht, wie Ihr Team Code mit KI produziert, nicht nur was es ausgeliefert hat. Sie ersetzt Meinungen durch die eigenen Delivery-Daten des Teams — Code-Churn, Review-Latenz, Incident-Links, ungeprüfte Merges — und ihr Output ist eine kleine Menge von Working Agreements für maschinell geschriebene Änderungen, jedes im folgenden Sprint messbar.

Sie unterscheidet sich von Ihrer regulären Retro im Umfang, nicht im Format. Eine normale Retro fragt „wie war der Sprint?" Diese hier stellt eine schärfere Frage: „Was ist unsere tatsächliche Beziehung zu dem Code, den wir nicht geschrieben haben?" Dieselben Templates, dasselbe Voting, dieselbe Timebox. Andere Evidenz auf dem Tisch.

Und sie sollte bald stattfinden, nicht irgendwann. Die Faros-Daten sagen, dass Verschlechterung sich verstärkt: Churn nährt Incidents, Incidents nähren Review-Last, Review-Last nährt die Versuchung, ohne Review zu mergen. Jeder Sprint ohne Kurskorrektur macht die Korrektur größer.

Datenbasiert arbeiten, nicht nach Bauchgefühl

Es ist eine echte Ironie, eine Retrospektive über Vibe Coding abzuhalten und sie nach Bauchgefühl zu führen. Wenn der Fehlermodus war „wir haben plausibler Ausgabe ohne Überprüfung vertraut", kann die Zeremonie, die das behebt, nicht selbst auf plausiblen Eindrücken basieren. Ihre Integrationen halten bereits die Beweise bereit — Ihre Repos kennen die Änderungsrate, Ihr Tracker kennt die Nacharbeit, Ihr Incident-Channel kennt die Spur.

Bringen Sie fünf Fragen auf das Board, jede verankert in einer Zahl, die Sie vor dem Meeting abrufen können:

1. Welche PRs der letzten 90 Tage haben wir bereits umgeschrieben? Churn ist das ehrliche Maß für Geschwindigkeit. Ein Feature, das Sie zweimal ausgeliefert haben, wurde nicht schnell ausgeliefert.
2. Wo geht Review tatsächlich hin? Wenn die Zeit bis zum ersten Review steigt, während No-Review-Merges gleichzeitig zunehmen, rationiert Ihr Review-Prozess sich selbst stillschweigend. Entscheiden Sie die Rationierung bewusst.
3. Welche Incidents lassen sich auf Änderungen zurückführen, die niemand vollständig gelesen hat? Nicht zur Schuldzuweisung: um die Überprüfungskosten zu beziffern, die Sie bereits im ungünstigsten Moment zahlen, in der Produktion.
4. Was ist unsere Arbeitsvereinbarung für maschinell geschriebene Diffs? Wenn der Raum sie nicht in einem Satz formulieren kann, haben Sie keine. Sie haben ein Bauchgefühl.
5. Haben die letzten Action Items Bestand gehabt? Zwei Drittel der Retro-Action-Items sterben. Wenn Ihre das getan haben, ist das die erste Korrektur. Nichts anderes, was Sie heute entscheiden, zählt, wenn es bis Donnerstag verdunstet.

Die Korrekturen überleben lassen beim Kontakt mit dem nächsten Sprint

Die Ausgabe dieser Retro ist keine Gefühlszusammenfassung. Es sind zwei oder drei Arbeitsvereinbarungen, jede so formuliert, dass die Daten des nächsten Sprints sie bestätigen oder widerlegen können. Das Muster, das funktioniert: eine konkrete Regel, eine Zahl, die sich bewegt, wenn sie befolgt wird, und ein benanntes Check-in.

• „Von Agenten generierte PRs über 400 Zeilen werden vor dem Review aufgeteilt." Check: PR-Größenverteilung, nächste Retro.
• „Nichts wird ohne eine menschliche Freigabe gemergt, grüne CI hin oder her." Check: No-Review-Merge-Anzahl, wöchentlich.
• „Jedes Incident-Review fragt, ob die auslösende Änderung KI-verfasst war, und wir tracken das Verhältnis." Check: Incident-Postmortem-Template, diese Woche.

Kleine Batches, verpflichtendes Review, Incident-Nachverfolgbarkeit — Sie werden bemerken, das sind DOARs KI-Fähigkeiten, übersetzt in Sätze, denen ein Team an einem Dienstag tatsächlich zustimmen kann. Das ist der Punkt. Die Forschung benennt die Fähigkeiten; die Retro ist der Ort, an dem ein Team sie installiert.

Dann schließt sich die Schleife so, wie wir immer argumentiert haben, dass sie sollte: Die nächste Retro beginnt damit zu prüfen, ob die Vereinbarungen gehalten haben und ob sich die Zahlen bewegt haben. Ist Churn gesunken? Hat sich die Review-Latenz erholt? Hat es Bestand gehabt? Verbesserung, die Sie nicht überprüfen können, ist nur ein weiteres Bauchgefühl.

Das Fazit

Der Kater war nie der Preis für die Nutzung von KI. Er ist der Preis dafür, eine neue Art der Softwareentwicklung einzuführen, ohne sich jemals als Team hinzusetzen und neu zu verhandeln, wie Sie Software entwickeln. Die Teams, die 2026 vorankommen, sind nicht diejenigen, die am meisten KI nutzen oder am wenigsten. Es sind diejenigen, die das Schleudertrauma in ihren eigenen Daten bemerkt, das Meeting einberufen und die Regeln aufgeschrieben haben — während alle anderen noch darüber stritten, wessen Bauchgefühl richtig war.

Sie brauchen keinen Aufräumspezialisten. Sie brauchen neunzig Minuten und Ihre eigenen Zahlen.

Nicht weniger KI. Mehr Reflexion.

Quellen

• Faros AI — „Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (April 2026)
• DORA — State of AI-assisted Software Development 2025 und Ankündigung von Google Cloud (September 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — „New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (Mai 2026)
• Stack Overflow — 2025 Developer Survey results (Dezember 2025)
• Gizmodo — „After AI Led to Layoffs, Coders Are Being Hired to Fix 'Vibe-Coded' Screwups" (September 2025)
• Autonoma — „Vibe Coding Technical Debt: The 90-Day Reckoning" (April 2026)

Weiterführende Literatur

• Why 2/3 of Retrospective Action Items Die (And How to Fix It) — das Follow-through-Problem, dessen Lösung diese Retro voraussetzt.
• Measuring What AI Actually Does to Your Team — wie Sie die echte Auswirkung von KI auf Ihr Team sehen, ohne Überwachung.
• Ship and Stick: How to Measure Whether AI Is Actually Working — der Outcome-Rahmen hinter „hat es Bestand gehabt?"
• Beyond Sprints: Continuous Improvement for AI-Native Teams — warum Reflexionskadenz wichtiger ist, wenn Deployment kontinuierlich ist.