Wie viel darf Claude Code allein? Die 4 Stufen sicherer Autonomie

Freitagabend bat ich Claude Code: „Reparier in den alten Blog-Artikeln nur die toten Links” und ging schlafen. Am nächsten Morgen schaute ich in die Commit-Historie – und 12 Artikel waren umgeschrieben. Die Links stimmten tatsächlich. Aber „nebenbei” hatte das Tool auch noch die Formulierungen in den Überschriften „geglättet” und dabei bewusst von mir stehen gelassene, ältere Wendungen überschrieben.

Zwei Stunden brauchte ich, um das zurückzudrehen. Warum macht ein eigentlich kluges Werkzeug solchen überflüssigen Unsinn? Die Antwort ist simpel: Ich hatte ihm nie gesagt, wie weit es gehen darf.

Es gibt auch das umgekehrte Problem. Aus Angst stellte ich danach alles so ein, dass es bei jeder einzelnen Zeile fragte: „Darf ich das ausführen?” Nach einer halben Stunde hatte ich vom Klicken auf „Freigeben” genug – am Ende war ich selbst schneller. Zu viel delegieren und einen Unfall bauen, oder zu viel bremsen und sich totklicken. Zwischen diesen beiden Extremen verirren sich die meisten Leute.

Dieser Artikel beendet das Verirren. Es geht um die „vier Stufen der Autonomie”: nur lesen lassen, ändern lassen, veröffentlichen lassen, und das, was nur ein Mensch anfasst. Wenn du diese vier Grenzen einmal zu Beginn ziehst, verschwinden fast alle Einzelentscheidungen.

Das Wichtigste in Kürze

• Teile die Aufgaben für Claude Code nach Gefährlichkeit in vier Stufen auf, dann fällt die Entscheidung leicht: nur lesen / reversible Änderung / veröffentlichen & deployen / nur für Menschen.
• Lege für jede Stufe genau einen „Beweis, dass es fertig ist” fest. Ein Diff erscheint, der Build läuft durch, die öffentliche URL stimmt, und so weiter.
• Löschen, Produktivdaten, Abrechnung und Force-Push werden nie automatisch – egal, wie routiniert du wirst. Diese Knöpfe drückt jedes Mal ein Mensch.
• Schreib die Stufen in eine einzige YAML-Datei neben deine CLAUDE.md, dann kann Claude Code selbst melden, „auf welcher Stufe es gerade ist”.
• Fang eine Stufe niedriger an als nötig und stufe nur die Operationen später hoch, die sich als sicher erwiesen haben. Andersherum nie.

Warum „Grenzen ziehen” wichtiger ist als „Klugheit”

Wer mit Claude Code scheitert, scheitert meist nicht an der Leistung des Modells, sondern daran, wie die Aufgabe abgeschlossen wird. Mir am Anfang ging es genauso. Die Anweisung selbst war nicht schlecht. Nur den Umfang „nur die Links” hatte ich ausschließlich in Worten übergeben. Eine Bitte in Worten ist wie eine mündliche Anweisung an einen Kollegen an einem hektischen Morgen – die Auslegung verschiebt sich schnell.

Genau hier hilft das Ziehen von Grenzen nach Gefährlichkeit. Lege das Erlaubte nicht über die „Formulierung der Bitte” fest, sondern über die „Stufe”. Dann kannst du jedes Mal, wenn Claude Code etwas tun will, abgleichen: „Welche Stufe ist diese Operation?” Aus einem Auslegungs-Hickhack über vages Deutsch wird eine mechanische Prüfung.

Dieser Gedanke ist nicht neu. Auch in einer Fabrik haben der Besucher, der nur zuschaut, der Monteur, der die Teile zusammensetzt, die Person am Versandknopf und die Person mit dem Tresorschlüssel von Anfang an getrennte Berechtigungen. Bei Claude Code ziehst du nur dieselben Linien.

Was in den vier Stufen steckt

Die vier Stufen, die ich tatsächlich nutze, sehen so aus. Zuerst das Gesamtbild als Tabelle.

