Claude Code Best Practices für Entwickler-Teams

Sie erfahren, wie Sie kippende Prompts nach einem Modellwechsel systematisch diagnostizieren, woran Sie erkennen, dass Ihr Claude-Code-Agent schleichend schlechter wird, und welche sechs Funktionen Sie vermutlich ungenutzt lassen. Dieser Artikel ordnet Best Practices aus einer Anthropic-Konferenz für Entwickler-Teams und Tech-Leads in KMU ein und prüft sie gegen die offizielle Dokumentation.

Über die Quelle: Ausgewertet wird ein Video-Zusammenschnitt mehrerer Sessions der Anthropic-Konferenz „Code with Claude" London (19. Mai 2026). Sicher zuordenbar sind Margot van Laar, Applied AI Engineer bei Anthropic (Prompting-Talk), und Ivan Nardini, Developer Advocate bei Google Cloud (Partner-Talk). Alle Aussagen wurden gegen die offizielle Dokumentation geprüft (vollständige Quellenliste am Artikelende).

Zahlen aus Live-Demos sind Einzelbeobachtungen, keine Benchmarks – im Text mit „(Demo)" markiert; unbelegte Praxis-Tipps der Sprecher mit „(Sprecher-Heuristik)". Stand dieses Artikels: 13. Juli 2026. Zur Konferenzzeit aktuell waren Claude Opus 4.7 und Sonnet 4.6. Inzwischen verfügbar: Opus 4.8 und Claude Fable 5 (Zugang zum Fable-5-Promo).

Wie prompte ich Claude richtig?

Bauen Sie vor jedem Prompt-Fix zuerst eine Eval-Suite, die die Diagnose liefert. Ein Prompt, der seit Monaten in Produktion läuft und beim Modellwechsel plötzlich Testfälle reißen lässt, hat zwei mögliche Ursachen (Empfehlung von Margot van Laar im Prompting-Talk).

Entweder verhält sich das neue Modell nur anders – das lässt sich per Prompt korrigieren. Oder es ist für die Aufgabe schlicht weniger fähig – dann hilft kein Prompt-Tuning, sondern nur ein anderes Modell oder eine andere Architektur.

Ihre Eval-Suite braucht drei Fallgruppen:

Control-Cases – müssen immer bestehen, weil sie unstrittig sind.
Edge-Cases – Fälle, an denen das Modell nachweislich schon einmal gescheitert ist.
Kompetenzgrenz-Fälle – prüfen, ob das Modell erkennt, wann es eskalieren oder eine Anfrage klar ablehnen sollte, statt sich in Kompetenzen zu versteigen, die es nicht hat.

Räumen Sie den Prompt erst danach auf, statt sofort am Wortlaut zu feilen. Über Monate gewachsene Prompts sammeln Ballast: veraltete Patches für frühere Modellgenerationen, kopierte Website-Texte, sich widersprechende Anweisungen. Faustregel: Wenn Sie beim Lesen nicht mehr zwischen Rolle, Guideline, Policy, Tonalität und Daten unterscheiden können, kann es das Modell erst recht nicht.

Trennen Sie diese Elemente strukturell über XML-Tags – Rolle, Guidelines, Policy, Tonalität und Nutzdaten in eigenen Blöcken. Ergänzen Sie einen Output-Contract und, auf API-Ebene, Stop-Sequences, die das Antwortformat absichern.

Nennen Sie in Zielvorgaben immer beide Seiten einer Abwägung – nie nur eine. Im gezeigten Beispiel stand im Prompt eines Support-Bots sinngemäß: Eskalation an einen Menschen vermeiden, weil sie rund 8 US-Dollar kostet (Demo). Der Bot eskalierte danach auch dann nicht, wenn es nötig gewesen wäre, etwa bei einem echten Abrechnungsfehler.

