Nicht blind einführen — Claude Code ist kein Autocomplete, sondern vollständige Code-Berechtigungsübergabe

Der häufigste Fehler: Claude Code als „noch ein AI-Autocomplete“ zu behandeln — CLI installieren, API-Key binden, Funktion shippen. Dieselbe Illusion wie ein self-hosted runner als „macos-latest ohne Queue“: man sieht Geschwindigkeit, nicht Grenzen.

Claude Code ist ein Terminal-Agent: er schlägt nicht nur Code vor — er kann Shell ausführen, viele Dateien bearbeiten, Env-Vars lesen, MCP-Tools aufrufen und Tests bis grün loopen. Default-Vertrauen im Hauptrepo bedeutet nicht ein Plugin mehr, sondern ein ganzes Paket Code- und Ausführungsrechte.

Dies ist Cloud Mac AI Stack · L3 Entscheidungseinstieg (L3-Q01): nach L0-Fundament und L1 Fact-Schicht (L1 ①②③ zuerst) beantworten wir wann ein Agent offiziell in den Dev-Workflow gehört. L3-Serientabelle unter § L3-Serie; vertikal L0, horizontal L4–L5 unter § Stack-Links. Workstation-Benchmark (L3 ③) und vs Cursor (L3 ②) sind anderes Terrain — dieser Artikel ist nur Entscheidung und Berechtigungen.

Was Sie wirklich übergeben: eine Berechtigungskarte

Die meisten Teams fixieren auf „wie smart ist das Modell“ und übersehen, was der Agent auf Disk und in Prozessen tun kann. Nutzen Sie die Tabelle beim Onboarding — sechs Berechtigungstypen; vor Go-live jeden prüfen.

Die Frage ist nie „sollen wir AI zum Coden nutzen“, sondern: wollen Sie alle sechs Zeilen oben default an einen halbautonomen Prozess delegieren? Bei Zögern: kein „alle installieren default Claude Code“, sondern phasenweise Einführung unten.

Es ist weder Copilot noch IDE-Plugin

Beifahrer (Copilot / Cursor Tab): Sie fahren im Editor; AI vervollständigt oder editiert die aktuelle Datei — kleine Diffs, schnelles Feedback. Chauffeur (Claude Code Agent): Sie nennen ein Ziel; der Agent plant Steps, öffnet Shell, editiert viele Dateien, retry bei Fehler — Sie reviewen Ergebnisse, nicht das Steuer.

Nicht welches „besser“ ist (siehe Claude Code vs Cursor), sondern Aufgabentyp: tägliche Vervollständigung bleibt in der IDE; modulübergreifende Migrationen, große Test–Fix-Loops und delegierte GitHub Actions CI-Edits gehören zum Agent. Agent als Copilot ist oft langsam und schwer auditierbar; Copilot als Agent löst keine „47 files changed“-Delegationen.

Blind einführen vs. formelles Onboarding · Vergleich

„Blind einführen“ in Teams sieht oft so aus: Lead liebt es, alle bekommen Max, Hauptrepo läuft CLI mit Default-Vertrauen. Formelles Onboarding schreibt den Agent in Engineering-Policy: Grenzen, Audit, CI-Split.

Drei Gates: vor formellem Onboarding Pflicht

Die drei Gates unten sind die Mindestschwelle für formelles Onboarding — nicht Perfektion, aber kein „volle Berechtigungsübergabe bei null Audit“.

Gate ① · Disk- und CI-Grenze (L1)

Teilen Agent und GitHub Runner nicht bereinigbare globale Verzeichnisse? Liegen Prod-Signing, .env und breite Caches im selben Home wie Agent-Sessions? Wenn L1 ③ one job, one workspace fehlt, Fact-Schicht fixen, bevor Diff weit aufgeht (L1-Serie unter L1-Serie).

Gate ② · Tool- und Secret-Grenze (L4)

Ist MCP „alles verbinden“? Überlappt Agent-PAT mit CI und privatem GitHub? Formelles Onboarding braucht getrennte Tokens, minimale Scopes, Rotation plus teamlesbares L4 MCP-Setup und Least-Privilege-Checkliste.

Gate ③ · Menschen- und Prozessgrenze (Team)

Wer darf Agent-Output direkt mergen? Hat ein großes Repo L4 CodeGraph oder Äquivalent gegen „verpasste Datei“? Wenn die Antwort „wer am schnellsten merged“ ist, verstärkt der Agent nur bestehende Prozessschulden.

Wann formal onboarden · wann warten

Was L3 im Stack verantwortet: Diff, nicht Fact

Serien-Slogan (L1–L3): Claude Code produziert Diff; GitHub Runner produziert Fact. Dieser L3-Einstieg fragt: wann geben Sie Diff-Produktion an einen Agent ab? Fact (CI grün, Signing ok) bleibt auf isolierten Runnern — „Tests bestanden“ vom Agent ist kein Release.

