KI in der Entwicklung wirtschaftlich bewerten: Was Jira-Daten leisten und Tokenkosten verfehlen

Das eigentliche Problem

Ein Entwicklungswerkzeug verursacht Kosten. Eine IDE, ein Testframework, ein Code-Review-System: jedes davon wird bezahlt und keines dieser Werkzeuge wird ausschließlich nach seinen Lizenzkosten bewertet. KI-Tools werden anders behandelt, weil ihre Kosten variabel sind und auf den ersten Blick groß wirken. Das verschiebt den Fokus auf eine Frage, die in keinem anderen Werkzeugkontext so gestellt würde: Was kostet das Tool? Die relevante Frage lautet: Welchen wirtschaftlichen Effekt erzeugt das Tool im Lieferprozess?

Adoption-Kennzahlen helfen dabei nicht weiter. Eine Organisation, in der 90 Prozent der Entwickler täglich einen Coding-Assistenten verwenden, ob GitHub Copilot, Claude Code oder Atlassian Rovo Dev, kann genauso teuer und unproduktiv arbeiten wie eine Organisation, in der niemand KI nutzt. Adoption ist Voraussetzung, nicht Ergebnis. Der Wert entsteht erst dort, wo KI zu schnellerer Lieferung, besserer Qualität oder weniger Nacharbeit führt.

Was tatsächlich gemessen werden muss

Was tatsächlich zu messen ist, sind die Ergebnisse des Lieferprozesses, nicht der Input. Drei Indikatoren reichen für den Einstieg:

• Durchsatz bei vergleichbarer Aufgabenkomplexität. Werden pro Sprint mehr Aufgaben einer vergleichbaren Klasse abgeschlossen?
• Rework und Defect Escape Rate. Steigt die Quote an Bugs, die nach Auslieferung gefunden werden, oder bleibt sie stabil?
• KI-bezogene Kosten je Sprint, Team oder Projekt.

Komplexitätsklassen statt Story Points sind dabei der belastbarere Anker. Story Points sind subjektiv, teamabhängig und inflationär. Eine grobe, aber konsistente Klassifikation von Aufgaben nach Art und Aufwand liefert verlässlichere Vergleiche als geschätzte Punktwerte, an denen sich Velocity-Mathematik aufhängt. Voraussetzung ist eine gemeinsam definierte Klassifizierungslogik, die entweder die Bearbeiter beim Anlegen eines Vorgangs aus einer festen Liste auswählen oder ein KI-Agent automatisch auf jeden neuen Jira-Vorgang anwendet.

Die nächste Falle ist absehbar

Sobald Tokenkosten als alleinige KPI als unzureichend erkannt sind, taucht die naheliegende Reaktion auf: Tokenverbrauch gegen eine andere leicht messbare Größe rechnen, etwa gegen Lines of Code im Pull Request. Das ergibt eine Zahl, die wissenschaftlicher wirkt, bleibt aber Input geteilt durch Input. KI-generierter Code ist strukturell länger als handgeschriebener, weil er mehr Defensive Coding, mehr Boilerplate und mehr Kommentare enthält. Refactoring reduziert Lines of Code und ist genau die Tätigkeit, die man eigentlich belohnen will. Und sobald Lines of Code bekanntermaßen in einem Dashboard stehen, wird Code länger. Das ist kein Vorwurf an Entwickler, das ist Goodhart's Law im Alltag: Sobald eine Kennzahl zur Zielgröße wird, taugt sie nicht mehr als Maß für das, was sie ursprünglich abbilden sollte. Belastbar ist nur die Kombination aus Tokenverbrauch und Outcome-Metrik, nicht der Quotient zweier Input-Größen.

Warum Jira die naheliegende Grundlage ist

Wenn Jira Software ohnehin die Steuerung der Entwicklung trägt, liegt die Datenbasis bereits vor. Aufgaben, Statusübergänge, Durchlaufzeiten, Rework-Schleifen. Was fehlt, ist eine zusätzliche Klassifikation, die KI-Nutzung auf Sprint- oder Aufgabenebene erfasst. Self-Reporting durch Entwickler ist dabei nicht belastbar. Coding-Assistenten laufen permanent im Hintergrund, die Grenze zwischen wesentlicher und beiläufiger Nutzung verschwimmt im Alltag. Belastbarer ist die Auswertung der aggregierten Tool-Telemetrie auf Team- oder Aufgabenebene.

Das ist keine wissenschaftliche Studie. Es ist eine Management-Indikation, die genügt, um Entscheidungen zu treffen. Ein Pilot über mehrere Sprints, mit kontrollierter Vergleichslogik innerhalb eines Teams und über Aufgabenklassen hinweg, liefert eine belastbare Tendenz. Der Vergleich zweier Teams reicht dafür nicht, weil sich Teams in Erfahrung, Codebasis und Domänenwissen unterscheiden. Vergleichbarkeit entsteht innerhalb eines Teams über die Zeit, nicht zwischen Teams im Querschnitt.

Wenn der Bearbeiter kein Mensch mehr ist

