Verantwortlichkeiten für KI-generierten Code im Team definieren

1. Warum diese Frage vor dem ersten Vorfall geklärt sein muss

Solange alles gut läuft, stellt niemand im Team die Frage nach Verantwortlichkeiten für KI-generierten Code. Erst wenn ein Fehler in Produktion auftritt, der auf einen unkritisch übernommenen Claude Code Vorschlag zurückgeht, wird sichtbar, ob ein Team diese Frage bereits beantwortet hat oder erst in der Krise improvisieren muss. Ein Team ohne geklärte Verantwortlichkeiten verliert in dieser Situation wertvolle Zeit mit Diskussionen darüber, wer eigentlich zuständig gewesen wäre, statt sich auf die Behebung des Fehlers zu konzentrieren.

Der Kern des Problems ist, dass KI-generierter Code eine neue Grauzone schafft, die klassische Verantwortungsmodelle nicht abdecken. Bei traditionellem Code ist klar: Wer die Zeilen geschrieben hat, trägt zunächst die Verantwortung, ergänzt durch den Reviewer, der den Merge freigegeben hat. Bei Claude Code generiertem Code verschiebt sich diese Zuordnung, weil der Entwickler den Code oft nicht selbst formuliert, sondern nur akzeptiert hat, was eine andere Art der Verantwortung bedeutet als eigenständiges Schreiben.

Wichtig ist, diese Klärung nicht als juristische Übung misszuverstehen, sondern als praktisches Werkzeug für den Arbeitsalltag. Klare Verantwortlichkeiten für KI-generierten Code sollen in erster Linie sicherstellen, dass im Fehlerfall schnell die richtige Person einbezogen wird, und dass Lernprozesse aus Fehlern entstehen können, statt in Schuldzuweisungen zu enden, die dem Team langfristig schaden.

2. Das Grundprinzip: Wer committet, verantwortet

Das tragfähigste Grundprinzip für Verantwortlichkeiten bei KI-generiertem Code ist denkbar einfach: Wer einen Commit erstellt, egal ob der Code selbst geschrieben oder von Claude Code vorgeschlagen und übernommen wurde, trägt die primäre Verantwortung dafür. Dieses Prinzip verschiebt den Fokus weg von der Frage, wer den Code technisch erzeugt hat, hin zu der Frage, wer die Entscheidung getroffen hat, ihn ins Projekt zu übernehmen.

Dieses Prinzip hat einen wichtigen erzieherischen Effekt: Es macht deutlich, dass die Nutzung von Claude Code die eigene Verantwortung nicht reduziert, sondern lediglich das Werkzeug ändert, mit dem Code entsteht. Ein Entwickler, der einen KI-Vorschlag ungeprüft übernimmt, trägt dieselbe Verantwortung, als hätte er den fehlerhaften Code selbst getippt. Diese Klarheit verhindert die verbreitete Fehlvorstellung, KI-generierter Code sei irgendwie weniger die eigene Verantwortung als selbst geschriebener Code.

{
  "accountability_principle": {
    "rule": "the_committer_owns_the_commit_regardless_of_origin",
    "applies_to": ["hand_written_code", "claude_code_generated_code", "mixed_code"],
    "rationale": "using_ai_tools_changes_the_process_not_the_responsibility",
    "explicit_non_excuse": "i_just_accepted_what_claude_suggested"
  }
}

3. Die Rolle des Reviewers in der Verantwortungskette

Neben dem Committer trägt der Reviewer eine zweite, klar abgegrenzte Verantwortung: die Freigabe des Merges. Ein Reviewer, der einen Pull Request mit KI-generiertem Code genehmigt, ohne die kritischen Stellen tatsächlich zu prüfen, teilt sich die Verantwortung mit dem Committer, auch wenn er den Code nicht selbst erzeugt hat. Diese geteilte Verantwortung ist kein Widerspruch zum Grundprinzip, sondern eine notwendige Ergänzung, weil Code Review genau für diesen Zweck existiert.

In der Praxis hat sich bewährt, diese geteilte Verantwortung explizit zu benennen, statt sie implizit vorauszusetzen. Ein Reviewer, der weiß, dass er mit seiner Freigabe eine echte Mitverantwortung übernimmt, prüft KI-generierten Code gründlicher als einer, der Reviews als reine Formalie versteht. Diese Erwartungshaltung sollte Teil der Onboarding-Dokumentation sein, nicht nur eine implizite Kultur, die neue Teammitglieder erst durch Beobachtung erschließen müssen.

