KI

KI im Dev-Team einführen: Warum deine Entwickler erst langsamer werden (und wann sich das dreht)

10. Juli 20269 Min. LesezeitArtur Thiessen

Heute vor genau einem Jahr, am 10. Juli 2025, veröffentlichte das Forschungsinstitut METR eine Studie, die in der Entwickler-Welt eingeschlagen ist wie kaum eine zweite: Erfahrene Entwickler waren mit KI-Unterstützung nicht schneller, sondern 19 Prozent langsamer. Die Aufregung danach war groß. Die Einordnung blieb meistens aus. Und weil mir dieselbe Verwirrung seitdem regelmäßig in Gesprächen mit Geschäftsführern begegnet – „Wir haben jetzt seit einem Vierteljahr Copilot, und ich sehe nichts davon" – hole ich die Einordnung heute nach.

Kennst du diese Situation auch:

  • Du hast vor drei Monaten KI-Lizenzen für dein Entwicklerteam gekauft – und die Velocity ist kein bisschen gestiegen?
  • Dein erfahrenster Entwickler murmelt im Standup, das Ding mache mehr Arbeit, als es spart?
  • Und du fragst dich langsam: Habe ich das falsche Tool gekauft, das falsche Team – oder messe ich nur zum falschen Zeitpunkt?

Meine Antwort vorweg, weil sie den ganzen Artikel trägt: Wahrscheinlich ist es der falsche Zeitpunkt. Die Produktivität deines Teams folgt nach einer KI-Einführung einer J-Kurve – sie sinkt erst, bevor sie steigt. Das ist kein Defekt, sondern der normale Verlauf. Nur schreibt das eben kein Tool-Anbieter ins Prospekt.

Die Studie, die keiner im Vertriebstermin erwähnt

Zuerst zu der Studie, die heute Geburtstag hat. METR hat ein randomisiertes Experiment durchgeführt: 16 erfahrene Open-Source-Entwickler bearbeiteten 246 echte Aufgaben in ihren eigenen, gewachsenen Projekten – Codebasen, die sie im Schnitt seit fünf Jahren kannten, teils mit über einer Million Zeilen. Mit KI-Unterstützung brauchten sie 19 Prozent länger als ohne.

Die eigentliche Pointe für dich als Geschäftsführer steckt aber in einem Nebenbefund: Vorher erwarteten die Entwickler, mit KI etwa 24 Prozent schneller zu sein. Hinterher glaubten sie, rund 20 Prozent schneller gewesen zu sein. Real waren sie langsamer. Gefühlte Produktivität ist keine Messung – wenn dein Team dir erzählt, die Tools brächten „auf jeden Fall was", kann das stimmen. Es kann aber auch genau dieser Wahrnehmungsfehler sein.

Bevor du jetzt die Lizenzen kündigst: Die Studie ist kein „KI bringt nichts"-Beleg, und die Autoren sagen das selbst sehr deutlich. Gemessen wurden ausgerechnet die Bedingungen, unter denen KI es am schwersten hat – Experten in ihrem eigenen, vertrauten Code, mit dem Tool-Stand von Anfang 2025. Was die Studie wirklich zeigt, ist etwas anderes: wie die Anfangsphase aussieht. Und die hat jedes Team vor sich.

Von „55 % schneller" bis „19 % langsamer": was die Studien wirklich messen

Denn die METR-Zahl steht ja nicht allein. Je nachdem, welche Vertriebsfolie du zuletzt gesehen hast, werden Entwickler durch KI 55 Prozent schneller, 26 Prozent produktiver oder eben 19 Prozent langsamer. Das klingt nach Chaos, ist aber keins – die Studien messen schlicht verschiedene Situationen:

StudieSettingErgebnisWas das für dein Team heißt
GitHub/Copilot 2022Labor: 95 Entwickler, eine isolierte Standardaufgabe (HTTP-Server in JavaScript)55,8 % schnellerDie Obergrenze unter Idealbedingungen: grüne Wiese, kein Legacy-Code, keine Abstimmung
Cui et al. 2024 (Microsoft, Accenture, Fortune-100)Feld: 4.867 Entwickler im echten Arbeitsalltag+26 % abgeschlossene AufgabenRealistischer Alltagswert über Monate – Juniors profitieren deutlich stärker als Seniors
METR 2025Feld: 16 erfahrene Entwickler im eigenen, gewachsenen Code19 % langsamerDer Experten- und Anfangsfall: die Delle ist real
DORA 2024 → 2025Branchenbefragung (~5.000 Entwickler)2024: Throughput −1,5 %, Stabilität −7,2 % je 25 % mehr KI-Adoption; 2025: Throughput positiv, Instabilität bleibtDie ganze Branche durchläuft gerade dieselbe Kurve

