Ein Bug, ein Prompt, fertig
Neulich fällt mir auf: Meine Blog-Artikel tauchen nicht in der Sitemap auf. Kein dramatischer Bug, aber ärgerlich – vor allem für SEO. Früher hätte ich jetzt das Sitemap-Modul geöffnet, die Konfiguration durchgelesen, die richtige Stelle gefunden, gefixt, getestet, committed und deployed. Vielleicht 30 Minuten, vielleicht eine Stunde.
Stattdessen schreibe ich einen Satz in mein Terminal:
"Die Blog-Artikel werden nicht in der Sitemap aufgenommen."
Fünf Minuten später ist der Fix live.
Wie das funktioniert
Ich arbeite mit einem Multi-Agent-Setup in Claude Code. Drei Agenten, klare Rollen:
- Lead-Agent – Plant, erstellt Tickets, koordiniert
- Builder-Agent – Implementiert den Code
- Tester-Agent – Macht echte Browser-Tests mit Screenshots
Der Workflow läuft immer gleich ab. Ich gebe dem Lead-Agent eine Aufgabe – manchmal ein Satz, manchmal ein Absatz. Er analysiert das Problem, durchsucht die Codebasis, erstellt ein YouTrack-Ticket mit einer detaillierten Beschreibung und einem Lösungsansatz. Ich schaue kurz drüber, sage "mach" – und der Rest läuft.
Der Lead delegiert die Implementierung an den Builder-Agent. Der schreibt den Code, hält sich an meine Coding-Rules aus der CLAUDE.md und meldet sich zurück. Dann beauftragt der Lead den Tester-Agent, der einen echten Browser hochfährt, die Seite aufruft und prüft, ob das Problem gelöst ist. Erst wenn alles grün ist, sagt mir der Lead: Review bitte.
Ein Beispiel, das mich überzeugt hat
Die Sitemap war trivial. Aber es gibt Aufgaben, bei denen der Workflow richtig zeigt, was er kann.
Als ich die komplette Barrierefreiheit meiner Website umsetzen wollte, habe ich dem Lead-Agent im Prinzip gesagt: "Die Website braucht WCAG-konforme Barrierefreiheit." Was dann passiert ist:
- Der Lead hat den Umfang analysiert – jede Seite, jede Komponente, jedes Formular
- Er hat ein Ticket erstellt mit einer priorisierten Liste aller notwendigen Änderungen
- Der Builder hat systematisch alle Komponenten durchgearbeitet – ARIA-Labels, Fokus-Management, Kontrastmodi, Skip-Links, Focus-Traps
- Der Tester hat nach jeder Iteration Screenshots gemacht und die Zugänglichkeit geprüft
Das Ergebnis: WCAG 2.1 Level AA in unter 2 Stunden. Nicht weil die AI magisch ist, sondern weil der Workflow die Arbeit parallelisiert und den Kontextwechsel eliminiert. Ich musste nicht zwischen Spezifikation, Code und Test hin- und herspringen – das haben die Agenten untereinander koordiniert.
Was ich an dem Workflow liebe
Kein Kontextverlust
Das Schlimmste an klassischer Entwicklung ist der Kontextwechsel. Ticket lesen, IDE öffnen, die richtige Datei finden, den Kontext wieder aufbauen, coden, testen, committen. Mit dem Agent-Workflow beschreibe ich das Problem einmal – der Kontext bleibt erhalten, vom Ticket über die Implementierung bis zum Test.
Dokumentation fällt nebenbei ab
Jede Änderung wird automatisch als Ticket mit Beschreibung, Lösungsansatz und Screenshot dokumentiert. Kein nachträgliches Ticket-Schreiben, kein "was hatte ich nochmal gemacht?". Das Ticket existiert bevor der erste Code geschrieben wird.
Kleine Fixes werden tatsächlich gemacht
Wir alle kennen das: Man entdeckt einen Tippfehler, eine unschöne Formulierung, einen kleinen visuellen Bug. Und dann denkt man "mach ich später" – und macht es nie. Mit dem Agent-Workflow ist die Hürde so niedrig, dass ich solche Dinge sofort angehe. Ein Satz, ein Prompt, erledigt.
Der Teil, den niemand hören will
Hier kommt der ehrliche Part. Der Workflow ist nicht "AI macht alles, ich lehne mich zurück". Das wäre auch fahrlässig.
Eingreifen ist normal
In vielleicht jedem dritten bis vierten Task muss ich eingreifen. Manchmal interpretiert die AI eine Anforderung anders als ich es meinte. Manchmal ist der generierte Code technisch korrekt, aber stilistisch nicht das, was ich will. Manchmal ist es schneller, selbst drei Zeilen zu ändern, als der AI zu erklären, was genau anders sein soll.
Das ist okay. Der Workflow spart mir nicht 100 % der Arbeit – er spart mir 70-80 %. Und die restlichen 20-30 % sind die Teile, bei denen menschliches Urteil tatsächlich einen Unterschied macht.
Review ist nicht optional
Ich reviewe jede einzelne Änderung. Jede. Nicht weil ich der AI nicht vertraue, sondern weil es mein Code ist, der in Production läuft. Ich lese den Diff, prüfe die Logik, teste kritische Pfade manuell. Das dauert in der Regel 2-5 Minuten pro Change – aber diese Minuten sind nicht verhandelbar.
Blind akzeptieren ist keine Option. Nicht weil die AI schlecht ist – sie ist meistens gut. Aber "meistens" reicht nicht für Production.
Die AI korrigieren gehört dazu
Manchmal sage ich: "Nein, nicht so. Mach es so." Und dann lernt der Agent im Kontext der Session, was ich will. Das ist kein Bug des Systems – das ist wie Zusammenarbeit funktioniert. Man gibt Feedback, justiert nach, iteriert. Genau wie mit einem menschlichen Kollegen.
Zeitersparnis – konkret
Ich will keine abstrakten Prozentzahlen nennen. Stattdessen ein paar reale Beispiele von dieser Website:
- Sitemap-Bug – von "mir fällt auf" bis "live": 5 Minuten
- Barrierefreiheit (WCAG) – komplette Umsetzung: unter 2 Stunden statt geschätzt 2-3 Tage
- Textanpassungen über mehrere Seiten – i18n in DE und EN: 3 Minuten statt 20
- Neuer Blog-Bereich – Planung, Implementierung, Styling: 1 Tag statt geschätzt 1 Woche
Der Hebel ist am größten bei Aufgaben, die viele Dateien betreffen, klare Regeln haben und repetitiv sind. Der Hebel ist am kleinsten bei kreativer Arbeit, komplexer Business-Logik und architektonischen Entscheidungen – da bin immer noch ich gefragt.
Was du dafür brauchst
Der Workflow klingt komplexer als er ist. Im Kern brauchst du drei Dinge:
- Eine gute CLAUDE.md – Das ist deine Projektspezifikation. Design System, Coding Rules, Projektstruktur. Je besser diese Datei, desto besser die Ergebnisse.
- Klare Agent-Definitionen – Jeder Agent hat eine Rolle, Werkzeuge und Grenzen. Das verhindert Chaos.
- Einen Ort für Aufgaben – Das muss kein Ticket-System sein. Du kannst Pläne und Aufgaben auch in Markdown-Dateien im Repo ablegen – Claude Code kann damit genauso arbeiten. Aber ich persönlich bevorzuge ein echtes Ticket-System wie YouTrack.
Warum ich ein Ticket-System bevorzuge
Markdown-Dateien funktionieren. Aber ein Ticket-System gibt mir mehr:
- Bessere Dokumentation – Jedes Ticket hat eine Historie, Kommentare, Screenshots. Das ist übersichtlicher als eine wachsende
.md-Datei. - Einfache Referenzierung – Jedes Ticket hat eine Nummer und einen Titel. Wenn ich in einer neuen Aufgabe auf ein älteres Ticket verweisen will, reicht die Nummer – das System verlinkt es automatisch mit Titel und Status. Kein Durchsuchen von Markdown-Dateien.
- Agenten kommentieren direkt – Meine Agenten kommentieren als "Claude" im Ticket. Ich sehe den Fortschritt, die Entscheidungen und die Ergebnisse direkt im Ticket – mit Screenshots.
- Ich kann im Ticket antworten – Statt immer ins Terminal zu wechseln, könnte ich auch direkt im Ticket Feedback geben. Das macht den Workflow noch flexibler.
Am Ende ist es Geschmackssache. Markdown reicht für den Anfang. Aber wenn du den Workflow ernsthaft nutzt, wirst du die Struktur eines Ticket-Systems schnell zu schätzen wissen.
Das Setup kostet ein paar Stunden. Die Zeitersparnis danach ist ein Vielfaches.
Die Realität hinter dem Hype
AI-Agenten sind kein Autopilot. Sie sind eher wie ein sehr schneller, sehr geduldiger Junior-Entwickler, der nie müde wird und sich exakt an deine Vorgaben hält – solange du sie klar formulierst.
Der Workflow funktioniert, weil ich die Kontrolle behalte. Ich entscheide, was gebaut wird. Ich reviewe, was gebaut wurde. Ich greife ein, wenn nötig. Die Agenten beschleunigen die Ausführung – aber die Verantwortung bleibt bei mir.
Und genau so sollte es sein.
AI-Agenten ersetzen keine Entwickler. Sie ersetzen die Teile der Arbeit, die Entwickler davon abhalten, sich auf das Wesentliche zu konzentrieren.