Stellen Sie sich vor, Sie wollen wissen, wie Ihre Belegschaft auf Süßigkeiten reagiert, und stellen drei Wochen lang eine Schale in den Pausenraum. Am Ende haben Sie eine sehr genaue Stichprobe von Naschkatzen, und kein einziges belastbares Datum über den Rest.
Genauso werden in den meisten Unternehmen Pilotteams für Coding Agents ausgewählt. Das Team, das von sich aus nach Cursor oder Claude Code fragt, bekommt das Pilotprojekt. Drei Monate später meldet es einen Erfolg, das Management beschließt den Rollout, und in Monat sechs steht die Bilanz auf dem Kopf. Das Pilotprojekt war kein Schaufenster. Es war ein Messinstrument. Und kalibriert wurde es an der falschen Stichprobe.
Wer den breiteren Rahmen sucht, findet ihn im Leitfaden zu Coding-Agents-Rollouts. Was hier folgt, ist der konkrete Schritt davor: Wie man das Pilotteam zusammenstellt, das im Rollout etwas wert ist.
Die Optimierung, die niemand benennt
Bei der Pilot-Team-Auswahl konkurrieren zwei Optimierungen, und sie ziehen in unterschiedliche Richtungen. Die erste optimiert auf maximale Erfolgswahrscheinlichkeit: nimm das Team, das schon halb verkauft ist, halte die Reibung niedrig, produziere ein vorzeigbares Ergebnis. Die zweite optimiert auf Aussagekraft: nimm das Team, dessen Ergebnis etwas darüber sagt, wie der Rollout im Rest der Organisation laufen wird.
Wer den Unterschied nicht ausspricht, optimiert reflexhaft auf die erste.
GitHub schreibt in der offiziellen Rollout-Dokumentation zu Copilot wörtlich: „Identify a small number of teams that are interested in using Copilot." Das ist der vorgegebene Standard, und es ist gleichzeitig eine ziemlich präzise Beschreibung des Selbstauswahl-Fehlers. Wenn das Pilotteam aus Freiwilligen besteht, ist es per Konstruktion nicht repräsentativ. Sie messen in der Teilmenge, die ohnehin wollte, und rollen an die Teilmenge aus, die nicht gefragt hat.
Eine Vorbemerkung zur Datenlage. Belastbare Studien zu echten Coding Agents sind noch dünn; verlässliche Zahlen kommen meist aus Copilot- und Assistant-Rollouts. Die Selbstauswahl-Verzerrung, um die es hier geht, ist in beiden Fällen identisch. Bei Agents wird sie nur teurer, weil sie tiefer in Workflow, Review und Verantwortung eingreifen.
Everett Rogers hat das Vokabular dazu geliefert: Innovators und Early Adopters probieren ein neues Werkzeug aus eigenem Antrieb, die Early Majority und Late Majority warten auf Referenzen und stabile Muster. Geoffrey Moore hat das später für Tech-Märkte zugespitzt und einen „Chasm" zwischen beiden postuliert; Rogers selbst hat in der fünften Auflage seines Buches widersprochen, Innovationsbereitschaft sei ein Kontinuum, kein Sprung. Der Einwand ändert nichts am praktischen Befund: Wer in der Population der Begeisterten misst und an die Pragmatiker ausrollt, hat das Falsche kalibriert.
Die drei beliebtesten Defaults sind teuer aus jeweils unterschiedlichen Gründen.
Das Freiwilligen-Team aus dem Beispiel oben gewinnt, weil es politisch keine Reibung verursacht. Das Legacy-Sanierungsteam klingt nach einer fairen Bewährungsprobe für den Agent: „Wir geben den Agent dem Team mit dem ältesten Monolithen, dann sehen wir schon, was er kann." Was Sie sehen, ist hauptsächlich, wo der Agent verliert, hochgerechnet aus einer verzerrten Extremstichprobe. Und das Strategische-A-Team bekommt das Pilotprojekt, weil das Vorhaben wichtig ist und „wenn schon, dann mit den besten Leuten". Ihre besten Leute kompensieren schlechte Rahmenbedingungen oft so gut, dass das Ergebnis mehr über sie sagt als über das Tool.
Deshalb zählt nicht, ob das Pilotprojekt gut aussieht. Entscheidend ist, ob es zuverlässig misst. Dafür gibt es sieben konkrete Kriterien.
Kriterium 1: Repräsentativ, nicht begeistert
Das Pilotteam sieht aus wie das mediane Team in Ihrer Engineering-Organisation. Gleicher Stack, ähnliche Seniorität, vergleichbare Domänenkomplexität. Wenn drei Viertel Ihrer Teams an einem Java-Monolithen mit fünfzehn Jahren Geschichte arbeiten, sitzt das Pilotteam dort, nicht im neu gestarteten TypeScript-Service.
Freiwillige sind selten repräsentativ genug für eine Rollout-Prognose. Sie haben sich gemeldet, weil sie sich vom Standardprofil unterscheiden, meist in Risikobereitschaft, Neugier oder bisheriger Tool-Nutzung. Genau diese Differenz müssten Sie aus den Ergebnissen herausrechnen können, was kaum gelingt. DX berichtet aus seinen instrumentierten Kunden-Deployments, dass die aktive KI-Nutzung selbst in führenden Organisationen bei rund 60 Prozent ein Plateau erreicht. DX ist hier kein neutraler Benchmark-Anbieter, sondern verkauft Messsoftware; die Zahl ist eher Signal als belastbarer Marktwert, und was als „aktive Nutzung" zählt, präzisiert DX öffentlich nicht. Die Richtung passt zu unabhängigen Daten von JetBrains, die für Copilot eine Adoption am Arbeitsplatz von etwa 29 Prozent finden, mit stagnierender Tendenz. Die übrigen 40 bis 70 Prozent sind jedenfalls keine Selbstläufer. Gerade diese Gruppe ist in einem Pilotprojekt aus Freiwilligen kaum vertreten.
Folge: Ein Pilotprojekt mit einem nicht-repräsentativen Team misst eine Population, die Sie nicht besitzen.
Kriterium 2: Mittlere Kritikalität
Nicht das Team, das die interne CI-Pipeline wartet. Es wird sich keine echte Mühe geben, weil die Folgen klein bleiben. Auch nicht das Team, das die Zahlungsabwicklung verantwortet. Es darf sich keine Mühe leisten, weil die Folgen zu groß sind. Das Pilotteam baut etwas, das Kunden bemerken, wenn es kaputt geht, das aber nicht den Quartalsabschluss trägt.
Bei niedriger Kritikalität fehlt der Druck, und ohne Druck nutzt niemand ein Werkzeug, mit dem er sich anstrengen müsste. Bei hoher Kritikalität fehlt der Spielraum, und ohne Spielraum schalten Entwickler beim ersten Reibungspunkt auf den alten Workflow zurück. Sie messen dann nicht, was der Agent leistet, sondern was die Risikoaversion erlaubt.
Folge: Zu wenig Risiko erzeugt keinen Druck. Zu viel Risiko erlaubt kein Scheitern.
Kriterium 3: Stabile Zusammensetzung über sechs Monate
Keine geplante Reorganisation. Kein Hiring-Sprint mit drei neuen Köpfen in Woche vier. Keine zwei Kündigungen, die schon bekannt sind. Messung braucht eine stabile Baseline, und eine Baseline kann nicht gleichzeitig stabil sein und sich personell ändern.
Die GitHub-eigene RCT mit Accenture aus dem Mai 2024 illustriert zumindest die Grundregel: Wer Treatment- und Kontrollgruppe vergleichen will, muss verhindern, dass sich während der Messung die Zusammensetzung verschiebt. Die Studie ist ein vom Anbieter durchgeführtes Experiment in einem einzigen Kundenkontext, mit allen Vorbehalten, die das mit sich bringt. Das Studiendesign selbst bleibt instruktiv. Wer in der Mitte das Personal austauscht, mischt zwei Effekte und kann keinen davon zuverlässig benennen.
Folge: Personalwechsel während des Pilots vermischen Team-Effekt und Tool-Effekt. Die Auswertung wird Interpretation, nicht Messung.
Kriterium 4: Ein anerkannter Senior, der nicht die Champion-Rolle übernimmt
Das Team braucht eine erfahrene Stimme, deren Urteil im Rest der Organisation Gewicht hat. Sie ist ausdrücklich nicht der interne KI-Evangelist. Die Aussagen, die Skeptiker bewegen, kommen nicht von Leuten, deren Slack-Avatar das Cursor-Logo trägt.
Warum nicht? Weil Skeptiker den Evangelisten schon eingerechnet haben. „Klar mag der das. Der mag jedes neue Tool." Was haftet, ist die Aussage einer Person, die vor dem Pilotprojekt eher zurückhaltend war und am Ende etwas Konkretes sagen kann, in beide Richtungen. Dafür muss diese Person vorher bekannt sein, sonst lässt sich die Veränderung nicht zuordnen.
Wichtig: Diese Person beobachtet das Pilotprojekt nicht vom Rand. Sie arbeitet selbst mit dem Coding Agent, sonst bleibt ihr späteres Urteil Reputation, nicht Erfahrung.
Folge: Ohne diese Person ist das Pilot-Ergebnis für den Rest der Organisation nicht übertragbar.
Kriterium 5: Eine eingeplante Skeptikerin
Bewusst eine Person mit Bedenken aufs Team holen. Keine Zynikerin (Zynismus liefert keine brauchbaren Einwände), sondern jemanden mit präzisen Sorgen und der Disziplin, sie auszuformulieren.
Diese Heuristik ist weniger Forschungsergebnis als robuste Praxisregel aus Change-Projekten: Ein Pilotteam, das nur aus Begeisterten besteht, produziert eine Liste von Erfolgen. Was beim Rollout gebraucht wird, ist auch eine Liste von Einwänden, gesammelt von jemandem, der nicht erst überzeugt werden musste, sie aufzuschreiben.
Zwei mögliche Ergebnisse, und beide sind nützlich. Im ersten Fall überzeugt das Pilotprojekt die Skeptikerin. Dann haben Sie Ihre glaubwürdigste interne Fürsprecherin, und zwar genau in der Population, die der Rollout am dringendsten braucht. Im zweiten Fall hält sich die Skepsis, aber sie ist nun konkret und auf spezifische Punkte bezogen. Das ist eine Karte dessen, was vor dem Rollout zu reparieren ist.
Folge: Ein Pilotprojekt ohne interne Kritik liefert Ergebnisse, die bei der ersten ernsthaften Frage im Rollout auseinanderfallen.
Kriterium 6: Messbare Baseline vor dem ersten Prompt
Das Team hat saubere DORA- und Developer-Experience-Kennzahlen aus den drei Monaten vor dem Pilotprojekt. Cycle Time. Change Failure Rate. PR-Review-Dauer. Pro Person, nicht aggregiert. Wer auf die Frage „wie waren die Zahlen vorher?" mit „die haben wir geschätzt" antwortet, hat kein Pilotprojekt. Er hat eine Erzählung.
Laura Tacho, CTO bei DX, hat das in einem Beitrag auf den Punkt gebracht: Wahrnehmungsdaten lassen sich nicht rückwirkend erheben. Sobald die KI im Workflow ist, ist die Erinnerung der Entwicklerin an „wie es vorher war" schon verzerrt. Wer den Vorher-Nachher-Vergleich erst nach dem Pilotprojekt konstruiert, hat ihn nie gehabt.
Genau hier scheitern die meisten Pilotprojekte in Unternehmen, leise und ohne dass es jemand merkt. Mehr zur konkreten Mess-Mechanik steht im Beitrag zum Pull-Request-Engpass. Aber die Logik ist banal: kein Vorher, kein Nachher. Kein Nachher, kein belastbares Ergebnis.
Folge: Ohne Baseline ist das Pilotprojekt ein Experiment ohne Instrumente.
Kriterium 7: Keine regulatorischen Sonderbedingungen
Nicht das BaFin-prüfungspflichtige Team. Nicht das Team mit aktiver DSGVO-Sonderprüfung. Nicht das, das gerade durch eine Zertifizierung für sicherheitskritische Software muss.
Pilotprojekte brauchen Freiheitsgrade. Die Möglichkeit, mit Prompts zu experimentieren, ein Tool drei Tage zu probieren und am vierten zu verwerfen, am Donnerstag etwas auszuprobieren, das am Freitag wieder weg ist. Regulierte Teams haben diesen Spielraum nicht. Sie können sich ihn auch nicht nehmen, ohne den Compliance-Prozess zu untergraben, der ihre eigentliche Arbeit ist. Wer trotzdem in einem regulierten Team pilotiert, bekommt am Ende Ergebnisse, die für Compliance-Reviewer lesbar sind, aber für Ingenieure nicht lernbar.
Regulierte Teams adoptieren später. Wenn die Muster bekannt sind, das Tooling ausgereift, die Audit-Spuren sauber dokumentierbar. Den Weg dorthin gehen sie nicht über ein Pilotprojekt, sondern über einen kontrollierten Nachzug.
Folge: Regulatorische Pilotteams messen Compliance-Verträglichkeit, nicht Tool-Wirkung.
Sechs Kriterien haben Sie selten
Wer ehrlich inventarisiert, kommt am Ende auf fünf der sieben Kriterien, nicht sieben. Das ist nicht das Problem, das es zu sein scheint. Es ist das normale Ergebnis ehrlicher Aufstellung in einer Organisation, die nicht zum Zweck dieses Pilotprojekts gegründet wurde.
Welche zwei dürfen Sie tauschen? Fast alle, außer zwei.
Stabile Zusammensetzung (Kriterium 3) und messbare Baseline (Kriterium 6) sind nicht handelbar. Ohne sie haben Sie kein Pilotprojekt. Sie haben ein Experiment ohne Instrumente, und was am Ende dabei herauskommt, ist eine Anekdote: „Das Team hat den Agent ausprobiert, und es war ganz okay." Das verkauft sich an niemanden, der den Rollout finanzieren soll.
Die anderen fünf sind echte Kompromisse mit echten Konsequenzen. Fehlt der anerkannte Senior (Kriterium 4), wird der Rollout schwerer zu verkaufen sein. Fehlt die Skeptikerin (Kriterium 5), entwertet die erste kritische Frage im Rollout das Pilotprojekt rückwirkend. Beides ist reparierbar, wenn Sie wissen, dass Sie es eingetauscht haben. Der Schaden entsteht da, wo der Kompromiss nicht ausgesprochen ist und das Team trotzdem so behandelt wird, als wäre es repräsentativ.
Eine pragmatische Vorauswahl reicht in den meisten Fällen. Erst die harten Ausschlüsse: keine stabile Zusammensetzung über sechs Monate, keine messbare Baseline, regulatorische Sonderlage. Was übrig bleibt, ordnen Sie nach Aussagekraft: Repräsentativität, mittlere Kritikalität, glaubwürdiger Senior, eingeplante Skepsis.
Zur Illustration drei Teams. Team A ist repräsentativ, stabil besetzt, hat eine Baseline, mittlere Kritikalität. Team B ist begeistert und technisch stark, aber ohne Baseline. Team C ist reguliert und politisch wichtig, mit wenig Freiheitsgraden. Team A gewinnt, auch wenn Team B mehr Energie mitbringt.
Begeisterung kompensiert keine fehlende Messbarkeit.
Ein Pilot-Team ist Teil des Messdesigns, nicht eine Anerkennung für die Engagiertesten. Diese Sicht macht die Auswahl strenger, dafür belastbarer.
Welche zwei Kriterien Sie in Ihrer konkreten Aufstellung tauschen, ist kein Strategieprozess. Es ist eine kurze, harte Sortierung. Bringen Sie drei Kandidatenteams mit, wenn Sie eine reale Liste durchgehen wollen, und sprechen Sie mich an. Nach dreißig Minuten ist meist klar, welches Team misst und welches nur gut aussieht.
Quellen
- GitHub: Rolling out GitHub Copilot at scale
- GitHub Engineering: Quantifying GitHub Copilot's Impact in the Enterprise with Accenture (Mai 2024)
- Everett Rogers: Diffusion of Innovations, 5. Auflage, Free Press 2003
- Geoffrey Moore: Crossing the Chasm, HarperBusiness 1991, 3. Auflage 2014
- DX: Measuring AI Code Assistants and Agents
- Laura Tacho (DX): How to introduce AI impact metrics into an engineering organization (August 2025)
- JetBrains Research: Which AI Coding Tools Do Developers Actually Use at Work (April 2026)