Alle vier Zahlen sind echt, alle vier sind sauber gemessen – sie liegen nur an verschiedenen Punkten derselben Kurve. Grüne Wiese und Standardaufgabe: KI glänzt. Gewachsener Code, erfahrenes Team, Anfangsphase: KI bremst erst. Und dein Team durchläuft mehrere dieser Punkte nacheinander.

Daraus folgt die Kernbotschaft für deine Kalkulation: Wer sein Projekt mit den 50-Prozent-Versprechen aus dem Vertriebstermin plant, kalkuliert es kaputt. In meiner eigenen Praxis fällt der Gewinn dort an, wo Code nach Mustern entsteht – Boilerplate, Tests, Migrationen, Dokumentation. Bei Architekturentscheidungen, Domänenlogik und Abstimmung ist er bis heute nahe null. Das ist mein Erfahrungswert, kein Studienergebnis – aber er deckt sich auffällig gut mit dem, was die Feldstudien messen.

Die J-Kurve: warum der Einbruch am Anfang normal ist

Der Begriff J-Kurve stammt übrigens nicht aus dem KI-Marketing, sondern aus der Ökonomie. Brynjolfsson, Rock und Syverson haben beschrieben, warum Basistechnologien – Dampfmaschine, Elektrifizierung, IT – die messbare Produktivität erst einmal drücken: Der Nutzen entsteht nicht durch das Werkzeug allein, sondern durch unsichtbare Begleit-Investitionen. Neue Prozesse, neue Fähigkeiten, neue Arbeitsteilung. Diese Investitionen kosten jetzt Zeit und zahlen erst später aus – auf dem Papier sieht das wie ein Einbruch aus, tatsächlich ist es Aufbauarbeit.

Übersetzt auf dein Dev-Team heißt das: Deine Entwickler lernen gerade eine neue Arbeitsweise, prüfen KI-Vorschläge misstrauisch nach (anfangs völlig zu Recht) und finden erst heraus, welche Aufgaben sich lohnen und welche nicht. Jede dieser Lernschleifen ist genau so eine Begleit-Investition.

Dass die Branche als Ganzes gerade dieselbe Kurve durchläuft, kannst du an den DORA-Reports ablesen: 2024 korrelierte mehr KI-Adoption noch mit sinkendem Durchsatz und sinkender Stabilität. Im Report 2025 hat der Durchsatz ins Positive gedreht – die erhöhte Instabilität bleibt. Der Kernsatz des Reports ist dabei der wichtigste für dich: KI ist ein Verstärker. Sie verbessert kein Team – sie verstärkt, was da ist. Gute Testabdeckung und kleine Änderungspakete werden schneller. Chaos wird schnelleres Chaos.

Meine eigene Rampe: was ich der KI am Anfang nicht durchgehen ließ

Ich schreibe das nicht aus der Beobachterperspektive. Ich entwickle seit 2009, und heute läuft ein erheblicher Teil meiner Firma über KI-Agenten und Claude Code – von der Buchhaltung bis zur Software-Entwicklung. Von außen sieht das nach einer glatten Erfolgsgeschichte aus. War es nicht.

In meiner Anfangsphase habe ich jede Zeile nachgeprüft, die mir das Werkzeug vorgeschlagen hat. Nicht aus Prinzipienreiterei, sondern weil die Vorschläge eben oft fast richtig waren – und fast richtig ist bei Code die teuerste Sorte von falsch. Es gab Aufgaben, die mit KI länger gedauert haben als von Hand, weil ich erst den Vorschlag verstehen, dann den Fehler darin finden und dann doch selbst schreiben musste. Zeitweise war ich sicher, dass sich das nie rechnen wird.

Der Wendepunkt kam nicht über Nacht und nicht durch ein besseres Modell, sondern durch belegtes Vertrauen: Ich wusste irgendwann aus Erfahrung, bei welchen Aufgabentypen ich mich auf das Ergebnis verlassen kann und bei welchen ich weiterhin jede Zeile lese. Genau diese Landkarte im Kopf – wo KI trägt und wo nicht – ist das, was deine Entwickler in den ersten Wochen aufbauen. Und Architekturentscheidungen überlasse ich dem Werkzeug übrigens bis heute nicht.

