Nutzen wir AI effizient in der Softwareentwicklung? Die häufigsten Messfehler im Überblick

Niemand mag warten. Niemand mag überschrittene Deadlines. Niemand mag Frust im Team. Und niemand mag ineffizientes Arbeiten. Seitdem Claude Code Ende 2025 angefangen hat, Agentic Software Engineering wirklich in den Mainstream zu bringen, werden die Forderungen nach effektiver AI Usage in Engineering Teams immer lauter. In meinem Umfeld geht es jeden Tag darum.

Gleichzeitig nehmen (zumindest in meiner Wahrnehmung) die Versuche zu, Effektivität von AI Agents in Software-Unternehmen auf eine Art und Weise zu messen, die nicht nur nachweislich ungeeignet ist, sondern sogar aktiv gegen das eigentliche Ziel arbeitet: Effizientere Entwicklungsprozesse.

Dieser Artikel gibt dir einen fokussierten Überblick über die drei Stolpersteine, auf die ich am häufigsten stoße, sowie einen Ausblick auf die Lösung, die sich immer und immer wieder bewährt hat.

1. AI Leaderboards messen nicht AI Effectiveness

Im April 2026 machte Meta (ehemals Facebook) mit seinem „Claudeonomics”-Leaderboard Schlagzeilen, das mehr als 85.000 Mitarbeiter nach ihrem Tokenverbrauch rankte und für die Spitzenreiter Titel wie „Token Legend” oder „Session Immortal” verteilte. Vereinfacht gesagt war die Folge davon, dass Engineers interne Agents dauerhaft laufen ließen, eine massive Menge an Token verbrauchten und außer einem Platz in den Top 250 des Leaderboards keine nennenswerten Ergebnisse produzierten. Das Leaderboard wurde kurze Zeit später als „Spaßprojekt” betitelt und abgeschaltet.

Einen Monat später wurde bekannt, dass Uber sein AI-Budget für das gesamte Jahr 2026 bereits verbraucht hatte. Gleichzeitig gab der COO zu, dass er keinen Zusammenhang zwischen den erhöhten Ausgaben und den tatsächlich gelieferten Features feststellen konnte.

Warum ist das so?

Tokenverbrauch misst AI Adoption: Er zeigt, wie intensiv ein Engineer AI Agents in seinem Alltag verwendet — nicht, wie effektiv. (Und entsprechend auch, wie viel die AI-Nutzung pro Engineer kostet.)

An ihm lässt sich auch ablesen, welche Engineers die Nutzung ablehnen. Hier kann ein Gespräch aufschlussreich sein: Welche Faktoren blockieren dich bei der Nutzung von AI? Ist der Output nicht gut genug? Sind die Agents zu langsam? Kommst du erst gar nicht an den Punkt, an dem du etwas implementieren kannst? (Möchtest du wissen, wie du ein solches Gespräch gewinnbringend führst? In einem zukünftigen Blogartikel liefere ich einen Leitfaden. Lass dich benachrichtigen, um ihn nicht zu verpassen.)

Die wichtigste Tatsache, die man über diese Messungen verstehen muss: Ein Engineer kann mehrere Millionen Token an einem einzigen Tag verbrennen und dabei keinerlei Mehrwert für dein Unternehmen schaffen. Agentic Software Engineering ist kein Heilmittel gegen „Busy Work” (und kann sogar zu solcher verleiten — das ist der „Vibe” in „Vibe Coding”).

2. Lines of Code bleibt der Klassiker unter den schlechten Metriken

Ich kenne noch Zeiten, in denen dem Betriebsrat eines Mittelständlers die Mutter aller Metriken vorgelegt wurde: Wie viele Lines of Code sind im letzten Quartal hinzugekommen? In Zeiten von AI Agents erlebt dieser Klassiker ein regelrechtes Revival: Wie viele Lines of Code hat ein Engineer mit Hilfe von Claude Code oder Codex generiert?