Stufe	Was es darf	Beweis, dass es fertig ist
0 nur lesen	Dateistruktur erfassen, Risiken auflisten, Prüfbefehle vorschlagen	Die Abschlussnotiz enthält eine „Liste gelesener Dateien”
1 reversible Änderung	einen Artikel korrigieren, einen Test aktualisieren	Ein Diff erscheint und der Build läuft durch
2 veröffentlichen & deployen	Deploy nach dem Build, öffentliche URL prüfen	h1, kanonische URL, CTA und Rollback-Notiz liegen vor
3 nur für Menschen	(lässt Claude Code nicht machen)	—

In Stufe 3 fallen geheime Schlüssel, Abrechnung, Produktivdaten und Force-Push. Das wird nie automatisiert, egal wie routiniert man wird. Der Verlust bei einem Fehler steht in keinem Verhältnis zur gesparten Mühe.

Wichtig ist bei jeder Stufe, den „Beweis, dass es fertig ist” verbindlich festzulegen. Ohne Beweis weißt du nicht, ob wirklich alles erledigt ist, auch wenn Claude Code „Fertig” meldet. Ein Diff erscheint, der Build läuft durch, du öffnest die öffentliche URL und die h1 stimmt – solche maschinell prüfbaren Dinge wählst du als Beweis.

Was die KI übernimmt und was der Mensch entscheidet

Sobald die Grenzen klar sind, ergibt sich die Rollenverteilung von selbst.

Claude Code überlassen darfst du Arbeiten, die viele Handgriffe brauchen und deren Ergebnis sich maschinell prüfen lässt. Viele Dateien lesen und zusammenfassen, Artikel in einem festen Format korrigieren, Tests laufen lassen und das Log lesen. Darin ist es schneller und genauer als ein Mensch.

Der Mensch sollte unumkehrbare Entscheidungen und verlustreiche Operationen treffen. Darf dieser Artikel wirklich veröffentlicht werden? Darf diese alte Formulierung gelöscht werden? Dürfen diese Kundendaten überschrieben werden? Hier lässt du Claude Code zwar „vorschlagen”, aber „ausführen” tut der Mensch per Knopfdruck.

Im Zweifel gibt es nur ein Kriterium: „Lässt sich das im Fehlerfall in 10 Minuten zurückdrehen?” Wenn ja, ist es Stufe 1; wenn nein, Stufe 2 oder 3. Mein Unfall vom Anfang brauchte zwei Stunden zum Zurückdrehen – also war es in Wahrheit eine Aufgabe, die die Vorsicht von Stufe 2 verlangt hätte.

Kopierfertige Stufen-Definition

Lässt du die Stufen nur im Kopf, verwischt am Ende doch alles. Schreib sie in eine YAML-Datei und leg sie als autonomy.yml direkt ins Projektverzeichnis. Lässt du sie aus der CLAUDE.md referenzieren, fängt Claude Code von selbst an zu melden: „Ich bin gerade auf Stufe 1, also veröffentliche ich nicht.”

# autonomy.yml — die an Claude Code übergebene Autonomie-Grenze
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["Dateistruktur erfassen", "Risiken auflisten", "Prüfbefehle vorschlagen"]
    proof: "Die Abschlussnotiz enthält eine Liste gelesener Dateien"
  level_1_reversible_edit:
    allowed: ["einen Artikel korrigieren", "einen Test aktualisieren"]
    proof: "git diff erscheint und der build läuft durch"
  level_2_publish_or_deploy:
    allowed: ["nach dem build deployen", "öffentliche URL prüfen"]
    proof: "h1, kanonische URL, CTA und Rollback-Notiz liegen vor"
  level_3_owner_only:
    allowed: []
    examples: ["geheime Schlüssel", "Abrechnung", "force push", "Kundendaten"]

In die CLAUDE.md reicht dieser eine Satz:

Lies vor der Arbeit autonomy.yml und erkläre zuerst, auf welcher Stufe die heutige Aufgabe liegt.
Operationen ab Stufe 2 nicht ausführen, sondern auf die Freigabe durch einen Menschen warten.

Prüfskript, das die Stufe maschinell kontrolliert

Nur ankündigen lassen beruhigt mich nicht, deshalb überwache ich maschinell, „ob eine Operation der Stufe 2 (Veröffentlichen) ohne Beweis durchgeführt wurde”. Das Skript unten holt nach dem Deploy die öffentliche URL und prüft, ob die h1 nicht leer ist und ob die kanonische URL auf den eigenen Slug zeigt. Ab Node.js 18 läuft es direkt.

