Pilotteam zuerst: KI-Coding-Einführung in Stufen

Die Lizenzen sind gekauft, das Rundschreiben ist verschickt, und trotzdem nutzen manche im Team Claude Code oder Cursor nur als besseres Autocomplete, andere hören nach einem misslungenen Agenten-Lauf ganz auf. Das liegt oft nicht am Modell. Meist fehlt eine Einführung, die Vertrauen Stufe für Stufe aufbaut, statt alle gleichzeitig ins kalte Wasser zu werfen.

Brendan O’Leary von Kilo Code, einem Open-Source-Agenten-Tool, hat auf der QCon Nutzungsdaten aus dem Gateway des Projekts ausgewertet, inzwischen über 40 Billionen Tokens. Er selbst weist darauf hin, dass die Nutzerbasis stark zu Early Adoptern tendiert. Gerade deshalb lohnt der Blick: Die Daten zeigen, woran Einführungen scheitern, bevor es die meisten Teams selbst merken.

Die Vertrauensleiter: vier Stufen, vier Feedback-Schleifen

O’Leary beschreibt die Nutzung von KI-Coding-Tools als Leiter mit vier Sprossen. Ganz unten steht Autocomplete: Der Vorschlag erscheint synchron, wird per Tastendruck angenommen oder verworfen, ein Fehler kostet praktisch nichts. Darüber liegt der Chat, bei dem Code erklärt oder angefordert und von Hand geprüft wird.

Auf der dritten Sprosse arbeitet ein Agent selbstständig: Er liest und schreibt Dateien, führt Befehle aus, oft mit den Rechten der Person, die ihn startet. Ein falscher Pfad ist hier kein schlechter Text mehr, sondern womöglich ein kaputter Build. Ganz oben steht die Orchestrierung mehrerer Agenten, die eine Aufgabe zerlegen und verteilen. Die Rückmeldung kommt erst nach Minuten bis Stunden.

Der entscheidende Punkt ist die Asymmetrie: Je höher die Stufe, desto mehr Vertrauen braucht es, und desto weniger unmittelbare Belege bekommt man. Teams, die von Autocomplete direkt zu Agenten-Schwärmen springen, haben nie gelernt, wie Halluzinationen und Fehlerpfade in ihrer Codebasis aussehen.

Drei Stellen, an denen Einführungen brechen

Kontext. Welche Dateien sieht der Agent, kennt er die Zusammenhänge im Projekt, ist die Aufgabe klar formuliert? Läuft der Agent bei der Frage nach der Auth-Logik in die falsche Richtung, zieht sich der Fehler durch die ganze Session. Bemerkenswert: Ein veralteter Index der Codebasis kann schlechter sein als gar keiner, weil der Agent einer falschen Karte folgt. Wer mit dem Kontext nicht zurechtkommt, kopiert ihn von Hand in den Chat und bleibt dort hängen.

Modellwahl. Viele Organisationen legen ein Modell fest und halten daran fest. In O’Learys Daten nutzen intensive Anwender dagegen regelmäßig Modelle mehrerer Anbieter, je nach Aufgabe. Für ein Team heißt das: Regeln und Kontextdateien sollten nicht an ein einzelnes Modell gebunden sein.

Feedback. Ein spürbarer Teil der Entwickler bleibt bewusst auf der Chat-Stufe. Nicht, weil Agenten gescheitert wären, sondern weil sie bei einem Fehler nicht sehen konnten, warum. Wer nicht erkennt, welchen Kontext der Agent hatte und welche Entscheidungen er getroffen hat, bricht ab, übernimmt selbst und versucht es beim nächsten Mal nicht wieder.

Warum ein Pilotteam, und welches

Vertrauen in Agenten baut sich über viele gute Erfahrungen auf und kann durch eine einzige schlechte zerstört werden. Dazu kommt eine soziale Komponente: Ein sichtbarer Fehlschlag vor einem skeptischen Senior Engineer oder in einer Live-Demo erzeugt eine Geschichte, die sich im Unternehmen lange hält. Geschichten über überschriebene Datenbanken verbreiten sich schneller als stille Erfolge.

O’Learys Schlussfolgerung: Allen Zugang geben und sie es selbst herausfinden lassen, ist nicht die richtige Rollout-Strategie. Starten Sie mit Entwicklern, die geduldig mit Unklarheit umgehen und bereit sind, mehrfach nachzusteuern. Sie bauen die Erfahrung auf, die später die Skeptiker überzeugt.

Für die Zusammensetzung lohnt ein zweiter Hinweis aus dem Vortrag: Den größten Nutzen hatten oft die erfahrensten Engineers, weil sie das System verstehen und dem Agenten den passenden Kontext geben. Und Agenten arbeiten besonders gut dort, wo es etablierte Muster und Leitplanken gibt. Ein guter Pilotbereich ist deshalb ein Teil der Codebasis mit klaren Konventionen, nicht das chaotischste Modul.

Vertrauen messen statt erfühlen

„Vertrauen“ klingt weich, lässt sich aber an Signalen pro Stufe ablesen. Bei Autocomplete ist es der Anteil verworfener Vorschläge, im Chat die Tiefe der Session und ob überhaupt nachgefragt wird. Bei Agenten zählt, ob eine Aufgabe bis zum Ende laufen darf oder abgebrochen wird. Über Wochen hinweg ist die wichtigste Frage, ob Entwickler die Leiter hinaufwandern.

Für ein Pilotteam heißt das ganz praktisch: Halten Sie fest, wann und warum Agenten-Sessions abgebrochen werden, und besprechen Sie das im Team. Jeder Abbruch wegen fehlenden Kontexts ist ein Kandidat für einen Eintrag in AGENTS.md oder die gemeinsamen Regeln, wie im Beitrag zu Claude Code im Team beschrieben. Und je höher das Team auf der Leiter steht, desto wichtiger wird ein belastbares Review; die Review-Checkliste für KI-Pull-Requests ist dafür ein Startpunkt.

Was das für Ihr Entwicklerteam bedeutet

Eine KI-Coding-Einführung ist kein Lizenzprojekt, sondern ein Lernprozess mit Stufen. Planen Sie bewusst, welche Stufe das Team gerade erreicht hat, und überspringen Sie keine. Wählen Sie ein Pilotteam aus geduldigen, erfahrenen Leuten und einen Codebereich mit klaren Mustern. Sorgen Sie dafür, dass Kontext gepflegt wird, statt zu veralten, und dass Abbrüche sichtbar und besprechbar sind. Fehlschläge gehören dazu; entscheidend ist, dass das Team aus ihnen lernt, statt eine Abschreckungsgeschichte daraus zu machen.

Erst wenn das Pilotteam auf einer Stufe sicher arbeitet, lohnt der nächste Schritt, sowohl auf der Leiter als auch beim Ausrollen auf weitere Teams. Welche Inhalte dabei eine Rolle spielen können, zeigt die Übersicht der Module.

Sie wollen die Einführung mit einem Pilotteam am eigenen Repository beginnen, mit Kontextdateien, Review-Prozess und klaren Grenzen für die Agenten? Inhouse-Training anfragen.