Claude Code im Team: Das Risiko-Register, das Deploy-Unfälle verhindert

Es war Freitagnachmittag, als ein Kollege meinte: “Claude Code ist so praktisch, lass uns das ab nächster Woche alle zusammen nutzen.”

Mir wurde sofort mulmig. Solange er das Tool allein benutzt hatte, hatte er seinen eigenen Branch selbst reviewt und selbst gemergt. Ging etwas schief, traf es nur ihn. Im Team sieht das anders aus. Wer erteilt die Erlaubnis, wie weit darf der Agent eingreifen, und wer kontrolliert die Änderung? Wenn das nicht geklärt ist und plötzlich sechs Leute loslegen, wird ganz selbstverständlich ein Commit gemergt, der die Produktions-Datenbank leert.

Genau das ist mir in einem anderen Team passiert. Drei Leute ließen Claude Code jeweils mit ihren eigenen Einstellungen laufen, und als einer “räum das mal schön auf” tippte, wurde die gemeinsame Konfigurationsdatei überschrieben. Am Montagmorgen scheiterten sämtliche Deploys. Einen halben Tag brauchten wir, um die Ursache zu finden. Niemand hatte böse Absichten. Es fehlte nur eine “Regel, wie man Aufgaben im Team delegiert”.

Daraufhin habe ich das gebaut, was ich in diesem Artikel vorstelle: das Risiko-Register. Register klingt groß, aber es ist nur eine einzige Tabelle. Trotzdem entscheidet diese Tabelle darüber, ob der Team-Rollout von Claude Code mit “ist viel leichter geworden” endet oder mit “wir reiben uns an Schadensbegrenzung auf”.

Das Wichtigste in Kürze

• Unfälle beim Team-Rollout entstehen nicht durch fehlende Intelligenz des Modells, sondern weil “wer, wie weit, mit wessen Kontrolle” nicht geklärt ist.
• Das Risiko-Register ist eine Tabelle, die für jeden gefährlichen Bereich in einer Zeile “Verantwortlicher, Prüfmethode, Bedingung zum Weitermachen” festhält. Drei Zeilen reichen am Anfang.
• Zuerst werden drei Dinge festgezurrt: Berechtigungen (welche Dateien darf der Agent anfassen), CI (der Beweis, dass die Änderung nichts zerstört) und Veröffentlichung (die Kontrolle dessen, was wirklich live geht).
• Claude Code übernimmt nur “Entwürfe schreiben und Prüfungen ausführen”. Löschen, Produktions-DB, kostenpflichtige Aktionen und Force-Push muss immer ein Mensch freigeben.
• Es gibt eine kopierbare Register-Vorlage und ein Konfigurationsbeispiel, das gefährliche Operationen abfängt. Der Trick: erst mit einer einzigen Datei testen.

Was ist dieses Risiko-Register eigentlich?

Das Risiko-Register ist eine Tabelle, die “die Stellen, an denen leicht etwas schiefgeht” auflistet, wenn man Claude Code im Team Arbeit überträgt.

Jede Zeile kommt mit nur drei Spalten aus: Wo ist es gefährlich, welcher Beweis sagt, dass es sicher ist, und wer führt diese Prüfung durch. Mehr nicht. Du brauchst kein kompliziertes Management-Tool. Am Anfang reicht eine Tabelle in der Kalkulation, im Zweifel sogar ein Array mitten im Code.

Warum eine Tabelle? Weil “irgendwie aufpassen” das Gefährlichste überhaupt ist. Wer im Stress ist, überspringt zwangsläufig Kontrollen. Schreibt man es als Tabelle und legt fest “es wird nicht gemergt, bis diese Zeile ausgefüllt ist”, dann stoppt der Unfall auch am hektischen Freitagnachmittag. Auch der Deploy-Unfall vom Anfang wäre verhindert worden, hätte man die gemeinsame Konfigurationsdatei mit einer einzigen Zeile als “Bereich, der nicht angefasst werden darf” eingetragen.

Die drei Gefahrenpunkte, die du zuerst festzurrst

Die Stellen, an denen Team-Rollouts scheitern, lassen sich grob auf die folgenden drei zusammendampfen. Anders gesagt: Trägst du allein diese drei ins Register ein, verhinderst du fast alle großen Unfälle am ersten Tag.

1. Berechtigungen (welche Dateien darf der Agent anfassen)

