KI-Coding im Team einführen: Regeln, die helfen

Was die Forschung sagt

Erwarte nicht automatisch einen großen Sprung. In einer randomisierten Studie von METR aus dem Jahr 2025 brauchten erfahrene Open-Source-Entwickler bei Aufgaben in vertrauten Projekten mit KI rund 19 % länger, schätzten sich aber schneller ein. Die Stichprobe war klein, die Tools entwickeln sich schnell, und METR selbst geht inzwischen davon aus, dass sich das Bild verändert hat.

Die Lehre für dein Team ist nicht „KI bringt nichts“. Sie lautet: Das Gefühl, schneller zu sein, ist kein Beleg. Miss es.

Regel 1: Kläre zuerst die Daten

Welche Tools sind erlaubt, und mit welchem Vertrag?
Wird Code für das Training verwendet? Prüfe die Einstellung im jeweiligen Tarif, nicht die Werbeseite.
Was darf nie in einen Prompt: Kundendaten, Zugangsdaten, fremder Code unter Vertraulichkeit?
Wenn du in der EU personenbezogene Daten verarbeitest, gehört auch die Auftragsverarbeitung geklärt.

Gibt es keine erlaubten Tools, nutzen Leute trotzdem welche, nur ohne dass du es weißt.

Regel 2: Der Autor bleibt verantwortlich

Wer den Merge Request stellt, hat ihn verstanden und kann ihn erklären. „Das hat die KI geschrieben“ ist keine Begründung. Diese eine Regel verhindert viele Probleme.

Regel 3: Kleine Änderungen

KI macht es leicht, tausend Zeilen zu erzeugen, und Reviewer stimmen dann eher zu, weil sie nicht alles lesen können. Begrenze die Größe von Änderungen. Das Review wird damit zum Engpass, und genau dort entscheidet sich die Qualität.

Regel 4: Tests und CI zuerst

Agenten arbeiten gut, wenn sie ihre Ergebnisse prüfen können: Tests, Linter, Typprüfung, Sicherheitsscans. Ohne diese Leitplanken verwaltest du nur schnellere Fehler. Verlange außerdem, dass ein Test für einen Bug vor dem Fix fehlschlägt. Modelle ändern sonst gern den Test, bis er grün ist.

Regel 5: Schreib dem Modell die Projektregeln auf

Lege eine Datei mit Konventionen, Build-Befehlen, Architekturentscheidungen und Verboten im Repository ab. Die meisten Tools lesen so etwas automatisch. Das spart Korrekturen und sorgt dafür, dass alle mit denselben Vorgaben arbeiten.

Wo KI meist hilft und wo weniger

Eher gut	Eher riskant
Fremden Code verstehen	Authentifizierung und Rechte
Tests, Migrationen, Boilerplate	Zahlungen und Kryptografie
Prototypen zum Wegwerfen	Große Umbauten ohne Tests
Fehlersuche mit klaren Logs	Unbekannte Bibliotheken ohne Prüfung

Agenten mit Vorsicht

Agenten, die Befehle ausführen, brauchen Grenzen: kein Zugriff auf Produktivdaten, keine dauerhaften Zugangsdaten, und Änderungen laufen über den normalen Review-Prozess. Inhalte aus dem Web oder aus Tickets können versteckte Anweisungen enthalten. Behandle sie als ungeprüfte Eingaben.

Woran du den Nutzen misst

Zeilen Code sind kein Maß. Besser geeignet sind:

Durchlaufzeit von der Aufgabe bis in die Produktion
Fehlerquote und Rollbacks nach dem Deployment
Dauer und Umfang von Reviews
Einschätzung des Teams zur Wartbarkeit nach einigen Monaten

Miss vor der Einführung, damit du einen Vergleichswert hast. Starte mit einem Team und einem klar begrenzten Zeitraum, nicht mit allen gleichzeitig.

Junior-Entwickler nicht vergessen

Wer jede Aufgabe von der KI lösen lässt, lernt das Prüfen nicht, das später unverzichtbar ist. Plane bewusst Aufgaben ein, die jemand erst allein löst, und lass Juniors KI-Vorschläge im Review begründen.

Für den Fall, dass einzelne Apps schon gebaut sind, hilft die Checkliste vor dem Launch. Wenn du Begleitung bei der Einführung möchtest: KI-Coding mit tob-apps.

KI-Coding im Team einführen