Wie viel darf Claude Code heute? Freigaben in 4 Stufen festlegen

An einem Freitagabend wollte ich eigentlich nur eine winzige Korrektur in die Staging-Umgebung einspielen.

„Korrigier den Tippfehler in der Doku und schau gleich nach, ob der Build durchläuft” – mehr hatte ich nicht gesagt. Claude Code korrigierte den Tippfehler, aktualisierte dann aber eigenmächtig zwei Abhängigkeiten und schrieb sogar den Verweis in .env.production um. Lokal lief der Build durch, also meldete der Agent seelenruhig: „Fertig.”

Was mir den kalten Schweiß auf die Stirn trieb: Ich habe das erst gemerkt, als ich das Diff bis zum Ende durchgesehen hatte. Schuld war nicht die KI. Schuld war, dass ich nie in Worte gefasst hatte, wie weit sie gehen darf.

Umgekehrt hatte ich an einem anderen Tag rund 30 Mal hintereinander „Erlauben? Ja/Nein” vor der Nase – allein für einen einzigen Commit war mein ganzer Klick-Akku leer. Zu viel Freiheit führt zum Unfall, zu wenig zum Stillstand. Dieser Artikel handelt von einem einzigen Worksheet, mit dem du genau dazwischen die richtige Linie ziehst.

Das Wichtigste in Kürze

• Teile die Aufgaben für Claude Code in vier Stufen ein: „nur lesen”, „nur ändern”, „veröffentlichen” und „Geheimnisse anfassen”.
• Lege je Stufe vorab fest, wer am Ende OK gibt und woran man Sicherheit erkennt (der Nachweis).
• Stufe 0 und 1 übernimmt die KI, Stufe 2 prüft ein Mensch, Stufe 3 fasst nur die zuständige Person an.
• Wenn du morgens in einem Satz „heute bis hierhin” erklärst, sinkt die Zahl der Freigaben drastisch.
• Es gibt einen kopierbaren Ledger-Code und eine Vorlage, mit der du jeden Morgen in einer Minute entscheidest.

Warum man das „Freigabe-Budget” vorher festlegt

Was an den Freigaben zermürbt, ist nicht die Leistung von Claude Code. Es ist, dass man losläuft, ohne entschieden zu haben, wie weit man heute geht.

Wer das nicht festlegt, kippt in eine von zwei Richtungen. Entweder klickt man aus Bequemlichkeit alles auf „Erlauben” und winkt eines Tages auch eine heikle Operation durch. Oder man wird so vorsichtig, dass selbst eine Tippfehlerkorrektur eine Rückfrage auslöst und die Arbeit stockt. Beide haben gemeinsam, dass die Entscheidung der Tageslaune überlassen wird.

Genau hier hilft der Gedanke vom „Freigabe-Budget”. Wie bei einem Geldbudget legst du vorab den Rahmen fest: bis zu dieser Spur heute frei, alles darüber entscheidet ein Mensch. Mit einem Rahmen musst du nicht bei jeder Antwort der KI das Herz in der Hand halten. Du achtest nicht mehr darauf, „ob die KI klug ist”, sondern „in welcher Spur sie stehen geblieben ist”.

Wenn das Entscheidungskriterium in Worten steht, gibt es auch im Team keinen Streit. Statt „mir war irgendwie mulmig, deshalb hab ich gestoppt” sagt man „das ist Stufe 2, also ist jetzt der Mensch dran zu prüfen.” Den Grundgedanken der Rechtevergabe streife ich auch im Claude Code Einstiegsleitfaden, aber hier geht es bodenständiger nur um die „Linie für heute”.

Die Aufgaben in vier Stufen einteilen

Sortiere zuerst die Aufgaben, die Claude Code erledigen soll, nach Gefährlichkeit in vier Stufen. Mach es dir nicht zu schwer: Teile nur danach ein, ob „es rückgängig zu machen ist”, ob „es veröffentlicht wird” und ob „Geld oder Geheimnisse im Spiel sind”.

Stufe	Beispiel der Aufgabe	Wer am Ende OK gibt	Nachweis für Sicherheit
0	Dateien lesen, Struktur erfassen	KI erledigt es	Liste des Gelesenen
1	Eine rückgängig machbare Datei ändern	KI (Mensch sieht das Diff)	Diff und Build-Ergebnis
2	Auf die öffentliche Site einspielen	Mensch entscheidet	Live-URL und Rollback-Schritte
3	Geheimnisse, Abrechnung, Kundendaten anfassen	Nur die zuständige Person	Schriftliche Freigabe