Der häufigste Unfall ist “zu viel anfassen lassen”. Bittet man “räum das Repository auf”, schreibt Claude Code seelenruhig auch Konfigurationsdateien und CI-Definitionen um. Deshalb legst du vorab schriftlich fest, welche Stellen bearbeitet werden dürfen und welche absolut tabu sind.

Mein Maßstab ist simpel. Artikel, Entwürfe und Testcode dürfen angefasst werden. .github/, Produktions-Umgebungsvariablen, Deploy-Konfiguration und Datenbank-Migrationen heißt es: “stoppen, bis ein Mensch prüft”. Überlässt du diese Grenze dem persönlichen Geschmack, wird die Regel von Person zu Person unterschiedlich, und am Ende verursacht die lockerste Einstellung den Unfall. Entscheidend ist, sich im Team auf eine Variante zu einigen.

2. CI (lass dir den Beweis geben, dass nichts kaputt ist)

Wenn Claude Code sagt “habe ich repariert”, ist das ein Eindruck. Kein Beweis. Deshalb trägst du ins Register den Befehl ein, der belegt, dass die Änderung nichts zerstört. Der Build läuft durch, die Tests werden grün, es gibt keine Typfehler. Eines davon legst du fest als “muss vor jeder Erfolgsmeldung ausgeführt werden”.

Wichtig ist dabei, den Prüfbefehl schnell zu halten. Braucht der volle Testlauf zehn Minuten, lässt ihn niemand mehr laufen. Sorgst du dafür, dass nur die zur geänderten Datei gehörenden Tests in 30 Sekunden durchlaufen, wird die Kontrolle zur Gewohnheit.

3. Veröffentlichung (sieh dir jede Änderung an, die live geht, unbedingt selbst an)

Egal ob Umsatzseite im Blog oder API: Bei Änderungen, die nach außen gehen, hältst du fest “habe ich es unter der echten URL angesehen”. Dass der Build durchläuft und dass die Seite, die der Nutzer tatsächlich sieht, korrekt ist, sind zwei verschiedene Dinge. Öffne die Produktions-URL und mach einen Screenshot. Das machst du zur Abschlussbedingung.

Selbst wenn die öffentliche URL 200 zurückgibt: Ist der Inhalt eine andere Seite, ist das so gut wie nicht veröffentlicht. Steht auf einer deutschen Seite englischer Fließtext, ist auch das unfertig. Klingt selbstverständlich, aber gerade an hektischen Tagen überspringt man genau das.

Was der KI überlassen, was der Mensch entscheidet

Wenn du bei der Grenzziehung zögerst, nimm diese Tabelle direkt. Der Entscheidungsmaßstab ist “lässt es sich rückgängig machen”.

Operation	An Claude Code delegieren	Erst nach menschlicher Freigabe
Entwurf erstellen / überarbeiten	OK
Test / Build ausführen	OK
Änderung erklären (Diff zusammenfassen)	OK
Dateien löschen		OK
In die Produktions-Datenbank schreiben		OK
Kostenpflichtige Operationen		OK
Force-Push / Historie umschreiben		OK
Deploy / Live-Veröffentlichung		OK

Es gilt eine Regel: Operationen, die schwer rückgängig zu machen sind, kommen anfangs alle auf “Mensch fragen”. Erst wenn sich eine Operation als sicher erwiesen hat, stufst du sie später auf automatisch hoch. Lieber streng anfangen und langsam lockern, als von Anfang an locker zu sein und einen Unfall zu bauen. Unterm Strich ist das sogar schneller.

Die kopierbare Risiko-Register-Vorlage

Zuerst bringst du, bevor du eine Aufgabe gibst, die Anweisung an Claude Code in eine Vorlagenform. Klebst du das jedes Mal ein, verhinderst du eigenmächtige Ausweitung.

Halte vor der Arbeit Folgendes ein.
- Bearbeitet werden darf nur, was in src/content/ und tests/ liegt.
- .github/, Produktions-Umgebungsvariablen, Deploy-Konfiguration und DB-Migrationen werden nicht angefasst. Ist eine Änderung nötig, melde den Grund, ohne zu editieren.
- Führe nach jeder Änderung zwingend `npm run check` aus und melde das Ergebnis.
- Wird Löschen, Produktions-DB, eine kostenpflichtige Aktion oder Force-Push nötig, führe es nicht aus, sondern fordere eine Bestätigung an.
Wiederhole vor dem Editieren die obigen Vorgaben in eigenen Worten, bevor du mit der Arbeit beginnst.

Und dann das Register selbst. Am Anfang reichen drei Zeilen. Ersetze sie durch die Gefahrenpunkte deines eigenen Teams.

