Wie führt man KI im Entwicklungsteam ein?

KI führen Sie im Entwicklungsteam ein, indem Sie zuerst gemeinsame Regeln, Kontrolle und einen Verantwortlichen festlegen. Die Toolwahl ist erst der zweite Schritt. Das Team kauft das Tool meist selbst, bevor die Firma es auswählt.

Was fehlt, ist die gemeinsame Schicht um das Tool: Regeln im Repository, Review durch jemand anderen als den Autor und Tests, die schlechten Code stoppen. Unten steht das Vorgehen, das wir selbst und mit den Teams nutzen, denen wir helfen.

KI schreibt heute unseren gesamten Code. Für das Ergebnis haftet ein Senior. Filip hat davor 7 Jahre lang ein SaaS entwickelt, das täglich 60.000+ Menschen nutzten.

Warum scheitert die KI-Einführung im Team, obwohl sie jeder nutzt?

Weil das Problem nicht im Tool liegt. Der typische Plan im Unternehmen lautet: Tool wählen, dann Methode, dann Kontrolle. Bis die Vergleichstabelle fertig ist, nutzen die Entwickler längst täglich Agenten.

Anfangen war also nie das Problem. Das Problem ist, dass jeder es allein eingerichtet hat. Eigene Regeln, eigener Kontext, eigene Art der Kontrolle. Lernt einer etwas, zahlen alle anderen für dieselbe Lektion noch einmal.

Die Regeln für KI leben dann an drei schlechten Orten. Nur ein Ort funktioniert:

Der Agent befolgt nur, was er im Kontext vor sich hat. Deshalb sagen wir: Ein Agent ist Modell plus Rahmen. Das Modell mieten Sie. Der Rahmen ist Ihre Arbeit.

Wo sollen die Regeln für KI leben, und wem gehören sie?

Im Repository, neben dem Code, in einer Datei, die der Agent selbst lädt. Bei Claude Code ist das CLAUDE.md, bei vielen anderen Tools AGENTS.md. Was hineingehört und was nicht, beschreiben wir im Artikel Regeln für KI-Code im Team. Welches Werkzeug das Team bekommt, vergleichen wir in Cursor vs Claude Code.

Wichtiger ist, wem die Regeln gehören. Den Rahmen um die KI hat niemand in seiner Stellenbeschreibung. Ohne Verantwortlichen zerfällt er nach und nach. Jeder passt ihn ein wenig an, und die gemeinsame Schicht driftet auseinander.

Uns hat Verteilung geholfen, nicht Disziplin. Unsere Regeln lagen im Haupt-Repository, die anderen Repositories sahen sie nicht. Einige haben das durch Kopieren „repariert“. Mit der Zeit liefen die Kopien auseinander, keine zwei waren gleich. Heute haben wir ein Regelpaket, das überall geladen wird.

Wie prüft man Code, den KI geschrieben hat?

So streng wie Code von einem Menschen. Dazu drei zusätzliche Regeln:

Prüfen Sie auch, ob Ihre CI überhaupt fehlschlagen kann. Bei übernommenen Systemen haben wir schon eine Pipeline gesehen, die läuft und meldet, aber nie einen Merge stoppt. Uns ist es auch passiert: Eine Prüfung war auf dem Hauptbranch lange rot, und niemand hat es bemerkt. Ohne Tests kann sie auch nicht fehlschlagen. Ein grüner Haken ohne Tests ist Dekoration.

Für den Livebetrieb gilt eine Regel ohne Ausnahme. Unser Agent kommt physisch nicht in den Livebetrieb. Ein Skript lehnt jeden Befehl ab, der die Produktionsdatenbank oder den Server berühren würde, noch bevor er läuft. Sicherheit kommt von einem Mechanismus, nicht von dem Satz „sei vorsichtig“.

Wie fängt man an, ohne dass sich das Team gegen KI sperrt?

Eine Präsentation überzeugt kein Team. Ein sicherer Raum und das eigene Backlog schon.

Bei einem Workshop für ein Entwicklungsteam hatten wir zwei Tage, in denen der Agent das einzige Werkzeug war. Gearbeitet wurde an echten Aufgaben aus dem Backlog, nicht an Demo-Aufgaben. Nachmittags Demos, am Ende eine gemeinsame Stunde, in der jeder erzählte, was er herausgefunden hatte. Ehrlich gesagt: Wir haben nicht gemessen, was Monate später davon blieb.

