Claude Code wird zum Spezialistenteam: wann Agenten-Skills die Bereitstellung beschleunigen und wann sie zusätzliches Chaos erzeugen

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und bei DennisCraft AI Studio liefere ich produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und self-hosted Postgres. Der kritische Moment in Claude Code ist nicht die einzelne fehlerhafte Funktion, sondern der Augenblick, in dem 4 angebliche Spezialisten denselben Änderungssatz anfassen, jeweils plausible Artefakte hinterlassen und am Ende niemand mehr die fachliche Verantwortung für das Gesamtverhalten trägt.

Genau dort entscheidet sich, ob Agenten-Skills nützlich sind oder ob sie nur eine weitere Schicht Unklarheit erzeugen. Die Idee klingt vernünftig: ein Skill für SQL, einer für Tests, einer für Sicherheitsprüfung, einer für Umstrukturierung. Im Produktivbetrieb entsteht Geschwindigkeit aber nicht durch mehr Rollenbilder, sondern durch enge Grenzen, klare Zuständigkeiten und prüfbare Übergaben.

Wann Skills in Claude Code tatsächlich helfen

Ich sehe 3 Fälle, in denen Skills einen klaren Nutzen haben.

1. Die Aufgabe ist eng abgegrenzt und wiederholbar

Das gilt etwa für Migrationen, Testdaten, Secret-Prüfungen, die Vereinheitlichung von Fehlerbehandlung oder kleine Änderungen an einem bekannten Datenzugriffsmuster. Hier arbeitet ein Skill wie ein spezialisierter Ausführender mit klaren Ein- und Ausgaben.

2. Die Aufteilung folgt dem Risiko, nicht dem Organigramm

Viele Teams bauen Skills nach menschlichen Rollen auf: Backend Engineer, Security Engineer, Reviewer, Architect. Für generierten Code ist das selten die beste Trennung. Sinnvoller ist eine Aufteilung nach Berechtigungen und Schadenspotenzial: nur lesen, nur Patch vorschlagen, Anwendungscode ändern, Schema-Dateien anfassen, Scanner ausführen, aber keine neuen Abhängigkeiten einführen.

3. Der Skill ergänzt die Prüfung, ersetzt sie aber nicht

OWASP führt in den Top 10 von 2021 „Broken Access Control“ erneut als häufigste Risikokategorie (OWASP Top 10, 2021). Für produktive Agentensysteme ist das ein klarer Hinweis: Eine Sicherheitsprüfung darf nicht von der Hoffnung abhängen, dass ein Modell problematische Stellen schon bemerken wird. In regulierten Umgebungen mit DSGVO, ISO 27001 oder NIS2 zählt ein nachvollziehbarer Kontrollpfad, nicht ein implizites Vertrauen in Modellverhalten.

Wann Skills zusätzliches Chaos erzeugen

In Projekten mit mehreren Agenten sehe ich immer wieder dieselben 4 Fehlermuster.

Zu viel geerbter Kontext

Wenn jeder Skill die gesamte Historie, frühere Entscheidungen und große Teile des Repositorys erhält, verhält er sich nicht mehr wie ein Spezialist. Er beginnt zu improvisieren. Das erschwert Nachvollziehbarkeit und spätere Prüfung.

Mehrere Skills dürfen dieselbe Schicht verändern

Wenn SQL sowohl durch einen Feature-Skill als auch durch einen Datenbank-Skill oder Bugfix-Skill geändert werden darf, ist der Konflikt bereits angelegt. Das Problem ist nicht die Qualität einzelner Änderungen, sondern überlappende Zuständigkeit.

Kein Vertrag auf Artefaktebene

Ein brauchbarer Skill erzeugt einen Patch, einen Bericht, eine Migration oder eine Testdatei. Ein schwacher Skill erzeugt nur Empfehlungen. Empfehlungen werden vom nächsten Agenten unterschiedlich ausgelegt. Damit hängt die Pipeline plötzlich von unscharfer Sprache statt von prüfbaren Ergebnissen ab.

Die Orchestrierung ist schwächer als das Modell

Der Anthropic SDK ist nützlich, weil er die Steuerung von Nachrichten, Werkzeugen und Reihenfolge erlaubt. Das praktische Problem ist selten, dass ein Skill fachlich zu wenig spezialisiert wäre. Meist fehlen feste Abbruchkriterien, begrenzte Schreibrechte und ein stabiler Übergabemechanismus.

Ein Muster für den Produktivbetrieb

Das verlässlichste Muster ist einfacher als viele Mehragenten-Demonstrationen. Ein Hauptagent trägt die Verantwortung für die Aufgabe. Skills werden als klar begrenzte Stufen aufgerufen, nicht als gleichberechtigte Mitentwickler. Jede codeerzeugende Stufe wird durch externe Prüfungen abgesichert.