// verify-publish.mjs — den "Beweis, dass es fertig ist" für Stufe 2 maschinell prüfen
// Aufruf: node verify-publish.mjs https://claudecode-lab.com/blog/dein-slug

const url = process.argv[2];
if (!url) {
  console.error("Bitte die öffentliche URL als Argument übergeben");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: noch nicht veröffentlicht`);
  process.exit(1);
}

const html = await res.text();

// Existiert eine h1 mit Inhalt?
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// Zeigt die kanonische URL auf diese Seite selbst?
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`h1 vorhanden:      ${hasH1 ? "OK" : "NG"}`);
console.log(`kanonische URL:    ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("Beweis für Stufe 2 vollständig. Veröffentlichung gilt als abgeschlossen.");
} else {
  console.error("Beweis unvollständig. Bitte noch nicht als fertig markieren.");
  process.exit(1);
}

Wer nur HTTP 200 für Erfolg hält, merkt nicht, wenn ein Fallback der Startseite oder ein alter Artikel ausgeliefert wird. Erst wenn du auch h1 und kanonische URL prüfst, kannst du sagen: „Diese Stufe ist fertig.”

In diesen Situationen wirkt es (drei Beispiele)

1. Direkt nach dem Einstieg in ein neues Repository Lässt du ohne Kenntnis von Struktur und Befehlen sofort bearbeiten, gehen leicht Konfigurationsdateien kaputt. Erlaube anfangs nur Stufe 0 und lass dir Dateiaufbau, verfügbare Befehle und gefährliche Stellen melden. Erst wenn die Landkarte steht, gehst du auf Stufe 1.

2. Tippfehler in einem Artikel korrigieren Dafür reicht Stufe 1. Erscheint ein Diff und läuft der Build durch, ist der Beweis vollständig. Mein Unfall vom Anfang wäre vermeidbar gewesen, hätte ich hier den Umfang notiert: „Nur Tippfehler korrigieren. Formulierungen nicht ändern.” Eine Vorlage für die Bitte an Claude Code sieht so aus.

Arbeite auf Stufe 1.
Ziel: nur offensichtliche Tippfehler in content/blog/foo.mdx
Nicht tun: Überschriften umformulieren, Stil ändern, andere Dateien bearbeiten
Zeig am Ende git diff und prüfe selbst, ob die Änderungen nur Tippfehler betreffen.

3. Kurz vor der Produktiv-Veröffentlichung Auf Stufe 2 lässt du unbedingt prüfen: läuft der Build, sind die Umgebungsvariablen vollständig, entspricht der Diff der Erwartung, gibt es eine Rollback-Anleitung. Lässt du am Ende das Prüfskript von oben laufen, kontrollierst du sogar den Inhalt der öffentlichen URL.

Drei Fehler, die ich gebaut habe

Ehrlich gesagt habe ich bis zu diesen vier Stufen mehrfach Unfälle gebaut.

Der erste: eine Stufe auf einmal übersprungen. Ich ließ Stufe 0 aus und sofort auf Stufe 1 massenhaft bearbeiten – heraus kam ein so großer Diff, dass ich ihn nicht mehr prüfen konnte und selbst nicht mehr wusste, was richtig war. Heute steige ich immer von 0 an der Reihe nach hoch.

Der zweite: den lokalen Build allein als „fertig” gewertet. Lokal lief es durch, also veröffentlichte ich. Doch in der Produktion wurde eine alte Seite angezeigt, und ich merkte es einen halben Tag lang nicht. Seitdem markiere ich nichts als fertig, bevor ich h1 und kanonische URL der öffentlichen URL gesehen habe.

Der dritte: die Freigabe allein meinen eigenen Augen überlassen. „Ich prüfe am Ende selbst” bricht an einem müden Abend garantiert zusammen. Seit ich maschinell prüfbare Checks wie Zeichenzahl, tote Links und Typfehler als „Beweis” der Stufe einbaue, sind die nächtlichen Versehen drastisch gesunken.

So fängst du an

Strebe nicht sofort den vollautomatischen, klugen Agenten an. Wähl eine kleine Aufgabe, die sich im Fehlerfall zurückdrehen lässt. Tippfehler im Entwurf prüfen, eine erste Review einer Änderung, die Kontrolle vor der Staging-Veröffentlichung. So viel ist genau richtig.