Der Fix: beide Seiten benennen – Kosten der Eskalation und Kosten der Nicht-Eskalation (Rückerstattungen, Vertrauensverlust). Je fähiger ein Modell wird, desto konsequenter optimiert es auf das explizit genannte Ziel. Ein einseitig formuliertes Ziel wird also nicht toleranter interpretiert, sondern strenger befolgt – die vollständige Nennung beider Seiten wird mit stärkeren Modellen wichtiger, nicht unwichtiger.

Lösen Sie Aufgaben mit harten Nebenbedingungen über einen Generate-Evaluate-Repair-Loop statt über ein einzelnes großes Modell. In einer Live-Demo scheiterte ein einfacher Prompt an einer Wochenplan-Erstellung mit harten Nebenbedingungen (Personalverfügbarkeit, Mindestbesetzung) (Demo). Ein großes Modell mit erweitertem Thinking löste die Aufgabe zwar vollständig, brauchte dafür aber rund dreimal so viele Tokens und entsprechend mehr Latenz (Demo).

Am günstigsten und zuverlässigsten war ein Loop aus drei getrennten, simplen Prompts:

Generator erzeugt einen Entwurf.
Evaluator prüft ihn Regel für Regel, mit Beleg für jede Verletzung.
Repair behebt gezielt nur die gemeldeten Probleme.

Ergebnis: alle Testfälle gelöst, bei geringeren Kosten als das große Modell allein. Praktischer Nebeneffekt: Weiche, fallabhängige Zusatzregeln – etwa „Person A soll möglichst nicht mit Person B eingeteilt werden" – wandern einfach in den Evaluator-Prompt, statt eine harte Prüf-Funktion im Code anzupassen.

Warum wird mein Claude-Agent mit der Zeit schlechter?

Woran Sie erkennen, dass Ihr Agent aufgebläht ist:

Der System-Prompt ist über Monate gewachsen, und niemand traut sich mehr, etwas zu streichen.
Mehrere Ihrer Tools sind eigentlich verkappte Sub-Agenten mit eigener Logik.
Die Trefferquote in Ihren Evals sinkt schleichend, ohne dass eine einzelne Änderung dafür verantwortlich scheint.
Das Modell übernimmt Reasoning-Arbeit, für die es eigentlich ein Tool bräuchte.

Der erste Schritt: Lassen Sie Claude die eigenen Eval-Fehlschläge triagieren. In einem Konferenz-Workshop zur Agent-Dekomposition diente ein Inventar-Management-Agent als Fallstudie (Demo) – über Monate gewachsen auf rund 400 Zeilen System-Prompt und zwölf Tools, drei davon verkappte Sub-Agenten. Die Eval-Trefferquote war von 83 auf 62 Prozent gefallen.

Die Workshop-Teilnehmer stellten die Diagnose nicht selbst: Sie ließen Claude Code die eigenen Eval-Ergebnisse triagieren und Fehlschlag-Themen extrahieren. Ergebnis: Das Modell übernahm viel Reasoning-Arbeit, für die es eigentlich Tools gebraucht hätte, die Ausgabestruktur von Sub-Agenten war nicht sauber durchgesetzt, und der überlange System-Prompt führte zu Widersprüchen.

Bauen Sie den Agenten radikal schlanker, sobald die Diagnose steht. Der Umbau reduzierte ihn auf einen 15-Zeilen-Prompt, drei Tools (Bash, Read, Write), Skills für die fachliche Logik und genau einen verbleibenden Sub-Agenten für die Absatzprognose.

Eine Aufgabe, die zuvor über 200.000 Tokens verschlang, weil eine komplette CSV-Datei in den Kontext geladen wurde, wurde nach Umstellung auf Dateisystem-Zugriff und Code-Ausführung drastisch günstiger (Demo). Claude schreibt und führt dabei selbst Python aus, statt Rohdaten „im Kopf" zu verarbeiten. Das Muster dahinter: Agenten wachsen additiv, niemand entfernt etwas, irgendwann trägt der Prompt mehr Ballast als Substanz.

