Die METR-Studie war kein Urteil über alle Situationen
Die im ersten Modul beschriebene Studie untersuchte gezielt erfahrene Entwickelnde bei komplexer Arbeit in Codebasen von rund einer Million Codezeilen. Das ist eine spezifische, anspruchsvolle Konstellation – nicht die durchschnittliche Programmieraufgabe. Kommentare zur Studie weisen darauf hin, dass sich Ergebnisse aus dieser Konstellation nicht automatisch auf andere Situationen übertragen lassen.
Der Adoptions-Produktivitäts-Widerspruch
Ein verwandtes Muster bestätigt das: Obwohl ein Großteil der Entwickelnden KI-Coding-Tools nutzt, zeigen branchenweite Produktivitätskennzahlen keinen entsprechend großen, gleichmäßigen Sprung. Die naheliegende Erklärung ist nicht, dass die Tools nichts bringen – sondern dass ihr Nutzen stark vom Kontext abhängt und sich deshalb im Durchschnitt verwässert.
Drei Kontextfaktoren, die den Unterschied machen
Drei Faktoren bestimmen maßgeblich, ob KI-Coding-Tools eher helfen oder eher bremsen: der Aufgabentyp (Boilerplate und Scaffolding profitieren mehr als komplexe Architekturentscheidungen), die Codebasis (Greenfield-Projekte und kleinere, klar abgegrenzte Repositories profitieren mehr als gewachsene, große Legacy-Systeme) und der Erfahrungsstand (Einsteigende profitieren oft stärker von Vorschlägen, weil weniger eigener Kontext im Kopf gehalten werden muss – erfahrene Entwickelnde verlieren eher den Flow durch ständiges Nachprompten).
Praxis-Teil: die eigene Situation einordnen statt raten
Statt Branchenversprechen oder einer einzelnen Studie blind zu vertrauen, lohnt sich eine einfache Selbsteinschätzung anhand der drei Kontextfaktoren – und darauf aufbauend eine kleine, eigene Zeitmessung an einer typischen Aufgabe, mit und ohne Tool. Das erklärt auch, warum Entwickelnde im Schnitt 2,3 verschiedene Tools parallel nutzen: Kein einzelnes Tool passt zu jedem der drei Kontextfaktoren gleichermaßen gut.