Mehr Lines of Code bedeutet mehr neue Features, richtig? Vermutlich ja, jedoch sind „mehr Features” kein Indiz für effektive Arbeit in der Softwareentwicklung und auch nicht dafür, dass die Software das erfüllt, was die Kunden brauchen.

Zwei Beispiele:

1. Schaltet das Backend-Team einen älteren Service ab, der fast nicht genutzt wird, hat es eine Verantwortung weniger: Der Service muss nicht mehr gewartet werden und die gelegentlichen Featurewünsche der zwei Kunden, die ihn genutzt haben, verstummen. Gleichzeitig zerstört dieser Schritt die Lines-of-Code-Metrik völlig, da der Service wahrscheinlich Zehntausende bis Hunderttausende Zeilen Code hatte, die auf einmal verschwinden.
2. Ein Frontend-Team migriert seinen Tech Stack von einer älteren Abhängigkeit auf eine neue. Die neue Abhängigkeit ist schneller, sicherer, leichter zu integrieren — und lässt sich mit 20% der Codezeilen konfigurieren und nutzen. Den Engineers im Frontend-Team erleichtert es die Arbeit und neue Features gehen etwas leichter von der Hand. Gleichzeitig „verliert” das Projekt vielleicht 8.000 Zeilen Code (mit dem die alte Abhängigkeit eingebunden war) und die Metrik fällt entsprechend ab.

In beiden Fällen werden Engineers entlastet; das Getriebe ist nach diesen Maßnahmen ein bisschen besser geölt. Misst man Effektivität jetzt mit Lines of Code, waren beide Maßnahmen „schlecht” — eben dieser Widerspruch macht Lines of Code ungeeignet, um Geschwindigkeit oder Effektivität zu messen.

Nebenbei: AI Leaderboards und Usage Metrics im Dashboard von Claude Code oder OpenAI messen typischerweise den Tokenverbrauch. Das ist ein wichtiger Unterschied, da ein langer Denkprozess eines Agents mehr Token verbraucht und weniger Lines of Code erzeugt. Zur Einordnung: Wenig „Reasoning” erzeugt mehr Code mit (wahrscheinlich) geringerer Qualität. Nichtsdestotrotz sind beide Metriken — Tokenverbrauch und Lines of Code — nicht geeignet, um die Effizienz eines Entwicklerteams zu messen, das AI Agents einsetzt.

3. Goodhart’s Law

Was ist Goodhart’s Law?

Wenn eine Messung das Ziel wird, ist es keine gute Messung mehr.

Was bedeutet das konkret?

Hier ein Beispiel: Ein Team arbeitet in Sprints und vergibt Story Points an jede Aufgabe. Am Ende des Sprints fertigt z. B. ein Scrum Master eine Auswertung der abgeschlossenen Story Points an: „Diesen Sprint haben wir 42 Story Points geschafft! Letzten Sprint waren es nur 33. Das heißt, diesen Sprint waren wir schneller!” Durch diese Wahrnehmung einigen sich die Teammitglieder darauf, dass „Story Points” eine geeignete Metrik sind für „Velocity”. Natürlich wünscht sich das Management eine optimale (oder gesteigerte) Velocity. So werden „mehr Story Points” zum Ziel. Goodhart’s Law sagt, dass das Team dadurch lernen wird, Story Points inflationär zu vergeben, um die „Velocity-Metrik” hoch zu halten; spätestens dann, wenn ein „schlechter Sprint” mit weniger abgeschlossenen Story Points begründet wird.

Warum ist das so?

Stark vereinfacht gesagt hat das Team in dem oben genannten Beispiel nach einem schlechten Sprint zwei Optionen:

1. Mehr Story Points pro Aufgabe vergeben, um wieder „mehr zu schaffen”.
2. Die zugrundeliegenden Ursachen des schlechteren Sprints analysieren, Hypothesen aufstellen, wie man diese Ursachen beheben kann, die Lösungswege ausprobieren, die Ergebnisse kritisch hinterfragen, …