Das Zweite ist die Angst vor der Rechnung. Ein CTO wollte KI nicht von uns verbieten lassen. Er wollte ein Limit. Die Lösung ist langweilig: ein Teamkonto mit Guthaben. Ist es aufgebraucht, ist es aufgebraucht. Und ein Entwickler, der die Ausgaben sieht, entscheidet besser.

Drittens: Fangen Sie nicht mit dem ganzen Team an. Ein einwöchiger Pilot mit einem Entwickler zeigt, wo Regeln fehlen. Erst dann rollen Sie sie auf alle anderen aus. So sieht der ganze erste Monat aus:

Genau so steigen wir im Rahmen von AI-native SDLC für Entwicklerteams in Teams ein. Fehlen Ihrem Team eher Hände als Regeln? Sehen Sie sich einen Senior-Entwickler für Ihr Team an.

Die ersten 30 Tage KI im Team: Checkliste

Haken Sie ab, was Ihr Team schon hat:

Wenn Sie nach einem Monat sagen können, wo die Regeln leben, wem sie gehören und was eine schlechte Änderung stoppt, ist KI eingeführt. Der Rest ist Pflege.

Die erste Version der Regeln müssen Sie nicht selbst von null schreiben. Vorlage herunterladen: Regeln für KI im Team (PDF).

Wann wir davon abraten

• Ihr Team arbeitet schon mit KI und hat die Regeln im Repository. Machen Sie weiter. Einen externen Senior brauchen Sie nicht.
• Sie suchen eine Präsentation zur KI-Strategie für die Geschäftsführung. Das machen wir nicht. Wir arbeiten im Repository, nicht in Präsentationen.
• Sie wollen günstige Stundenkapazität, die nur Tickets abarbeitet. Das machen wir nicht. Suchen Sie einen Freelancer oder eine Agentur, die Entwickler vermietet.

Möchten Sie das mit jemandem einführen, der es täglich macht?

Sie brauchen keine weitere Demo, dass KI eine App schreiben kann. Sie brauchen einen Senior, der sich ab dem ersten Tag in Ihr Repository und Ihre Pull Requests einklinkt. Ihr Team lernt dabei, auf seine Art mit KI zu arbeiten.

Schreiben Sie uns, wo Ihre Entwicklung stockt. Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Wo bremst KI Ihr Team heute mehr, als sie hilft?

Häufige Fragen

Wie führt man KI im Entwicklungsteam ein?

Beginnen Sie mit gemeinsamen Regeln im Repository, Review durch jemand anderen als den Autor und Tests, die schlechten Code stoppen. Bestimmen Sie eine Person, der die Regeln gehören. Das Tool ist erst der zweite Schritt, meist hat das Team es schon.

Claude Code, Cursor oder Copilot: welches Tool für das Team?

Das Tool ist weniger wichtig, als es scheint. Modelle ändern sich jeden Monat. Wählen Sie eines, das Regeln aus dem Repository liest und auch in der CI läuft. Wichtiger ist, dass das ganze Team mit denselben Regeln arbeitet.

Wer haftet für Code, den KI geschrieben hat?

Die Person, die die Änderung zum Mergen freigegeben hat. KI schreibt den Code, verantwortet ihn aber nicht. Deshalb geht jede Änderung durch ein Review von jemandem, der sie nicht geschrieben hat, und durch Tests, die bei einem Fehler wirklich fehlschlagen.

Macht KI unsere Entwicklung schneller?

Wenn Sie Tests, Reviews und klare Regeln haben, meistens ja. Wenn nicht, produziert KI schneller Fehler. KI verstärkt, was im Team funktioniert, und auch, was nicht funktioniert.

Wie lange dauert die Einführung von KI im Team?

Ein Pilot mit einem Entwickler dauert eine Woche. Gemeinsame Regeln, Review und ein Ausgabenlimit lassen sich innerhalb eines Monats aufsetzen. Danach wachsen die Regeln mit jedem Fehler, den Sie abfangen.