Wir werden skeptisch, sobald ein KI-Programm in der Entwicklung mit einem versprochenen Produktivitätsplus in Prozent startet.
Nicht weil Verbesserung unmöglich wäre, die ist oft ganz real. Sondern weil solche frühen Zahlen meist viel präziser klingen als das operative Modell, das dahintersteht.
Und das ist ein Problem.
Eines der nützlichsten Korrektive, das uns dazu begegnet ist, stammt aus der METR-Studie vom 10. Juli 2025 zu erfahrenen Open-Source-Entwicklern. Dort waren Entwickler, die KI-Tools aus dem Frühjahr 2025 einsetzten, im Schnitt langsamer, obwohl sie selbst überzeugt waren, schneller gewesen zu sein. Diese Lücke ist aussagekräftig. Sie zeigt, dass gefühlte und gemessene Produktivität auseinanderfallen können, gerade in reifen Codebasen und bei kontextintensiver Arbeit.
Wenn Sie eine technische Führungskraft sind, sollte Sie dieses Ergebnis nicht zum KI-Gegner machen. Es sollte Sie dazu bringen, die Messung ernster zu nehmen.
Der Fehler, den wir am häufigsten sehen
Teams fragen Wie groß ist unser Produktivitätsgewinn?, bevor sie die Frage Was genau haben wir eigentlich eingeführt? beantwortet haben.
Daraus entstehen drei schlechte Angewohnheiten:
- Man misst die Tool-Nutzung statt der Adoption des Workflows.
- Man zählt die Menge der Ausgabe statt die Qualität der Reviews.
- Man greift zur ROI-Sprache des Managements, bevor das operative Modell in der Entwicklung überhaupt stabil ist.
Heraus kommt ein Dashboard, das viel Betrieb zeigt, aber niemandem bei der Entscheidung hilft, ob die Einführung funktioniert.
Erst die Adoption belegen, nicht den ROI am Ende
Anthropics Economic Index vom 10. Februar 2025 hat festgestellt, dass KI eher ergänzend als vollständig automatisierend eingesetzt wird. Das deckt sich mit dem, was wir in Entwicklungsorganisationen sehen: Der größte Teil des Nutzens entsteht, weil Menschen anders arbeiten, nicht, weil sie aus dem Workflow verschwinden.
Ihr erstes Messmodell sollte also erfassen, ob die Organisation den Workflow so nutzt, wie er gedacht ist.
Wir empfehlen dafür meist vier Ebenen.
| Ebene | Frage | Gutes frühes Signal |
|---|---|---|
| Zugang | Haben die richtigen Leute die richtigen Tools? | Freigegebener Tool-Pfad steht |
| Adoption | Nutzen die Teams den benannten Workflow tatsächlich? | Wiederholte Nutzung in den richtigen Repositories oder Aufgaben |
| Kontrolle | Werden Review-Regeln und Leitplanken eingehalten? | Einheitliches Reviewer-Verhalten und wenige Ausnahmen |
| Ergebnis | Verändert der Workflow das Lieferverhalten? | Mehr Durchsatz, weniger Nacharbeit oder weniger Unklarheit |
Die ersten drei Ebenen kommen, bevor Sie versuchen, eine ROI-Story auf CFO-Niveau zu verkaufen.
Was wir in den ersten 90 Tagen verfolgen würden
Wenn wir einen CTO bei einem Vorzeige-Programm zur KI-Befähigung begleiten würden, würden wir mit einer kleinen Scorecard wie dieser starten:
| Signal | Warum es zählt | Was Sie vermeiden sollten |
|---|---|---|
| Benannte Workflows im Geltungsbereich | Verhindert schwammige Einführungs-Rhetorik | KI in der gesamten Entwicklung |
| Teams nutzen den freigegebenen Tool-Pfad | Zeigt, ob Standardisierung wirklich greift | Jedes Tool gleich zu zählen |
| Review-Ausnahmen oder Eskalationen | Macht Kontrolllücken schnell sichtbar | Stille als Erfolg zu deuten |
| Takt der Verankerung durch Führungskräfte | Zeigt, ob jemand Verantwortung übernimmt | Die Einführung als einmalige Schulung abzuhaken |
| Folge-Review zur Einführung | Erzwingt Belege statt Anekdoten | Sechs Monate zu warten, bevor etwas geprüft wird |
Keines dieser Signale ist spektakulär. Alle sind nützlicher als frühe Eitelkeitsmetriken.
Warum reine Nutzungszahlen nicht reichen
Hohe Nutzung kann eine schlechte Einführungsqualität immer noch verdecken.
Ein Beispiel:
- Ein Team setzt das Tool intensiv in risikoarmen Aufgaben ein.
- Ein anderes nutzt es selten, dafür aber korrekt im wertvollsten Workflow.
- Ein drittes nutzt es ständig und umgeht dabei das vorgesehene Review-Modell.
Eine simple Nutzungszählung wirft alle drei in einen Topf. Operativ sind sie alles andere als gleich.
Deshalb sind uns Adoption-Reviews lieber als reine Aktivitäts-Dashboards.
Ein Adoption-Review fragt: Hat das Team den freigegebenen Workflow auf die freigegebene Weise genutzt?
Das ist die Frage, auf die es ankommt.
Messen Sie, wo die gewonnene Zeit hinfließt
GitHubs Enterprise-Umfrage von 2024 hat zudem auf etwas hingewiesen, das Führungskräfte gern übersehen: Die Befragten gaben an, die durch KI-Coding-Tools gewonnene Zeit für Zusammenarbeit, Systemdesign und Lernen einzusetzen.
Das ist wichtig, weil ein Teil des frühesten Nutzens sich eben nicht als mehr ausgelieferte Tickets zeigt.
Er kann sich stattdessen zeigen als:
- weniger ins Stocken geratene Design-Entscheidungen
- mehr Fokus bei den Reviewern
- schnellere Einarbeitung in eine bestehende Codebasis
- weniger Reibung bei wiederkehrender Entwurfsarbeit
Das sind reale operative Effekte. Sie sind nur schwerer zu sehen, wenn Sie ausschließlich auf die Feature-Ausgabe pro Sprint schauen.
Eine Scorecard, der wir mehr trauen als der KI-Produktivität
Hier ist ein einfacheres Modell, das wir in einem Leadership-Meeting lieber vertreten würden:
1. Adoption der Workflows
- Welche benannten Workflows laufen?
- Welche Teams nutzen sie?
- Wie oft werden sie innerhalb der vorgesehenen Grenzen genutzt?
2. Integrität der Reviews
- Sind sich die Reviewer einig, was sie validieren?
- Sind die Ausnahmepfade klar?
- Gibt es wiederkehrende Fehlerklassen?
3. Verankerung durch Führungskräfte
- Coachen die Entwicklungsmanager ihre Teams entlang des Workflows?
- Bringen Retrospektiven oder Einzelgespräche die Nutzungsqualität ans Licht?
- Driftet die Einführung je nach Team auseinander?
4. Auswirkungen auf das Geschäft
- Sind Entscheidungen schneller geworden?
- Sind Dokumentation oder Testabdeckung verlässlicher geworden?
- Ist das Vertrauen der Führung in die Einführung gewachsen?
Die ersten drei sind operativ. Erst bei der vierten wird der ROI überhaupt diskutierbar.
Verwechseln Sie Tempo nicht mit Wert
Es gibt einen tieferen Grund, frühe geschönte Produktivitätsrechnungen zu meiden: Tempo allein kann die falsche Größe sein.
Wenn KI ein Team dazu bringt, mehr Code zu produzieren, dabei aber die Unsicherheit in Reviews, das Aufweichen von Richtlinien oder die Preisgabe von Secrets erhöht, dann bewegt sich die Organisation womöglich nur schneller in einen schwächeren Zustand.
GitHub schrieb am 1. April 2025, dass 2024 mehr als 39 Millionen Secrets über GitHub geleakt wurden. Diese Zahl sagt nichts speziell über Ihre Organisation aus, aber sie erinnert nützlicherweise daran, dass Entwicklerkomfort und Sicherheitsdisziplin nicht von allein im Gleichschritt laufen.
Wenn uns ein Team also sagt wir sind schneller, fragen wir gern nach:
- Schneller worin?
- Unter welchen Review-Regeln?
- Mit welchen Sicherheitskontrollen?
- Und mit welchem Beleg dafür, dass das neue Tempo wiederholbar ist und nicht bloß Zufall?
Unsere bevorzugte Reihenfolge
Wir würden eine KI-Einführung in dieser Reihenfolge messen:
- Klarheit über den Workflow
- freigegebene Nutzung
- Konsistenz der Reviewer
- Verankerung durch Führungskräfte
- nachgelagerte Liefereffekte
Erst wenn diese fünf sichtbar sind, würden wir an einer stärkeren ROI-Begründung arbeiten.
Diese Reihenfolge ist weniger aufregend als ein vollmundiges Versprechen. Dafür ist es mit ihr deutlich schwerer, sich später zu blamieren.
Ein Wort zur Glaubwürdigkeit
Wer die Rendite verkauft, bevor er das operative Modell beschreiben kann, borgt sich Glaubwürdigkeit von einem Zukunftszustand, den es noch gar nicht gibt.
Wir geben einem Auftraggeber lieber eine kleinere, belastbare Geschichte an die Hand:
Wir haben diese Workflows freigegeben. Diese Teams nutzen sie. Diese Review-Regeln halten. Diese Führungskräfte verankern sie. Und das ist der bisherige Beleg.
Das ist nicht schwächer als ein frühes Uplift-Versprechen.
Es ist genau das, was eine spätere Wert-Story erst glaubwürdig macht.
Quellen
- METR,
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10. Juli 2025 - Anthropic,
The Anthropic Economic Index, 10. Februar 2025 - GitHub,
Survey: The AI wave continues to grow on software development teams, 20. August 2024, aktualisiert am 15. April 2025 - GitHub,
GitHub found 39M secret leaks in 2024. Here's what we're doing to help, 1. April 2025
Häufige Fragen
- Warum stimmen frühe KI-Produktivitätszahlen so oft nicht?
- Gefühlte und gemessene Produktivität können deutlich auseinanderfallen. Die METR-Studie vom Juli 2025 zu erfahrenen Open-Source-Entwicklern hat gezeigt, dass Teilnehmer mit KI-Tools aus dem Frühjahr 2025 im Schnitt langsamer waren, obwohl sie selbst glaubten, schneller gewesen zu sein. In reifen Codebasen und bei kontextintensiver Arbeit ist dieser Effekt besonders ausgeprägt.
- Was sollten technische Führungskräfte in den ersten 90 Tagen einer KI-Einführung messen?
- Sinnvoll sind fünf Signale, bevor man überhaupt von ROI spricht: welche benannten Workflows im Geltungsbereich sind, ob Teams den freigegebenen Tool-Pfad tatsächlich nutzen, ob Review-Ausnahmen oder Eskalationen sichtbar werden, ob Führungskräfte den Workflow aktiv verankern, und ob ein Folge-Review zur Einführung terminiert ist. Diese Signale zeigen, ob die Einführung funktioniert — nicht nur, ob sie viel Betrieb erzeugt.
- Warum reichen hohe Nutzungszahlen nicht als Beleg für eine gelungene KI-Einführung?
- Hohe Nutzung kann eine schlechte Einführungsqualität verdecken. Ein Team setzt das Tool vielleicht intensiv in risikoarmen Aufgaben ein; ein anderes umgeht das vorgesehene Review-Modell komplett, zeigt aber starke Aktivitätswerte; ein drittes nutzt es selten, dafür aber korrekt im wertvollsten Workflow. Eine einfache Nutzungszählung wirft alle drei in einen Topf. Adoption-Reviews, die fragen, ob der freigegebene Workflow auf die freigegebene Weise befolgt wurde, tun das nicht.
- Bedeutet mehr Tempo durch KI automatisch, dass das Team in einer besseren operativen Position ist?
- Nicht zwingend. Wenn höhere Code-Geschwindigkeit mit wachsender Unsicherheit in Reviews, aufgeweichten Richtlinien oder nachlassender Sicherheitsdisziplin einhergeht, bewegt sich die Organisation womöglich nur schneller in einen schwächeren Zustand. GitHub hat für 2024 mehr als 39 Millionen geleakte Secrets auf der Plattform gemeldet — ein nützlicher Hinweis darauf, dass Entwicklerkomfort und Sicherheitskontrollen nicht von allein im Gleichschritt laufen. Bevor ein Geschwindigkeitsgewinn als Erfolg gilt, sollte klar sein, unter welchen Review-Regeln und Sicherheitskontrollen er entstanden ist.