L2 Inference: Ollama für Entwürfe und offline; L3 Claude Code für delegierte Ausführung und Diff — kann auf einem Host mit getrennten Rechten koexistieren. L4 Context: MCP Hub und Least Privilege regeln Tools. L5 Workflow: OpenHands eher Orchestrierung; Claude Code eher Terminal-Tiefe — Onboarding-Gates gelten für beide.

Phasenweise Einführung (~30 % des Workflows)

Nach klarer Entscheidung in drei Phasen landen — nicht Tag eins „alle auf Max + Prod-Repo weit offen“:

1. Phase A · Read-only-Sandbox (1–3 Tage): Fork oder Kopie, kein Push; beobachten, wie Agent Tasks zerlegt und welche Shell er nutzt. Ziel: Berechtigungskarte spüren.
2. Phase B · überwachtes Schreiben (1–2 Wochen): Hauptrepo Read-only-Clone in separatem Verzeichnis oder nur Branch; jedes Merge braucht Human Review; MCP nur essenzielle Tools.
3. Phase C · formale Diff-Schicht: feste Trennung mit L1 Runner; CLAUDE.md, Token-Rotation, workspace-Isolation im Runbook; optional L1 ④ OpenClaw-Pipeline-Triggerkette.

# Agent-Onboarding-Gates (Phase B)
1. Repo-Root braucht CLAUDE.md (erlaubte/verbotene Pfade, Testbefehle)
2. Agent nutzt dediziertes PAT, Scope ≤ aktuelle Aufgabe; nie gleich wie CI-Secrets
3. Einzeldelegation >15 Dateiänderungen → zweiter Reviewer Pflicht
4. Vor Merge muss derselbe Testbefehl lokal oder auf Runner grün sein
5. Anderer macOS-User oder Cloud-Mac-Node als Runner (empfohlen)

Hardwarewahl (Mac mini kaufen vs. Cloud Mac mieten) ist out of scope — das ist die Workstation-Benchmark-Story. Dieser Einstieg sagt nur: wenn Berechtigungen und Prozess die Schwelle passieren, dann Daily Use besprechen.

L3-Serie · Aufteilung der Artikel

Dieser Artikel öffnet die L3 (Diff-Schicht)-Entscheidungslinie: ob Berechtigungen an einen Agent gehen, dann Toolvergleich und Praxis. Tabelle der Reihe nach; vertikal zurück zu L0–L2, horizontal zu L4–L5 unter § Stack-Links.

Stack-Schicht-Links · vertikaler Einstieg

Stack-Vertikallinks (ein Einstieg pro Schicht; neben L1-Serie lesen):

• L0 · Fundament: Mac mini vs. Cloud Mac · Cloud-AI-Workstation
• L1 · Fact: Runner-Ausführungsengine · CI-Queue · workspace-Isolation · OpenClaw-Pipeline
• L2 · Inference: Ollama Private Inference · parallele Planung mit Runner
• L3 · Diff: ① dieser Artikel · Onboarding-Entscheidung · vs Cursor · Workstation-Benchmark
• L4 · Context: MCP Triple-Connect Hub · Least-Privilege-Exposition · MCP-Setup · CodeGraph und verpasste Edits
• L5 · Workflow: OpenHands Agent-Plattform

Nach diesem L3-Einstieg, wenn Gates passieren, folgt meist L3 ③ Workstation-Benchmark (Hardware und Abrechnung); bei IDE-Wahl zuerst L3 ② vs Cursor. L6 End-to-End-Karte geplant.

FAQ

Wie unterscheidet sich Claude Code von Cursor-Autocomplete?
Cursor ist ein In-Editor-Copilot — Änderungen sind meist zeilenweise sichtbar. Claude Code ist ein Terminal-Agent mit Shell, vielen Dateien und Test-Loops — er übergibt Ausführung an einen halbautonomen Prozess.

Brauchen Solo-Devs alle drei Gates?
Vereinfachen geht, aber getrennte Tokens, getrennte Verzeichnisse, große Diffs reviewen bleibt. Privates Repo ≠ null Risiko — Löschungen und Secret-Leaks passieren trotzdem.

Bedeutet formelles Onboarding IDE-Ersatz?
Nein. Üblich: IDE für Features, Agent für Delegationen. Dieser Artikel beantwortet, wann Agent in den Prozess geschrieben wird, nicht wann VS Code wegfällt.

Bezug zu L1 Runner-Security?
L1 ③ workspace-Isolation regelt CI-Disk-Grenzen; dieser Artikel (L3 ①) regelt wer Agent auf Prod-Repos laufen darf. Erst L1, dann L3 weit. Stack-Einstieg unter § Stack-Links.

Cloud Mac oder lokale Maschine zum Testen?
Phasen A/B auf L0 Cloud Mac isoliert testen ist oft günstiger — chaotische Umgebung resetten; nach Daily-Use-Bestätigung dedizierte Hardware. Siehe L3 ③ Workstation-Benchmark.