Hohe Aktivierung, niedrige Acceptance, kein Liefersignal. So liest sich das Dashboard nach drei Monaten mit 50 Claude-Code-Lizenzen. Eine Senior-Backendentwicklerin hat damit drei Features gebaut. Zwei Mid-Levels haben die Nutzung still eingestellt. Eine Junior-Entwicklerin merged PRs, die niemand mehr in Ruhe gelesen hat.
Was hier fehlt sind die ersten beiden 30-Tage-Phasen.
Für Engineering-Organisationen heißt KI im Unternehmen einführen heute oft: Coding Agents kontrolliert ausrollen. Coding Agents einführen ist kein Werkzeug-Deployment, sondern ein Organisationsexperiment, das in drei Phasen drei verschiedene Fragen beantwortet, eine pro Monat. 90 Tage sind kein vollständiger Rollout. Sie sind ein Entscheidungsfenster für ein erstes belastbares Team-Experiment. Werden alle drei Phasen parallel angesetzt, beantwortet keine davon sauber. Den größeren Rahmen für Tooling, Messung und Compliance bündelt unser Leitfaden für Engineering-Leads.
Der Reflex, an dem Rollouts scheitern
Der gefährliche Reflex sieht so aus: Lizenzen für das ganze Team kaufen, Lunch & Learn ansetzen, Slack-Channel #ai-coding eröffnen, Rollout abhaken.
Bitkom meldet für 2025: 36 Prozent der deutschen Unternehmen ab 20 Beschäftigten setzen KI aktiv ein, nach 20 Prozent im Vorjahr. Der Einsatz konzentriert sich auf Kundenkontakt und Marketing, in der IT-Abteilung sind es nur zwei Prozent. KI ist als Unternehmensthema angekommen. Für Engineering ist die Methode noch offen.
Der Lizenz-Reflex scheitert an der Streuung. Die Ergebnisse von KI-Coding-Werkzeugen variieren innerhalb eines Teams ungewöhnlich stark. Derselbe Agent, dieselbe Codebasis, fünf verschiedene Ergebnisse. Über diese Spannweite einen Mittelwert zu legen, hilft niemandem.
Der 90-Tage-Plan existiert, um diese Streuung früh sichtbar zu machen, statt sie später aus der Incident-Statistik herauszulesen. Wer eine Phase überspringt, skaliert die Streuung, ohne sie verstanden zu haben. Wer KI in deutschen Unternehmen implementieren will, muss zusätzlich Legacy-Code, Compliance und Mitbestimmung mitdenken. Das macht frühe Begrenzung wichtiger. Mehr dazu im Mittelstand-Pfad.
Drei Phasen. Eine Entscheidung am Tag 90.
Tage 1 bis 30 · Die Hypothese
Die zentrale Frage der ersten dreißig Tage: Kann ein kleines Team das Werkzeug auf unserem Code zum Laufen bringen?
Nicht: „Findet das Team das Werkzeug spannend?" Die Hypothese ist operativ. Ein Team, eine Codebasis, ein Agent. Eine Behauptung, die spezifisch genug ist, um falsch zu sein.
Security vor dem ersten Prompt klären. Bevor irgendjemand einen Agenten startet, steht fest, welche Repositories, Secrets, Kundendaten und Logs tabu sind. Genauso geklärt ist, welche Prompts und Outputs gespeichert werden, ob Produktivcode an externe Modelle gesendet werden darf oder ob ein On-Premise-Setup nötig ist, und wie personenbezogene Daten ausgeschlossen werden. Diese Grenze ist keine Policy für Tag 90, sondern die Eintrittskarte für Tag 1.
Das Pilotteam ist kein Enthusiasten-Team. Der Reflex ist, die drei Leute zu nehmen, die Cursor seit Monaten in einem Sideproject benutzen. Genau diese Wahl macht den Pilotbefund unbrauchbar. Enthusiasten haben sich an die Schwächen des Werkzeugs angepasst und melden sie nicht mehr zurück. Die Senior-Skepsis am anderen Ende ist genauso wichtiges Signal und gehört in die Pilotaufstellung, nicht herausgefiltert. Ein belastbares Pilotteam muss repräsentativ sein, nicht maximal motiviert: Seniorität, normale Mid-Level-Nutzung, mindestens eine weniger erfahrene Person und eine Teamleitung mit Abbruchmandat. Das wichtigste Auswahlkriterium ist die Codebasis. Sie muss repräsentativ für den Rest der Organisation sein, also der Teil mit Geschichte, nicht der Service auf der grünen Wiese.
Den Betriebsrat in Woche 1 einbinden. Wer Entwickleraccounts für einen Agenten bereitstellt, der Sitzungen und Token-Verbrauch protokolliert, wird in vielen Konstellationen mitbestimmungspflichtig nach §87 Absatz 1 Nummer 6 BetrVG. Sitzungsdaten, Nutzungsdaten oder Token-Verbrauch können Rückschlüsse auf Verhalten oder Leistung einzelner Beschäftigter erlauben. Wie Sie diese Verhandlung führen, ohne den Rollout-Termin zu verlieren, ist im Betriebsrat-Beitrag ausgeführt. Der Punkt hier ist allein die Zeitachse: Wer das Gespräch zur Betriebsvereinbarung erst spät beginnt, verliert acht bis zwölf Wochen genau in dem Moment, in dem die Skalierung anstehen sollte.
Eine prüfbare Behauptung pro Entwickler. Keine Floskel wie „mehr Produktivität". Eine konkrete Aussage. Ich werde Standard-CRUD-Endpoints 40 Prozent schneller liefern, bei gleicher Fehlerrate. Oder: Ich werde die Testabdeckung auf Modul X um 20 Prozentpunkte erhöhen. Zwei Eigenschaften muss diese Aussage haben: Sie kommt von der Entwicklerin selbst, nicht aus einer OKR-Vorlage, und sie lässt sich falsifizieren. Vage Behauptungen produzieren vage Evidenz und überleben in jede Richtung.
An Tag 30 schreibt das Team ein nüchternes Debriefing. Die Entscheidung ist binär. Die Hypothese ist falsifiziert, teilweise bestätigt oder unklar. Unklar ist das häufigste Ergebnis. Es wird am häufigsten als Erfolg gemeldet.
Tage 31 bis 60 · Die Evidenz
Die zentrale Frage der zweiten Phase: Überlebt der Produktivitätsgewinn die Messung?
Hier fallen viele Rollouts auseinander. Hier wird der Engpass aus dem Pull-Request-Beitrag fällig. Bis Tag 45 liefert das Pilotteam mehr PRs. Die Review-Kapazität ist nicht mitgewachsen. Jemand im Team wird leise überlastet. Dieses Signal gehört in den nächsten Status-Termin, ganz oben.
Trauen Sie der Selbstauskunft nicht. Die schärfste Einzelevidenz dazu liefert weiterhin METR, mit zwei Vorbehalten gleich vorweg. Das ursprüngliche Setup vom Juli 2025 testete Tooling, das den heutigen Coding-Agents um ein Jahr hinterherhinkt. Und ein Folgeversuch im Februar 2026 konnte das Studiendesign nicht halten, weil viele Entwickler echte Aufgaben nicht mehr ohne KI übernehmen wollten. Die methodische Lehre bleibt trotzdem stehen: Selbstauskunft ersetzt keine Liefermetrik.
In der ursprünglichen Studie bearbeiteten sechzehn erfahrene Open-Source-Entwickler mit im Schnitt fünfzig Stunden Cursor-Erfahrung 246 echte Aufgaben aus den eigenen reifen Repositorien, zufällig zugewiesen in eine „KI erlaubt"- und eine „KI nicht erlaubt"-Bedingung. Vorher schätzten die Teilnehmer 24 Prozent Tempogewinn, hinterher meldeten sie 20 Prozent. Gemessen wurden sie 19 Prozent langsamer.
Die aktuelle METR-Survey vom Mai 2026 befragt 349 Tech-Beschäftigte und findet selbstgemeldet einen 1,4- bis 2-fachen Value-Gain. Im selben Bericht qualifiziert METR den Wert als wahrscheinlich überschätzt: Bei Stichproben-Reviews extremer Claims fand das Team in mehreren Fällen Hinweise auf Übertreibung. Die Prozentwerte verschieben sich mit jedem Modellsprung. Die Skepsis gegenüber Selbstauskünften bleibt.
Für jeden KI-Rollout im Unternehmen folgt daraus: Die Evidenz an Tag 60 darf nicht „das Team sagt, es ist schneller" sein. Sie muss aus einer Liefermetrik bestehen, die das Team an Tag 1 ausgewählt hat und an Tag 60 nicht mehr umschreiben kann.
DORA-Metriken statt PR-Zähler. Der DORA-Report 2025 basiert auf knapp 5.000 Tech-Fachkräften und über hundert Stunden qualitativer Interviews. Er stellt einen positiven Zusammenhang zwischen KI-Adoption und Software-Delivery-Throughput fest, zugleich einen negativen zur Stability, mit höherer Change Failure Rate. DORA liefert keinen simplen Kausalbeweis für „KI macht Teams schneller". Der Report ist trotzdem nützlich, weil er die richtige Warnung setzt: Mehr Durchsatz ist kein Erfolg, wenn Change Failures oder Rework steigen. Die DORA-Autoren formulieren es so: KI repariert kein Team, sie verstärkt das, was schon da ist. Die Change Failure Rate steht im 60-Tage-Briefing deshalb gleichberechtigt neben dem Throughput.
Evidenz kennzeichnen, während sie entsteht. Pull Requests, an denen KI mitgearbeitet hat, bekommen ein Tag. Incidents mit KI-Anteil ebenfalls. Ohne diese Kennzeichnung sammeln Sie am Tag 60 Anekdoten. Das ist der unspektakuläre Teil dieser Phase, den niemand machen will, und genau darüber entscheidet sich, ob Tag 90 eine verteidigbare Entscheidung hat.
An Tag 60 fasst das Team die Evidenz auf einer Seite schriftlich zusammen. Wenn diese Seite schwer zu schreiben ist, ist die Evidenz nicht da.
Tage 61 bis 90 · Die Institutionalisierung
Die zentrale Frage der dritten Phase: Was lassen wir im Team, was wird Regel, was beerdigen wir?
An dieser Stelle bricht das übliche Silicon-Valley-Narrativ. Kapwing hat im April 2026 öffentlich gemacht, dass jede Person im Unternehmen mindestens einen produktiven, Codex-generierten Pull Request liefert. Hübsche Schlagzeile. Die Hintergründe: 25 Beschäftigte insgesamt, davon etwa zwölf in Engineering, ausgerollt in drei Phasen über fünf Monate ab Oktober 2025. Eine Engineering-Organisation mit 180 Leuten und einem fünfzehn Jahre alten Zahlungs-Modul kann dieses Playbook nicht kopieren, und sie sollte es nicht versuchen. Kapwing ist ein Gegenbeispiel, keine Blaupause.
Ausweiten, aber eng geführt. Das zweite Team durchläuft dieselbe Pilotphase wie das erste: gleiche Messung, gleiche Dauer, gleiche Disziplin. Kein paralleler Rollout auf drei Teams gleichzeitig. Das ist die zweite Versuchung, und sie scheitert aus demselben Grund wie der Lizenz-Reflex: Drei schlecht vergleichbare Pilots erzeugen Aktivität, aber selten klare Evidenz.
Regeln aufschreiben, statt sie mündlich weiterzureichen. Ein knappes internes Dokument, drei bis fünf Seiten. Es beantwortet vier Fragen: Welcher Agent darf welche Aufgaben übernehmen? Welche Review-Regeln gelten? Welche Datenklassifizierungen sind tabu? Welche Pfade verlangen benannte Reviewer? Der Pull-Request-Beitrag argumentiert für Risk Lanes: risikoarme Änderungen laufen durch automatische Gates, kritische Pfade bekommen benannte Reviewer und kleinere PR-Limits. An Tag 90 ist dieses Dokument verbindlich.
Die Nicht-jetzt-Liste. Das wichtigste Ergebnis eines 90-Tage-Rollouts kann eine Liste sein: Dinge, die das Team bewusst nicht automatisiert. Agentengesteuerte Merges in regulierten Modulen. Lang laufende autonome Tasks ohne menschliches Sign-off. Alles, was Zahlungsflüsse oder personenbezogene Kundendaten berührt. Wer in einem BaFin-regulierten Haus arbeitet, findet die Vorgaben für Coding Agents unter BaFin und MaRisk ohnehin schon im Pflichtenheft. Diese Liste ist ein einfacher Reifetest: Kann eine Engineering-Organisation öffentlich sagen, was sie noch nicht tut, ohne sich dafür zu entschuldigen?
An Tag 90 fällt die Entscheidung, für die der gesamte Plan gedacht war: skalieren, eingrenzen oder einstellen. Alle drei sind legitime Ergebnisse. Wer behauptet, es gäbe nur eines, hat in der Regel etwas zu verkaufen.
Was bleibt am Tag 90
Wer KI im Unternehmen einführen will, plant nicht primär einen Zeitplan, sondern eine Zwangsmechanik. Der 90-Tage-Plan erzwingt Evidenz vor der Skalierung und macht aus stillschweigendem Konsens schriftliche Regeln, bevor diese zu Stammeswissen werden. Vor allem zwingt er das Team, manchen Workflows ein „nicht jetzt" zu sagen, für die es noch nicht reif ist. Engineering Leads im Mai 2026 leiden selten an einem Mangel an Werkzeugen. Was fehlt, ist die Disziplin, ein kleines Experiment sauber zu Ende zu bringen, bevor das große scheitert.
Wenn Sie gerade entscheiden müssen, ob Sie Coding Agents skalieren, eingrenzen oder einstellen sollten, sollten wir reden.
Quellen
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Juli 2025)
- METR: Updates from a follow-on AI uplift study (Februar 2026)
- METR: Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity (Mai 2026)
- Google Cloud / DORA: Announcing the 2025 DORA Report on AI-assisted Software Development
- Bitkom: Durchbruch bei Künstlicher Intelligenz · Pressemitteilung
- Kapwing: How we achieved 100% adoption of AI coding agents
- §87 BetrVG: Gesetzestext bei gesetze-im-internet.de
