KI im SDLC in 30 Tagen: ein Plan Woche für Woche

Für CTOs und Tech Leads, deren Entwickler bereits Claude Code, Codex oder Cursor nutzen, jeder auf seine Art. Der Plan ändert nicht Ihre Tools. Er ändert, was für alle gilt: Regeln im Repository, Gates in der CI, Review und Messung.

KI schreibt heute unseren gesamten Code, und ein Senior verantwortet das Ergebnis. Seit 2023 haben wir 15+ Produktivprojekte geliefert. Dieser Plan beschreibt, wie wir es bei uns eingerichtet haben. Das Gerüst können Sie aus unserem öffentlichen Repository claude-code-production-starter übernehmen.

1. Tag 0: messen Sie den heutigen Stand

Ohne Ausgangswerte wissen Sie nach einem Monat nicht, ob sich etwas verbessert hat. Drei Zahlen reichen, aus den letzten 20 gemergten PRs:

• Zeit vom Öffnen eines PR bis zum Merge. Der Median, nicht der Durchschnitt.
• Wie viele PRs mindestens einmal aus dem Review zurückkamen. Und warum, in einem Wort.
• Wie viele Änderungen nach dem Deployment zurückgenommen wurden. Revert, Hotfix oder Korrektur innerhalb von zwei Tagen.

Wo Ihr Team heute steht, sehen Sie in wenigen Minuten im Test Wie weit sind Sie von AI-native SDLC entfernt?. Die Punkte, die Ihnen dort fehlen, sind Ihre Arbeit für die nächsten vier Wochen.

2. Der Plan für vier Wochen

01

Woche 1: Regeln in CLAUDE.md und AGENTS.md

Der Agent liest seine Regeln zu Beginn jeder Aufgabe. Stehen sie nur in den Köpfen der Leute, arbeitet jeder Agent anders. AGENTS.md lesen Codex, Cursor und weitere Tools, Claude Code liest CLAUDE.md. Am einfachsten stehen die Regeln in AGENTS.md und CLAUDE.md verweist darauf.

Die vollständige Regelvorlage finden Sie im Tool Regeln für KI-Agenten im Team. Eine kürzere Version für den Anfang:

# Regeln für KI-Agenten in diesem Repository

## Befehle
- Nach jeder Änderung: pnpm verify (Typecheck, Lint, Unit-Tests)
- Vor dem PR: pnpm verify:full

## Fertig ist es, wenn
- Tests, Typecheck, Lint und Build grün sind,
- geänderter Code einen geänderten oder neuen Test hat,
- die PR-Vorlage ausgefüllt ist, auch das, was Sie nicht gemacht haben.

## Der Agent niemals
- verbindet sich mit der Produktionsdatenbank,
- liest .env-Dateien oder Schlüssel,
- deployt oder führt Produktionsmigrationen aus,
- ändert den Test, nach dem er bewertet wird, damit er besteht.

02

Woche 2: CI-Gates und Hooks

Ein Satz in AGENTS.md ist eine Bitte. Der Agent kann ihn umgehen, wenn er schnell fertig werden will. Was wichtig ist, muss eine Einstellung, ein Hook oder die CI erzwingen. In Claude Code erledigen das .claude/settings.json (verbotene und erlaubte Befehle) und Hooks, die vor einem Befehl laufen oder bevor der Agent „fertig“ sagt.

{
  "permissions": {
    "deny": ["Read(**/.env)", "Bash(git push --force:*)", "Bash(git reset --hard:*)", "Bash(psql:*)"],
    "ask": ["Bash(git push:*)", "Bash(gh pr merge:*)"]
  },
  "hooks": {
    "Stop": [{ "hooks": [{ "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/stop-gate.sh" }] }]
  }
}

Die konkreten Gates mit Beispielen finden Sie im Tool Wie viele von 10 Gates stoppen schlechten KI-Code in Ihrer CI?.

03

Woche 3: Review-Regeln und agentisches Review

Wenn der Agent schneller schreibt, wird das Review zum Engpass. Die Regeln müssen sagen, was ein Mensch immer prüft und was der Maschine überlassen bleibt.

04

Woche 4: Messung und Einführung im Team

Messen Sie dieselben drei Zahlen wie an Tag 0 und vergleichen Sie. Machen Sie dann aus dem Pilot den Standard für das ganze Team.

3. Wohin welche Regel gehört

Eine Regel, die zweimal gebrochen wurde, rückt eine Stufe höher.