Zwölf Arbeitsvereinbarungen für maschinell geschriebenen Code

Die Retro war der einfache Teil.

Ihr Team hat die Vibe-Coding-Hangover-Retro durchgeführt. Die Churn-Daten waren auf dem Board, der Raum war sich einig, dass die Review-Warteschlange sich stillschweigend rationiert hatte, und alle gingen mit dem seltenen Post-Retro-Gefühl, etwas entschieden zu haben. Zwei Sprints später leben die Vereinbarungen in einem Zusammenfassungsdokument, das niemand öffnet, und das Churn-Diagramm hat nichts bemerkt.

Dieser Fehlermodus ist gut dokumentiert: etwa zwei Drittel der Retrospektiven-Aktionen sterben, ohne etwas zu verändern. Arbeitsvereinbarungen sterben schneller, weil eine Vereinbarung eine Norm ist, und eine Norm erhält keine Ticket-Nummer und keinen Verantwortlichen, es sei denn, Sie geben ihr welche.

Dies ist die Regelwerk-Hälfte der Hangover-Retro. Zwölf Arbeitsvereinbarungen für Teams, die maschinengeschriebenen Code ausliefern, aufgebaut auf derselben öffentlichen Forschung, die das Problem benannt hat. Die drei Beispiele aus dem ursprünglichen Beitrag sind hier, ergänzt um neun weitere, alle im gleichen Format: eine Regel, die das Team in einem Satz formulieren kann, die Zahl, die sich bewegt, wenn die Regel befolgt wird, und der Check-in, bei dem Sie nachsehen.

Was ist eine Arbeitsvereinbarung für maschinengeschriebenen Code?

Eine Arbeitsvereinbarung für maschinengeschriebenen Code ist eine Regel, die ein Team für sich selbst darüber aufstellt, wie KI-generierte Änderungen produziert, überprüft und verantwortet werden. Sie unterscheidet sich von einer Richtlinie sowohl in Ursprung als auch Durchsetzung: Eine Richtlinie wird von oben vorgegeben und auditiert, während eine Arbeitsvereinbarung in einer Retrospektive ausgehandelt, anhand der eigenen Lieferdaten des Teams verifiziert und neu geschrieben wird, wenn diese Daten sagen, dass sie nicht funktioniert.

Die Forschungsgrundlage dafür ist direkt. Der DORA-Bericht 2025 stellte fest, dass 90 % der Entwickler mittlerweile KI bei der Arbeit nutzen, wobei die Einführung positiv mit Durchsatz und negativ mit Lieferstabilität verknüpft ist. Sein AI Capabilities Model identifiziert, was Teams, die KI verstärkt, von Teams trennt, die sie destabilisiert, und jede Fähigkeit auf der Liste ist organisatorisch: eine klare und kommunizierte KI-Haltung, kleine Batches, starke Versionskontrollpraktiken. Eine Arbeitsvereinbarung ist die kleinste Einheit organisatorischer Haltung – ein Satz, dem das gesamte Team zugestimmt hat, sich daran halten zu lassen.

Eine Regel, eine Zahl, ein Check-in

Die meisten Arbeitsvereinbarungen scheitern strukturell, nicht kulturell. Ihnen fehlt einer von drei Teilen.

Die Regel muss in einen Satz passen, den ein Teammitglied spontan formulieren kann. Wenn sie einen Absatz braucht, ist es eine Anleitung, und Anleitungen verlieren jedes Mal gegen eine Deadline.

Die Zahl macht die Regel falsifizierbar. Verifizierung ist genau dort, wo Intuition in die Irre führt: Die Stack Overflow-Umfrage 2025 unter 49.000+ Entwicklern ergab, dass die größte Frustration mit KI-Tools, genannt von 45 %, Code ist, der „fast richtig, aber nicht ganz" ist – und fast-richtiger Code fühlt sich gut an, bis die Produktion widerspricht. Gefühle entscheiden das nicht. Zahlen schon.

Der Check-in gibt der Zahl ein Datum und einen Ort, normalerweise die ersten fünf Minuten der nächsten Retro. Eine Regel ohne Zahl ist eine Meinung. Eine Zahl ohne Check-in ist Tapete.

Die Zwölf

Stehlen Sie frei. Die Zahlen in den Regeln (400 Zeilen, 90 Tage, zwei Aufgaben) sind Ausgangspunkte zum Anpassen, keine Gesetze.

