KI-Coding-Regeln im Team einführen: So bleibt KI-generierter Code wartbar

KI-Assistenten wie Cursor oder Claude Code schreiben funktionierenden Code, aber ohne verbindliche Regeln schreiben sie ihn jedes Mal anders. Wer solche Werkzeuge im Team einsetzt, braucht eine kurze, versionierte Regeldatei im Repository, sonst wachsen Inkonsistenz und technische Schuld schneller als die Produktivität.

Warum KI-generierter Code ohne Regeln auseinanderläuft

Ein Sprachmodell hat aus unzähligen fremden Repositories gelernt, was „üblicher Code" ist. Es hat nicht gelernt, was in Ihrem Projekt üblich ist. Ohne Vorgaben greift es zu den Mustern, die in den Trainingsdaten am häufigsten vorkommen: lange if/else-Kaskaden, reguläre Ausdrücke zum Parsen strukturierter Daten, ein useEffect für jeden Seiteneffekt in React, Funktionen, die alles auf einmal erledigen. Jedes einzelne Stück läuft. Zusammen ergeben sie eine Codebasis, in der jede Datei eine andere Handschrift trägt und ein Review länger dauert als das Schreiben.

Erster Schritt: die Regeln festlegen

Beginnen Sie mit wenigen Regeln, die die häufigsten Schwächen abdecken, und formulieren Sie jede so, dass das Modell sie befolgen und ein Mensch sie im Review prüfen kann. Bei dataso haben sich diese bewährt; sie stehen so in unserer eigenen Regeldatei.

Keine langen Bedingungsketten. Ab drei, vier Fällen wird aus if/else ein Nachschlagewerk: ein Objekt, das Schlüssel auf Werte oder Funktionen abbildet, oder ein früher Rückgabepunkt.

const STATUS_LABELS: Record<string, string> = {
  pending: 'Ausstehend',
  active: 'Aktiv',
  cancelled: 'Abgebrochen',
};
const label = STATUS_LABELS[status] ?? 'Unbekannt';

Kein regulärer Ausdruck zum Parsen. Für Dateiendungen, URLs oder Pfade gibt es split, new URL() und spezialisierte Parser. Reguläre Ausdrücke bleiben für einfache Prüfungen erlaubt, nicht für das Zerlegen strukturierter Daten.

useEffect vermeiden. Was auf eine Nutzeraktion folgt, gehört in den Ereignis-Handler; was ein Element beim Einhängen braucht, in einen Ref-Callback. Das Modell greift reflexartig zu useEffect, weil es in den Trainingsdaten überall steht.

Abstraktion statt Inline-Logik. Wenn eine Funktion je nach Typ etwas anderes tut, gehört die Zuordnung in eine Strategie-Map, die man um einen Eintrag erweitert, statt die Funktion zu ändern.

const JOB_HANDLERS: Record<Job['type'], (job: Job) => Promise<unknown>> = {
  scan: runScan,
  report: generatePdf,
};

Trainingswissen nicht blind übernehmen. Modelle haben einen Wissensstand mit Stichtag. Bei Versionssprüngen von Bibliotheken oder frischen Sicherheitslücken raten sie überzeugend falsch. Die Regel verlangt, vor dem Vorschlag die aktuelle Dokumentation oder das Repository zu lesen.

Zweiter Schritt: die Regeln im Team verankern

Eine Regeldatei, die ein Einzelner schreibt und ins Repository legt, wird ignoriert. Legen Sie die Regeln gemeinsam fest, mit den Entwicklerinnen und Entwicklern, die den Code später warten, und mit den Beispielen aus dem eigenen Projekt, an denen es zuletzt gehakt hat. Die Datei heißt je nach Werkzeug CLAUDE.md, AGENTS.md oder .cursorrules, liegt im Repository und wird wie Code versioniert und reviewt.

Wichtiger als die Datei ist der Review. Wer einen Pull Request prüft, prüft ausdrücklich auch, ob der Assistent die Regeln befolgt hat. Verstöße sind kein Vorwurf an den Kollegen, sondern ein Hinweis darauf, dass eine Regel unklar formuliert ist oder fehlt.

Dritter Schritt: die Regeln weiterentwickeln

Regeln, die einmal geschrieben und nie angepasst werden, veralten mit dem ersten Framework-Update. Nehmen Sie sich die Datei in jeder Retrospektive kurz vor: Welche Verstöße kamen im Review am häufigsten vor? Welche Regel hat niemand mehr gebraucht? Eine Regel, die sich nicht durchsetzt, wird gestrichen oder umformuliert, nicht verteidigt.

Häufige Fragen zu KI-Coding-Regeln

Wie viele Regeln braucht ein Team?

So wenige, dass alle sie im Kopf haben. Eine Handvoll gut formulierter Regeln wirkt stärker als eine Seite, die weder Mensch noch Modell zu Ende liest.

Gelten die Regeln für alle Assistenten?

Ja. Cursor, Claude Code und GitHub Copilot lesen projektspezifische Regeldateien; die Syntax unterscheidet sich, das Prinzip ist dasselbe.

Wie überzeugen Sie Skeptiker im Team?

Mit einem konkreten Vergleich: dasselbe Ticket, einmal mit und einmal ohne Regeldatei generiert, nebeneinander im Review. Der Unterschied in Lesbarkeit und Korrekturaufwand ist meist offensichtlicher als jedes Argument.

Öffnen Sie den letzten Pull Request, an dem ein KI-Assistent beteiligt war, und markieren Sie die Stellen, die Sie im Review von Hand geradegezogen haben. Aus diesen Stellen entsteht Ihre erste Regeldatei. Wenn Sie wissen möchten, wie wir bei dataso KI-gestützt entwickeln und trotzdem eine einheitliche Codebasis halten, buchen Sie den kostenlosen Potenzial-Check, eine halbe Stunde, in der wir Ihre Situation gemeinsam einschätzen.