Rolle · Entwicklung & ITLernweg

Entwickler & IT

Claude Code im Terminal, Agenten über die API, MCP-Anbindung – vom ersten Prompt bis zum System, das im Betrieb trägt.

Warum Claude für deine Rolle?

Einordnung

Die meisten Guides dieser Academy sind für dich geschrieben – Claude Code, Hooks, Subagents, MCP, Headless-Betrieb. Was bisher fehlte, war der rote Faden: In welcher Reihenfolge lohnt sich das, und wo hört der Prototyp auf und fängt das Produkt an?

Dieser Track führt vom Terminal zum Betrieb: Claude Code sauber aufsetzen, Projektwissen in einer CLAUDE.md verankern, Permissions bewusst konfigurieren, Arbeit an Subagents delegieren, wiederkehrende Abläufe als Skill festschreiben – und am Ende über die API eigene Agenten bauen, die nicht nur in der Demo funktionieren.

Der wichtigste Unterschied zu anderen Rollen: Du prüfst Claudes Arbeit nicht durch Lesen, sondern durch Ausführen. Tests, Diffs und CI sind deine Review-Instanz. Das macht dich schneller als jede andere Rolle – und macht ungeprüftes Übernehmen umso gefährlicher.

Claude Code arbeitet mit deinen echten Dateien und Rechten. Vor dem ersten Lauf in einem fremden Repository: Permissions bewusst setzen, nicht pauschal alles erlauben. Zugangsdaten gehören nie in eine CLAUDE.md – sie wird bei jeder Session mitgelesen. In CI-Läufen ohne Rückfragen gilt das doppelt: Was dort erlaubt ist, passiert ohne Nachfrage.

Dein Lernweg

Schritt für Schritt

01

Claude Code CLI & Konfiguration →
Das Grundwerkzeug: Session starten, Flags, In-Session-Befehle, Permissions und Kontext-Management.

Befehle, Flags und Einstellungen – alles, was du für den produktiven Alltag mit Claude Code brauchst.
02

CLAUDE.md schreiben →
Projektwissen einmal verankern statt in jedem Prompt wiederholen – Konventionen, Build-Befehle, Architektur.

Die Konfigurationsdatei für Claude Code – Projektstruktur, Konventionen und Regeln in einer Datei.
03

Plan Mode nutzen →
Bei unbekannten Codebasen erst verstehen lassen, dann ändern. Spart die teuren Fehlgriffe im fremden Code.

Erst analysieren, dann umsetzen – wie du Claude Code dazu bringst, vor dem Coden nachzudenken.
04

Git-Workflow mit Claude Code →
Commits, Branches und PRs aus der Session heraus – mit sauberen, nachvollziehbaren Diffs.

Commits, Branches und Pull Requests – alles in natürlicher Sprache, direkt aus dem Terminal.
05

Subagents in Claude Code →
Recherche und Suche auslagern, damit der Hauptkontext für die eigentliche Aufgabe frei bleibt.

Spezialisierte Helfer mit eigenem Context, eigenen Tools und eigenem System-Prompt – für Side-Tasks, die das Hauptgespräch zumüllen würden.
06

Custom Skills erstellen →
Wiederkehrende Abläufe als Skill festschreiben – einmal formuliert, im ganzen Team nutzbar.

Wiederverwendbare Agent Skills, die Claude bei passenden Aufgaben automatisch lädt – als SKILL.md mit YAML-Frontmatter.
07

MCP-Server konfigurieren →
Claude an eure eigenen Systeme anbinden: Datenbanken, Ticketsysteme, interne APIs.

Claude mit externen Tools verbinden – Dateisysteme, Datenbanken und APIs über das Model Context Protocol.
08

Hooks einrichten in Claude Code →
Prüfungen erzwingen, statt auf Disziplin zu hoffen – Formatierung, Tests und Freigaben laufen automatisch mit.

Deterministische Shell-Befehle, die an festgelegten Lifecycle-Events feuern – für Security-Gates, Auto-Format, Audit-Logs und mehr.
09

Die erste Claude-API-Anfrage →
Der Einstieg in die API, wenn das Terminal nicht mehr reicht und etwas dauerhaft laufen soll.

Vom API-Key zur ersten Antwort: Wie du Claude per Python-SDK ansprichst – Messages-Endpoint, System-Prompt, Modellwahl und das Auslesen der Antwort.
10

Tool Use: Claude eigene Werkzeuge geben →
Eigene Werkzeuge definieren und den Tool-Loop verstehen – die Grundlage jedes Agenten.

Claude entscheidet selbst, wann er eine von dir definierte Funktion aufruft – Wetter-API, Datenbank, Rechner. Wie der Round-Trip funktioniert und wann er sich lohnt.
11

Eigene Agenten mit der API bauen →
Der Schritt vom interaktiven Werkzeug zum eigenen Agenten mit Tool-Loop und Fehlerbehandlung.

Wann sich ein Agent lohnt und wie der Agent-Loop funktioniert – vom manuellen Tool-Loop über den SDK-Tool-Runner bis zur Abgrenzung von Managed Agents.
12