# Simple pre-merge checklist enforced via pull request template
# for commits tagged with the AI-assisted marker
cat > .github/pull_request_template.md <<'EOF'
## AI-assisted changes checklist
- [ ] I reviewed every AI-suggested line, not just the diff summary
- [ ] I understand why this approach was chosen, not just that it works
- [ ] Security-relevant paths (auth, payment, data export) received extra scrutiny
- [ ] I am comfortable being the primary owner of this commit going forward
EOF

4. Ein RACI-ähnliches Modell für KI-generierten Code

Für Teams mit mehreren Rollen, etwa Entwickler, Reviewer, Tech Lead und Security-Verantwortlicher, hilft ein einfaches, RACI-ähnliches Modell, um Verantwortlichkeiten für KI-generierten Code über den einfachen Commit-Review-Zyklus hinaus zu klären. Responsible ist der Entwickler, der den Code committet. Accountable ist bei normalem Code derselbe Entwickler, bei sicherheitsrelevantem Code zusätzlich der Tech Lead, der die endgültige Freigabe erteilt.

Consulted sind Fachexperten, etwa ein Security-Verantwortlicher bei Authentifizierungscode oder ein Datenbankspezialist bei Migrationen, die vor der Freigabe konsultiert werden sollten, aber nicht selbst freigeben. Informed ist das restliche Team, das über wichtige, mit KI-Unterstützung getroffene Architektur-Entscheidungen informiert werden sollte, ohne selbst in die Entscheidung eingebunden zu sein. Dieses Modell muss nicht für jeden Commit angewendet werden, es lohnt sich aber für klar definierte Risikobereiche.

{
  "raci_ai_code": {
    "standard_code": {
      "responsible": "committing_developer",
      "accountable": "committing_developer",
      "consulted": [],
      "informed": ["team_channel_via_commit_marker"]
    },
    "security_relevant_code": {
      "responsible": "committing_developer",
      "accountable": "tech_lead",
      "consulted": ["security_owner"],
      "informed": ["full_team_in_next_standup"]
    }
  }
}

5. Eskalationspfade bei sicherheitsrelevantem Code

Für Bereiche mit besonders hohem Schadenspotenzial, etwa Zahlungsabwicklung, Authentifizierung oder Datenexport, reicht das einfache Committer-Reviewer-Modell oft nicht aus. Hier lohnt sich ein definierter Eskalationspfad, der vor dem Merge automatisch einen zusätzlichen, benannten Verantwortlichen einbezieht, unabhängig davon, ob der Code mit oder ohne KI-Unterstützung entstanden ist.

Wichtig ist, diesen Eskalationspfad technisch zu verankern, statt ihn nur als organisatorische Regel zu kommunizieren. Eine Pull-Request-Regel, die bestimmte Verzeichnisse automatisch einem zusätzlichen Reviewer zuweist, verhindert, dass die Eskalation im Alltagsstress vergessen wird, weil sie nicht von der Erinnerung einzelner Personen abhängt.

6. Verantwortung im Postmortem: Lernen statt Schuldzuweisung

Wenn trotz klarer Verantwortlichkeiten ein Fehler auftritt, entscheidet die Postmortem-Kultur darüber, ob das Team daraus lernt oder nur Schuldige sucht. Ein Postmortem, das fragt, wer verantwortlich war, um daraus Verbesserungen abzuleiten, unterscheidet sich fundamental von einem, das fragt, wer schuld war, um jemanden zur Rechenschaft zu ziehen. Klare Verantwortlichkeiten für KI-generierten Code sollten explizit in den Dienst des ersten Ansatzes gestellt werden.

Ein bewährtes Format ist, im Postmortem-Dokument getrennt zu erfassen, was der KI-Vorschlag war, was der Reviewer geprüft hat, und wo die Prüfung eine Lücke hatte. Diese Trennung macht sichtbar, ob das Problem in der KI-Nutzung selbst lag, etwa ein zu vager Prompt, oder im Review-Prozess, etwa eine zu oberflächliche Prüfung, was zu unterschiedlichen, gezielten Verbesserungsmaßnahmen führt.

#!/usr/bin/env bash
# postmortem-ai-section.sh — generates a structured template section
# for incidents involving AI-assisted code
set -euo pipefail

commit_hash="${1:?Usage: postmortem-ai-section.sh <commit_hash>}"

cat <<EOF
## AI-assisted code section for postmortem

- Commit: $commit_hash
- Was this commit AI-assisted? (check git trailer)
- What did the original prompt ask for?
- What did the review process check, and what did it miss?
- Root cause: prompting gap, review gap, or both?
- Action item: which of the two gaps gets addressed first?
EOF