Review rationiert sich selbst. Rationieren Sie es bewusst.

Faros AIs Telemetrie von 2026 über 22.000 Entwickler ergab eine mediane Zeit bis zum ersten Review von +156,6 % und PRs, die ohne Review gemergt wurden, um 31,3 % gestiegen. Wenn die Review-Kapazität erschöpft ist, entscheiden Teams nicht, Reviews zu überspringen — es entscheidet sich von selbst, ein „sieht gut aus" nach dem anderen.

1. „Nichts wird ohne eine menschliche Freigabe gemergt, grüne CI hin oder her." Die Basis-Vereinbarung. Fast ein Drittel mehr Änderungen erreichen jetzt Production, ohne dass ein einziger Mensch sie gelesen hat, und fast-richtiger Code ist genau die Art, die CI passiert. Check: Anzahl Merges ohne Review, wöchentlich.

2. „Maschinell geschriebene PRs über 400 Zeilen werden vor dem Review aufgeteilt." Kleine Batches sind die tragendste Fähigkeit in DORAs Modell, und die Batch-Größe ist der Input, den ein Team am direktesten kontrolliert. Ein Reviewer kann 400 Zeilen ehrlich halten; niemand hält 2.000. Check: PR-Größenverteilung, nächste Retro.

3. „Änderungen, die Auth, Payments oder Datenmigrationen betreffen, erhalten einen zweiten Reviewer, unabhängig vom Autor." Skalieren Sie Verifikation mit dem Blast Radius, nicht mit Vertrauen in das Tool. Die kritischen Pfade sind dort, wo Ihre Incidents bereits clustern; benennen Sie sie explizit in der Vereinbarung. Check: Zwei-Freigaben-Rate bei kritischen PRs, nächste Retro.

Verantwortung überlebt die Autovervollständigung

Das Modul, das niemand anfassen will, hat einen Autor, der es nicht erklären kann. Diese zwei Vereinbarungen halten Autorenschaft bedeutsam.

4. „Wenn Sie das Diff nicht erklären können, können Sie es nicht mergen." Erklärung ist die günstigste verfügbare Verifikation: sie kostet zehn Minuten und fängt die Klasse von Bugs, die Reviews überfliegen. Wenn das Erklären einer Änderung länger dauert als sie neu zu generieren, ist das Information über die Änderung. Check: bei Demo-Vorbereitung wird ein gemergter maschinell geschriebener PR pro Engineer laut durchgegangen, jeden Sprint.

5. „Die PR-Beschreibung dokumentiert, was der Mensch verifiziert hat, nicht was das Modell generiert hat." „Migration lokal ausgeführt, Rollback getestet, Query-Plan geprüft" sagt einem Reviewer, wo die menschliche Aufmerksamkeit lag. DORAs ROI-Report von 2026 nennt die Kosten der Prüfung von Maschinen-Output die Verifikationssteuer; diese Zeile macht die Steuer sichtbar statt ambient. Check: Anteil gemergter PRs mit Verifikationsnotiz, nächste Retro.

Churn ist die ehrliche Geschwindigkeitsmetrik

Code-Churn ist in den Faros-Daten um 861 % gestiegen. Ein Feature, das zweimal shipped wurde, war beim ersten Mal nicht schnell, egal was der Sprint-Report sagte.

6. „Ein Rewrite innerhalb von 90 Tagen ist Nacharbeit, und Nacharbeit wird getickt." Das 90-Tage-Fenster kommt vom Muster, das Autonoma die 90-Tage-Abrechnung nennt: Geschwindigkeit in Monat eins wird zu Schulden in Monat drei. Nacharbeit, die nie im Tracker erscheint, ist ein Preis, den das Team zahlt, aber nie zählt. Check: Nacharbeits-Tickets und Churn-Rate pro Modul, nächste Retro.

7. „Wegwerf-Code wird bei der Geburt als Wegwerf deklariert." Spikes und Prototypen sind eine legitime Nutzung von KI-Geschwindigkeit. Labeln Sie sie bei der Erstellung, damit die Churn-Stats ehrlich bleiben und kein Spike zu Production befördert wird, weil alle vergessen haben, was es war. Check: Anteil von Churn aus gelabelten Spikes, monatlich.

Incidents sind, wo die Steuer fällig wird

