Das Dashboard des Pilotprojekts sieht gut aus. Akzeptanzrate ordentlich, Durchlaufzeit runter, das Team will das Werkzeug behalten. Alle nicken. Dann fragt jemand aus der Geschäftsleitung, wann die übrigen 200 Entwickler Zugang bekommen. Mit diesem Satz kippt das Gespräch. Aus einem Werkzeug wird ein Eingriff ins Produktionssystem.
„Wann skalieren wir?“ kommt zu früh. Erst müssen Sie wissen: Was hat der Pilot überhaupt gemessen? Wer den Unterschied nicht sieht, behandelt eine Systementscheidung wie einen Kalendereintrag. Das rächt sich, nur nicht sofort.
Kurz gefasst: Ein erfolgreicher Pilot ist kein Belastungstest. Das Team hat sich meist selbst gemeldet, die Aufgaben sind handverlesen, und irgendjemand räumt jeden Stolperstein sofort weg. Ob starke technische Grundlagen beim Rollout schützen, ist offen: DORA (Befragung) bejaht es, Faros (Telemetrie) misst auch bei reifen Organisationen längere Reviews und mehr Incidents, sobald viele KI-generierte Änderungen ankommen. Die Antwort ist kein Stopp, sondern ein gestufter Rollout: Telemetrie vor dem Volumen, Wellen von 20 bis 30 Entwicklern, Risikopfade (getrennte Spuren nach Risiko) und ein Änderungsbudget von drei Dateien und 80 Zeilen pro Pull Request.
Der Leitfaden zum Skalieren von Coding Agents im Unternehmen behandelt den gesamten Weg. Hier geht es um die schmale Stelle davor: den Sprung vom Pilotteam in die Organisation.
Ihr Pilot war ein Schönwetterversuch
Pilotteams sind keine Stichprobe, sie sind eine Auslese. Im Pilotprojekt sitzen selten die Skeptiker aus dem Legacy-Team. Dort sitzen Freiwillige, Early Adopters und Leute, die den internen Champion ohnehin schon kennen (welche Teams in den Pilot gehören, ist eine eigene Diskussion). Das Team wurde aktiv betreut, der Champion saß im Slack-Kanal und räumte Stolperstellen noch am selben Tag aus dem Weg. Die Aufgaben waren handverlesen: ein Greenfield-Feature hier, ein gut dokumentierter Service dort. Dazu kamen Senior-Entwickler mit Luft im Kalender. Im echten Rollout ist genau diese Luft zuerst weg.
Außerhalb des Pilotprojekts ist keine dieser Bedingungen garantiert.
Der Pilot misst, was Coding Agents unter Idealbedingungen leisten. Er misst nicht den Donnerstag um 16:40 Uhr, wenn ein Agent in einem fünfzehn Jahre alten Monolithen eine Änderung vorschlägt und der einzige Mensch mit Kontext gerade im Zug sitzt. Genau dort findet aber der Rollout statt.
Der unbequeme Teil: In vielen Unternehmen läuft dieser Rollout längst. Die Telemetrie-Auswertung 2026 von Faros, Herstellerdaten aus überwachten Entwicklungsumgebungen, zeigt: Die Akzeptanzquote von KI-generiertem Code stieg von 20 auf 60 Prozent, und bei 80 Prozent der Teams nutzt inzwischen mehr als die Hälfte der Entwickler die Werkzeuge wöchentlich. Die genaue Zahl ist weniger wichtig als der Kontrollverlust dahinter. Das ist größtenteils ohne organisatorische Freigabe passiert. Faros formuliert es zugespitzt: Die KI assistiert nicht mehr, sie führt. Während der Rollout noch auf der Tagesordnung steht, arbeiten Teile der Organisation schon anders. Nur ohne Messung. Und ohne Sie.
Zwei Instrumente, zwei Bilder
Der DORA-Report 2025 gehört zu den brauchbarsten Quellen, die wir derzeit zu KI in der Softwareentwicklung haben: eine Befragung von knapp 5.000 Fachleuten aus der Softwareentwicklung, ergänzt um mehr als 100 Stunden qualitativer Interviews. Der zentrale Befund: KI wirkt als Verstärker. Wo die Grundlagen stimmen (Plattformqualität, kleine Batches, Disziplin in der Versionskontrolle, klarer Nutzerfokus), verstärkt KI den Nutzen und puffert die Nebenwirkungen ab. Auf dem Papier folgt daraus: erst die Fundamente festigen, dann skalieren. Klingt vernünftig. Ist es auch.
Dann veröffentlichte Faros Anfang 2026 Acceleration Whiplash. Hier spricht keine Umfrage, hier spricht Telemetrie: zwei Jahre Daten von 22.000 Entwicklern in mehr als 4.000 Teams, erhoben in den Umgebungen der eigenen Kunden, keine Zufallsstichprobe. Der unbequeme Befund: Leistungsstarke Organisationen mit reifen DevOps-Praktiken und starken DORA-Werten zeigen dieselbe nachgelagerte Verschlechterung wie alle anderen, sobald viele KI-generierte Änderungen in Review und Betrieb landen. Mediane Zeit im Review: plus 441,5 Prozent. Incidents pro gemergtem PR: plus 242,7 Prozent. Bugs pro Entwickler: plus 54 Prozent.
Auf den ersten Blick beißen sich die Befunde.
DORA misst, wie Teams ihre Praxis wahrnehmen und berichten. Faros misst, was nachgelagert tatsächlich durch die Pipeline geht. Beide können recht haben. Sie schauen nur auf verschiedene Stellen derselben Fabrik. Eine Organisation kann ihre Versionskontrolle für diszipliniert halten, ihre Batches für klein, ihre Plattform für solide, und trotzdem in der Review-Schlange ertrinken. Die Selbstauskunft und der Materialfluss erzählen dann zwei verschiedene Geschichten über dasselbe Unternehmen.
Vor dem Rollout zählt deshalb weniger die Selbstbeschreibung als der Blick auf den Fluss: Haben Sie die Telemetrie, um zu sehen, ob Ihre Reviews gerade verstopfen, während die Commit-Zahlen steigen? Review-Zeiten, Incidents pro Merge, Defektdichte, sauber erhoben und über mehrere Quartale vergleichbar.
Bei den meisten Organisationen ist die ehrliche Antwort: nein.
Was die Daten zum Rollout hergeben
Die bislang am besten dokumentierte groß angelegte Einführung kommt von Booking.com, erfasst mit der Developer-Intelligence-Plattform DX (Fallstudie): mehr als 3.500 Entwickler, Verbreitung von unter 10 Prozent auf rund 70 Prozent, eine um 16 Prozent höhere PR-Merge-Rate bei täglich aktiven Nutzern eines KI-Code-Assistenten, rund 150.000 eingesparte Entwicklerstunden im ersten Jahr. DX misst hier die Wirkung seines eigenen Produkts; das ist kein neutraler Benchmark. Interessant ist deshalb weniger die große Zahl als die Bremse: Booking.com hat nicht alle auf einmal freigeschaltet. Stattdessen Segmente, viele Monate, Telemetrie-Auswertung bei jedem Schritt und strukturierte Schulung und Begleitung, konkret Workshops, Sprechstunden und gezielte Ansprache der Teams, die noch zurücklagen.
Eine Umfrage unter 650 Technologieverantwortlichen in großen Unternehmen vom März 2026 (Digital Applied) zeigt dasselbe Muster: viele Piloten, wenig Fläche. 78 Prozent berichten von laufenden Pilotprojekten mit KI-Agenten, aber nur 14 Prozent erreichen den flächendeckenden Produktivbetrieb. Die Zahl betrifft KI-Agenten insgesamt, nicht nur Coding Agents.
Für Deutschland liefert Bitkom zwei getrennte Befunde. Die Befragung „Digitalisierung der Wirtschaft“ vom März 2026 (604 Unternehmen, repräsentativ): 41 Prozent der deutschen Unternehmen ab 20 Beschäftigten setzen KI aktiv ein, nach 17 Prozent im Vorjahr; 33 Prozent der KI-nutzenden Unternehmen berichten von deutlich höheren Kosten als erwartet. Ein separater Bitkom-Studienbericht zu KI mit Erhebungsdaten aus dem Jahr 2025 nennt 53 Prozent, die fehlendes technisches Fachwissen als Hürde sehen, und 43 Prozent, die keine KI-Weiterbildung anbieten. Die praktische Folgerung steht in keinem der Berichte, aber sie ist für den Rollout entscheidend: Wer Coding Agents einführen will, zahlt den größten Teil der Rechnung nicht für Lizenzen, sondern für Schulung, Begleitung und Review-Kapazität. Rechnen Sie damit.
Die drei Fehler, die den Rollout kippen
Der erste Fehler ist der Sprung von 10 auf 200. Wer das in einem Quartal macht, überspringt genau die Wochen, in denen ein Unternehmen lernt, was unter Last bricht: Telemetrie, Review-Konventionen, Eskalationswege. Booking.com zeigt das umgekehrte Muster, Segment für Segment, mit Messung dazwischen. Die Testfrage lautet: „Haben wir heute die Telemetrie, um einen Qualitätsabfall innerhalb von 48 Stunden zu erkennen?“ Lautet die Antwort „nein“, ist der Rollout nicht reif.
Der zweite Fehler ist die Annahme, dass gute Teams sich selbst schützen. Hier entscheidet sich, ob bei Ihnen eher DORA oder Faros recht bekommt. Selbst wenn DORAs Verstärker-These stimmt, gilt sie nur in Organisationen, die die Grundlagen tatsächlich haben, die DORA benennt: reife CI/CD-Pipelines, Disziplin bei kleinen Batches, tragfähige Qualitätsplattformen. Das Pilotteam hatte diese Voraussetzungen, sonst wäre der Pilot nicht erfolgreich gewesen. Daraus zu schließen, die ganze Organisation habe sie auch, ist der häufigste Fehlschluss bei dieser Entscheidung. Ob Ihre Organisation zum DORA-Beispiel oder zur Faros-Warnung wird, sehen Sie nicht in einer Studie. Sie sehen es in Ihren eigenen Pull Requests.
Der dritte Fehler macht keinen Lärm: Im Review entsteht eine Lücke. Im Pilot hielt oft ein eingespieltes Paar die Qualität: zwei Leute, die denselben Code kannten und wussten, wo die heiklen Stellen liegen. Dieses Modell überlebt keine 200 Entwickler, die agentengestützte Pull Requests einreichen; der bereits beschriebene Engpass im Pull Request wird im Rollout zur dominanten Größe. Was dagegen hilft, habe ich in The Magic Words That Make AI Code Better dokumentiert: ein Änderungsbudget von höchstens drei Dateien und etwa 80 geänderten Zeilen. Im Pilot war das ein Tipp für gute Prompts. Im Rollout wird daraus eine verbindliche Vorgabe.
Nicht per Knopfdruck: vier Stufen
Stufe 0: Erst messen, dann ausweiten
Bevor das erste Team außerhalb des Pilotprojekts eine Lizenz bekommt, müssen vier Kennzahlen verfügbar sein: KI-gestützte Commits, sauber gekennzeichnet. Change Failure Rate, also der Anteil fehlgeschlagener Änderungen, pro Team. PR-Review-Zeit im Wochentrend. Incident-zu-PR-Verhältnis mit Ausgangswert. Können Sie diese vier Kennzahlen heute nicht auswerten, sind Sie nicht bereit, und kein noch so gutes Pilot-Ergebnis ändert daran etwas. Welche Metriken sich für den Rollout eignen, habe ich an anderer Stelle ausführlich aufgeschrieben.
Stufe 1: Welle für Welle statt alles auf einmal
Wer KI-Tools im Entwicklerteam skalieren will, öffnet den Zugang in Wellen von 20 bis 30 Entwicklern. Zwischen zwei Wellen liegen vier bis sechs Wochen. Jede Welle liefert eine Auswertung, bevor die nächste startet. Der Kreis bleibt klein, bis die Messwerte stabil bleiben. Booking.com hat seine Einführung nach Nutzersegmenten gestaffelt; das ist dieselbe Idee, angewendet auf eine Engineering-Organisation.
Stufe 2: Risikopfade statt Einheitsprozess
Änderungen mit niedrigem Risiko laufen schnell durch automatisierte Prüfungen. Kritische Pfade (Authentifizierung, Zahlung, regulierte Systeme, alles BaFin-Relevante) behalten benannte Reviewer und verpflichtende Freigaben. Der Risikopfad wird vor Arbeitsbeginn festgelegt, nicht erst im Pull Request. Wer das dem einzelnen Pull Request überlässt, hat keinen geregelten Prozess, sondern Zufall.
Stufe 3: Review-Kapazität wächst mit, statt nachgezogen zu werden
Wenn Agenten mehr Code in die Pipeline bringen, muss jemand den Rückstau verhindern. Benannte Reviewer für kritische Pfade, automatisierte Prüfungen für den Rest, PR-Größe mechanisch durchgesetzt: drei Dateien, 80 Zeilen als Standardbudget. Größere Änderungen brauchen eine explizite Begründung, bevor sie in die Review-Warteschlange dürfen.
Kein Terminproblem
Der Rollout ist kein Terminproblem. Er verändert Ihr Produktionssystem. Viele Organisationen planen ihn wie einen Kalendereintrag und zahlen später den Preis eines Systemumbaus. Teuer wird nicht der Pilot. Teuer wird die Fläche. Wenn Sie prüfen wollen, ob Ihre Organisation die vier Stufen heute schafft, schauen wir auf vier Dinge: Telemetrie, Review-Fluss, Risikopfade und PR-Größe.
Quellen
- DORA: State of AI-assisted Software Development 2025
- Faros AI: Acceleration Whiplash · Takeaways
- DX: Booking.com uses DX to measure AI's impact on developer productivity
- Digital Applied: AI Agent Scaling Gap, März 2026
- Bitkom: Digitalisierung der Wirtschaft, März 2026
- Bitkom: Studienbericht Künstliche Intelligenz in Deutschland
