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
Wer wissen will, was KI bringt, findet 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 Copilot-Gruppe war um 55,8 Prozent schneller, mit einem breiten Unsicherheitsbereich von 21 bis 89 Prozent (arXiv:2302.06590). Dazu gehört: Drei der vier Autoren arbeiten laut Papier bei Microsoft Research und GitHub, also beim Hersteller des untersuchten Werkzeugs. Das macht die Zahl nicht falsch, aber man liest sie anders.
Die dritte ist die unbequemste. METR hat 2025 sechzehn erfahrene Open-Source-Entwickler in ihren eigenen Projekten beobachtet, 246 Aufgaben, jeweils 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 waren sie um 19 Prozent langsamer (arXiv:2507.09089).
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. Und der Gewinn lag vor allem bei denen, die das Fach noch nicht beherrschten. In der dritten Studie war es umgekehrt: Leute, die ihr Projekt seit Jahren kennen, mit eigenen Ansprüchen an die Qualität, in gewachsenem Code. Dort hat die KI eher gebremst.
Und die Selbsteinschätzung lag daneben, um fast vierzig Prozentpunkte. Das trifft nicht nur Programmierer. Wenn ein Werkzeug flüssig antwortet und Arbeit abnimmt, fühlt sich das schnell an. Ob es schnell war, sieht man erst auf der Uhr.
Darauf achte ich
Bevor ich einem Werkzeug einen Nutzen zuschreibe:
- Vorher messen. Ein paar Vorgänge ohne KI stoppen, ehe die KI ins Spiel kommt. Nachher lässt sich die alte Zeit nur noch schätzen, und Schätzungen fallen zugunsten des neuen Werkzeugs aus.
- Das Nacharbeiten mitzählen. Korrekturlesen, Nachfragen, Ausbessern gehört zur Zeit. Sonst vergleicht man einen fertigen Vorgang mit einem halbfertigen.
- Wer misst. Bin ich in dieser Sache Anfänger oder Routinier? Die Studien legen nahe, dass das über Gewinn oder Verlust entscheidet.
- Wer die Studie bezahlt. Herstellernähe ist kein Ausschlussgrund, gehört aber dazugesagt.
Meine eigenen Zahlen, 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. Wer die zehn Grundlagen gelesen hat, weiß, was ein Modell ist, was es kann, was es nicht kann und wie man prüft, ob es einem etwas bringt. Der Rest ist Alltag.