Incidents-zu-PR-Verhältnis: +242,7 %. Bugs pro Entwickler seit Adoption: +54 %. Die Verifikation, die Sie zur Review-Zeit überspringen, wird in Production durchgeführt, zum schlechtestmöglichen Stundensatz.

8. „Jede Incident-Review fragt, ob die auslösende Änderung maschinell geschrieben wurde, und wir tracken das Verhältnis." Nicht für Schuldzuweisungen — das Verhältnis ersetzt die lauteste Anekdote im Raum durch die eigene Zahl des Teams, und es ist die Zahl, die Ihnen sagt, ob Vereinbarungen 1 bis 5 funktionieren. Check: Postmortem-Template-Feld; Verhältnis monatlich geprüft.

9. „Ein Mensch verantwortet jede Test-Assertion." KI schreibt plausible Tests so wie sie plausiblen Code schreibt, und ein Test, der nichts assertiert, ist schlimmer als kein Test, weil er Vertrauen kauft ohne Verifikation zu kaufen. Tests zu entwerfen ist delegierbar. Zu entscheiden, was wahr sein muss, ist es nicht. Check: Anzahl durchgerutschter Bugs, nächste Retro.

Überfluten Sie die Queue nicht

10. „Zwei Agent-Tasks gleichzeitig pro Person, maximal." Tippgeschwindigkeit war früher ein natürliches Work-in-Progress-Limit; Agents haben es entfernt. Ein Engineer kann jetzt PRs schneller öffnen als drei sie reviewen können, und der Overflow wird entweder Review-Latenz oder unreviewte Merges — dieselben zwei Zahlen, die sich bereits in die falsche Richtung bewegen. Ein WIP-Limit auf Delegation hält das menschliche Verifikationsbudget solvent. Check: offene PRs pro Autor, wöchentlich.

Vereinbarungen über die Vereinbarungen

Die letzten zwei existieren, weil die ersten zehn sonst zu den zwei Dritteln der Action Items gehören, die sterben.

11. „Jede Vereinbarung trägt ein Ablaufdatum." Drei Sprints sind ein sinnvoller Default. Bei Ablauf stimmt das Team neu ab: behalten, umschreiben oder ausmustern. Eine Vereinbarung, die sich für immer automatisch erneuert, ist eine getarnte Policy, und eine Liste voller toter Regeln lehrt das Team, dass die Liste Dekoration ist. Check: die aktive Liste und ihr Alter, jede Retro.

12. „Die Retro beginnt mit der Scorecard." Erste fünf Minuten, vor neuen Themen: jede aktive Vereinbarung, ihre Nummer und ob sie sich bewegt hat. Das ist die Schleife shipping and sticking statt shipping and evaporating. Check: es ist der erste Agendapunkt, jede Retro.

Den Code kennzeichnen, nie den Coder

Mehrere dieser Vereinbarungen verfolgen, ob eine Änderung maschinell geschrieben wurde. Keine von ihnen verfolgt, wer sich auf das Modell gestützt hat, und diese Unterscheidung trägt das gesamte System. Daten auf Änderungsebene beschreiben, wie der Prozess des Teams mit einer neuen Art von Code umgeht. Daten auf Personenebene werden zu einer Rangliste, und eine Rangliste korrumpiert jede Zahl, die sie anzeigt: In dem Moment, in dem Entwickler vermuten, dass die Incident-Quote in eine Leistungsbeurteilung einfließt, hören sie auf, ehrlich zu kennzeichnen, und die Retro läuft wieder auf Bauchgefühl.

Das ist dasselbe Argument, das wir über die Messung der Auswirkungen von KI im Allgemeinen vorgebracht haben: Ergebnisse auf Teamebene messen, niemals Aktivität auf Personenebene. Die obigen Vereinbarungen funktionieren nur, weil jeder im Raum weiß, dass die Zahlen den Prozess beurteilen, nicht die Menschen.

Wie man diese einführt, ohne sie zu töten

Führen Sie zwei oder drei ein, nicht zwölf. Ein Team, das zwölf neue Regeln hält, überprüft keine davon; das Menü existiert, damit Sie Vereinbarungen an Ihre eigenen schlechtesten Zahlen anpassen können.

