Wie steuerst du den Einsatz von KI-Coding-Assistenten in deinem Team?

Behandle generierten Code als Entwurf einer fremden beitragenden Person: schnell, nützlich und exakt demselben Review-Standard unterworfen wie alles andere. Sei explizit, wo du ihn förderst (Boilerplate, Tests, unbekannte Syntax, Exploration) und wo er zusätzliche Prüfung braucht (sicherheitsrelevante Pfade, Lizenzen, alles, was die Person nicht erklären kann). Beobachte die Review-Last genau, denn der Flaschenhals wandert vom Schreiben zum Prüfen.

Meine Regel ist einfach: Wer den Pull Request aufmacht, besitzt jede Zeile darin, und wenn du im Review nicht erklären kannst, warum es funktioniert, wird es nicht gemergt. Dieses eine Prinzip deckt den Großteil des Risikos ab, ohne dass ich eine Policy schreibe, die niemand liest. Ich fördere es aktiv für die langweilige Masse, Test-Gerüste, Migrationen, unbekannte Library-Syntax, und um einen Ansatz schnell auszuprobieren. Bei sicherheitsrelevanten Pfaden und allem, was Lizenzen berührt, verlange ich mehr Sorgfalt, und wir fügen keine Kundendaten in externe Tools ein. Der Effekt, den ich am schärfsten beobachte, ist die Review-Last. Der Output ist in meinem Team spürbar gestiegen und Review wurde fast sofort zur Beschränkung, also haben wir die Erwartung gesetzt, dass ein großer generierter Diff mit einer eigenen Zusammenfassung des Autors ankommt, worauf zu achten ist, und wir wehren uns viel aggressiver als früher gegen riesige unfokussierte Pull Requests. Das andere, was ich beobachte, sind Juniors, denn man kann jetzt funktionierenden Code produzieren, ohne ihn zu verstehen, also lasse ich sie in Eins-zu-eins häufiger als früher ihre Überlegungen durchgehen.