Quality-Gates gegen KI-Fehler

Ob ein Mensch oder ein Agent den Code schreibt: die Regeln, die ihr euch gegeben habt, müssen eingehalten werden, und Fehler sollten so früh wie möglich auffallen. Menschen übersehen im Eifer des Gefechts eine Konvention oder einen Edge Case. Agenten tun das genauso. Der Unterschied ist die Menge. Ein Agent produziert in einer Stunde mehr Code als ein Mensch an einem Vormittag. Was ihr früher im Review mit den Augen aufgefangen habt, läuft jetzt an euch vorbei, weil niemand so schnell lesen kann, wie die Maschine schreibt.

Die Antwort ist nicht, langsamer zu werden. Die Antwort ist, jede Regel, die sich maschinell prüfen lässt, auch maschinell zu prüfen. Automatisch, an einer Stelle, an der niemand sie vergessen kann.

Was sich automatisch prüfen lässt

Ein großer Teil eurer Regeln ist deterministisch. Es gibt genau eine richtige Antwort, und ein Skript kann sie liefern. Typische Kandidaten:

• Namensschema. Ihr habt euch auf ein Muster geeinigt, aber es wird nicht immer eingehalten. Ein Linter prüft das in Millisekunden.
• Bugs, die eine statische Analyse findet. Ungenutzte Variablen, fehlende Null-Checks, unsichere Patterns. Werkzeuge wie ESLint, Ruff oder SonarQube finden diese Klasse zuverlässig.
• Metadaten nach Schema. Dateien mit Frontmatter, Konfigurationen, Manifeste. Wenn die einem Format folgen sollen, kann ein Skript das erzwingen.
• Commit-Messages nach Konvention. Ein festes Präfix, eine Ticket-Nummer, Conventional Commits. Reines Pattern-Matching.

Die Leitfrage ist simpel: Kann eine Maschine diese Regel eindeutig prüfen? Wenn ja, gehört die Prüfung in ein Skript und nicht in den Kopf eines Reviewers.

Zwei Prinzipien: deterministisch und früh

Deterministisch heißt: kein "bitte dran denken", sondern ein Programm, das bei einem Verstoß mit einem Fehler abbricht. Eine Regel, die man einhält, indem man sich erinnert, ist keine Regel, sondern eine Hoffnung. Bei einem Agenten, der im Sekundentakt commit-reifen Code ausspuckt, ist diese Hoffnung schnell aufgebraucht.

Früh heißt: so nah wie möglich am Moment, in dem der Code entsteht. Je später ein Verstoß auffällt, desto teurer wird er. Lokal beim Commit kostet er dich zehn Sekunden. In der CI kostet er einen Pipeline-Durchlauf. Im Review kostet er die Zeit eines Kollegen. In Produktion kostet er einen Incident. Der billigste Ort ist immer der früheste.

Der beste Ort für Code-Regeln: Git-Hooks

Git-Hooks sind Skripte, die Git zu bestimmten Zeitpunkten automatisch ausführt. Zwei sind für Quality-Gates besonders nützlich:

• pre-commit läuft bei jedem Commit. Es muss schnell sein, ein bis zwei Sekunden, sonst nervt es und wird umgangen. Ideal für Formatierung, Linting und Namensprüfungen auf den geänderten Dateien.
• pre-push läuft seltener, nämlich vor dem Teilen. Es darf länger dauern und eignet sich für Typecheck, Build und Testsuite. Es ist das Gate, das verhindert, dass kaputter Code überhaupt beim Team ankommt.

Ein wichtiges Detail: das Standardverzeichnis .git/hooks liegt nicht im Repository. Deine Hooks gelten also nur bei dir. Damit sie versioniert sind und für alle gelten (auch für jeden Agenten, der im Repo arbeitet), legst du sie in einen Ordner im Repo und zeigst Git einmalig darauf:

# Hooks in einen versionierten Ordner legen und aktivieren
git config core.hooksPath .githooks

Ab jetzt zieht jeder, der das Repo klont und diesen einen Befehl ausführt, dieselben Gates.

Ehrlich bleiben muss man bei einem Punkt: lokale Hooks lassen sich mit --no-verify überspringen. Sie sind die schnelle Rückkopplung, nicht die letzte Instanz. Deshalb gehört dieselbe Prüfung zusätzlich in die CI-Pipeline, wo niemand sie überspringen kann. Lokal fürs Tempo, CI als Netz. Wer rohe Shell-Skripte nicht selbst pflegen will, nimmt einen Hook-Manager wie husky, lefthook oder das pre-commit-Framework, die das Verteilen und Ausführen übernehmen.