// Team-Rollout-Risiko-Register: pro Gefahrenpunkt eine Zeile mit "Verantwortlicher, Beweis, Bedingung zum Weitermachen"
type RolloutRisk = {
  area: string;       // gefährlicher Bereich
  risk: string;       // was passieren könnte
  owner: string;      // wer prüft
  proof: string;      // Beweis, dass es sicher ist
  nextGate: string;   // Bedingung, um weitermachen zu dürfen
};

const rolloutRisks: RolloutRisk[] = [
  {
    area: "Berechtigungen",
    risk: "Claude Code schreibt sogar die gemeinsame Konfiguration um",
    owner: "Lead",
    proof: "Liste erlaubter / verbotener Bearbeitungen ist dokumentiert",
    nextGate: "zuerst nur mit einer Datei testen",
  },
  {
    area: "CI",
    risk: "Prüfbefehl ist langsam oder existiert nicht",
    owner: "Entwickler",
    proof: "Build grün oder nur relevante Tests grün",
    nextGate: "Prüfschritt in die PR-Vorlage aufnehmen",
  },
  {
    area: "Veröffentlichung",
    risk: "Live gehende Änderung wurde nicht am echten Objekt geprüft",
    owner: "Betrieb",
    proof: "Screenshot der öffentlichen URL",
    nextGate: "Rollback-Schritte als Notiz festhalten",
  },
];

console.table(rolloutRisks);

Speicherst du das so, dass es mit node läuft, und führst es aus, wird die Tabelle ausgegeben. Spektakulär ist das nicht, aber der Wert liegt darin, “die Gefahrenpunkte in Worte zu fassen, bevor die Arbeit beginnt”. Machst du daraus die Regel “es wird nicht gemergt, bis jede Zeile ausgefüllt ist”, wird das Register zum Türsteher gegen Unfälle.

In solchen Teams wirkt es (drei Praxisbeispiele)

Gibt es eine ähnliche Situation, baue das Register nicht neu, sondern tausche nur die Namen aus.

1. Ein kleines Zweierteam Bevor ihr gemeinsamen Code anfasst, lest ihr zu zweit die Stellen vor, die bearbeitet werden dürfen, die tabu sind und die menschliche Freigabe brauchen, und fasst alles auf einem Blatt zusammen. Allein damit verschwindet der Unfall “der eine zerschießt die Konfiguration, ohne dass der andere es merkt”. Gerade in kleinen Teams baut man mit “das versteht sich doch von selbst” Unfälle, deshalb ist es so viel wert, es zu Beginn schriftlich festzuhalten.

2. Ein Team mit Review-Prozess Der Lead macht zur Pflicht, dass eine von Claude Code erstellte Änderung “das Ergebnis des ausgeführten Prüfbefehls” und “eine Zusammenfassung der Änderungen” mitbringt, bevor sie in den Review geht. Einen PR ohne das schaut er sich gar nicht erst an. Ziel ist, die Änderung so weit zu bringen, dass der Reviewer den Diff liest, die Prüfung erneut ausführt und den Rückweg erklären kann.

3. Ein Team mit Umsatzseiten Bei Änderungen an Seiten, die direkt mit Geld zu tun haben - Blog oder Produktseiten -, wird ein Screenshot der öffentlichen URL festgehalten, bevor etwas als abgeschlossen gilt. Es endet nicht mit “Build ist durchgelaufen”, sondern man prüft den Bildschirm, den der Nutzer wirklich sieht. Mit eigenen Augen kontrolliert man, ob Titel, Fließtext, Bild und Call-to-Action wie geplant sind.

Häufige Fehler und wie du sie behebst

Ehrlich gesagt: Auch dieses Register lief am Anfang nicht rund. Ich teile drei Patzer.

Jeder bastelte sich eigene Regeln Anfangs überließ ich die Einstellungen jedem selbst, und der bearbeitbare Bereich wurde von Person zu Person unterschiedlich. Wer die lockerste Einstellung hat, baut den Unfall. Die Lösung ist simpel: Ich habe die Liste der erlaubten und verbotenen Bearbeitungen im Team auf eine Version vereinheitlicht und ins Repository gelegt.

CI-Fehler aufgeschoben Wird “machen wir später alles zusammen” zur Floskel, endet der erste Team-Rollout mit dem schlechten Eindruck “wenn wir Claude Code reinholen, geht alles kaputt”. Fällt der Prüfbefehl durch, wird sofort gestoppt, und es bleibt im Draft-Status, bis es grün ist. Das habe ich zur Regel gemacht.