Bis hierhin ging es um KI als Assistenz für menschliche Entwickler. Coding-Agenten wie Claude Code oder Atlassian Rovo Dev verändern diese Logik, weil sie selbst als Bearbeiter eines Jira-Vorgangs auftreten können. Die Mess-Infrastruktur bleibt dieselbe, die wirtschaftliche Frage wird sogar präziser: Was kostet ein Vorgang einer bestimmten Komplexitätsklasse bei Bearbeitung durch einen Agent verglichen mit einem Menschen, und welche Cycle Time, welche Rework-Quote und welche Review-Belastung entstehen dabei? Erstmals lassen sich Tokenkosten direkt einem einzelnen Vorgang zuordnen, statt sie pro Entwickler-Lizenz zu pauschalisieren. Adoption-Quoten verlieren in diesem Modell vollends an Bedeutung, weil der Agent eine Aufgabe entweder übernimmt oder nicht.

Die Frage, die in der Diskussion fast immer fehlt

Ob KI als Assistenz eines Entwicklers oder als eigenständiger Bearbeiter eingesetzt wird, an einer Stelle bleibt die Frage in beiden Modellen offen: bei den Senioren. Im Mensch-mit-KI-Setup verändert KI nicht in erster Linie die Menge der Arbeit bei Senior-Entwicklern, sondern deren Art. Statt Code zu schreiben, lesen, prüfen und ordnen sie generierten Code ein. Im agentischen Setup wird der Senior zum Reviewer von Agent-Output, und die Review-Last konzentriert sich strukturell auf die wenigen, die fachliche Tiefe haben. In beiden Fällen ist das verdichtete Engineering-Arbeit, keine automatische Beschleunigung. Sichtbar wird der Effekt nur, wenn der Jira-Workflow Review als eigenen Status trägt. Dann fällt eine Aufgabe auf, die mit KI-Unterstützung zwar schneller den Status "In Entwicklung" verlässt, dafür länger in "In Review" hängt und ihren scheinbaren Geschwindigkeitsvorteil bei der Cycle Time wieder einbüßt. Wer Review im Sammelstatus "In Bearbeitung" verschwinden lässt, sieht diese Verschiebung nicht. Das ist kein Argument gegen Cycle Time als Metrik, sondern ein Argument für eine Workflow-Struktur, die zur Mess-Absicht passt.

Auf die Selbsteinschätzung der Entwickler ist dabei kein Verlass. Eine METR-Studie aus 2025 zeigte: Erfahrene Entwickler arbeiteten mit KI-Tools langsamer als ohne, fühlten sich aber schneller. Belastbar sind Workflow-Daten, nicht das Bauchgefühl der Beteiligten.

Härter ist die Frage zum Junior-Bereich. Wenn KI repetitive Aufgaben übernimmt, fallen klassische Lernpfade weg. Junior-Entwickler haben weniger Berührung mit den Mustern, an denen Erfahrung entsteht. Das ist kein Argument gegen KI, aber es ist ein Argument gegen die Annahme, KI sei eine reine Effizienzfrage. Eine Organisation, die heute ausschließlich den Durchsatz optimiert, baut eine Lücke im fachlichen Nachwuchs auf, die sich nicht im nächsten Sprint, sondern erst über mehrere Senioritäts-Zyklen zeigt. Auch hier liegt ein Hebel im Workflow: Geht eine Aufgabe vom Review zurück in den Backlog oder in Bearbeitung, entsteht im besten Fall ein dokumentiertes Feedback des Seniors am Vorgang, an dem der Junior konkret lernen kann. Das ersetzt verlorene Lernpfade nicht, macht die verbleibenden aber sichtbar und nutzbar. Diese Frage gehört in die wirtschaftliche Bewertung, auch wenn sie sich nicht über einen einzelnen Sprint messen lässt.

In der Praxis beginnt die wirtschaftliche Bewertung mit drei Fragen, die ein Blick auf die Jira-Daten der letzten sechs Sprints in den meisten Organisationen sofort beantwortet: Werden Komplexitätsklassen heute überhaupt sauber unterschieden? Trägt der Workflow Review als eigenen Status oder verschwindet die fachliche Prüfung im Sammelstatus? Und steht aggregierte Tool-Telemetrie zur Verfügung, sodass die Auswertung nicht auf Self-Reporting der Entwickler angewiesen ist? Liegt eine dieser Voraussetzungen nicht vor, ist die Bewertung der KI-Investition nicht das eigentliche Problem, sondern die fehlende Engineering-Grundlage.

Nicht die Nutzung von KI ist der Wert. Der Wert entsteht erst, wenn KI zu besserer, schnellerer oder wirtschaftlicherer Engineering-Leistung führt. Die Voraussetzung dafür wird nicht im KI-Tool entschieden, sondern in der eigenen Jira-Struktur.

Ein Process Impact Check macht sichtbar, welche dieser Voraussetzungen in der eigenen Organisation tragen und welche nachgezogen werden müssen, bevor eine Lizenzdiskussion sinnvoll geführt werden kann: Kontakt