Der Kern dieser Tabelle sind die rechten beiden Spalten. Lege vor dem Start fest, „wer OK gibt” und „woran man Sicherheit erkennt”. Entscheidest du es erst hinterher, reißt dich der Schwung des „Fertig!” mit und du überspringst die Prüfung.

Der Punkt bei Stufe 1 ist „rückgängig machbar”. Eine Tippfehlerkorrektur oder ein zusätzlicher Kommentar lässt sich bei einem Fehler sofort zurücknehmen. Deshalb überlässt du es der KI und der Mensch wirft nur kurz einen Blick aufs Diff. Das Aktualisieren von Abhängigkeiten dagegen hebst du auf Stufe 2 an. Auch wenn es klein wirkt, ist die Tragweite nicht abzuschätzen. Mein Unfall vom Anfang kam genau daher, dass ich das als Stufe 1 behandelt hatte.

Was die KI übernimmt und was ein Mensch entscheidet

Ich ziehe die Linie noch etwas schärfer. Der KI überlassen darfst du, was bei einem Fehler sofort auffällt und sofort rückgängig zu machen ist. Ein Mensch sollte entscheiden, was einmal ausgeführt nach außen wirkt.

• Der KI überlassen: lesen, recherchieren, einen Entwurf erstellen, eine rückgängig machbare Datei ändern, Tests laufen lassen
• Der Mensch entscheidet am Ende: veröffentlichen, Produktionsdaten ändern, sich bei externen Diensten registrieren, Abhängigkeiten aktualisieren, löschen

Im Zweifel eine Stufe höher. Merk dir nur das, dann liegst du nicht grob daneben. Nur Operationen, von denen du dir sicher bist, dass sie sicher sind, stufst du nachträglich eine Stufe nach unten und automatisierst sie. Der Trick ist, nicht von Anfang an die Vollautomatik anzustreben. Dieses „schrittweise Hochstufen” passt gut zu den Projektregeln aus CLAUDE.md richtig schreiben – halte deine festgelegte Linie in der Datei fest, dann ist sie reproduzierbar.

Ein kopierbares Freigabe-Ledger

Mit Worten allein vergisst man es schnell. Deshalb bringen wir die vier Stufen in eine maschinenlesbare Form und lassen uns per Filter ausgeben, „bis wohin heute”. Mit installiertem Node.js läuft es direkt.

// Freigabe-Ledger: jede Aufgabe trägt "Gefahrenstufe", "Verantwortlich" und "Nachweis"
const approvalBudget = [
  { action: "Dateien lesen",                  level: 0, owner: "KI",            proof: "Liste des Gelesenen" },
  { action: "eine rückgängig machbare Datei ändern", level: 1, owner: "KI (Mensch prüft)", proof: "Diff und Build-Ergebnis" },
  { action: "auf die öffentliche Site einspielen", level: 2, owner: "Mensch",       proof: "Live-URL und Rollback-Schritte" },
  { action: "Geheimnisse oder Abrechnung anfassen", level: 3, owner: "nur zuständige Person", proof: "schriftliche Freigabe" },
];

// Heutiges Limit. 0 = nur lesen, 1 = bis zur rückgängig machbaren Änderung an die KI
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`Heutiges Limit für die KI: Stufe ${todayMax}`);
console.table(allowedToday);
console.log("Aufgaben, die ein Mensch entscheidet:");
console.table(needsHuman);

Das Ausführen ist nur das hier. Über eine Umgebungsvariable schaltest du das „heutige Limit” um.

# Heute bis zur "rückgängig machbaren Änderung" überlassen
APPROVAL_MAX=1 node approval-budget.mjs

# Heute nur lesen lassen
APPROVAL_MAX=0 node approval-budget.mjs

Die Feldnamen lässt du, wie sie sind, und passt nur die Inhalte von action und proof an dein Projekt an. Gibst du Claude Code diesen Code mit der Bitte „füll die Werte für unser Repo aus”, hast du im Nu einen Entwurf.

Eine Prompt-Vorlage, mit der du morgens in einer Minute entscheidest

Steht das Ledger, teilst du der KI vor dem Start „den Rahmen für heute” mit. Kopier den folgenden Text und füll nur die Lücken.

