Wie viele von 10 Gates stoppen schlechten KI-Code in Ihrer CI?

Für CTOs und Tech Leads, deren Team bereits mit Claude Code, Codex oder Cursor Code schreibt. Eine Regel in AGENTS.md kann der Agent umgehen. Ein Gate in der CI nicht. Die Beispiele sind für GitHub Actions und pnpm. In GitLab CI ist jedes Gate derselbe Befehl unter script:.

KI schreibt heute unseren gesamten Code, und ein Senior verantwortet das Ergebnis. Die meisten Beispiele stammen aus unserem öffentlichen Repository claude-code-production-starter, wo Sie sie vollständig finden.

1. Welche Gates haben Sie schon?

Haken Sie nur ab, was den Merge wirklich blockiert. Ein Gate, das nur meldet, zählt nicht.

2. Zehn Gates mit Beispielen

01

Lint blockiert den Merge

Lint, das nur warnt, ignoriert der Agent. Lassen Sie es in der CI laufen und fehlschlagen. Wenn Sie eine neue strenge Regel in alten Code einführen, halten Sie die heutigen Verstöße fest und lassen Sie die CI fehlschlagen, wenn es mehr werden.

- run: pnpm lint --max-warnings 0

02

Typprüfung im Strict-Modus

Agenten ändern gern einen Typ auf any, damit der Code durchgeht. Der Strict-Modus und ein eigener CI-Schritt verhindern das.

# tsconfig.json: "strict": true
- run: pnpm exec tsc --noEmit

03

Tests sind Pflicht und beweisen etwas

Ein Test, der auch auf dem Hauptbranch besteht, beweist nichts. Geänderter Quellcode braucht einen geänderten Test, und der muss auf dem Hauptbranch fehlschlagen und auf Ihrem bestehen. Eine Ausnahme (reines Refactoring) genehmigt ein Mensch per Label, nicht der Agent.

- name: Geänderte Tests scheitern auf base und bestehen hier
  if: "!contains(github.event.pull_request.labels.*.name, 'skip-red-proof')"
  run: bash scripts/gate.sh red-proof "origin/${{ github.base_ref }}"

04

Verbotene Muster

Manche Abkürzungen von Agenten findet eine einfache Suche: .only im Test, abgeschaltete Typprüfung, abgeschaltetes Lint. Lassen Sie sie in der CI fehlschlagen.

- name: Verbotene Muster
  run: "! git grep -nE '(it|test|describe)\\.only\\(|@ts-ignore|eslint-disable' -- src tests"

05

Secret-Scan

Ein Schlüssel in einem Commit ist auch nach dem Löschen ein Problem, er bleibt in der Historie. Scannen Sie vor dem Commit (Hook) und in der CI.

- uses: actions/checkout@v5
  with:
    fetch-depth: 0
- run: docker run --rm -v "$PWD:/repo" ghcr.io/gitleaks/gitleaks:latest git /repo --redact

06

Migrationswächter

Eine Datenbankmigration lässt sich nicht so leicht zurücknehmen wie Code. Ein PR, der Migrationen ändert, geht nur mit einem Label von einem Menschen durch. Eine Produktionsmigration erfordert in den Einstellungen des Agenten eine Bestätigung.

- name: Migrationen nur mit Label
  if: "!contains(github.event.pull_request.labels.*.name, 'migration-ok')"
  run: "! git diff --name-only origin/${{ github.base_ref }}... | grep -E '(^|/)migrations/'"

07

Abhängigkeitsprüfung

Der Agent fügt ein Paket hinzu, wenn die Aufgabe es braucht. Prüfen Sie, dass es keine bekannte schwere Schwachstelle hat, und lassen Sie Abhängigkeiten regelmäßig aktualisieren.

- run: pnpm audit --audit-level high
# .github/dependabot.yml: package-ecosystem npm, schedule weekly

08

PR-Vorlage mit KI-Abschnitt

Ein PR muss sagen, wie die Änderung geprüft wurde und was der Autor nicht gemacht hat. Dann weiß der Reviewer, wo er hinschauen muss.

## Wie es geprüft wurde
- [ ] das Gate ist grün, inklusive Red-Proof
- [ ] kein Test wurde abgeschwächt, übersprungen oder gelöscht

## Was der Agent geschrieben und der Autor geprüft hat
<!-- Welche Teile der Agent erzeugt hat, was Sie Zeile für Zeile geprüft haben. -->

## Was nicht fertig ist

09

Review-Regel

Eine Änderung genehmigt jemand, der sie nicht geschrieben hat. Regeln für Agenten und CI ändern nur ihre Verantwortlichen, sonst lockert der Agent mit der Zeit seine eigenen Gates.

# .github/CODEOWNERS
*             @ihre-firma/team
/.claude/     @ihre-firma/regel-owner
/.github/     @ihre-firma/regel-owner
/AGENTS.md    @ihre-firma/regel-owner

10

Geschützter Branch

Alles oben gilt nur, wenn sich der Hauptbranch nicht umgehen lässt. Ein zusammenfassender Check ci, ein Pflicht-PR, die Freigabe durch den Code Owner und Regeln auch für Admins.

gh api -X PUT repos/IHRE-FIRMA/REPO/branches/main/protection \
  -F 'required_status_checks[strict]=true' -f 'required_status_checks[contexts][]=ci' \
  -F 'required_pull_request_reviews[required_approving_review_count]=1' \
  -F 'required_pull_request_reviews[require_code_owner_reviews]=true' \
  -F enforce_admins=true -F restrictions=null