Kosten senken: Caching, Modellwahl, Batch →
Was im Dauerbetrieb die Rechnung bestimmt: Caching, Modellwahl und Effort bewusst steuern.

Vier Hebel, um API-Kosten drastisch zu senken – das richtige Modell, Prompt Caching, die Batch API und bewusst gesetzte Token-Grenzen.

Was du damit machst

Konkrete Anwendungen

Legacy-Code verstehen, bevor du ihn anfasst

code

Plan Mode auf ein fremdes Modul ansetzen: Claude liest sich ein, zeichnet die Abhängigkeiten nach und schlägt einen Änderungsweg vor – bevor eine einzige Zeile geschrieben wird. Der Plan ist dein Prüfpunkt, nicht der fertige Code.

Root Cause statt Symptom

code

Fehlermeldung, Stacktrace und reproduzierbaren Fall übergeben, dann auf der Ursache bestehen: „Erkläre erst, warum es fehlschlägt, und schlage dann eine Korrektur vor." Verhindert Patches, die den Test grün machen und den Fehler behalten.

Review-Runde vor dem Pull Request

code

Den eigenen Diff gegenlesen lassen – auf Fehlerbehandlung, Randfälle und Testlücken. Als Subagent gestartet, damit der Hauptkontext unberührt bleibt.

Wiederkehrende Aufgaben im CI

code

Headless-Modus für Abläufe ohne Rückfragen: Changelog aus Commits erzeugen, Doku nach API-Änderungen nachziehen, Abhängigkeiten prüfen. Permissions vorher explizit setzen, sonst scheitert der Lauf still.

Eigener Agent über die API

api

Tool-Definitionen, Tool-Loop, Fehlerbehandlung und Kostensteuerung über Effort und Prompt Caching – der Weg vom Skript zum System, das dauerhaft läuft.

Spezialisierte Lernfäden

Mini-Workflows für konkrete Aufgaben

01

Neues Repository übernehmen

Du steigst in eine fremde Codebasis ein und sollst dort produktiv werden, ohne dich wochenlang einzulesen.

1

Mit Plan Mode einlesen

Shift+Tab in den Plan Mode, dann: „Verschaffe mir einen Überblick: Einstiegspunkte, Datenfluss, Build- und Testbefehle." Claude liest, ändert aber nichts.
→ Plan Mode nutzen
2

Erkenntnisse in die CLAUDE.md

Was du gerade gelernt hast, gehört ins Projektgedächtnis: Konventionen, Testbefehl, Ordnerstruktur, Fallstricke. Danach muss es nie wieder erklärt werden.
→ CLAUDE.md schreiben
3

Permissions festlegen

Lesen und Tests laufen lassen dauerhaft erlauben, Schreiboperationen zunächst mit Rückfrage. Das nimmt Tempo auf, ohne die Kontrolle abzugeben.
→ Claude Code CLI & Konfiguration
4

Erster echter Handgriff

Eine kleine, klar umrissene Änderung mit Test. So prüfst du gleichzeitig die Codebasis und deine Konfiguration.

02

Bug mit unklarer Ursache

Ein Fehler tritt auf, die naheliegende Erklärung stimmt nicht, und der schnelle Patch würde ihn nur verstecken.

1

Reproduktion zuerst

Erst einen Fall, der zuverlässig fehlschlägt – ohne ihn diskutiert ihr über Vermutungen. Am besten als Test, dann ist die Korrektur später beweisbar.
2

Auf der Ursache bestehen

Formuliere ausdrücklich: „Erkläre die Ursache, bevor du etwas änderst." Ohne diese Aufforderung liefern Modelle gern die schnellste Symptomkorrektur.
3

Recherche auslagern

Die Suche nach Aufrufern und ähnlichen Stellen an einen Subagent geben – der Hauptkontext bleibt für die Analyse frei.
→ Subagents in Claude Code
4

Test zuerst rot sehen

Der Test muss erst fehlschlagen, sonst weißt du nicht, ob er den Fehler überhaupt fängt. Danach die Korrektur.

03

Ablauf im CI automatisieren

Eine wiederkehrende Aufgabe soll ohne dich laufen – nachts, im Pipeline-Schritt, ohne Rückfragen.

1

Interaktiv erproben

Erst von Hand durchspielen, bis der Ablauf zuverlässig sitzt. Was interaktiv wackelt, wird headless nicht stabiler.
2

Als Skill festschreiben

Den erprobten Ablauf in einen Skill gießen – dann ist er versioniert, teilbar und nicht an deinen Prompt-Stil gebunden.
→ Custom Skills erstellen
3

Permissions explizit setzen

Im Headless-Modus gibt es keine Rückfrage. Fehlt eine Berechtigung, bricht der Lauf ab – oder tut still nichts.
→ Claude Code headless im CI/CD
4

Ergebnis prüfbar machen

Ausgabe in eine Datei oder einen PR schreiben, nicht nur ins Log. Was niemand sieht, prüft niemand.

