Produktions-Drift-Ratio: Warum KI-Teams Verschleiß am Code messen müssen

KI hat die Softwareentwicklung revolutioniert: Code wird in Sekunden generiert, Funktionen entstehen im Minutentakt, und die Velocity-Kennzahlen explodieren förmlich. Doch während die Produktionsgeschwindigkeit steigt, bahnt sich ein stiller Verfall an. Der Code entfernt sich immer weiter von der ursprünglichen Absicht – ein Phänomen, das als Produktions-Drift-Ratio (PDR) messbar und damit beherrschbar gemacht werden kann.

Der unsichtbare Code-Verfall durch KI

Die Devise der modernen Softwareentwicklung lautet: Schneller liefern, mehr liefern, überhaupt liefern – und dabei seltener fragen, ob das Ergebnis auch gut genug ist. KI hat diesen Deal noch attraktiver gemacht. Mit KI lassen sich Komponenten in Sekunden erzeugen, ganze Funktionen per Prompt refaktorieren und neue Features vor dem nächsten Stand-up bereitstellen. Die Velocity-Charts schießen nach oben. Doch was unter der Oberfläche passiert, ist weniger erfreulich: Die Codebasis beginnt zu bröckeln.

Dieses Phänomen nennt sich Drift – die stille und schleichende Abweichung zwischen dem, was der Code eigentlich leisten sollte, und dem, was er tatsächlich tut. Es sind keine einzelnen Commits, die das Problem verursachen, sondern eine Ansammlung kleiner Abweichungen: Ein Hex-Wert hier, ein verlorener Fokusstatus dort, eine API-Abfrage in der falschen Schicht. Jede dieser Abweichungen für sich betrachtet mag vertretbar erscheinen. Doch in der Summe korrodiert der Code wie Rost, der unbemerkt eine Maschine zerfrisst.

Was sich verändert hat, ist das Tempo. Eine KI, die plausiblem Code schneller generiert, als Menschen ihn überprüfen können, wird damit automatisch zu einem Drift-Turbo. Die Industrie hat gelernt, die Menge des produzierten Codes zu messen – doch sie ignoriert, wie stark sich dieser Code von der ursprünglichen Intention entfernt hat. Dabei ist nicht die Codequalität das eigentliche Problem, sondern die Drift.

Die Kennzahl, die den Unterschied macht: Produktions-Drift-Ratio (PDR)

Die Produktions-Drift-Ratio (PDR) quantifiziert genau diese Abweichung und gewichtet sie nach dem Aufwand, der nötig wäre, um sie zu beheben. Sie macht sichtbar, was bisher im Verborgenen blieb: die schleichende Erosion der Codequalität. Die PDR bewegt sich zwischen 0 (keine Drift) und 1 (extreme Drift).

PDR-Bewertungstabelle

• < 0,30 (Niedrig): Minimale Drift, leicht zu beheben. Keine gesonderten Ressourcen nötig.
• 0,30 – 0,50 (Mäßig): Deutliche Drift. Sollte im Sprint eingeplant werden, bevor sie sich verschlimmert.
• 0,50 – 0,70 (Hoch): Erhebliche Drift. Erfordert gezielte Aufräumarbeiten.
• ≥ 0,70 (Schwerwiegend): Der Code hat sich so weit von den Produktionsanforderungen entfernt, dass ein massiver Sanierungsaufwand droht.

Während eine niedrige PDR noch problemlos in den normalen Entwicklungsprozess integriert werden kann, wird eine hohe PDR zu einem kostspieligen Problem. Die Kennzahl zeigt nicht nur das Ausmaß der Drift, sondern auch, wie viel engineering Zeit und Ressourcen für die Behebung aufgewendet werden müssen – eine Perspektive, die Führungskräfte verstehen.

Warum klassische Metriken die Drift ignorieren

Story Points, Pull Requests pro Woche oder die Zeit bis zum Merge: Diese Kennzahlen messen vor allem die Produktionsmenge, nicht die Produktionsqualität. Doch mit KI hat sich dieses Ungleichgewicht dramatisch verschärft. Wenn eine KI in einer Minute 800 Zeilen plausiblen TypeScript-Code erzeugt, steigen die Zahlen in den Dashboards weiter an – während die eigentliche Messlatte längst nicht mehr erreicht wird.

