Wie viel Code in einem Entwicklungsteam stammt inzwischen von einer KI? Bei uns gab es ein Gefühl, aber keine Zahlen. Für Entscheidungen über Budget und Werkzeuge reicht ein Gefühl nicht aus. Deshalb wollten wir die KI-Nutzung messen und haben dafür ein Dashboard gebaut. Dieser Beitrag zeigt, welche Fragen es beantwortet, welches Kostenrisiko dadurch sichtbar wurde und wo die Zahlen täuschen.
Warum sich KI-Nutzung messen lohnt
Wir arbeiten mit Claude Code, einem KI-Werkzeug für die Softwareentwicklung, über den Team-Plan des Anbieters mit fester Monatsgebühr pro Person. Wie wir das Werkzeug zuvor im Alltag getestet haben, steht im Beitrag Claude Code im Praxistest. Der Team-Plan ist zunächst kein Risiko. Offen blieb, wie das Werkzeug tatsächlich genutzt wird.
Vier Fragen wollten wir beantworten. Wie verändert sich die Nutzung im Lauf der Zeit? Mit welchen Modellen, Werkzeugen und Anbindungen an externe Systeme arbeitet das Team? Wie viel Code entsteht dabei? Und was lässt sich daraus für die weitere Verwendung ableiten? Claude Code liefert dafür von Haus aus Telemetrie, also laufende Messdaten. Wir haben sie eingesammelt und ein Dashboard daraufgesetzt.
Das Kostenrisiko hinter der Monatspauschale
Die feste monatliche Gebühr ist eine Entscheidung des Anbieters, nicht unsere. Fällt sie morgen weg und es wird nur noch nach Verbrauch abgerechnet, sollte man die Folgen vorher kennen. Wir haben deshalb mitgerechnet, was dieselbe Nutzung über die API kosten würde, also bei Abrechnung nach Verbrauch.
Dass der Anbieter das Abo subventioniert, war uns klar. Die Größenordnung nicht. Ein Werktag des Teams über die API kostet so viel wie unser Abo für einen ganzen Monat.
Zur Einordnung gehört: Das ist der öffentliche API-Preis. Die echten Kosten des Anbieters liegen niedriger, und bei größerem Volumen würde man über Konditionen sprechen. Das Verhältnis dürfte sich aber auf andere Teamgrößen übertragen lassen. Wer Abläufe und Planung auf eine Pauschale stützt, sollte das Szenario „Abrechnung nach Verbrauch“ einmal durchgerechnet haben.
Was im Dashboard steht
Das Dashboard zeigt für ein wählbares Zeitfenster:
- Commits und Pull Requests
- Zahl der Nutzer, Sessions und Prompts
- Token und Kosten, aufgeschlüsselt nach Modell
- die Werkzeuge, die der Agent tatsächlich benutzt
- angenommene und abgelehnte Änderungsvorschläge
- Zeilen Code, die der Agent geschrieben oder geändert hat
Der Aufbau dahinter ist unspektakulär. Claude Code exportiert die Daten über den Standard OpenTelemetry, die Metriken landen in Prometheus, die Ereignisse in Loki, angezeigt wird alles in Grafana. Die Konfiguration kommt als Einstellungsdatei über den Team-Account, eine zentrale Geräteverwaltung ist nicht nötig. Für Entscheider reicht die Einordnung: Der Rohbau war schnell fertig. Die eigentliche Arbeit begann danach, denn jede Frage aus dem Team wurde zu einer eigenen Auswertung im Dashboard.
Wenn die Zahlen täuschen
Die erste Antwort auf die Frage „Wer nutzt es überhaupt?“ war falsch. Zu wenige Entwickler tauchten auf. Der Grund war ein Zustimmungsdialog. Das Kommandozeilenwerkzeug fragt beim ersten Start nach der Telemetrie, die Desktop-App nicht. Wer nur die Desktop-App nutzte, war unsichtbar. Erst als das klar war, stimmte die Zahl.
Ein zweites Beispiel: Die aktive Zeit einer Sitzung springt irgendwann auf das Alter der Sitzung. Wer damit rechnet, bekommt Fantasiewerte. Die Ursachen lagen teils in unseren eigenen Abfragen, teils in Fehlern im Programm des Anbieters.
Die Konsequenz ist einfach. Wer KI-Nutzung messen will, muss jede Kennzahl mindestens einmal gegen die Wirklichkeit prüfen, bevor sie in eine Entscheidung eingeht. Ungeprüfte Rohzahlen messen manchmal Unsinn.
Die wichtigste Kennzahl: Wie viel bleibt erhalten?
Viele Zeilen zu erzeugen ist einfach. Die richtigen Zeilen zu erzeugen, die jemand behält, ist die Leistung. Deshalb halten wir die Quote der angenommenen Änderungsvorschläge für die wichtigste Frage. Dazu kommen Commits und Pull Requests, also was tatsächlich im Projekt landet.
Der Anteil des vom Agenten geschriebenen Codes steigt bei uns derzeit stark an. Für sich genommen sagt diese Zahl wenig, denn ohne den Projektmix dahinter lässt sie sich nicht lesen. Uns interessiert die Richtung, nicht der absolute Wert, und die sieht man erst, wenn man misst. Warum die Menge erzeugten Codes allein kein Erfolgsmaß ist, zeigt der Beitrag Wartungskosten durch KI.
Was bewusst nicht gemessen wird
Der Inhalt der Prompts landet nicht im Dashboard, wir übertragen ihn bewusst nicht. Ausgewertet wird nur aggregiert. Das Dashboard ist kein Instrument zur Leistungsbewertung, und es soll weder zu mehr noch zu weniger Nutzung motivieren. Diese Grenzen sollten vor dem Start feststehen und im Team bekannt sein. Sonst entsteht schnell der Verdacht, es gehe um Kontrolle.
Fazit
Ein Telemetrie-Dashboard ersetzt das Bauchgefühl durch Zahlen, die man hinterfragen kann. Es zeigt das Kostenrisiko hinter einer Pauschale, es macht die Richtung der Nutzung sichtbar, und es liefert mit der Akzeptanzquote ein Maß, das mehr aussagt als die Zahl erzeugter Zeilen. Voraussetzung ist, dass die Daten geprüft und die Spielregeln vorab geklärt sind.