Option 2 erfordert enorme Disziplin und ein gemeinsames Commitment. Option 1 ist trivial. Es liegt in der Natur des Menschen, den Weg des geringsten Widerstands zu wählen. (Wichtiger Hinweis: Die Gründe dafür sind wesentlicher komplexer als hier skizziert und das Beispiel oben ist eben nur das: ein Beispiel. Für den Zweck dieses Artikels ist es jedoch ausreichend.)

Wie wirkt sich Goodhart’s Law auf unser Ziel aus? Wie verhindern wir, dass unsere Messungen ihre Aussagekraft verlieren, sobald wir sie zum Ziel ausrufen?

Goodhart’s Law liefert uns zwei sehr wichtige Erkenntnisse:

1. Wenn Tokenverbrauch oder Lines of Code jemals gute Metriken waren (waren sie nicht), dann sind sie es spätestens dann nicht mehr, wenn man sie als Ziel ausruft — direkt oder indirekt:

   Ein CEO, der sich über den geringen Tokenverbrauch eines Engineers ärgert, weil er sich mehr Geschwindigkeit in der Feature-Entwicklung wünscht, kann bestenfalls damit erreichen, dass der Engineer in Zukunft mehr Token verbraucht — nicht aber schneller Features entwickelt.

2. Sobald ein Team eine Metrik findet, die tatsächlich seine Effizienz misst, darf diese nicht zum Ziel deklariert werden — weder direkt, noch indirekt.

Wie verhindern wir, dass eine sinnvolle Metrik Goodhart’s Law zum Opfer wird?

Die folgenden zwei Maßnahmen reduzieren die Wahrscheinlichkeit, dass ein Team bewusst oder unbewusst eine Metrik optimiert, statt das Ergebnis, das sie misst:

1. Mach sie nicht zum Ziel: Eine Metrik bleibt ehrlich, solange sie ein teaminternes Diagnose-Werkzeug ist. Wenn eine Führungskraft die Zahlen kennt und weiß, was sie aussagen, wird sie nach den Zahlen fragen. Damit wird sie im Team direkt oder indirekt zum Ziel, und plötzlich sind wir wieder beim Betriebsrat, dem man „Lines of Code“ oder die Velocity im Quartalsbericht vorlegt. Passiert das, liefert selbst scrum.org 13 Möglichkeiten, diese Zahl zu manipulieren (was ich nebenbei dezent lustig finde).

2. Finde mehr als eine gute Metrik: Wenn eine einzelne Zahl (und damit eine einzelne Metrik) fällt, ist das wahrscheinlich schlecht. Wenn sie steigt, ist es wahrscheinlich gut. Das ist das Velocity-Beispiel von oben: Wir können die Zahl manipulieren, sodass der Output besser aussieht, als er ist. Was jedoch, wenn ich zwei, drei oder vier Zahlen habe, die in Wechselwirkung zueinander stehen? Abstrakt gefragt: Was bedeutet es, wenn Wert 2 und 3 steigen, Wert 4 gleich bleibt und Wert 1 sinkt? Ist das gut oder schlecht?

   Sobald wir mehrere Metriken gefunden haben, mit denen wir Effizienz beurteilen können, verlieren wir den Anreiz, eine einzelne davon zu optimieren. Stattdessen ergibt sich ein umfassenderes Gesamtbild, das wir im Blick behalten müssen.

Also: Messen wir einfach Lines of Code und Tokenverbrauch? Nein, aber netter Versuch.

In Teil 2 der Artikelreihe schauen wir uns die Metriken an, mit denen dein Team wirklich messen kann, wie effektiv es arbeitet. Wir lernen, was jeder der Werte bedeutet, wie ihr ihn messen könnt und wie ihr letztlich die Frage beantworten könnt: Macht uns AI in der Entwicklung wirklich schneller und lohnt sich die Investition?

Lass dich benachrichtigen, sobald der Artikel online ist.

---

Du willst nicht auf den Artikel warten, sondern direkt Hilfe dabei erhalten, die richtigen Metriken in deinem Team zu implementieren? Dann lass uns unverbindlich sprechen.

×