Ein paar Beispiele, wie sich Drift manifestiert – und warum sie in den gängigen Metriken unsichtbar bleibt:

• Eine Schaltfläche wird 17 Mal in neun Teams neu implementiert. Jede Version hat einen leicht abweichenden Fokusring, aber keine entspricht dem Design-System. Das Ergebnis: Inkonsistenz und Wartungsaufwand.

• Barrierefreiheitsprobleme häufen sich: Interaktive Elemente basieren auf nicht-semantischem HTML, Dialoge enthalten Fokusfallen. Die KI kennt die Anforderungen der Nutzer nicht – und niemand überprüft sie.

• Geschäftslogik und API-Aufrufe wandern in UI-Komponenten ab, geheime Schlüssel landen im Client, Fehlergrenzen fehlen. All diese Probleme erscheinen erst im Dashboard, wenn eine davon eine Seite zum Absturz bringt.

Keine dieser Abweichungen wird in den klassischen Velocity-Metriken erfasst. Doch sie alle summieren sich zu einem Produkt, das sich anfühlt, als hätte es sieben Teams unabhängig voneinander gebaut – oder schlimmer noch: sieben KI-Agenten, die ohne ausreichende menschliche Kontrolle agiert haben.

Wie die PDR Führungsteams zum Umdenken zwingt

Jede kleine Abweichung im Code – sei es ein fehlender Fokusstatus oder eine falsch platzierte API-Abfrage – ist eine kleine Schuld, die irgendwann ein Entwickler begleichen muss. Doch diese Schulden werden selten sichtbar, solange sie nicht in der einen Währung gemessen werden, die wirklich zählt: menschliche Arbeitszeit.

Die PDR ändert genau das. Sie übersetzt die schleichende Erosion des Codes in eine messbare Größe – und damit in eine kalkulierbare Kostenposition. Plötzlich wird aus einer vagen Sorge wie „Das fühlt sich irgendwie inkonsistent an“ ein konkretes Budgetargument: „Hier müssen wir X Stunden investieren, um die Drift zu beheben.“

Für Führungskräfte ist das eine entscheidende Verschiebung. Bisher waren es oft Einzelpersonen – etwa Accessibility-Advokaten, Architekten oder Design-System-Verantwortliche –, die auf Probleme hinwiesen, aber in Planungssitzungen selten Gehör fanden. „Die Dinge wirken unkoordiniert“ oder „Das Design-System erodiert“ sind Argumente, die gegen konkrete Roadmap-Punkte kaum bestehen können. Doch wenn die Drift als messbare Kostenposition dargestellt wird, wird sie zu einem Thema, das Führungskräfte nicht mehr ignorieren können. Die PDR macht das Unsichtbare sichtbar – und gibt den Menschen, die sich für Codequalität einsetzen, endlich eine Stimme im Budgetprozess.

KI als Lösung, nicht als Problem

KI ist nicht das Problem – sie ist das Werkzeug, das Drift sowohl verursachen als auch beheben kann. Die Technologie, die in kürzester Zeit tausende subtile Abweichungen in einem Codebase hinterlassen kann, sollte gleichzeitig genutzt werden, um diese Abweichungen zu erkennen und zu korrigieren.

Nicht alle Probleme sind für Automatisierung geeignet. Entscheidungen wie „Soll dieses neue Muster ins System integriert werden oder muss es stattdessen umstrukturiert werden?“ oder „Ist diese Abweichung beabsichtigt?“ erfordern menschliches Urteilsvermögen. Doch bei klaren Verstößen – etwa fehlenden Fokusringen, falsch platzierten API-Aufrufen oder Sicherheitslücken – sollte die KI proaktiv eingreifen.

Die Herausforderung liegt darin, die Technologie so einzusetzen, dass sie nicht nur Code generiert, sondern auch sicherstellt, dass dieser Code den ursprünglichen Anforderungen entspricht. Erst dann wird aus einer Drift-Maschine ein Werkzeug, das nachhaltig Qualität sichert – und die Softwareentwicklung wieder zu dem macht, was sie sein sollte: ein kontrollierter, zielgerichteter Prozess.

Die Zukunft der Softwareentwicklung wird nicht nur daran gemessen werden, wie schnell wir Code produzieren, sondern daran, wie gut wir sicherstellen, dass dieser Code auch das tut, was er soll. Der Produktions-Drift-Ratio könnte dabei der entscheidende Hebel sein.