Die Reihenfolge ist immer dieselbe: ① den Lese-Umfang eng festlegen → ② das Ergebnis klar definieren → ③ die Prüfung möglichst von Befehlen erledigen lassen → ④ gefährliche Operationen (Löschen, Produktivdaten, Abrechnung, Force-Push) anfangs ausnahmslos auf „Mensch fragen” stellen. Nur die als sicher erprobten Operationen stufst du später jeweils um eine Stufe hoch. Eine Herabstufung in die Gegenrichtung gibt es nicht.

Wenn du bei den Feineinstellungen der Berechtigungen hängst, schau vorher in Einstieg in Claude Code. Wie du die Stufenregeln in die CLAUDE.md schreibst, zeigt So schreibst du eine gute CLAUDE.md – dann fallen diese vier Stufen direkt in deine Konfiguration. Wenn Nicht-Techniker im Team mitarbeiten sollen, lies ergänzend Claude Code für Nicht-Entwickler.

Häufige Fragen

F. Muss ich die Stufeneinteilung jedes Mal von Hand einstellen? Nein. Erstellst du einmal eine autonomy.yml und lässt sie aus der CLAUDE.md referenzieren, erklärt Claude Code danach selbst: „Ich bin gerade auf Stufe 1.” Eingerichtet wird nur ein einziges Mal.

F. Darf ich bis zur „Veröffentlichung” auf Stufe 2 automatisieren? Wenn sich der Beweis maschinell erbringen lässt, darfst du das nach etwas Routine automatisieren. Bau aber unbedingt einen Mechanismus ein, der den Inhalt der öffentlichen URL prüft – so wie das Prüfskript oben. Nur HTTP 200 zu glauben ist am gefährlichsten.

F. Wie erkenne ich Operationen, die in Stufe 3 gehören? Frag dich: „Reicht im Fehlerfall eine Entschuldigung, oder droht Schadenersatz?” Kundendaten überschreiben, Abrechnung, Produktiv-Löschungen gehören zu Letzterem – also Stufe 3. Auch mit Routine nie automatisch.

F. Brauchen auch kleine Teams diese Grenzen? Je weniger Leute, desto stärker wirkt es sogar. Wer freigegeben hat, verwischt schnell – mit einer geteilten Stufentabelle sieht jeder auf einen Blick: „Wer gibt diese Operation frei?”

F. Reichen geschickte Prompts nicht, statt Stufen einzuteilen? Prompts schwanken in der Auslegung. Die Fähigkeit, gute Bitten zu formulieren, baust du separat mit Prompt Engineering in der Praxis aus. Die Stufeneinteilung ist das „Sicherheitsnetz, das nicht von der Formulierungskunst abhängt”. Beides zusammen ist am stärksten.

Was beim Ausprobieren herauskam

Seit ich diese vier Stufen in den Betrieb meines Blogs eingebaut habe, sind Unfälle der Art „es wurde mehr gemacht als gebeten” wie zu Beginn auf null gesunken. Bestätigt habe ich zwei Dinge.

Erstens: Sobald ich die autonomy.yml aus der CLAUDE.md referenzieren ließ, fing Claude Code an, vor der Arbeit von selbst zu erklären: „Diesmal Stufe 1, also keine Veröffentlichung.” Übergibst du die Grenze nicht in Worten, sondern als Stufe, schwankt die Auslegung nicht – das habe ich deutlich gespürt.

Zweitens: Seit ich verify-publish.mjs nach jeder Veröffentlichung laufen lasse, erkenne ich das Phänomen „eine alte Seite steht in der Produktion”, das ich früher einen halben Tag übersah, direkt nach der Veröffentlichung. Schon der Blick auf h1 und kanonische URL stopft das Schlupfloch von HTTP 200.

Statt nach dem klügsten Modell zu suchen, lege zuerst die Stufen fest, auf denen du dir beim Stolpern nicht wehtust. Das wirkt wie ein Umweg, ist aber nach meiner heutigen Erfahrung der schnellste Weg. Wenn ihr im Team die Berechtigungsregeln für Claude Code ordnen wollt, können wir in der Schulung & Beratung gemeinsam die Grenzen entwerfen. Die offiziellen Berechtigungseinstellungen findest du außerdem in der Anthropic-Dokumentation.