Verantwortung schwammig gelassen und schwere Entscheidungen vermieden Legt man nicht fest “wer gibt frei”, schwebt die schwerste Entscheidung - die Live-Veröffentlichung - in der Luft. Die owner-Spalte des Registers wird immer ausgefüllt. Niemals leer weitermachen. Allein damit kommen Entscheidungen nicht mehr ins Stocken.

Hast du das Gefühl, die Arbeit fängt an auszuufern, schreibe nicht den ganzen Auftragstext neu, sondern zurre in dieser Reihenfolge fest: den bearbeitbaren Bereich verengen, die Prüfung zuerst vorlegen, einen Verantwortlichen für die Kontrolle benennen. Wichtig ist auch, Fehler im Team als geteilte Erfahrung festzuhalten. Schaust du nur auf Erfolgsbeispiele, merkst du nicht, dass du selbst gerade in einen gefährlichen Zustand gerätst.

Häufige Fragen

F. Braucht auch ein kleines Team ein Register? Schon zu zweit ja. Im Gegenteil, gerade kleine Teams bauen Unfälle, weil sie glauben “das versteht sich auch ohne Worte”. Am Anfang reicht die Drei-Zeilen-Vorlage, also erstelle sie in fünf Minuten und teile sie.

F. Reichen nicht allein die Berechtigungseinstellungen von Claude Code? Berechtigungseinstellungen sind der “Mechanismus, der das Anfassen verhindert”, das Register ist die Betriebsregel “wer prüft womit”. Du brauchst beides. Technisch stoppst du über die Einstellungen, menschlich kontrollierst du über das Register. Details findest du im Berechtigungs-Leitfaden.

F. Welchen Prüfbefehl soll ich wählen? Den kürzesten Befehl, mit dem dein Team sagen kann “nichts ist kaputt”. Typprüfung, nur die relevanten Tests, oder den Build. Braucht der volle Testlauf zehn Minuten, lässt ihn niemand laufen, also lege zuerst einen fest, der in 30 Sekunden fertig ist.

F. Funktioniert es auch mit Mitgliedern, die keine Entwickler sind? Ja. Das Register muss man nur lesen und ausfüllen, also lässt es sich auch ohne Code-Kenntnisse betreiben. Für den Einstieg von Nicht-Entwicklern hilft Claude Code für Nicht-Entwickler.

F. Wo schreibe ich projektspezifische Regeln hin? Schreibst du sie in die CLAUDE.md des Repositorys, liest Claude Code sie jedes Mal. Bündelst du verbotene Bereiche und Prüfbefehle hier, lässt sich das leicht mit dem Register abgleichen. Wie man sie schreibt, habe ich in CLAUDE.md richtig schreiben zusammengefasst. Sieh dir auch die offizielle Claude Code Dokumentation von Anthropic als Primärquelle an.

Mein Fazit aus dem echten Test

Nach dem Deploy-Unfall vom Anfang habe ich aufgehört, mir den Kopf darüber zu zerbrechen, “ob ich Claude Code vertraue”. Stattdessen schaue ich darauf, welche Zeile des Registers noch nicht ausgefüllt ist.

Ich habe tatsächlich ein Drei-Zeilen-Register eingeführt, und nachdem die gemeinsame Konfigurationsdatei schriftlich als “Bereich, der nicht angefasst werden darf” festgelegt war, ging die Zahl der Merges, die die Konfiguration zerschießen, auf null. Seit der Prüfbefehl “vor der Erfolgsmeldung Pflicht” ist, fällt nicht mehr erst im Review auf, dass etwas kaputt ist, und die Zurückweisungen sind sichtbar weniger geworden. Seit die Screenshot-Kontrolle auf den öffentlichen Seiten drin ist, ist auch das Übersehen “Build lief durch, aber eine andere Seite war live” gestoppt.

Geprüft habe ich nur diese drei Punkte. Statt nach einem schlaueren Agenten zu suchen, baust du zuerst einen Betrieb, der dich auch nach einem Sturz wieder aufstehen lässt. Sieht nach Umweg aus, aber beim Team-Rollout ist das der schnellste Weg - das ist mein heutiger Eindruck.

Wenn du in der Firma die Einführung von Claude Code ernsthaft vorantreiben oder die Betriebsregeln gemeinsam entwerfen willst, dann stellen wir in der Schulung & Beratung zusammen die konkreten Schritte auf. Fang einfach damit an, die Gefahrenpunkte deines eigenen Teams in drei Zeilen aufzuschreiben.