So sieht das in der Praxis aus

Diese Website läuft mit genau so einem Gate. Vor jedem Push, der die Website betrifft, prüft ein pre-push-Hook der Reihe nach: einen Content-Linter für die Metadaten, einen Link-Check, ESLint für die statische Analyse, einen Typecheck und einen Build. Bricht einer davon ab, gibt es keinen Push. Vereinfacht sieht der Kern so aus:

#!/bin/sh
# .githooks/pre-push (gekürzt)
cd website || exit 1

echo "Content-Lint..."
node scripts/lint-content.mjs || { echo "Content-Lint fehlgeschlagen."; exit 1; }

echo "ESLint..."
pnpm lint --quiet || { echo "ESLint fehlgeschlagen."; exit 1; }

echo "Typecheck..."
pnpm typecheck || { echo "Typecheck fehlgeschlagen."; exit 1; }

echo "Alle Checks bestanden."

Der Content-Linter ist dabei das interessanteste Stück, weil er unsere eigenen Metadaten- und Schreibregeln in Code gießt: Titel-Länge fürs SEO, echte Umlaute statt Ersatzschreibungen, gerade Anführungszeichen, gültige Rollen und Level im Frontmatter. Das sind Regeln, die vorher in einer Doku standen. Eine Doku überfliegt ein Agent und priorisiert sie weg. Ein Skript, das mit Exit-Code 1 abbricht, tut das nicht. Genau das ist der Unterschied zwischen einer Regel und einem Gate.

Für alles, was nicht Code ist: Skripte

Nicht jede Regel passt in einen Git-Hook. Manchmal geht es um Metadaten-Dateien, um die Struktur einer Doku oder um das Format eines Reports. Dafür lohnt sich ein kleines Prüfskript, das du selbst oder die KI laufen lässt.

Der Haken dabei: du musst sicherstellen, dass es auch gelaufen ist. Der KI zu sagen "prüf das bitte" reicht nicht, denn sie vergisst es so zuverlässig wie ein Mensch unter Zeitdruck. Es gibt zwei verlässliche Wege. Entweder hängst du das Skript in einen Hook oder die CI ein, dann bist du wieder beim harten Gate. Oder das Skript erzeugt eine überprüfbare Ausgabe, einen Report oder einen klaren Exit-Code, den du kurz kontrollierst. Das ist immer noch deutlich weniger Arbeit und zuverlässiger, als die Prüfung selbst von Hand zu machen.

Lass dir die Gates von der KI bauen

Der schnellste Weg zu diesen Checks ist, sie generieren zu lassen. Die KI kennt die Hook-Mechanik und die gängigen Linter. Du musst nur deine konkreten Regeln liefern. Drei Startpunkte:

Und ein Tipp, der die halbe Arbeit spart: gib der KI deine Regeln schon als Kontext, bevor sie Code schreibt. Eine CLAUDE.md oder AGENTS.md mit euren Konventionen sorgt dafür, dass der Agent sie in den meisten Fällen von sich aus einhält. Dann fängt der Hook nur noch die Ausrutscher ab, statt jede zweite Datei zu blockieren. Die Reihenfolge ist die Verteidigung in zwei Linien: Regeln als Kontext, damit der Agent sie meistens trifft, plus das harte Gate, das den Rest zuverlässig stoppt. Die Doku allein genügt nicht, weil ein Agent Kontext überfliegt. Das Gate ist die Rückversicherung.

Was Gates nicht können

Automatisierte Gates nehmen euch die stumpfe Arbeit ab: Formatierung, Namen, offensichtliche Bugs, Schema-Verstöße. Was sie nicht ersetzen, ist das Urteil. Ob die Logik stimmt, ob der Code ins bestehende System passt, ob die Lösung überhaupt die richtige ist, das entscheidet weiter ein Mensch. Der Gewinn ist, dass genau dafür wieder Zeit bleibt, statt sie an Kleinkram zu verlieren.

Wie dieses menschliche Review bei KI-Code konkret aussieht, steht in KI-Code: Fast richtig reicht nicht. Und wer Agenten nicht nur prüfen, sondern von vornherein enger führen will, findet den passenden Ansatz in Guided Determinism: KI-Agenten auf Schienen.