Claude Code Agents

Ich arbeite inzwischen seit einiger Zeit regelmäßig mit Claude Code, vor allem in diesen wöchentlichen Projekten. Für vieles ist das inzwischen fester Bestandteil meines Workflows geworden: Code verstehen, Features umsetzen, Tests schreiben, Refactoring.

Diese Woche habe ich mir allerdings eine neue Frage gestellt:

In diesem Zusammenhang bin ich wieder über ein Wort gestolpert, das aktuell überall auftaucht: Agents.

Viele sprechen darüber, wenige erklären konkret, was damit eigentlich gemeint ist, und noch weniger zeigen, wie man sie in der Praxis wirklich nutzt.
Genau deshalb wollte ich diesen Post schreiben.

Was sind Agents?

In Claude Code sind Agents keine separaten Programme, keine Skripte und keine Plugins.
Ein Agent ist im Kern:

Statt dass ein einzelner Claude-Chat alles gleichzeitig macht, also planen, implementieren, testen und dokumentieren, kann man diese Aufgaben auf mehrere Agenten aufteilen. Jeder Agent bekommt:

• eine klare Aufgabe (z. B. Backend-Code schreiben)
• feste Arbeitsregeln
• und eine eigene Perspektive auf das Problem

Wichtig dabei: Agents arbeiten alle im selben Projektkontext, sehen also denselben Code, dieselben Dateien und dieselben Projektregeln.

Wie Agents funktionieren

Ein häufiger Irrtum ist, dass man Agents ständig manuell steuern müsste:

So funktioniert Claude Code nicht.

Stattdessen gilt:

• Du beschreibst Agenten einmal
• Claude weiß, wann welcher Agent sinnvoll ist
• und kann selbst entscheiden, welchen Agenten er einsetzt

Du kannst Agenten explizit ansprechen, musst es aber nicht immer. Das ist ein wichtiger Unterschied zu vielen anderen Agent-Konzepten.

Agents sind also keine Befehle, sondern Verhaltensprofile, die Claude situationsabhängig nutzt.

Agents anzulegen ist viel einfacher als es klingt

Technisch bestehen Agents am Ende aus Markdown-Dateien mit vielen Details:

• Beschreibung
• Regeln
• Tool-Zugriff
• Arbeitsanweisungen

Entscheidend ist aber: man muss diese Dateien in der Praxis nicht selbst schreiben.

In Claude Code legt man einen Agenten im Dialog an, zum Beispiel mit:

/agents
→ Create new agent

Danach beschreibt man einfach in natürlicher Sprache, was dieser Agent tun soll, etwa:

Claude Code erstellt daraus automatisch eine vollständige Agent-Definition als Markdown-Datei: mit deutlich mehr Struktur und Detailtiefe, als man sie selbst formulieren würde.

Das fühlt sich weniger nach Konfiguration an und mehr nach Onboarding eines neuen Teammitglieds.

Man kann diese Datei später anpassen oder verfeinern, muss es aber nicht, um produktiv zu sein.

Vorteile von Agents im Alltag

Aus meiner bisherigen Beschäftigung mit dem Thema ergeben sich ein paar klare Vorteile:

✅ Struktur statt Kontext-Chaos

Agents verhindern, dass alles in einem einzigen Chat verschwimmt.

✅ Klarere Verantwortung

Ein Agent plant, ein anderer implementiert, ein dritter testet: das macht Entscheidungen nachvollziehbarer.

✅ Weniger Micromanagement

Man muss nicht jeden Schritt vorgeben. Claude kann selbst entscheiden, welcher Agent gerade passt.

✅ Sehr niedrige Einstiegshürde

Kein Framework, kein YAML-Gefrickel, kein Setup-Marathon: beschreiben reicht.

Aber: Agents haben auch Nachteile

Gleichzeitig gilt:

⚠️ Overengineering-Gefahr

Für kleine Aufgaben sind Agents oft unnötig und sogar langsamer.

⚠️ Mehr Denkaufwand am Anfang

Man muss sich überlegen, welche Rollen wirklich sinnvoll sind.

⚠️ Kein Autopilot

Agents ersetzen keine Entscheidungen. Schlechte Anforderungen bleiben schlechte Anforderungen.

Warum ich mich dazu entschieden habe, Agents zu testen

Gerade weil Agents nicht automatisch „besser“ sind, will ich sie nicht theoretisch bewerten, sondern praktisch.

Ich habe mir deshalb ein sehr einfaches Agent-Setup eingerichtet und werde es in den nächsten Wochen in meinen Projekten nutzen.

In einem Folgepost werde ich konkret beantworten:

• War ich schneller oder langsamer?
• Hat mir die Aufteilung geholfen oder eher gebremst?
• Würde ich Agents im Alltag weiter einsetzen?

Welche Agents ich jetzt konkret testen werde

1️⃣ Planung & Architektur, Architecture Agent

Aufgabe:

• Anforderungen ordnen
• Lösungsansätze skizzieren
• Architekturentscheidungen vorbereiten
• aber kein Code schreiben

2️⃣ Backend-Implementierung, Backend Agent

Aufgabe:

• Python- oder Node-Backend schreiben
• Business-Logik
• API-Endpunkte
• keine Architektur-/Designentscheidungen treffen

3️⃣ Frontend-Implementierung, Frontend Agent

Aufgabe:

• React-Komponenten
• State-Management
• API-Integration
• UI-spezifische Entscheidungen

4️⃣ Test & QA, Test Agent

Aufgabe:

• Unit-Tests schreiben
• Fehler finden
• Edge-Cases prüfen
• Code kritisch bewerten

Fazit

Agents in Claude Code sind weniger kompliziert, als viele es darstellen und gleichzeitig nützlicher, als man auf den ersten Blick denkt.

Sie sind kein neues Framework und kein Zaubertrick, sondern ein Werkzeug für Struktur.
Ob sie den eigenen Workflow wirklich verbessern, hängt stark davon ab, wie bewusst man sie einsetzt.

Genau das werde ich in den nächsten Wochen testen, und ehrlich darüber berichten.