Vom Coding-Agent-Wildwuchs zum messbaren Team-Standard

Als eine einzige Produktivitätszahl für die ganze Organisation nicht. Ich lege vorab zwei bis drei vergleichbare Anwendungsfälle fest und ziehe die Baseline aus Ihren eigenen Daten. Verglichen werden danach Median und Bandbreite bei Time-to-Merge, Review- und Rework-Zyklen und escaped defects, neutrale und negative Befunde inklusive. Tokens, Zeilen Code und Nutzungsquoten sind allenfalls Frühindikatoren, als Erfolgsbeweis oder Leistungsziel taugen sie nicht. Ist die Stichprobe klein, weise ich das Ergebnis als Richtung und Entscheidungsgrundlage aus und nicht als Kausalnachweis.

Beides, und in dieser Reihenfolge. Der Kern ist eine dreitägige KI-Schulung für bis zu acht Entwickler an Ihrem eigenen Code, inhouse und vor Ort. Davor liegt das Assessment, das Engpass, Anwendungsfälle und Baseline bestimmt, danach 30 Tage Transfer und der Wirkungsnachweis. Ohne diesen Rahmen bliebe die Schulung ein Termin im Kalender, mit ihm wird daraus eine Arbeitsweise, die Sie belegen können.

Ein Seminar ist schneller gebucht, und für eine Handvoll Interessierter reicht es auch. Bei 50 oder mehr Entwicklern entscheidet aber nicht der Kurs darüber, was hängen bleibt, sondern was in den 30 Tagen danach passiert: ohne Baseline fehlt der Vergleich, ohne Transfer setzt sich der alte Arbeitsstil wieder durch, und ohne eigene Zahlen bleibt Ihre Rollout-Entscheidung eine Vermutung. Deshalb liegen die drei Tage hier zwischen einem Assessment und einem Wirkungsnachweis. Die Schulung wird dadurch nicht kleiner, sie ist nur nicht mehr das ganze Angebot.

Grundlagen finden Ihre Entwickler online, dafür brauchen Sie mich nicht. Hier buchen Sie den Zuschnitt auf Ihren Stack, Ihre Aufgaben und Ihre Prüfprozesse. Das Assessment bestimmt Reifegrad, Engpass und die Anwendungsfälle, die sich lohnen. Im Enablement arbeitet die Gruppe an echten Tickets und entwickelt daraus gemeinsame Regeln für Kontext, Review, Test und Governance. Fortgeschrittene Teams fangen dabei nicht bei null an.

Ja, gearbeitet wird mit dem Agenten, der bei Ihnen freigegeben ist: Claude Code, Codex, GitHub Copilot, Cursor oder ein vergleichbares Werkzeug für echte Codebases. Die drei Tage laufen an einer bestehenden Codebase mit Ihren Tests, Ihrem Review und Ihren Freigaben, reine Prototyping-Werkzeuge sind deshalb nicht Teil davon. Welcher Agent in den drei Tagen läuft und welche MCP-Server dazugehören, klärt das Assessment vorab mit Ihrem Team. Die Arbeitsweise selbst, also Aufgabenzuschnitt, Kontextaufbau, Code Review und Prüfentscheidung, funktioniert mit jedem Agenten dieser Klasse.

Weil der kleinere Teil davon Schulung ist. Von den sechs Wochen sind drei Tage Präsenz, der Rest läuft an Ihren echten Tickets. Am dritten Tag arbeitet die Gruppe bereits an Aufgaben aus Ihrem Stack, danach kommen zwei Sprechstunden, in denen Ihre Leute mit einer konkreten Session hereinkommen und wir am realen Fall entscheiden, was durchgeht und was nicht. Die Kohorte bleibt bei maximal acht, damit sich niemand in der Gruppe verstecken kann. Und Ihre Führungskräfte haben ihren eigenen halben Tag, sie sitzen nicht in der Kohorte: Wo zu viel Hierarchie im Raum ist, redet der Rest nicht mehr.

Der Review-Bottleneck ist der wahrscheinlichste Ort, an dem das schiefgeht, und Review-Fatigue macht ihn schlimmer: Wer zehn Pull Requests am Tag prüft, liest den zehnten anders als den ersten. Deshalb zählt hier nicht die Menge erzeugter Änderungen, sondern der Weg vom Ticket bis zur Freigabe. Review, Test und Prüfentscheidung laufen im Enablement mit, Ihre Qualitäts-, Security- und Freigabe-Gates bleiben dabei aktiv. Am dritten Tag arbeitet die Gruppe an echten Tickets aus Ihrem Stack und begründet ihre Prüfentscheidung. Ein Anwendungsfall gilt nur dann als Erfolg, wenn Time-to-Merge und Rework-Zyklen besser werden, ohne dass mehr Fehler in die Produktion durchgehen. Wandert die Last nur nach hinten, lautet die Empfehlung anpassen oder stoppen.

Oft ja. Coding Agents verändern ein Arbeitssystem und nicht nur den Schritt, in dem Code entsteht. Deshalb schaut das Assessment auch auf Requirements, Aufgabenzuschnitt, Kontext, Review, Test, Release und Governance. Das Enablement setzt nur dort an, wo eine gemeinsame Team-Praxis wirklich der Hebel ist. Das Werkzeug ist nur ein Teil des Systems.

Deutsch oder Englisch, je nach Team. Die Materialien sind teilweise englisch, weil die Fachliteratur es ist.

Dann beginnt das Kern-Enablement nicht. Den schriftlichen Befund bekommen Sie trotzdem: priorisierte Anwendungsfälle, Risikobild, Messplan und eine Entscheidungsempfehlung. Fehlen messbare Anwendungsfälle, der Zugang zu den Daten, ein verantwortlicher Sponsor oder ein realistisches Zeitfenster für den Transfer, endet das Vorhaben nach dem Assessment. Liegt der Engpass in Requirements, Review, Release oder Governance, benenne ich genau das. Das Assessment ist kostenpflichtig und steht für sich: Es ist auch dann verwertbar, wenn danach nichts weiter folgt, und wird bei Beauftragung des Enablements vollständig angerechnet.

Dann steht das im Bericht, mit Median und Bandbreite und mit den Anwendungsfällen, in denen sich nichts verbessert hat. Stoppen ist an dieser Stelle ein legitimes Ergebnis und genau der Grund, warum in Woche sechs ein Entscheidungstor steht und keine Erfolgsmeldung. Ein Befund, der einen teuren Rollout auf weitere Teams verhindert, ist mehr wert als ein Bericht, der zu allem ja sagt. Der wahrscheinlichere Fall ist ohnehin ein gemischtes Bild: ein Anwendungsfall trägt, ein zweiter nicht, und die Empfehlung lautet anpassen.