In der Praxis sind hier einfache Prüfwerkzeuge oft wertvoller als ein weiterer „intelligenter“ Prüfer. Semgrep, Bandit und Gitleaks liefern wiederholbare Mindestkontrollen.

#!/usr/bin/env bash
set -euo pipefail

python -m pytest -q
semgrep --config auto .
bandit -r app -q
gitleaks detect --no-banner --source .

if git diff --name-only | grep -E 'schema|migration'; then
  echo "Database-related change detected"
fi

echo "Verification finished"

Gerade im DACH-Umfeld ist das relevant: Für Anforderungen aus DSGVO, BSI Grundschutz oder dem EU AI Act ist ein nachweisbarer Prüfpfad deutlich hilfreicher als ein informelles Vertrauen in autonome Spezialisten.

Wo der Geschwindigkeitsgewinn wirklich entsteht

In meinen Projekten kommt der Gewinn nicht aus „Autonomie“, sondern aus der Senkung der Kosten wiederkehrender Änderungen. Claude Code ist stark, wenn über 8 bis 15 Dateien dieselbe Anpassung konsistent durchgeführt werden muss: Audit-Felder ergänzen, Fehlerbehandlung vereinheitlichen, Zugriffsschichten auf Postgres oder Supabase angleichen oder Regressionstests um eine bereits entschiedene Implementierung herum aufbauen.

Schwach wird das Muster, wenn die Architekturfrage noch offen ist. Muss der Agent gleichzeitig Schemaform, Berechtigungsgrenzen, Verhalten externer APIs und Wiederholungslogik entscheiden, schreibt ein Spezialistenteam oft zu früh. Der Umfang des Outputs wächst, die Sicherheit der Entscheidung aber nicht.

Welche Fragen ich vor jedem neuen Skill stelle

Bevor ich einen weiteren Skill einführe, prüfe ich 5 Punkte.

• Welches einzelne messbare Ergebnis liefert dieser Skill?
• Welche Dateien oder Ressourcen darf er verändern?
• Was passiert, wenn er still fehlschlägt?
• Lässt sich dieselbe Aufgabe durch statische Analyse oder Vorlagen abdecken?
• Wer trägt die endgültige Verantwortung: der Skill oder der Hauptagent?

Wenn diese Antworten nicht klar sind, ist der Skill noch nicht bereit. In vielen Teams fehlt kein weiterer Spezialist, sondern eine engere Begrenzung der bereits vorhandenen Kette.

from pathlib import Path
import subprocess

ALLOWED_PATHS = {"app/", "tests/"}

def changed_files():
    out = subprocess.check_output(
        ["git", "diff", "--name-only", "HEAD~1"]
    ).decode().splitlines()
    return out

for file_path in changed_files():
    if not any(file_path.startswith(p) for p in ALLOWED_PATHS):
        raise SystemExit(f"blocked change: {file_path}")

print("change scope accepted")

Solche kleinen Schranken verhindern im Alltag mehr Schäden als ein zusätzlicher Reviewer-Agent.

FAQ

Sollte jedes Team einen eigenen Skill für Sicherheitsprüfung bauen?

Nur dann, wenn dieser Skill einen festen Prüfbereich hat und Ergebnisse gegen klar definierte Artefakte liefert. Er sollte die Prüfung unterstützen, aber niemals die eigentliche Kontrolle ersetzen.

Lohnen sich Skills auch für kleine Teams?

Ja, aber erst dann, wenn der Ablauf bereits wiederholbar ist. Ein instabiler Prozess wird durch Skills nur schneller instabil.

Darf ein Skill Migrationen verändern?

Ja, aber nur als getrennte Stufe mit sichtbarer Diff-Prüfung. Änderungen am Schema sollten nie versteckt in einer allgemeinen Feature-Stufe mitlaufen.

Woran erkenne ich, dass Skills mehr schaden als nutzen?

Typische Zeichen sind wiederholte Änderungen an denselben Dateien, größere Diffs ohne bessere Begründung und Situationen, in denen niemand die finale Umsetzung sauber erklären kann. Dann ist die Zuständigkeit verloren gegangen.

Was ist für den Produktivbetrieb wichtiger: Modellqualität oder Orchestrierung?

Fast immer die Orchestrierung. Ein stärkeres Modell in einem schwachen Kontrollpfad produziert teure Fehler nur schneller.

An welcher Stelle Ihrer LLM-Pipeline entsteht im Produktivbetrieb der meiste Schaden: bei der Planung, bei der Übergabe zwischen spezialisierten Agenten oder erst nach dem Merge, wenn niemand den finalen Diff fachlich verantwortet? Ich würde das gern mit den Mustern vergleichen, die ich bei DACH-B2B-Teams sehe.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.