Ich lege zuerst den Rahmen für die heutige Arbeit fest.

- Heutiges Ziel: (z. B. Tippfehler und tote Links in einem Blogartikel korrigieren)
- Lesen erlaubt in: nur site/src/content/blog/
- Ändern erlaubt: nur eine Datei davon (ausschließlich rückgängig machbare Änderungen)
- Erlaubte Befehle: npm run lint, Tests ausführen
- Nicht anfassen: .env, Produktions-Deploy, Abhängigkeiten aktualisieren, löschen

Regeln:
- Ab Stufe 2 (Veröffentlichen, Produktionsdaten, Abhängigkeiten, Löschen) immer
  bei mir rückfragen und stoppen.
- Nach einer Änderung das Diff und das Build-Ergebnis als "Nachweis" am Ende zeigen.
- Nicht mit "Fertig" abschließen, sondern schreiben, mit welchem Befehl du geprüft hast.

Allein durch diesen einen Absatz hört die KI auf, „erst mal alles zu machen”, und bewegt sich innerhalb des Rahmens. Wenn du dich daran gewöhnt hast, verschiebst du den Inhalt gemäß CLAUDE.md richtig schreiben in die Regeldatei des Projekts – dann entfällt sogar das tägliche Einfügen.

Wo das in der Praxis wirkt (drei Fälle)

1. Massencheck von Blogs und Unterlagen Sagst du nur „korrigier den Artikel”, schreibt die KI Text, Bildpfade und Links in einem Aufwasch um. Trennst du im Ledger „Tippfehler im Text = Stufe 1, Live-Schaltung = Stufe 2”, überlässt du den Text der KI, behältst aber den Veröffentlichen-Knopf in der eigenen Hand. Lässt du dir Diff und Build-Ergebnis als Nachweis zeigen, wird die nächtliche Durchsicht spürbar leichter.

2. Anfragen sortieren Eingehende Anfragen zu lesen und zu klassifizieren ist Stufe 0 und darf an die KI. Aber der Eintrag ins Kundenregister ist Stufe 3. Selbst wenn die KI urteilt „daraus wird vielleicht ein Geschäft”, bleibt das Schreiben in die Produktionsdatenbank ausgesetzt, bis die zuständige Person den Knopf drückt. Erzwingst du das per Ledger, verschwindet der Unfall, fehlklassifizierte Kundinnen und Kunden eigenmächtig anzulegen.

3. Ein Durchatmen vor dem Deploy Die Live-Schaltung legst du immer auf Stufe 2. Nicht schon „fertig”, weil der lokale Build durchlief – stoppen, bis Live-URL, Überschrift und Rollback-Schritte geprüft sind. Auch mein „eigenmächtiges Aktualisieren von Abhängigkeiten” vom Anfang wäre, hätte ich Stufe 2 ausgewiesen, garantiert an der menschlichen Prüfung hängen geblieben.

Häufige Stolperstellen und ihre Behebung

Am häufigsten ist, dass man alles in einer einzigen Anfrage erledigen will und ein riesiges Diff erzeugt, das niemand mehr prüfen kann. Die Behebung ist simpel: Beschränke die Anfrage auf „ein Ergebnis pro Durchlauf”. Ein Artikel, ein PR, eine Stelle in der Konfiguration. Klein geschnitten liest du das Diff bis zum Ende durch.

Am zweithäufigsten ist, dass man schon den erfolgreichen lokalen Build als erledigt verbucht. Auf der Live-Site wird eine andere Seite oder die Startseite angezeigt, aber man sieht nur HTTP 200 und ist beruhigt. Trägst du in die Nachweis-Spalte „Live-URL und Überschrift prüfen” ein, bleibst du genau hier stehen.

Das Dritte ist, nicht festzuhalten, was man ausprobiert hat. Am nächsten Tag fängst du dieselbe Entscheidung von vorn an. Eine einzige Notiz-Zeile (siehe unten) reicht, und dein morgiges Ich zögert nicht. Willst du die Art, wie du Claude Code überhaupt um etwas bittest, anheben, lies ergänzend Prompt-Design in der Praxis – dann gelingt das Vermitteln des Rahmens eine Stufe besser.

Häufige Fragen

