Coding-Agents wie Claude Code sind in vielen Entwicklungsteams vom Experiment zum Werkzeug geworden. Auch bei uns arbeiten sie inzwischen täglich mit, von der TYPO3-Extension bis zum Frontend-Build. Die offiziellen Best Practices zu Claude Code bringen eine Unterscheidung auf den Punkt, die wir in der Praxis für zentral halten.
Empfehlung oder Regel
Anweisungen an einen Agenten gibt es in zwei Formen. Nicht deterministisch sind alle Texte, die das Modell liest: der Prompt, die Projektdatei CLAUDE.md, Skills. Das Modell folgt ihnen fast immer, aber eben nicht garantiert. Deterministisch sind Hooks, Deny-Regeln und verwaltete Einstellungen. Sie werden von der Laufzeitumgebung ausgeführt, unabhängig davon, was das Modell entscheidet.
Daraus folgt eine einfache Faustregel: Was ausnahmslos gelten muss, gehört nicht in einen Text, sondern in eine Regel. „Nie die .env-Datei lesen“ oder „Migrationsordner nicht anfassen“ sind Fälle für eine Deny-Regel oder einen Hook. Wenn man eine Zeile in der Projektdatei immer stärker betonen muss, ist das laut Dokumentation ein Zeichen, dass sie dort falsch aufgehoben ist.
Die Projektdatei kurz halten
Die CLAUDE.md wird in jede Sitzung geladen und kostet bei jeder Aufgabe Aufmerksamkeit. Sie sollte deshalb nur enthalten, was der Agent nicht selbst aus dem Code ablesen kann: Build- und Testbefehle, Besonderheiten des Deployments, Konventionen, die nirgends dokumentiert sind. Längere Abläufe, etwa ein Release-Prozess, gehören in Skills. Diese werden nur geladen, wenn die Aufgabe sie braucht. Persönliche Vorlieben kommen in eine separate, nicht eingecheckte Datei.
Prüfbar statt vertrauenswürdig
Der wichtigste Hebel ist, dem Agenten eine Möglichkeit zu geben, seine Arbeit selbst zu prüfen: Tests, Typprüfung, Linter. Die nützlichste Zeile in der Projektdatei ist oft schlicht der Befehl dafür. Ein Stop-Hook kann erzwingen, dass der Agent erst fertig meldet, wenn die Prüfung durchläuft. Ergänzend empfiehlt die Dokumentation ein Review durch einen frischen Subagenten, der die vorangegangene Begründung nicht kennt.
Parallel, aber getrennt
Für mehrere gleichzeitige Aufgaben arbeitet jede Sitzung in einem eigenen Git-Worktree, damit sich Änderungen nicht überschneiden. Mit /clear zwischen unabhängigen Aufgaben bleibt der Kontext fokussiert, das spart Kosten und verbessert die Ergebnisse.
Was heißt das für Ihr Projekt?
Ein Coding-Agent ist so gut wie die Leitplanken, die das Projekt ihm gibt. Investieren Sie in eine schlanke Projektdatei, automatisierte Tests und wenige, harte Regeln für das, was nie passieren darf. Code-Review durch Menschen bleibt dabei Pflicht. Wenn Sie überlegen, Coding-Agents in Ihrem Team oder in einem TYPO3-Projekt einzusetzen, teilen wir gern unsere Erfahrungen mit Setup und Arbeitsweise.