KI-Coding-Agenten einführen: Ein 100-Tage-Plan

Die meisten KI-Einführungen in Entwicklungsteams laufen nach demselben Drehbuch: Lizenzen werden gekauft, ein Workshop findet statt, drei Begeisterte nutzen die Werkzeuge täglich, der Rest fällt in alte Gewohnheiten zurück, und nach sechs Monaten kann niemand sagen, was sich eigentlich geändert hat. Der Fehler liegt darin, Agentic Coding wie eine Werkzeug-Einführung zu behandeln. Es ist ein Wechsel des Arbeitsmodells, und Arbeitsmodelle ändern sich durch Praxis, Struktur und Messung. Hier ist der Plan, den wir mit Teams durchlaufen, verdichtet auf sein Gerüst.

Tag 1–20: Ausgangsbasis und Verifikation

Zwei Dinge, bevor ein Agent Produktivcode schreibt. Erstens: den Startpunkt messen. Zykluszeit und Durchsatz, ehrlich erhoben. Ohne Ausgangsbasis ist das Gespräch an Tag 80 ein Austausch von Meinungen. Zweitens: die Verifikationsschleife schließen. Tests, denen das Team vertraut, laufend in der CI, schnell genug zum Arbeiten. Das ist der wirksamste einzelne Schritt des ganzen Plans: Ein Agent, der die eigene Arbeit prüfen kann, arbeitet ohne Menschen in der Schleife weiter; einer, der es nicht kann, hört auf, sobald der Code fertig aussieht. Ist die Testabdeckung dünn, sind die ersten Agenten-Aufgaben: Tests schreiben. Geringes Risiko, sofortiger Nutzen, und es entsteht genau die Schleife, von der alles Weitere abhängt.

Tag 21–60: Echte Aufgaben, angepasster Prozess

Keine Trockenübungen. Die Agenten arbeiten am echten Backlog (Fehlerbehebungen, Refactorings, sauber umrissene Funktionen), während die Entwickler das Orchestrieren im Tandem üben: Aufgaben präzise beschreiben, Leitplanken setzen, Ergebnisse prüfen. Drei Prozessänderungen gehören bewusst in diesen Abschnitt. Das Review passt sich an: Liefert ein Agent 500 Zeilen in Minuten, verlagert sich das Review vom zeilenweisen Lesen zu Architektur, Schnittstellen und Testqualität, mit klaren Regeln, was menschliche Augen sehen müssen. Fehler werden zu Gedächtnis: Jeder wiederholte Agentenfehler wird zur Regel in einer dauerhaften Datei (CLAUDE.md, Regelwerke), sodass der Aufbau Woche für Woche klüger wird. Parallelität beginnt klein: ein Entwickler, zwei Agenten auf Git-Worktrees, und mehr erst, wenn das Review Schritt hält.

Tag 61–100: Skalieren, messen, übergeben

Jetzt verbreitet sich der Werkzeugkasten über das Team, und wiederkehrende Abläufe werden in dauerhafte Bausteine überführt (Kommandos, Prüflisten, Unteragenten), damit der Gewinn nicht länger an einzelnen Begeisterten hängt. An Tag 80: Messung. Zykluszeit und Durchsatz gegen die Ausgangsbasis von Tag 1. Zahlen, keine Eindrücke. Haben sie sich nicht bewegt, stimmt etwas am Aufbau nicht, und es bleiben zwanzig Tage, um es zu finden. Der Schlussabschnitt ist planmäßiger Wissenstransfer: Das Team betreibt den Aufbau ohne externe Hilfe, sonst ist die Einführung gescheitert, egal, was die Kennzahlen sagen.

Die typischen Fehlschläge

Vier Muster sehen wir immer wieder: Lizenzen kaufen, ohne das Review anzupassen (ein paar Prozent Gewinn, dann Stillstand); mit dem härtesten Altsystem-Modul beginnen, statt zuerst die Verifikationsschleife zu bauen; jeden Entwickler einen privaten Arbeitsablauf erfinden lassen, statt die fünf Praktiken zu standardisieren; und den Erfolg nach Stimmung verkünden statt nach der Messung von Tag 80. Jedes dieser Muster ist mit der Struktur oben vermeidbar.

Genau diese Form haben unsere Engagements: Wir betten uns ins Team ein, durchlaufen den Plan mit Ihrem echten Backlog und gehen an Tag 100, mit den Zahlen auf dem Tisch und der Fähigkeit in Ihrem Team. Siehe KI-Anwendungen und die häufigen Fragen.