Der Hebel dagegen: Agent Skills. Anthropic definiert sie offiziell als „Packages" aus Instruktionen, Metadaten und Ressourcen. Zentrales Designprinzip ist progressive disclosure: Skills laden in drei Stufen – zuerst nur die Frontmatter (Name plus Kurzbeschreibung), dann bei Bedarf der Body, dann verlinkte Zusatzdateien.

Der Kontext bleibt schlank, solange eine Skill nicht gebraucht wird, und Skills lassen sich kombinieren (offizielle Doku). Wer selbst einen Agenten für das eigene Unternehmen bauen lassen will, findet bei uns unter KI-Agenten entwickeln lassen den Einstieg. Schlanker Prompt plus Skills statt monolithischem Systemprompt ist inzwischen ein zentraler Baustein professioneller Agent-Architektur.

Nutzen Sie für die Tool-Auswahl diese Reihenfolge (Sprecher-Heuristik): zuerst eingebaute Primitive (Bash, Dateisystem, Websuche), dann bei Bedarf Custom Tools, erst MCP-Server, wenn mehrere Clients oder Agenten dasselbe Tool-Set teilen sollen. Dokumentarisch untermauert ist die Grundidee: Anthropics Engineering-Blog empfiehlt, MCP-Server über Code auszuführen („Code execution with MCP") – das bringt Token- und Latenzvorteile gegenüber vielen MCP-Tool-Definitionen direkt im Kontext.

Setzen Sie Sub-Agenten gezielt ein, nicht standardmäßig. Sie lohnen sich vor allem bei echter Parallelisierung – viele Claude-Instanzen gleichzeitig auf ein Problem, etwa Codebasis-Exploration. Oder wenn Sie einen unbelasteten, „frischen" Kontext brauchen: einen Reviewer, der nicht derselbe Agent ist wie der Autor. Alles andere lässt sich meist einfacher direkt im Hauptagenten lösen, ergänzt um eine passende Skill.

Welche Claude-Code-Funktionen übersehen die meisten Teams?

Sechs kleinere, aber im Alltag wirksame Funktionen nutzen laut den Sprechern die wenigsten Teams. Ein schneller Check, was davon in Ihrem Workflow fehlt:

Esc+Esc / /rewind – Bei leerer Eingabezeile zweimal Escape drücken öffnet ein Rewind-Menü, mit dem Sie Code und/oder Konversation auf einen früheren Punkt zurücksetzen. Wenn ein Agent sich verrannt hat, ist das oft schneller als manuelles Aufräumen (Dokumentation).
CLAUDE.md-Hierarchie – Beim Start lädt Claude Code die CLAUDE.md aus dem aktuellen Arbeitsverzeichnis vollständig, dazu alle CLAUDE.md-Dateien in übergeordneten Verzeichnissen sowie die globale ~/.claude/CLAUDE.md. CLAUDE.md in Unterordnern wird dagegen nicht automatisch beim Start geladen, sondern erst bei Bedarf. Per @-Pfad-Syntax lassen sich zusätzlich weitere Dateien importieren. Empfohlener Inhalt: Build-Kommandos, Code-Style, wiederkehrende Workflows – Dinge, die sonst in jedem neuen Chat erneut erklärt werden müssten (Dokumentation).
/model und /config – Modell und Konfiguration lassen sich jederzeit direkt in der Session wechseln (Dokumentation), ohne neue Session für unterschiedlich anspruchsvolle Teilaufgaben.
Interleaved Thinking – nicht mehr „think hard" – Seit der Claude-4-Generation denkt Claude auch zwischen Tool-Aufrufen weiter, nicht nur einmal am Anfang einer Antwort (Anthropic nennt das interleaved thinking). Im Konferenzvideo wurde dafür noch „think hard" als Trigger genannt – das ist überholt. Laut aktueller Doku ist ausschließlich „ultrathink" das von Claude Code erkannte Trigger-Wort für erweitertes Thinking; andere Formulierungen wie „think hard" werden inzwischen als normaler Fließtext behandelt (Extended-Thinking-Doku, Model-Config-Doku).
Effort-Regler und Auto-Mode – Fünf offizielle Stufen – low, medium, high, xhigh, max – umschaltbar per /effort, separat dazu ein eigener /fast-Modus. Über Shift+Tab lassen sich die Permission-Modes durchschalten, darunter der Auto-Mode. Die Doku empfiehlt Auto-Mode konditional: dann, wenn Sie der Richtung der Aufgabe vertrauen, nicht pauschal (Model-Config-Doku, Interactive-Mode-Doku):

Modus / Stufe	Aufruf	Kurzcharakteristik
low	/effort low	Geringster Reasoning-Aufwand, für einfache und eindeutige Aufgaben
medium	/effort medium	Ausgewogenes Verhältnis von Tempo und Gründlichkeit
high	/effort high	Mehr Reasoning-Tiefe für komplexere Aufgaben
xhigh	/effort xhigh	Sehr hoher Reasoning-Aufwand für anspruchsvolle Multi-Step-Aufgaben
max	/effort max	Maximaler Reasoning-Aufwand, entsprechend höhere Latenz und Kosten
Fast-Modus	/fast	Eigener, von den Effort-Stufen getrennter Modus für besonders schnelle Antworten
Auto-Mode	Shift+Tab (Permission-Modes)	Laut Doku empfehlenswert, „wenn man der Richtung der Aufgabe vertraut"

Parallele Sessions über Git-Worktrees – keine Bastel-Lösung, sondern offiziell dokumentierte Best Practice: Mehrere Sessions arbeiten gleichzeitig an unterschiedlichen Branches, ohne sich ins Gehege zu kommen (Best-Practices-Doku). Für Teams ohne Parallel-Erfahrung ist das oft der einfachste Schritt zu mehr Durchsatz, ohne die Prompt- oder Agenten-Architektur anzufassen.

Was sind Routines, Memory Stores und Dreams?

Prüfen Sie diese fünf Plattform-Bausteine, wenn Sie Agenten dauerhaft und mit Gedächtnis betreiben wollen – nicht nur interaktiv in einer einzelnen Session. Sie bilden den zweiten großen Themenblock der Konferenz. Wichtig vorab: Alle hier genannten Bausteine tragen offiziell den Status Beta oder Research Preview – keine allgemein verfügbaren, fertig ausgereiften Produkte, sondern sich weiterentwickelnde Funktionen.

Die Basis bilden Claude Managed Agents (Beta): ein vorgefertigter Agent-Harness in verwalteter Infrastruktur, wahlweise Anthropics eigene Cloud-Sandbox oder self-hosted. Vorteil gegenüber einem selbstgebauten Agent-Loop: kein eigenes Sandboxing, keine eigene Skalierung oder Session-Verwaltung – Sie konzentrieren sich auf Tools, Skills, Sub-Agenten.

Darauf setzen Multi-agent sessions auf – im Video noch „callable agents" genannt, offiziell Multi-agent sessions. Ein Coordinator delegiert an bis zu 20 Agenten, jeder als eigener Session-Thread mit eingebauten Events und Observability. Das adressiert ein bekanntes Problem selbstgebauter Multi-Agent-Setups: Kommunikation zwischen Orchestrator und Sub-Agenten geht leicht verloren, Logging über mehrere Agenten ist mühsam.

Für Gedächtnis über einzelne Sessions hinaus gibt es Memory stores (Beta): persistenter, versionierter Speicher unter /mnt/memory/, wahlweise read_write oder read_only auf Dateisystem-Ebene. Jede Änderung erzeugt eine neue, unveränderliche Version als Audit-Trail, verwaltbar per API, CLI oder Console. Limits: acht Memory Stores pro Session, 2.000 Memories pro Store.

Weil solche Speicher mit der Zeit unübersichtlich werden, gibt es Dreams (Research Preview, Zugang auf Antrag). Ein asynchroner Job erzeugt aus einem Memory Store plus 1 bis 100 Session-Transkripten einen neuen, separaten Memory Store – verifiziert, dedupliziert, reorganisiert. Der Input-Store bleibt dabei unverändert.

Für proaktive, zeit- oder ereignisgesteuerte Läufe gibt es Routines (Research Preview): vollständige Claude-Code-Sessions auf Anthropics Cloud-Infrastruktur, ausgelöst per Zeitplan (mindestens einstündiges Intervall), API-Trigger (HTTP-POST mit Bearer-Token) oder GitHub-Events wie Pull-Requests/Releases inklusive Filtern. Angelegt per /schedule, verfügbar für Pro-, Max-, Team- und Enterprise-Konten.

Drei Team-Patterns aus dem Talk:

Ein Generator-Kritiker-Paar: Eine Routine öffnet Pull-Requests, eine zweite reviewt sie automatisch.
Ein Deploy-Verifier über CD-Webhook.
Eine wöchentliche automatisierte Backlog-Priorisierung.

Zur Einordnung dieser fünf Bausteine hier eine kompakte Übersicht:

Baustein	Offizieller Name	Status	Wofür
Verwalteter Agent-Harness	Claude Managed Agents	Beta	Vorgefertigte, gehostete Infrastruktur für Agenten (Cloud-Sandbox oder self-hosted)
Delegation an mehrere Agenten	Multi-agent sessions	Teil von Claude Managed Agents (Beta)	Coordinator delegiert an bis zu 20 Agenten mit eigenem Session-Thread und Observability
Persistenter Speicher	Memory stores	Beta	Versionierter Speicher unter /mnt/memory/, read_write oder read_only, mit Audit-Trail
Speicher-Konsolidierung	Dreams	Research Preview (Zugang auf Antrag)	Asynchrone Bereinigung/Reorganisation eines Memory Store in eine neue Kopie
Proaktive Sessions	Routines	Research Preview	Zeit-, API- oder GitHub-getriggerte Claude-Code-Sessions in der Cloud

Wie verifiziere ich, was Claude gebaut hat?

Bauen Sie Ihre Verifikation so, dass nicht nur Menschen, sondern auch Agenten sie zuverlässig prüfen können. Ein Anthropic-internes Team bereitet Frontend-Änderungen entsprechend auf – über Storybook-Fixtures, DOM-Datenattribute, die den Zustand einer Komponente maschinenlesbar nach außen spiegeln, sowie das offizielle Playwright MCP von Microsoft.

Zentraler Gedanke: drei gleichwertige Prüfpfade zum selben Ergebnis.

Ein Mensch klickt manuell durch die Anwendung.
Ein Agent steuert denselben Ablauf im Browser.
Derselbe Ablauf läuft headless in der CI.

Jeder Lauf wird aufgezeichnet und als Beleg abgelegt.

Bauen Sie Spezifikationen als klickbares HTML-Artefakt, nicht als langes Markdown-Dokument. Das ist informationsdichter und leichter zu beurteilen als Fließtext, den ohnehin kaum jemand vollständig liest.

Lassen Sie Claude Sie aktiv über den AskUserQuestion-Mechanismus interviewen – Claude stellt dabei strukturierte Rückfragen mit Auswahloptionen, statt sofort loszulegen –, statt selbst im Voraus alles ausformulieren zu müssen. Lassen Sie bei Design-Entscheidungen zusätzlich mehrere Varianten parallel generieren und visuell vergleichen.

Das ist praktikabler geworden, weil Opus 4.7 laut Anthropic deutlich mehr Bildauflösung verarbeitet als der Vorgänger: bis 2.576 Pixel Kantenlänge (rund 3,75 Megapixel, dreimal so viel wie Opus 4.6). Im Visual-Acuity-Benchmark erreicht das Modell 98,5 statt 54,5 Prozent bei Opus 4.6 (Anthropic).

Wer solche Verifikations- und Interview-Workflows im eigenen Unternehmen aufbauen will, findet in unserem KI-Zertifikat-Kurs eine praxisnahe Einführung in diese Arbeitsweise mit Claude.

Läuft Claude Code auch auf Google Cloud?

Ja – und für Unternehmen mit bestehender Google-Cloud-Infrastruktur mehr als eine Randnotiz. Im Partner-Talk zeigte Ivan Nardini, Developer Advocate bei Google Cloud, wie Claude Code auf Google Clouds Agent Platform läuft (früher Vertex AI). Drei Dinge ändern sich bei der Einrichtung:

Auth: Application Default Credentials statt API-Key, aktiviert über die Umgebungsvariable CLAUDE_CODE_USE_VERTEX=1 – kein separater Schlüssel zum Rotieren.
Abrechnung: Sie zahlen entweder nach Token-Verbrauch, oder Sie buchen Provisioned Throughput mit reservierter Kapazität für Produktivanwendungen.
Governance: Ihre Anfragen laufen über Ihr eigenes GCP-Projekt mit dessen IAM-Rechten, Quotas und Abrechnung; Data-Governance und Zero-Data-Retention dokumentiert Google separat (Claude-Code-Doku, Google-Cloud-Doku).

Dazu kommen globale und regionale Endpoints, je nach Verfügbarkeits- und Datenresidenz-Anforderung. Für Datenbankzugriff nannte der Talk MCP Toolbox for Databases – Open Source von Google (googleapis/mcp-toolbox) –, das Agenten an BigQuery und Looker anbindet.

Für KMU mit GCP-Bestandsinfrastruktur heißt das konkret: Sie betten einen Claude-Code-Agenten ohne zusätzliche Schlüsselverwaltung in Ihre bestehende Governance- und Kostenstruktur ein, statt eine parallele Abrechnungswelt aufzubauen.

Für Entscheider: Was bedeutet das für Entwickler-Teams?

Der Flaschenhals in der Softwareentwicklung wandert – weg vom Schreiben von Code, hin zu Review, Verifikation und Koordination (These aus dem Abschluss-Talk).

Wenn Coding nicht mehr der limitierende Faktor ist, verschieben sich die Engpässe dorthin, wo vorher Kapazität war: Wer prüft generierten Code? Wer stimmt zwischen parallel arbeitenden Teammitgliedern und Agenten ab? Wie wird Wissen weitergegeben, wenn jemand schon im ersten Monat produktiv mit Agenten arbeitet?

Anthropic-intern verschieben sich diese Punkte (ausdrücklich als interne Praxis gekennzeichnet, nicht als allgemeingültige Empfehlung):

Code-Review findet nicht mehr pauschal statt, sondern nach menschlichem Ermessen, abhängig vom Risiko der Änderung.
Planung erfolgt just-in-time statt als lange Roadmap, die ohnehin nach Monaten veraltet ist.
Technische Grundsatzdebatten laufen zunehmend über mehrere konkurrierende, tatsächlich generierte Pull-Requests statt am Whiteboard – entschieden wird am fertigen Code samt Auswirkung auf alle Aufrufer, nicht an der überzeugendsten Meeting-Argumentation.
Ein wöchentliches Tabellen-Status-Update ist einer eigenen Standup-Skill gewichen, die den Stand automatisiert zusammenträgt.

Verzichten Sie auf reines Code-Volumen als Erfolgskennzahl – „X Prozent des Codes von KI generiert" sagt wenig über Qualität oder Nutzen. Messen Sie stattdessen Onboarding-Zeit, PR-Zykluszeit bis zum Merge und den Anteil KI-gestützter Commits als Kontextsignal.

Diese Kennzahlen sind kein Selbstzweck, sondern zeigen, ob Review, CI und Deployment mit dem Durchsatz mithalten. Prüfen Sie deshalb zuerst, ob Ihr Review- und Verifikationsprozess mit dem Schritt hält, was Claude Code heute liefert – bevor Sie in mehr Agenten-Tooling investieren.

Häufige Fragen

Wie stelle ich alte Prompts auf ultrathink um?

Durchsuchen Sie Ihre Prompt-Bibliotheken und Vorlagen systematisch nach der Formulierung „think hard" und ersetzen Sie sie durch „ultrathink". Grund: Nur „ultrathink" ist laut aktueller Claude-Code-Dokumentation ein erkanntes Trigger-Wort für erweitertes Thinking – „think hard" wird heute als normaler Fließtext behandelt und löst kein zusätzliches Reasoning mehr aus. Im Konferenzvideo wurde „think hard" noch als Trigger genannt; das war zum Aufnahmezeitpunkt korrekt, ist aber überholt.

Lohnt sich das für ein kleines Team, oder nur für große Entwicklungsorganisationen?

Die Basics – evalgestütztes Prompt-Debugging, CLAUDE.md-Hygiene, Rewind, Effort-Level, schlanke Skills statt aufgeblähter Prompts – funktionieren unabhängig von der Teamgröße und kosten nichts zusätzlich. Die Agent-Plattform (Managed Agents, Routines, Memory Stores, Multi-agent Sessions) ist an Pro-, Max-, Team- oder Enterprise-Konten gebunden und trägt Beta- beziehungsweise Research-Preview-Status. Für ein Fünf-Personen-Team lohnt sich meist erst der Einstieg über die Basics, die Plattform-Bausteine später bei konkretem Bedarf.

Wann brauche ich einen MCP-Server statt eines Custom Tools?

Setzen Sie laut Sprecher-Heuristik auf MCP, sobald mehrere Clients oder mehrere Agenten dasselbe, standardisierte Tool-Set nutzen sollen – etwa wenn dasselbe Ticket-System-Tool vom Support-Agenten und vom Claude-Code-Setup der Entwickler genutzt wird. Für ein einzelnes Agenten-Projekt reichen eingebaute Primitive wie Bash, Dateisystem und Websuche sowie bei Bedarf einfache Custom Tools meist aus.

Brauche ich für Routines eigene Server-Infrastruktur?

Nein. Routines laufen als vollständige Claude-Code-Sessions auf Anthropics eigener Cloud-Infrastruktur und starten über einen Zeitplan, einen API-Aufruf oder GitHub-Events. Die Funktion trägt aktuell den Status Research Preview und ist für Pro-, Max-, Team- und Enterprise-Konten verfügbar.

Womit fange ich morgen an?

Bauen Sie zuerst eine kleine Eval-Suite mit Control-, Edge- und Kompetenzgrenz-Fällen für Ihren wichtigsten Prompt – ohne Evals bleibt jede Prompt-Änderung Rätselraten. Prüfen Sie parallel Ihre CLAUDE.md auf Aktualität, und lassen Sie einen aufgeblähten Agenten von Claude selbst anhand der Eval-Fehlschläge triagieren.

Quellen

Ausgangspunkt dieses Beitrags war ein Video von @ajitcodes auf X (https://x.com/ajitcodes/status/2076501882319810994) mit Session-Mitschnitten der Code-with-Claude-Konferenz – alle Aussagen wurden gegen die folgenden Primärquellen geprüft und ergänzt:

Beta- und Research-Preview-Funktionen können sich jederzeit ändern; alle Angaben laut Anbieter-Dokumentation, ohne Gewähr.

Bleiben Sie auf dem Laufenden

Erhalten Sie die neuesten Artikel, Insights und Branchen-Updates direkt in Ihr Postfach.

Claude Code Best Practices: Prompts, Agent-Verfall und 6 Funktionen