• Beginnen Sie mit Ihren Daten, nicht mit diesem Beitrag. Wenn Churn flach ist, aber Incidents steigen, brauchen Sie 8 und 9, nicht 6 und 7. Ziehen Sie die Zahlen vor der Retro und lassen Sie sie auswählen.
• Stimmen Sie in der Retro ab. Eine von einem Manager auferlegte Vereinbarung ist eine als Kostüm verkleidete Richtlinie — sie bekommt Compliance, nicht Ownership. Das Team, das die Regel geschrieben hat, ist das Team, das sie unter Deadline verteidigt.
• Erfassen Sie die Baseline bei Einführung. „Merges ohne Review: 14 im letzten Sprint" macht das erste Check-in zu einem Vergleich statt zu einer Debatte. Keine Baseline? Dann ist das Finden der erste Action Item.
• Geben Sie jeder Vereinbarung einen Verantwortlichen. Keinen Durchsetzer — einen Reporter. Eine Person bringt die Zahl zur Retro, damit die Scorecard nie vom kollektiven Gedächtnis abhängt.

FAQ

Wie viele Working Agreements sollte ein Team gleichzeitig haben?

Zwei oder drei aktive Vereinbarungen gleichzeitig. Jede braucht eine gezogene Zahl, ein gehaltenes Check-in und einen berichtenden Verantwortlichen, und dieses Aufmerksamkeitsbudget ist schnell erschöpft. Teams, die eine lange Liste einführen, überprüfen nichts davon; Teams, die drei einführen und sie bei Ablauf zurückziehen oder ersetzen, bauen die Gewohnheit auf, die die nächsten drei günstig macht.

Sollten Pull Requests als KI-generiert gekennzeichnet werden?

Ja, auf Änderungsebene — ein Label oder eine Notiz in der PR-Beschreibung reicht aus, um Churn- und Incident-Verhältnisse berechenbar zu machen. Niemals auf Personenebene: Die Verfolgung der KI-Nutzung pro Entwickler korrumpiert die Daten, die sie sammelt, weil Menschen alles manipulieren, was beobachtet wird. Die nützliche Frage ist, wie der Prozess mit maschinell geschriebenen Änderungen umgeht, nicht wer sie produziert hat.

Was, wenn sich die Zahl nicht bewegt?

Dann hat das Check-in funktioniert. Entweder wurde die Regel nicht befolgt, was normalerweise bedeutet, dass sie wie geschrieben zu teuer war und neu verhandelt werden muss, oder sie wurde befolgt und hat nicht geholfen, was bedeutet, sie zurückzuziehen und die Aufmerksamkeit woanders zu investieren. Eine Vereinbarung, die sichtbar scheitern kann, ist die einzige Art, die glaubwürdig erfolgreich sein kann.

Funktionieren diese ohne Sprints?

Ja. Die Check-ins hängen an welchem Reflexionsrhythmus auch immer das Team hat — wöchentlich, pro Release oder ereignisgesteuert. Die Kadenz ist weniger wichtig als der Ort: ein wiederkehrender Moment, in dem die Zahlen auf dem Board sind und das Team die Regeln ändern darf.

Das Fazit

Das Argument der Hangover-Retro war, dass Vibe-Coding-Schulden ein Prozessversagen sind, und die Retrospektive ist der Ort, an dem Prozesse neu verhandelt werden. Das ist die andere Hälfte: Was diesen Raum verlässt, muss falsifizierbar sein, oder die nächste Retro argumentiert es von vorne. Die Teams, die über den Hangover hinauskommen, sind nicht die mit den strengsten KI-Regeln oder den lockersten. Es sind die, die Regeln schreiben, die ein Argument mit den Daten verlieren können — und sie verlieren lassen.

Stehlen Sie drei. Setzen Sie das Ablaufdatum. Öffnen Sie die nächste Retro mit der Scorecard.

Quellen

• Faros AI — „Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (April 2026)
• DORA — State of AI-assisted Software Development 2025 (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)
• Autonoma — „Vibe Coding Technical Debt: The 90-Day Reckoning" (April 2026)

Weiterführende Literatur

• The Retro for the Vibe-Coding Hangover — die Retrospektive, aus der dieses Regelwerk stammt.
• Why 2/3 of Retrospective Action Items Die (And How to Fix It) — die Follow-through-Mechanik hinter den Vereinbarungen 11 und 12.
• Measuring What AI Actually Does to Your Team — das Messargument auf Teamebene, KI-neutral, in voller Länge.
• Ship and Stick: How to Measure Whether AI Is Actually Working — der Ergebnisstandard, auf den die Scorecard abschließt.