Tipps & Tricks

Rollenspezifische Power-Hebel

▶

Die CLAUDE.md ist Code, kein Notizzettel

Sie wird bei jeder Session gelesen und gehört ins Repository – mit Review wie jede andere Datei. Kurz halten: Was drinsteht, kostet in jeder Session Kontext.

▶

Ausführen schlägt Lesen

Du musst generierten Code nicht Zeile für Zeile prüfen, wenn Tests ihn prüfen. Lass Claude den Test zuerst schreiben und rot sehen – dann ist die Korrektur belegt statt behauptet.

▶

Ein Subagent kostet nichts vom Hauptkontext

Suchen, die viele Dateien öffnen, gehören ausgelagert. Zurück kommt die Antwort, nicht der Dateiberg – der Hauptkontext bleibt für die eigentliche Aufgabe frei.

▶

Effort statt Modellwechsel

Vor dem Griff zum größeren Modell die Effort-Stufe erhöhen. Oft reicht das, und der Unterschied in der Rechnung ist erheblich.

▶

Skill statt langer Prompt

Wenn du denselben Prompt zum dritten Mal tippst, gehört er in einen Skill. Danach ist er im Team verfügbar und lässt sich versionieren.

Prompt-Packs

Copy & Paste – sofort einsetzbar

Entwicklung – sofort einsetzbar

Vier Prompts für die Situationen, in denen die Formulierung über das Ergebnis entscheidet. Jeder enthält eine eingebaute Sicherung gegen einen typischen Fehlgriff.

Codebasis erschließen

Verschaffe mir einen Überblick über dieses Repository, ohne etwas zu ändern:
1. Einstiegspunkte und wie eine Anfrage durch das System läuft
2. Build-, Test- und Lint-Befehle
3. Die drei Stellen, an denen Änderungen erfahrungsgemäß wehtun
4. Was dir unklar geblieben ist

Nenne zu jedem Punkt die Dateien, auf die du dich stützt.

Punkt 4 ist der wichtigste: Er gibt dem Modell einen erlaubten Weg, Unsicherheit zu benennen, statt sie mit einer plausiblen Vermutung zu füllen.

Fehlersuche mit Ursachenzwang

Dieser Test schlägt fehl: [Test + Fehlermeldung].

Gehe in dieser Reihenfolge vor:
1. Erkläre die Ursache und belege sie am Code
2. Nenne die Stelle, an der sie sitzt
3. Schlage erst dann eine Korrektur vor

Wenn du die Ursache nicht sicher benennen kannst, sage das und nenne, was dir dafür fehlt.

Die Reihenfolge ist die Sicherung. Ohne sie kommt zuerst ein Patch – und der behebt oft das Symptom an der Stelle, an der es sichtbar wurde, nicht dort, wo es entsteht.

Eigener Diff im Review

Prüfe die Änderungen in diesem Branch gegen main. Achte auf:
- Fehlerbehandlung: Was passiert im Fehlerfall, was wird stillschweigend verschluckt?
- Randfälle: leere Eingaben, Nebenläufigkeit, Zeitzonen
- Testlücken: Welche Änderung ist durch keinen Test abgedeckt?

Nenne nur, was du am Code belegen kannst. Keine Stilfragen.

„Nur was du belegen kannst" senkt die Zahl der plausibel klingenden, aber erfundenen Befunde deutlich. Der Ausschluss von Stilfragen hält die Liste bei dem, was zählt.

Ablauf für den Headless-Betrieb

Wir wollen [Aufgabe] künftig ohne Rückfragen im CI ausführen.

1. Welche Schritte laufen dabei ab?
2. Welche Berechtigungen braucht jeder Schritt?
3. Woran scheitert der Lauf, ohne dass es jemand merkt?
4. Wie wird das Ergebnis prüfbar – Datei, PR oder Kommentar?

Frage 3 zielt auf den häufigsten Betriebsfehler: Ein Automatismus, der still nichts tut, sieht monatelang aus wie einer, der funktioniert.

Häufige Fehler

Was du in dieser Rolle vermeiden solltest

✕

Pauschal alles erlauben

Wer beim ersten Prompt jede Berechtigung erteilt, um Ruhe zu haben, gibt sie dauerhaft ab – auch für den Lauf, in dem es darauf angekommen wäre. Lesen und Tests dauerhaft, Schreiben bewusst.

✕

Grüner Test als Beweis

Ein Test, den dieselbe Session mitgeschrieben hat und der nie rot war, beweist nichts. Er prüft womöglich das, was der Code tut – nicht das, was er tun soll.

✕

Geheimnisse in der CLAUDE.md

Tokens, Zugangsdaten und interne URLs landen dort schnell aus Bequemlichkeit. Die Datei wird jede Session gelesen und liegt im Repository – beides ist der falsche Ort dafür.

✕

Kontext volllaufen lassen

Wenn Antworten unvermittelt schlechter werden, ist meist der Kontext voll, nicht das Modell schwach. Rechtzeitig verdichten oder eine neue Session mit klarer Aufgabe starten.