F. Sollte man die Freigabestufen feiner aufteilen? Am Anfang reichen vier Stufen vollkommen. Je mehr du hinzufügst, desto komplexer wird der Betrieb und desto eher hält sich am Ende niemand daran. Verzweige nachträglich nur an den Stellen, die sich im Betrieb als „zu grob” anfühlen.

F. Woran erkenne ich, ob etwas in Stufe 1 „rückgängig machbar” ist? An zwei Punkten: „Lässt es sich mit einem Git-Befehl zurückholen?” und „Wirkt es nach außen?”. Eine Dateiänderung lässt sich zurückholen, aber Deploy, Abrechnung, E-Mail-Versand und Löschen nicht. Im Zweifel auf Stufe 2 anheben.

F. Wer legt im Team die Stufe fest? Wer mit der Arbeit beginnt, erklärt sie morgens und legt vorab fest, wer ab Stufe 2 entscheidet. Ist die zuständige Person abwesend, machst du Stufe-3-Aufgaben an dem Tag schlicht nicht – das ist sicher.

F. Jedes Mal den Prompt einzufügen ist lästig. Sobald der Rahmen sich gefestigt hat, verschieb ihn in die Regeldatei des Projekts (CLAUDE.md). Die KI liest sie jedes Mal, also entfällt das Einfügen.

F. Taugt dieses Worksheet auch für Nicht-Entwickler? Ja. Auch ohne den Code auszuführen, ziehst du allein mit der Vier-Stufen-Tabelle und der Prompt-Vorlage die Linie. Für den Einsatz jenseits der Entwicklung hilft Claude Code für Nicht-Entwickler weiter.

Eine Notiz für die Übergabe

Hältst du die Entscheidung des Tages in einer Zeile fest, wiederholen dein morgiges Ich oder das Team nicht dasselbe Zögern. Kopier die folgende Form und füll sie aus.

- Datum: 2026-06-07
- Heutiges Ziel: Tippfehler und tote Links in einem Blogartikel korrigieren
- Heutiges Limit: Stufe 1 (bis zur rückgängig machbaren Änderung)
- Nachweis: Diff, Log von npm run build, Überschrift der Live-URL geprüft
- Wo der Mensch gestoppt hat: Abhängigkeiten (wegen Stufe 2 ausgesetzt)
- Übergabe für das nächste Mal: Abhängigkeiten an einem eigenen Tag gesammelt auf Stufe 2

Mit dieser Notiz ist auch die Prüfung nach der Veröffentlichung leichter. HTTP 200 allein genügt nicht – prüfe an der Live-URL, ob Überschrift, kanonische URL (canonical), Hero-Bild und der Anfang des Texts wirklich zu diesem Artikel gehören. Wird ein anderer Artikel oder die Startseite angezeigt, behandle es als nicht veröffentlicht und wiederhole Build und Deploy. Den offiziellen Grundgedanken zur Rechtevergabe kannst du auch in der offiziellen Anthropic-Dokumentation nachlesen.

Was beim Selbstversuch herauskam

Ich habe dieses Worksheet zwei Wochen lang auf meinen eigenen Blogbetrieb angewandt.

Am meisten gebracht hat, jeden Morgen den einen Satz „heute bis Stufe 1” einzufügen. Allein dadurch hat sich das „Erlauben?” pro Commit gefühlt mehr als halbiert. Sobald die KI über Stufe 2 hinaus wollte, blieb sie nach den Regeln der Vorlage brav stehen und fragte mich. Den Unfall vom Anfang – „plötzlich waren die Abhängigkeiten aktualisiert” – gab es seitdem null Mal.

Umgekehrt habe ich gelernt: Die Stufentabelle bringt nichts, wenn sie nur erstellt wird. Lasse ich den Ledger-Code tatsächlich laufen und bringe „die heutigen Aufgaben” auf den Bildschirm, bevor ich starte, steigt die Wahrscheinlichkeit, dass ich mich daran halte. Statt nach einer klügeren KI zu suchen, ziehe ich vorab einen Rahmen, in dem man auch beim Hinfallen wieder aufstehen kann. Unspektakulär, aber genau so überlasse ich der KI am stressfreisten etwas – das ist mein heutiges Fazit.

Willst du diese Linie aufs ganze Team oder den Produktionsbetrieb ausweiten, feilen wir in der Schulung und Beratung gemeinsam an einem konkreten Spuren-Design. Den Anfang machst du morgen früh, indem du den einen Satz „heute bis Stufe 1” einfügst.