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 überzeugt ist, vermeide Widerstände, 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 empfiehlt in seiner Anleitung zum organisationsweiten Copilot-Rollout bis heute als Einstieg: „You can start by identifying a small number of teams that are interested in using Copilot." Das ist eine ziemlich präzise Beschreibung des Selbstauswahl-Fehlers. Wenn das Pilotteam aus Freiwilligen besteht, ist es schon von der Anlage her nicht repräsentativ. Sie messen in der Teilmenge, die ohnehin wollte, und rollen an die Teilmenge aus, die nicht gefragt hat.
Für agentische Werkzeuge sieht GitHub das inzwischen selbst anders. Die im September 2026 ergänzte Anleitung zur Team-Adoption von agentischem Copilot rät ausdrücklich: „Avoid selecting only enthusiasts. Include a representative mix of experience levels." Dazu verlangt sie stabile Liefermetriken als Baseline, festgehalten vor dem Start. Selbst der Anbieter hält die Stichprobe der Begeisterten für Agents also nicht mehr für aussagekräftig (Stand: Oktober 2026).
Eine Vorbemerkung zur Datenlage. Wie verbreitet KI-Werkzeuge und Coding Agents in der Entwicklung sind, ist inzwischen breit belegt. Dünn sind dagegen die Daten zur Wirkung auf Produktivität und Qualität, und was es an verlässlichen Zahlen gibt, stammt meist noch 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 aus jeweils anderen Gründen teuer.
Das Freiwilligen-Team aus dem Beispiel oben gewinnt, weil es politisch keinen Widerstand weckt. 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. Die Nutzung an sich ist dabei kaum noch die Hürde. DX meldet für das zweite Quartal 2026 eine KI-Nutzung von über 90 Prozent über die Branche hinweg und verschiebt die Frage von „nutzen wir KI?" zu „zahlt es sich aus?". DX ist hier kein neutraler Benchmark-Anbieter, sondern verkauft Messsoftware. Die Zahl ist eher Signal als belastbarer Marktwert. Unabhängige Daten von JetBrains zeigen dieselbe Richtung und zugleich die Lücke dahinter: Von Mai bis Juli 2026 nutzten 90 Prozent der befragten Entwickler mindestens wöchentlich einen Coding Agent bei der Arbeit, täglich aber nur 68 Prozent. Die Hürde liegt inzwischen woanders: bei der Gewohnheit und bei der messbaren Wirkung. Wer einmal pro Woche einen Agent anstößt, ist noch kein 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 es in Ihrer Organisation so nicht gibt.
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 kann sich keine Experimente leisten, weil die Folgen zu groß sind. Das Pilotteam baut etwas, das Kunden bemerken, wenn es kaputt geht, von dem aber nicht der Quartalsabschluss abhängt.
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 bei der ersten Hürde 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 aufschlussreich. Wer mittendrin 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 zur Interpretation, nicht zur 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." Hängen bleibt 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. Damit wissen Sie, 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. DORA umfasst fünf Liefermetriken auf Anwendungs- oder Service-Ebene, die die liefernden Teams verantworten und interpretieren: drei zum Durchsatz (Deployment-Frequenz, Vorlaufzeit für Änderungen, Wiederherstellungszeit nach fehlgeschlagenen Deployments) und zwei zur Instabilität (Change Failure Rate, Deployment-Rework-Rate). Leitindikatoren wie die PR-Review-Dauer reagieren schneller und ergänzen sie. Erhoben pro Anwendung oder Service, nicht pro Entwickler. 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, damals 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 Compliance-Reviewer lesen können, aus denen Ingenieure aber nichts lernen.
Regulierte Teams steigen später ein. 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.
Alle sieben Kriterien haben Sie selten
Wer ehrlich inventarisiert, kommt am Ende auf fünf der sieben Kriterien, nicht sieben. Das ist weniger schlimm, als es aussieht. Es ist das normale Ergebnis ehrlicher Aufstellung in einer Organisation, die nicht zum Zweck dieses Pilotprojekts gegründet wurde.
Auf welche zwei dürfen Sie verzichten? Auf fast alle, außer zwei.
Stabile Zusammensetzung (Kriterium 3) und messbare Baseline (Kriterium 6) sind nicht verhandelbar. 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." Damit überzeugen Sie 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 darauf verzichtet 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, keine Auszeichnung für die Engagiertesten. Diese Sicht macht die Auswahl strenger, dafür belastbarer.
Auf welche zwei Kriterien Sie in Ihrer konkreten Aufstellung verzichten, 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 Docs: Driving GitHub Copilot adoption in your company
- GitHub Docs: Driving team adoption of agentic GitHub Copilot (September 2026)
- 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: State of AI Impact in Engineering, Q2 2026
- Laura Tacho (DX): How to introduce AI impact metrics into an engineering organization (August 2025)
- JetBrains Research: AI Coding Agents: Adoption Trends (August 2026)