7. Verantwortlichkeiten dokumentieren statt mündlich vereinbaren

Mündlich vereinbarte Verantwortlichkeiten funktionieren, solange das Team klein und stabil bleibt, und versagen genau dann, wenn sie am wichtigsten wären: bei einem neuen Teammitglied, das die informelle Regelung nie mitbekommen hat, oder bei einem akuten Vorfall, bei dem sich niemand mehr sicher an die genaue Absprache erinnert. Eine schriftlich dokumentierte Verantwortungsregelung, etwa als Abschnitt in der CLAUDE.md-Datei oder als eigenes Governance-Dokument, vermeidet dieses Risiko.

Diese Dokumentation muss nicht lang sein, um wirksam zu sein. Ein einzelner Abschnitt, der das Grundprinzip, die Reviewer-Verantwortung und den Eskalationspfad für sicherheitsrelevanten Code in wenigen Sätzen zusammenfasst, reicht in den meisten Teams aus, solange er tatsächlich gelesen und bei neuen Teammitgliedern aktiv angesprochen wird.

8. Grenzfälle: Wenn mehrere Personen beteiligt waren

In der Praxis ist nicht jeder Fall so eindeutig wie ein einzelner Commit eines einzelnen Entwicklers. Häufig überarbeitet ein zweiter Entwickler einen bestehenden, KI-unterstützten Commit im Rahmen eines Folge-Tickets, ohne den ursprünglichen Kontext vollständig zu kennen. Für solche Grenzfälle hilft die Regel, dass Verantwortung an der letzten wesentlichen Änderung hängt, nicht an der Historie des gesamten Codeabschnitts.

Ein weiterer Grenzfall entsteht, wenn ein Reviewer Änderungen anfordert, die der Committer ohne erneute eigene Prüfung mit einem weiteren KI-Vorschlag umsetzt. Hier verschiebt sich die Verantwortung nicht automatisch zum Reviewer, weil die endgültige Entscheidung, den geänderten Vorschlag zu committen, weiterhin beim ursprünglichen Entwickler liegt. Diese Nuancen lassen sich nicht vollständig im Voraus regeln, aber ein klar kommuniziertes Grundprinzip reduziert die Zahl der strittigen Fälle erheblich.

#!/usr/bin/env bash
# blame-last-substantive-change.sh — finds who last substantively touched a file
# used to resolve edge cases where multiple developers contributed
set -euo pipefail

file_path="${1:?Usage: blame-last-substantive-change.sh <file>}"

# Ignore trivial whitespace-only commits when determining ownership
git log --follow -w --pretty=format:"%h %an %ad" --date=short -- "$file_path" | head -n 5

9. Verantwortungsmodelle im Vergleich

Die folgende Übersicht vergleicht drei Ansätze, wie Teams mit Verantwortlichkeiten für KI-generierten Code umgehen.

Der Vergleich zeigt, dass ein dokumentiertes Verantwortungsmodell nicht nur im akuten Vorfall Zeit spart, sondern auch die Qualität der Postmortems langfristig verbessert, weil es Lernorientierung strukturell verankert statt sie vom Zufall der jeweiligen Teamkultur abhängig zu machen.

10. Zusammenfassung

Verantwortlichkeiten für KI-generierten Code müssen definiert sein, bevor der erste Vorfall Klarheit erzwingt. Das tragfähigste Grundprinzip ist einfach: Wer einen Commit erstellt, verantwortet ihn, unabhängig davon, ob der Code selbst geschrieben oder von Claude Code vorgeschlagen wurde. Der Reviewer trägt eine geteilte Verantwortung für die Freigabe, und für sicherheitsrelevante Bereiche lohnt sich ein erweitertes, RACI-ähnliches Modell mit zusätzlichen Eskalationspfaden.

Entscheidend für den langfristigen Erfolg ist, diese Regelungen schriftlich zu dokumentieren statt mündlich zu vereinbaren, und Postmortems konsequent auf Lernen statt Schuldzuweisung auszurichten. Grenzfälle mit mehreren beteiligten Personen lassen sich nicht vollständig im Voraus regeln, aber ein klar kommuniziertes Grundprinzip reduziert strittige Fälle erheblich und gibt dem Team im Ernstfall die nötige Klarheit, um sich auf die Fehlerbehebung zu konzentrieren, statt über Zuständigkeiten zu diskutieren.

11. FAQ: Verantwortlichkeiten für KI-generierten Code im Team definieren