Ich bin seit über 15 Jahren in der Software- und Produktentwicklung unterwegs, habe über 150 Softwareprojekte umgesetzt oder begleitet und eine eigene Softwareagentur aufgebaut. Heute helfe ich Menschen ohne klassischen Entwicklerhintergrund, mit KI vernünftig Software zu entwickeln. Dabei sehe ich immer wieder dieselben fünf Stufen, auf denen Leute mit Claude Code arbeiten.
In diesem Artikel gehen wir alle fünf Level durch. Am Ende weißt du, wo du gerade stehst und was dein nächster sinnvoller Schritt ist.
Die 5 Level im Überblick
Stell dir die Level wie einen Werkzeugkasten vor. Jedes Level ist für eine bestimmte Art von Aufgabe gemacht. Das Ziel ist nicht, möglichst weit oben zu sein, sondern zu wissen, welches Werkzeug zu deiner Aufgabe passt.
| Level | Rolle | Kernwerkzeuge | Geeignet für |
|---|---|---|---|
| 1 | Prompter | Einzelne Prompts | Kleine, klar abgegrenzte Aufgaben, Prototypen |
| 2 | Kontext Engineer | CLAUDE.md, Dateien als Kontext, Plan-Modus | Bessere Ergebnisse bei mittelgroßen Aufgaben |
| 3 | Requirements Engineer | Spezifikationen mit Akzeptanzkriterien | Echte Features, reproduzierbare Ergebnisse |
| 4 | Systemarchitekt | Skills, Rules, Subagents | Wiederverwendbarer Entwicklungsprozess |
| 5 | Orchestrator | Mehrere Agenten parallel, Orchestrator-Worker-Pattern | Große Features, Reviews, Migrationen |
Level 1: Der Prompter
Auf diesem Level nutzt du Claude Code im Grunde wie einen Chat. Du gibst einen Prompt ein, Claude entwickelt den passenden Code, und du arbeitest dich Stück für Stück zum Ergebnis vor.
Als Einstieg ist das völlig in Ordnung. Für kleine, klar abgegrenzte Aufgaben reicht es sogar vollkommen. Wenn ich schnell einen Prototyp oder eine Website brauche oder kurz etwas testen will, mache ich es im Prinzip genauso. Dafür brauchst du kein Setup, du legst einfach los.
Die Grenze kommt, sobald das Projekt wächst. Willst du ein echtes Softwareprodukt mit Login, Datenbank und vielen Features entwickeln und arbeitest nur mit einzelnen Prompts, wird Claude irgendwann unzuverlässig. Er ändert Dinge an Stellen, die er nicht anfassen sollte, verliert den Überblick und macht im schlimmsten Fall Bestehendes kaputt. Das passiert mir genauso, wenn ich auf diesem Level bleibe. Claude Code ist dann kein schlechtes Tool. Du brauchst einfach eine andere Arbeitsweise.
Level 2: Der Kontext Engineer
Der Unterschied zu Level 1 ist simpel, macht aber extrem viel aus: Du gibst Claude ein Fundament, bevor er loslegt. Statt ihn raten zu lassen, was für ein Projekt ihr gemeinsam baut, sagst du ihm klar, womit er es zu tun hat.
Die CLAUDE.md als Gedächtnis
Das wichtigste Werkzeug dafür ist die CLAUDE.md. Diese Datei lädt Claude bei jeder Session automatisch in sein Kontextfenster, also sein Arbeitsgedächtnis. Hinein gehören eine klare Projektbeschreibung sowie Konventionen und Regeln, an die er sich halten soll. Gibt es die Datei in deinem Projekt noch nicht, bitte Claude einfach, sie anzulegen. Wie das mit /init geht, zeige ich in meiner Anleitung zur ersten Web-App mit Claude Code.
Mehr Kontext, aber gezielt
Kontext ist mehr als die CLAUDE.md. Alles, was Claude hilft, dein Projekt zu verstehen, kannst du ihm mitgeben: bestehende Dokumentation, Beispielcode, einen Screenshot des Designs, das du nachbauen willst, oder konkrete Dateien, die du mit @ im Prompt referenzierst. Je weniger Annahmen Claude treffen muss, desto besser das Ergebnis.
Aber Achtung: Das Kontextfenster ist begrenzt. Lade nur die Informationen, die Claude für die aktuelle Aufgabe wirklich braucht. Mit dem Befehl /context siehst du jederzeit, wie voll es gerade ist.
Wie du Kontext in mehreren Ebenen aufbaust, damit Claude auch in großen Projekten nichts vergisst, zeige ich in Context Engineering in Claude Code.
Der Plan-Modus
Dazu kommt der Plan-Modus. Statt Claude direkt losarbeiten zu lassen, lässt du ihn zuerst einen Plan schreiben. Erst wenn du ihn geprüft und freigegeben hast, wird er umgesetzt. So klärst du Missverständnisse, bevor sie im Code landen. Allein dieser Schritt macht die meisten Ergebnisse spürbar besser. Mehr dazu in meinem Artikel über Claude Code Befehle.
Level 3: Der Requirements Engineer
Level 1 und 2 sind das, was viele unter Vibe Coding verstehen: Du arbeitest schnell und intuitiv aus dem Bauch heraus. Das fühlt sich produktiv an und ist es für viele Anwendungsfälle auch. Vibe Coding ist eine super Möglichkeit, schnell etwas auszuprobieren.
Es hat aber ein großes Problem: Die Ergebnisse sind nicht reproduzierbar. Du kommst irgendwie zum Ziel, könntest aber nicht genau sagen, wie. Und bei stark wachsenden Projekten verliert Claude schnell den Überblick und arbeitet fehleranfällig.
Erst festlegen, dann bauen
Ab Level 3 wird aus Vibe Coding echtes AI Engineering. Der wichtigste Unterschied: Du legst erst genau fest, was gebaut werden soll, bevor gebaut wird. Bevor eine Zeile Code entsteht, schreibst du eine Spezifikation, die diese Fragen beantwortet:
- Was soll das Feature können?
- Woran erkenne ich, dass es fertig ist und korrekt funktioniert? Das sind die sogenannten Akzeptanzkriterien.
- Welche Fehlerfälle können eintreten?
Erst wenn das steht, geht es in die Umsetzung. So macht man es auch in der professionellen Softwareentwicklung.
Wie ein Produktmanager denken
Jetzt ein Punkt, der vielleicht kontrovers ist: Aus meiner Sicht wird es immer weniger wichtig, den im Hintergrund geschriebenen Code im Detail zu verstehen. Wichtiger wird, wie ein Produktmanager zu denken und zu arbeiten:
- Anforderungen und Funktionen definieren,
- Edge Cases, also Sonderfälle, identifizieren und durchdenken,
- Prioritäten bei der Umsetzung setzen,
- das Ganze sauber und messbar formulieren.
Bei der Implementierung werden die Modelle immer besser. Noch geben wir Best Practices und Rahmenbedingungen mit, dazu gleich mehr auf Level 4. Entscheidend ist aber, festzulegen, was gebaut wird und wie man den Erfolg messbar macht. Dann kannst du das Ergebnis prüfen, ohne den Code bewerten zu müssen. Und Claude kann während der Umsetzung selbst immer wieder prüfen, ob er das Ziel schon erreicht hat. So wird das Ergebnis besser und vollständiger.
Meine Spezifikationen schreibe ich übrigens nicht von Hand. Ich nutze dafür einen eigenen Skill, der mich zum Feature interviewt und daraus die Spezifikation ableitet. Damit sind wir beim nächsten Level.
Level 4: Der Systemarchitekt
Auf Level 3 hast du gelernt, ein Feature sauber zu spezifizieren. Auf Level 4 hörst du auf, alles manuell anzustoßen, und baust dir stattdessen ein wiederverwendbares System. Dafür gibt es drei Bausteine.
Baustein 1: Skills
Skills sind Arbeitsanleitungen für Claude, damit er exakt nach deinen Vorgaben arbeitet. Im Prinzip sind das einfache Markdown-Dateien, in denen du einen Arbeitsablauf einmal beschreibst. Rufst du den Skill auf, führt Claude ihn genau so aus. Mein Spezifikations-Skill von eben ist so ein Skill. Alles zu Aufbau und Einsatz von Skills steht in meinem kompletten Guide zu Agent Skills.
Baustein 2: Rules
Rules sind Vorgaben, die automatisch gelten, je nachdem, in welchem Bereich deiner App Claude gerade arbeitet. Zum Beispiel Coding-Standards, Namenskonventionen oder dein Tone of Voice, also dein Schreibstil.
Rules werden wie die CLAUDE.md automatisch in den Kontext geladen. Der Unterschied: Du kannst sie auf bestimmte Bereiche begrenzen. Dann sind sie nicht immer im Kontext, sondern nur, wenn Claude an passenden Dateien arbeitet. So gehst du sparsam mit dem Kontextfenster um. In Claude Code liegen Rules als Markdown-Dateien im Ordner .claude/rules/. Mit dem Feld paths legst du fest, für welche Dateien eine Regel gilt:
---
paths:
- "src/api/**/*.ts"
---
# Regeln für API-Endpunkte
- Jeder Endpunkt prüft seine Eingaben.
- Fehler werden immer im einheitlichen Fehlerformat zurückgegeben.
Eine Regel ohne paths wird wie die CLAUDE.md immer geladen.
Baustein 3: Subagents
Subagents sind kleine, unabhängige Helfer, die Claude starten kann. Jeder Subagent hat sein eigenes, frisches Kontextfenster und eine fokussierte Aufgabe. Der Hauptagent gibt ihm einen eigenen Prompt mit, damit er weiß, was zu tun ist. Ist die Aufgabe erledigt, berichtet der Subagent an den Hauptagenten zurück.
Aus Werkzeugen wird ein System
Von diesen drei Bausteinen sind Skills mit Abstand die wichtigsten. Wenn du mehrere Skills aneinanderreihst, wird aus einzelnen Werkzeugen ein ineinandergreifendes System.
Genau das habe ich gemacht: Aus mehreren Skills ist bei mir ein komplettes Development Team entstanden. Ein Skill definiert die Anforderungen, der nächste entwirft die Architektur, also das Systemdesign. Ein weiterer übernimmt die Implementierung, ein QA-Skill prüft das Ergebnis, und ein Deployment-Skill bringt die App live. So wird aus einem manuellen Entwicklungsprozess eine kleine Software-Fabrik.
Level 5: Der Orchestrator
Auf Level 4 hast du ein System gebaut, das du selbst bedienst. Auf Level 5 verschiebt sich deine Rolle noch einmal: vom Entwickler zum Orchestrator. Du setzt ein Team aus spezialisierten Agenten ein, die parallel arbeiten und sich gegenseitig kontrollieren.
Mehrere Sessions parallel
Die direkteste Form: Du lässt mehrere Claude-Sessions parallel laufen, zum Beispiel in mehreren Terminal-Fenstern. Du bist dann der Teamlead, der mehrere Leute gleichzeitig betreut. Hier Feedback geben, dort ein Ergebnis abnehmen, an dritter Stelle die nächste Aufgabe anstoßen.
Das Orchestrator-Worker-Pattern
Es geht noch eine Ebene tiefer. Jeder Claude-Agent, den du steuerst, kann wiederum Subagents starten. Das nennt sich Orchestrator-Worker-Pattern: Deine Hauptagenten werden selbst zu Orchestratoren und steuern Spezialisten.
Ein klassischer Anwendungsfall ist ein Review aus mehreren Perspektiven. Ein Hauptagent hat ein Feature fertig gebaut und schickt mehrere Subagents los, jeder mit einer eigenen Sicht:
- einer prüft auf Sicherheitslücken,
- einer prüft die Lesbarkeit des Codes,
- einer prüft die Wartbarkeit,
- einer ist der Skeptiker und sucht gezielt nach Fehlern und Edge Cases, an die der Hauptagent nicht gedacht hat.
Am Ende melden alle ihre Erkenntnisse an den Hauptagenten zurück, und der verbessert das Feature.
So setzt du das technisch um
Für jede Rolle legst du eine kleine Markdown-Datei an, in der steht, wer dieser Agent ist und worauf er achten soll. In Claude Code liegen eigene Subagents im Ordner .claude/agents/. Ein Beispiel für den Sicherheitsprüfer:
---
name: security-reviewer
description: Prüft neuen Code auf Sicherheitslücken. Nach Änderungen an Login, Formularen oder API-Endpunkten einsetzen.
tools: Read, Glob, Grep
---
Du bist Sicherheitsprüfer. Lies die geänderten Dateien und melde Risiken wie fehlende Eingabeprüfung, fehlende Zugriffsprüfungen oder offen liegende Secrets. Ändere selbst keinen Code.
Dazu kommt ein Skill, sagen wir ein Review-Skill, den dein Hauptagent aufruft. Darin steht das eigentliche Ziel, etwa so:
Prüfe den neu entwickelten Code aus mehreren Perspektiven. Starte dafür die Subagents security-reviewer, readability-reviewer, maintainability-reviewer und skeptic. Führe ihre Ergebnisse am Ende zusammen und behebe die gefundenen Probleme.
Das ist der Kern von Level 5: Statt selbst Skills nacheinander auszuführen, stellst du ein Team zusammen und lässt es für dich arbeiten.
Zwei Funktionen, die auf Level 5 helfen
/goal: Du gibst Claude eine Zielbedingung, und er arbeitet autonom weiter, bis sie erreicht ist. Mehr dazu in meinem Artikel über Claude Code Befehle.- Dynamic Workflows: Seit Ende Mai 2026 kann Claude komplexe Aufgaben automatisch in kleine Teilaufgaben zerlegen und sie von vielen Subagents im Hintergrund abarbeiten lassen. Das passt perfekt zu großen Aufgaben wie einem Code-Audit oder einer Migration. Laufende Workflows verwaltest du mit
/workflows.
Ein praktischer Haken: Claude Code läuft lokal auf deinem Rechner. Stößt du ein großes Refactoring, eine Migration oder ein großes Feature an und klappst dann den Laptop zu, brechen deine Agenten ab. Wenn Agenten wirklich über Stunden oder über Nacht arbeiten sollen, brauchst du einen Server, auf dem Claude Code dauerhaft läuft und den du von Laptop oder Smartphone aus steuerst.
Deine neue Rolle: verstehen und steuern
Je mehr du orchestrierst, desto stärker verschiebt sich deine Arbeit. Du nimmst Ergebnisse ab, gibst Feedback und korrigierst, wenn ein Agent in die falsche Richtung läuft. Das geht nur, wenn du verstehst, was im Hintergrund passiert: was gebaut wurde und warum es so gelöst wurde.
Gib nur frei, was du auch beurteilen kannst. Bei echter Software liegt die Verantwortung bei dir, auch wenn Claude die Entwicklungsarbeit leistet.
Einordnung: Welches Level brauchst du?
Wir haben alle irgendwann auf Level 1 angefangen, und für viele Aufgaben bleibt das auch das richtige Werkzeug. Ein schneller Prototyp braucht keine Spezifikation und kein Agententeam.
Wenn du aber ernsthaft Software mit Claude Code entwickeln willst, die wächst und die du vielleicht verkaufen willst, empfehle ich dir mindestens Level 4. Erst mit einem festen System aus Spezifikation, Architektur, Umsetzung und Prüfung bekommst du reproduzierbare Ergebnisse in hoher Qualität. Und wenn dein Kontextfenster dabei zum Engpass wird, hilft dir der Handoff-Skill gegen Context Rot.
