Was KI messbar bringt, und warum das Gefühl täuscht

Ein Besprechungsprotokoll hat mich früher 60 bis 90 Minuten gekostet: Notizen ordnen, ausformulieren, Zuständigkeiten und Termine nachtragen. Heute brauche ich höchstens zehn Minuten, das Korrekturlesen eingerechnet. Bei der Angebotsprüfung sind aus rund 25 Minuten etwa zwei geworden. Diese Zahlen habe ich, weil ich vorher und nachher auf die Uhr geschaut habe. Das Gefühl allein hätte mir dasselbe gesagt, und genau da wäre ich vorsichtig.

Drei Studien, die gestoppt haben statt gefragt

Zu der Frage gibt es viele Umfragen und wenige Messungen. Drei Arbeiten haben gemessen.

Die erste kommt aus dem Kundendienst. Brynjolfsson, Li und Raymond haben Daten von 5.179 Beschäftigten eines Callcenters ausgewertet, die einen KI-Assistenten bekamen. Gelöste Anliegen pro Stunde stiegen im Schnitt um 14 Prozent. Bei Neuen und weniger Geübten waren es 34 Prozent, bei den Erfahrenen fast nichts (Generative AI at Work, NBER Working Paper 31161¹).

Die zweite ist ein Versuch mit Programmierern. Peng, Kalliamvakou, Cihon und Demirer ließen Entwickler einen kleinen Webserver in JavaScript schreiben, eine Gruppe mit GitHub Copilot, eine ohne. Die Gruppe mit dem Werkzeug war um 55,8 Prozent schneller, mit einem breiten Unsicherheitsbereich von 21 bis 89 Prozent (arXiv:2302.06590²). Drei der vier Autoren arbeiten laut Papier bei Microsoft Research und GitHub, also beim Hersteller. Das macht die Zahl nicht falsch, ich lese sie aber anders.

Die dritte ist die unbequemste. METR hat 2025 sechzehn erfahrene Open-Source-Entwickler in Projekten beobachtet, die sie im Schnitt seit fünf Jahren kennen: 246 Aufgaben, per Los mit oder ohne KI-Werkzeuge. Vorher schätzten die Entwickler, KI mache sie um 24 Prozent schneller. Nachher glaubten sie, um 20 Prozent schneller gewesen zu sein. Gemessen brauchten sie 19 Prozent länger, ein Schätzwert mit breitem Unsicherheitsbereich (arXiv:2507.09089³). METR schreibt dazu selbst, daraus folge nicht, dass KI in anderen Lagen nichts bringt.

Was die drei gemeinsam haben, und wo sie auseinandergehen

Gemeinsam ist ihnen die Methode: nicht fragen, wie es sich anfühlt, sondern zählen, was herauskommt. Das ist der ganze Unterschied zu einer Meinung.

Auseinander gehen die Ergebnisse, und das ist kein Widerspruch, sondern die eigentliche Lehre. In den beiden ersten Studien war die Aufgabe klar umrissen: ein Kundenanliegen nach Muster, ein Programm von null auf nach Vorgabe. Der Gewinn lag dort vor allem bei denen, die das Fach noch nicht beherrschten. In der dritten war es umgekehrt: gewachsener Code und eigene Ansprüche an die Qualität. Dort hat die KI eher gebremst.

Die Selbsteinschätzung lag dort um fast vierzig Prozentpunkte daneben. Ich vermute, das trifft nicht nur Programmierer. Wenn ein Werkzeug flüssig antwortet und Arbeit abnimmt, fühlt sich das schnell an. Ob es schnell war, sehe ich erst auf der Uhr.

Darauf achte ich

Bevor ich einem Werkzeug einen Nutzen zuschreibe:

• Vorher messen. Ein paar Vorgänge ohne KI stoppen, ehe sie ins Spiel kommt. Nachher lässt sich die alte Zeit nur noch schätzen, und bei METR fiel die Schätzung zugunsten des Werkzeugs aus.
• Das Nacharbeiten mitzählen. Korrekturlesen, Nachfragen, Ausbessern gehört zur Zeit. Sonst vergleiche ich einen fertigen Vorgang mit einem halbfertigen.
• Wer misst. Bin ich in dieser Sache Anfänger oder Routinier? In den drei Arbeiten hing das Ergebnis daran. Ob es darüber hinaus gilt, zeigen sie nicht.
• Wer die Studie bezahlt. Herstellernähe ist kein Ausschlussgrund, gehört aber dazugesagt.

Das Protokoll und die Angebotsprüfung sind in zwei Beiträgen genauer beschrieben: Das Besprechungsprotokoll aus der Aufnahme und Das Angebot kommt als PDF. Wie aus einer solchen Zeitmessung eine Rechnung wird, die trägt, steht in Rechnen, bevor man baut.

Damit endet der Lernpfad. Die zehn Grundlagen behandeln, was ein Modell ist, was es kann, was es nicht kann und wie ich prüfe, ob es mir etwas bringt. Der Rest ist Alltag.