Der realistische Fahrplan – mein Erfahrungswert, kein Naturgesetz

Wie lange dauert das Ganze also? Hier ist der Fahrplan, den ich aus meiner eigenen Umstellung und aus Kunden-Workshops mitgenommen habe. Und damit das klar ist: Das sind Erfahrungswerte, kein Benchmark und kein Naturgesetz. Dein Team kann schneller sein oder länger brauchen – je nach Alter und Testabdeckung der Codebasis, Aufgabenmix, Senioritätsmix und danach, ob jemand das Onboarding begleitet.

PhaseTypische Dauer (Erfahrungswert)Was passiertWas du als Geschäftsführer tust
Die DelleWochen 1–4Output sinkt, Frust wächst, erste „brauchen wir nicht"-StimmenDie Delle vorher ankündigen und Lernzeit schützen – nicht wegmoderieren
Break-evenMonate 2–3Erste Aufgabentypen laufen spürbar schneller (Tests, Boilerplate, Doku)Erfahrungsaustausch organisieren: Was funktioniert bei wem?
Echte Gewinneab Monat 3–4Gewinne werden sichtbar – aber ungleich verteilt über Aufgaben und PersonenDranbleiben und realistisch messen statt Vertriebsfolien zitieren

Ein ehrlicher Zusatz, der mir wichtig ist: Ohne Begleitung dauert es nicht einfach nur länger – es kann dauerhaft kippen. Das Team fällt nach dem ersten Frust in die alte Arbeitsweise zurück, die Lizenzen laufen ungenutzt weiter, und in einem Jahr sagt jeder: „Haben wir probiert, bringt nichts." Dann hast du nicht nur die Delle bezahlt, sondern auch den Aufschwung verpasst.

„Brauchen wir nicht" – warum der Widerstand deines besten Entwicklers rational ist

Noch ein Wort zu der Person, die dir im Standup widerspricht. Es ist verlockend, den Widerstand des erfahrensten Entwicklers als Veränderungsscheu abzutun. Ich halte das für einen Fehler – denn er hat ja recht mit seiner Beobachtung. METR zeigt, dass genau erfahrene Entwickler im eigenen, vertrauten Code am ehesten langsamer werden. Dein Senior in der Delle erlebt real einen Verlust. Sein „das bremst mich nur" ist eine Messung, kein Trotz.

Die Stack-Overflow-Umfrage 2025 gibt dieser Erfahrung eine Zahl: 84 Prozent der Entwickler nutzen KI-Tools oder planen es – aber nur 33 Prozent vertrauen der Genauigkeit der Ergebnisse, und 66 Prozent nennen als größte Frustration ausgerechnet „KI-Lösungen, die fast richtig sind, aber eben nicht ganz". Die Werkzeuge werden also breit genutzt und breit misstraut. Beides gleichzeitig. Genau so fühlt sich die Mitte der J-Kurve an.

Für dich als Führungskraft folgt daraus etwas sehr Praktisches: Kündige die Delle an, bevor sie kommt. Wenn dein Team weiß, dass die ersten Wochen zäh werden und warum, ist der Frust ein erwartetes Symptom. Wenn du es verschweigst, wird jeder berechtigte Einwand zum Glaubenskrieg zwischen „KI-Fans" und „Verweigerern". (Wie du die Ängste-Ebene dahinter adressierst – Stichwort Jobsorgen – ist ein eigenes Thema, das ich in einem der nächsten Beiträge aufgreife.)

Begleitetes Onboarding statt „hier ist die Lizenz, viel Spaß"

Was den Unterschied macht zwischen Teams, die durch die Kurve kommen, und Teams, bei denen es kippt, ist nach allem, was ich sehe, nicht das Tool. Es ist die Rampe. Geschützte Lernzeit statt Lernen unter Sprint-Druck. Der Einstieg über Aufgaben, bei denen KI nachweislich trägt – Tests, Boilerplate, Dokumentation – statt ausgerechnet über die Kern-Domänenlogik. Eine Pilotgruppe mit Leuten, die ihre Erkenntnisse weitergeben. Und ein regelmäßiger Austausch darüber, welche Muster funktionieren, damit nicht jeder dieselben Fehler einzeln macht.

Das ist übrigens derselbe Grund, aus dem unkoordinierte ChatGPT-Begeisterung im Office nichts verändert: Werkzeuge verteilen ist keine Einführung. Und es passt zur Verstärker-Logik von DORA – Begleitung wirkt, weil sie genau die Grundlagen stärkt, die KI dann verstärkt.

Genau dafür haben wir unsere KI-Workshops gebaut: vom konkreten Use Case bis zur Umsetzung, als begleitete Rampe statt Lizenz-Wurf. Nicht weil Workshops magisch sind, sondern weil die Delle mit Begleitung kürzer und flacher wird – und weil dein Team dann weiß, dass sie kommt.

Also: Wenn dein Dev-Team drei Monate nach dem Rollout noch nicht schneller ist, hast du sehr wahrscheinlich weder das falsche Tool noch das falsche Team. Du siehst den linken Teil einer J-Kurve – und die Zahlenversprechen aus dem Vertriebstermin waren Laborwerte. Wenn du den KI-Rollout für dein Entwicklerteam gerade planst, oder mittendrin steckst und dich fragst, ob die Delle in deinem Team noch normal ist: Lass uns reden. Im Erstgespräch schauen wir gemeinsam, wo dein Team auf der Kurve steht und was die Rampe verkürzt. Kein Pitch, keine 55-Prozent-Folien – versprochen.

Häufige Fragen

Warum werden Entwickler mit KI-Tools zuerst langsamer?
Weil die Einführung echte Lernarbeit ist: Entwickler müssen neue Arbeitsweisen finden, KI-Vorschläge prüfen (anfangs zu Recht besonders gründlich) und erst herausfinden, für welche Aufgaben das Werkzeug taugt. Die METR-Studie 2025 hat diesen Effekt messbar gemacht: Erfahrene Entwickler waren in ihren eigenen, gewachsenen Projekten mit KI 19 % langsamer – glaubten aber, schneller zu sein. Diese Anfangsdelle ist der linke Teil der J-Kurve und normal, kein Zeichen, dass das Tool oder das Team versagt.
Wie lange dauert es, bis sich KI-Coding-Tools im Team auszahlen?
Eine allgemeingültige Zahl gibt es nicht – sie hängt von Codebasis, Aufgabenmix und Begleitung ab. Als Erfahrungswert aus meiner eigenen Umstellung und aus Kunden-Workshops: einige Wochen spürbare Delle, Break-even nach etwa zwei bis drei Monaten, danach echte Gewinne auf geeigneten Aufgaben. Voraussetzung ist begleitetes Onboarding mit geschützter Lernzeit – wer nur Lizenzen verteilt, riskiert, dass das Team dauerhaft in alte Arbeitsweisen zurückfällt.
Ist die GitHub-Copilot-Studie („55 % schneller“) auf echte Projekte übertragbar?
Nur sehr begrenzt. Die 55,8 % stammen aus einem Laborexperiment von 2022: 95 Entwickler bauten isoliert einen HTTP-Server in JavaScript – eine Standardaufgabe ohne Legacy-Code, Reviews und Abstimmung. Feldexperimente mit 4.867 Entwicklern bei Microsoft, Accenture und einem Fortune-100-Unternehmen fanden im echten Arbeitsalltag rund 26 % mehr abgeschlossene Aufgaben, vor allem bei weniger erfahrenen Entwicklern. Als Kalkulationsgrundlage für dein Projekt taugt keine der beiden Zahlen unbesehen.
Wie viel schneller werden Entwickler durch KI wirklich?
Die ehrliche Antwort: Es hängt von Aufgabe, Erfahrung und Phase ab. Bei Boilerplate, Tests, Migrationen und Dokumentation sind die Gewinne real und deutlich; bei Architektur, Domänenlogik und Abstimmung nahe null – und erfahrene Entwickler im eigenen, vertrauten Code können anfangs sogar langsamer werden (METR: −19 %). Wer pauschal mit 50 % Ersparnis kalkuliert, kalkuliert sein Projekt kaputt; realistisch ist ein spürbarer Gewinn auf einem Teil der Tätigkeitsfläche – nach der Anfangsdelle.

Quellen

  1. METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
  2. GitHub Research: Quantifying GitHub Copilot's impact on developer productivity and happiness
  3. Cui et al.: The Effects of Generative AI on High-Skilled Work – Evidence from Three Field Experiments (SSRN)
  4. DORA: State of AI-assisted Software Development 2025
  5. Stack Overflow Developer Survey 2025 – AI
  6. Brynjolfsson/Rock/Syverson: The Productivity J-Curve (NBER Working Paper 25148)

Artikel teilen

Willst du KI sinnvoll einsetzen?

Beratung, Coaching und Implementierung — von der Strategie bis zum produktiven System.

KI-Projekt besprechen

Mehr zum Thema