Ich dachte, ich würde KI zum Programmieren nutzen.
In Wahrheit tippte ich nur schneller.
Hier ist der Unterschied – und das 7-Agenten-System, das alles verändert hat.
Speichere das. Es wird dir Monate ersparen.
DAS PROBLEM, ÜBER DAS NIEMAND SPRICHT
Die Schleife, die sich produktiv anfühlt, es aber nicht ist:
→ Claude bitten, eine Funktion zu bauen → Es generiert Code → Etwas geht kaputt → Fehler zurückgeben → Es flickt ihn → Etwas anderes geht kaputt → Erneut bitten
Tag 1: Das fühlt sich wie Magie an.
Tag 30: Du verbringst mehr Zeit damit, die KI zu beaufsichtigen, als du früher mit dem Schreiben von Code verbracht hast.
Dieselbe Logik taucht an drei verschiedenen Stellen auf.
Claude hat die Konvention vergessen, die du vor zwei Wochen aufgestellt hast.
Neue Funktionen zerstören alte.
Tests fehlen oder sind oberflächlich.
Du wachst auf und erkennst: Die KI versagt nicht.
Dein Workflow versagt.
Das eigentliche Problem ist struktureller Natur.
Wenn du "baue diese Funktion" in Claude Code eingibst, bittest du eine einzige KI-Sitzung darum, Folgendes zu sein:
→ Produktanalyst → Architekt → Backend-Entwickler → Frontend-Entwickler → Testentwickler → Code-Reviewer
Alles auf einmal.
In derselben chaotischen Unterhaltung.
Falsche Annahmen im Plan werden zu falschen Datenbankmodellen.
Falsche Datenbankmodelle werden zu falschen APIs.
Falsche APIs werden zu falschen Benutzeroberflächen.
Bis du es bemerkst, hat sich der Fehler überall ausgebreitet.
Das nennt man Vibe Coding.
Und es hat eine harte Obergrenze.
DER WECHSEL: VOM VIBE CODING ZUR SOFTWARE-FABRIK
Was wirklich alles verändert:
Echte Entwicklungsteams arbeiten nicht in einem großen Gespräch.
Verschiedene Personen übernehmen verschiedene Aufgaben:
→ Jemand klärt das Benutzerproblem → Jemand denkt über die Architektur nach → Jemand baut die API → Jemand baut die Benutzeroberfläche → Jemand denkt über Randfälle nach → Jemand prüft
Wenn du das alles in eine einzige KI-Sitzung packst, verstärken sich Fehler still und leise.
Die Lösung ist, die Arbeit auf spezialisierte Agenten aufzuteilen.
Jeder Agent bekommt: → Eine fokussierte Aufgabe → Seinen eigenen, sauberen Kontextbereich → Nur die Werkzeuge, die er tatsächlich benötigt → Strenge Regeln, was er nicht anfassen darf
Das Ergebnis: eine Software-Fabrik.
Ein Entwickler + sieben fokussierte Agenten = ein koordiniertes Team.
Hier sind die sieben Agenten, die es möglich machen.
DIE 7 AGENTEN
Agent 1: Der Codebase-Researcher
Der größte Fehler, den Entwickler mit KI machen?
Als ersten Schritt nach Code zu fragen.
Die KI akzeptiert die Aufforderung, macht Annahmen, um die Lücken zu füllen, und beginnt mit der Generierung.
Dann schlüpfen die schlechten Entwürfe hinein.
Der Codebase-Researcher behebt das.
Seine einzige Aufgabe: die Codebase untersuchen und erklären, wie die Dinge funktionieren – bevor eine einzige Zeile geschrieben wird.
Was er tut: → Die relevanten Dateien und ihre Rollen abbilden → Vorhandene Muster dokumentieren, die befolgt werden sollen → Ähnliche, bereits gebaute Funktionen finden → Risiken kennzeichnen (Zeitzonen, Multi-Tenant, Wiederholungslogik) → Auflisten, welche Tests aktualisiert werden müssen
Was er nicht tun kann: → Dateien bearbeiten (nur Lesezugriff) → Einen Befehl ausführen, der den Zustand ändert → Annahmen treffen – er fragt stattdessen nach
Werkzeuge: Nur Lesen, Grep, Glob.
Die Regel: Erkunde, bevor du baust – jedes einzelne Mal.
Der Researcher läuft immer zuerst.
Agent 2: Der Story Writer
Die meisten Funktionen scheitern nicht, weil der Code falsch war.
Sondern weil das Problem nie klar definiert wurde.
Der Story Writer verwandelt eine grobe Funktionsidee in eine echte User Story – bevor irgendwelche technischen Entscheidungen getroffen werden.
Eingabe, die er erhält: → Deine grobe Funktionsbeschreibung → Die Ergebnisse des Researcher
Was er produziert:
Eine User Story:"Als [Rolle] möchte ich [Verhalten], damit [Ergebnis]."
Abnahmekriterien:Aussagen, die ein Test direkt überprüfen kann. Erfolgsweg. Fehlerpfade. Geschäftsregeln.
Randfälle:Grenzen, Wiederholungen, Multi-Tenant-Aspekte.
Nicht im Umfang:Was explizit NICHT gebaut wird.
Offene Fragen:Dinge, die er wirklich nicht weiß – er rät nie.
Was er nicht tun kann: → Geschäftsregeln erfinden → Code oder technisches Design schreiben → Fortfahren, wenn etwas wirklich unklar ist
Werkzeuge: Nur Lesen.
Die Regel: Du liest diese Story und genehmigst sie, bevor irgendetwas anderes passiert.
Dies ist der menschliche Kontrollpunkt, der alles flussabwärts rettet.
Agent 3: Der Spec Writer
Sobald die Story genehmigt ist, verwandelt der Spec Writer sie in ein technisches Exposé.
Dies ist der Bauplan, dem jeder Build-Agent folgt.
Eingabe, die er erhält: → Deine genehmigte User Story → Die Ergebnisse des Researcher → Die CLAUDE.md-Regeln deines Projekts
Was er produziert:
→ Datenmodelländerungen (Felder, Typen, Migrationen) → Hintergrundablauf / Prozessablauf → API-Änderungen (Endpunkte, Anfrage-/Antwortstrukturen) → Frontend-Änderungen (Komponenten, Seiten, Hooks) → Erforderliche Tests (Erfolg, Fehler, Randfälle) → Risiken und offene Fragen → Jede Datei, die geändert wird
Was er nicht tun kann: → Eine Datei bearbeiten → Neue Infrastruktur erfinden – er benennt sie stattdessen explizit → Fragen zur Tenant-Isolation oder Zeitzonen überspringen → Fragen unbeantwortet lassen
Werkzeuge: Nur Lesen, Grep, Glob.
Die Regel: Dieses Exposé ist der zweite menschliche Kontrollpunkt.
Du liest es und genehmigst es, bevor eine einzige Datei angefasst wird.
Wenn du "Store-IDs im Speicher" siehst – das ist deine rote Flagge.
Erwische es jetzt. Nicht, nachdem 10 Dateien geändert wurden.
Agent 4: Der Backend Builder
Jetzt beginnt das Bauen.
Der Backend Builder implementiert die Backend-Hälfte der Funktion – und nur die Backend-Hälfte.
Eingabe, die er erhält: → Genehmigtes technisches Exposé → Ergebnisse des Researcher → Deine CLAUDE.md des Projekts
Was er baut: → API-Routen → Dienste und Geschäftslogik → Datenbankzugriff und Migrationen → Hintergrund-Jobs → Unit-Tests für alles, was er schreibt
Was er nicht tun kann: → React-Komponenten, Seiten oder clientseitige Hooks anfassen (das ist Agent 5) → Neue Abhängigkeiten ohne Anweisung erfinden → Dateien außerhalb des vereinbarten Umfangs ändern → Anhalten, ohne Typprüfung, Linting und die Testsuite auszuführen
Nach Abschluss gibt er eine Zusammenfassung zurück: → Jede hinzugefügte oder bearbeitete Datei → Jeder wiederverwendete vorhandene Helfer oder jedes Muster → Jede CLAUDE.md-Regel, die geholfen hätte
Werkzeuge: Lesen, Bearbeiten, Schreiben, Bash – beschränkt auf Backend-Ordner.
Die Trennung ist der Punkt.
Backend Builder kann niemals versehentlich das Frontend kaputt machen. Niemals.
Agent 5: Der Frontend Builder
Der Frontend Builder implementiert die UI-Hälfte – und nur die UI-Hälfte.
Er liest zuerst die Zusammenfassung des Backend Builder.
Das ist wichtig.
Er konsumiert die API genau so, wie das Backend sie produziert hat.
Er erfindet keine neuen Endpunkte.
Wenn die API-Form für die UI falsch ist, meldet er die Diskrepanz als Feedback – nicht als Patch.
Eingabe, die er erhält: → Genehmigtes technisches Exposé → Ergebnisse des Researcher → Zusammenfassung des Backend Builder (der API-Vertrag)
Was er baut: → React-Komponenten und -Seiten → Clientseitige Hooks und Zustand → Lade- und Fehlerzustände → Komponenten- und Unit-Tests für alles, was er schreibt
Was er nicht tun kann: → Dienste, API-Routen, Worker oder Migrationen anfassen (das ist Agent 4) → Endpunkte oder Antwortstrukturen erfinden → Abhängigkeiten ohne Anweisung hinzufügen → Anhalten, ohne Typprüfung, Linting und die Testsuite auszuführen
Werkzeuge: Lesen, Bearbeiten, Schreiben, Bash – beschränkt auf Frontend-Ordner.
Zwei Builder.
Zwei saubere Kontextbereiche.
Null Chance, dass einer die Arbeit des anderen kaputt macht.
Agent 6: Der Test Verifier
Beide Builder haben Unit-Tests für ihren eigenen Code geschrieben.
Das ist nicht genug.
Der Test Verifier macht nur eines: beweisen, dass die Funktion tatsächlich das tut, was die User Story versprochen hat.
Er schreibt Abnahmetests.
Keine Unit-Tests.
Abnahmetests.
Diese testen die Funktion von außen – so, wie ein echter Benutzer sie erleben würde.
Eingabe, die er erhält: → Genehmigte User Story (mit allen Abnahmekriterien) → Genehmigtes technisches Exposé → Zusammenfassungen beider Builder
Was er produziert: → Eine Abnahmetestdatei, die jedes Abnahmekriterium abdeckt → Einen Bericht: welche Kriterien bestanden wurden, welche fehlschlugen, welche nicht sauber abgedeckt werden können
Was er nicht tun kann: → Backend- oder Frontend-Code ändern → Workarounds für nicht testbare Kriterien erfinden → Ein Kriterium als abgedeckt markieren, wenn es das wirklich nicht ist
Wenn ein Test fehlschlägt: die Funktion erfüllt die Story nicht.
Er meldet genau, welches Kriterium fehlgeschlagen ist.
Er flickt den Code nicht.
Das geht zurück an den richtigen Builder.
Werkzeuge: Lesen, Bearbeiten, Schreiben (nur Testdateien), Bash.
Die Regel: Du hast keine Funktion, bis die Abnahmetests bestanden sind.
Agent 7: Der Implementation Validator
Dies ist der Agent, der alles auffängt, was alle anderen übersehen haben.
Der Validator vergleicht die aktuelle Implementierung mit der genehmigten Story und dem Exposé – und meldet Lücken.
Er repariert nie etwas.
Er sagt nur die Wahrheit.
Jede Prüfung, die er jedes Mal durchführt:
→ Abnahmekriterien aus der Story, die noch nicht implementiert sind → Fehlerpfade ohne Testabdeckung → Sicherheitsprobleme: fehlende Authentifizierungsprüfungen, Lücken in der Tenant-Isolation, Geheimnisse in Logs, rohe Fehler, die an Clients weitergegeben werden → Geänderte Dateien außerhalb des vereinbarten Umfangs → Muster, die nicht mit CLAUDE.md oder vorhandenem Code übereinstimmen → Doppelte Logik, die vorhandene Helfer wiederverwenden sollte → Zeitzonen- oder Multi-Tenant-Aspekte aus dem Exposé, die stillschweigend übersprungen wurden
Die Ausgabe ist immer nach Schweregrad gruppiert:
Kritisch – muss vor dem Zusammenführen behoben werden Wichtig – sollte vor dem Zusammenführen behoben werden Geringfügig – meinungsbasiert, Entscheidung des Reviewers
Jeder Befund enthält den Dateipfad und die Zeilennummer.
Wenn nichts falsch ist, sagt er das deutlich.
Er erfindet keine Probleme, um gründlich zu wirken.
Werkzeuge: Nur Lesen, Grep, Glob.
Dieser Agent ist der Grund, warum die Fabrik vertrauenswürdig ist.
Eine selbst benotete Arbeit ist wertlos.
Ein Validator, der nur sieht, was auf der Festplatte ist – nicht, wie es geschrieben wurde – ist ehrlich.
WIE DIE KETTE LÄUFT
Der vollständige Ablauf – ein Prompt startet alles:
Du öffnest Claude Code und tippst:
"Rechnungserinnerungen für Rechnungen erstellen, die seit mehr als 7 Tagen unbezahlt sind."
Folgendes passiert, ohne dass du etwas anderes tippst:
Schritt 1 → Researcher bildet deinen Rechnungs-, Zahlungs- und E-Mail-Code ab. Gibt relevante Dateien, vorhandene Muster, Risiken zurück.
Schritt 2 → Story Writer produziert die User Story und die Abnahmekriterien.
⏸ PAUSE: Du liest und genehmigst die Story.
Schritt 3 → Spec Writer verwandelt die genehmigte Story in ein technisches Exposé.
⏸ PAUSE: Du liest und genehmigst das Exposé.(Erwische den Fehler "Store-IDs im Speicher" genau hier.)
Schritt 4 → Backend Builder implementiert den Dienst, die API-Route, den BullMQ-Job und die Unit-Tests. Gibt zurück: geänderte Dateien, wiederverwendete Muster, alle Tests grün.
Schritt 5 → Frontend Builder liest die API-Zusammenfassung des Backend Builder, baut die Admin-UI-Kachel und den Erinnerungsbutton, schreibt Komponententests. Alle Tests grün.
Schritt 6 → Test Verifier schreibt Abnahmetests für alle sechs Abnahmekriterien. Berichtet: 7 bestanden, 1 fehlgeschlagen – manuelle Auslösung prüft nicht die Tenant-Besitzer.
Schritt 7 → Validator findet es. Meldet es als Kritisch mit Dateipfad und Zeilennummer.
→ Zurück zum Backend Builder. Korrektur angewendet. Alle 8 Abnahmetests bestanden. Validator läuft erneut. Sauber.
⏸ PAUSE: Du prüfst und eröffnest den PR.
Drei menschliche Kontrollpunkte.
Alles andere läuft von selbst.
DIE GRUNDLAGE: BEVOR AGENTEN ARBEITEN, BRAUCHST DU DAS
CLAUDE.md – der Speicher, der jede Sitzung überlebt:
Jedes Mal, wenn du Claude Code öffnest, startet es mit null Speicher.
CLAUDE.md behebt das.
Es ist eine Markdown-Datei im Stammverzeichnis deines Repos, die automatisch in jeder Sitzung geladen wird.
Hier leben die dauerhaften Projektfakten:
→ Dein Stack (Next.js App Router, Node.js, Prisma, BullMQ, Resend) → Deine Befehle (npm run dev, npm test, npx prisma migrate dev) → Architekturregeln ("Geschäftslogik lebt in Services. API-Routen bleiben schlank.") → Was du nicht tun sollst ("Füge kein Cron hinzu – verwende BullMQ. Logge keine rohen Zahlungsdaten.") → Verweise auf tiefere Dokumente (docs/billing.md, docs/architecture.md)
Halte es auf 100-300 Zeilen.
Jedes Mal, wenn die KI einen Fehler macht, der dich überrascht, frage: Hätte eine Regel in CLAUDE.md das verhindert?
Füge die Regel hinzu.
In wenigen Wochen wird dein CLAUDE.md zu einer Aufzeichnung jeder Annahme, die die KI falsch getroffen hat – und deine Sitzungen werden merklich besser.
Context Drift – der stille Killer:
Die meisten Claude Code-Sitzungen scheitern nicht dramatisch.
Sie driften ab.
Eine falsche Annahme gelangt in den Kontext.
Das Modell baut weiter darauf auf.
Du bittest Claude, das Abonnementmanagement zu bauen.
Es entwirft: Benutzer → Abonnement.
Du erinnerst dich: Abonnements gehören zum Unternehmen, nicht zum Benutzer.
Wenn du nur sagst "nein, Abonnements gehören zu Unternehmen" – flickt Claude.
Jetzt schweben sowohl user.subscriptionId als auch company.subscriptionId herum.
Regel:
→ Kleiner Tippfehler? Korrigiere ihn direkt. → Falsche architektonische Annahme? Wirf die Unterhaltung weg und beginne neu mit der richtigen Annahme, die in den ersten Prompt eingebaut ist.
Eine saubere Sitzung mit dem richtigen mentalen Modell schlägt eine geflickte Sitzung jedes Mal.
DIE ERGEBNISSE: WAS SICH WIRKLICH ÄNDERT
Vor der Fabrik:
→ Vibe-Coding-Schleife: Prompt → generieren → Fehler → flicken → wiederholen → Sitzungskontext füllt sich mit Rauschen → Falsche Annahmen verstärken sich zu kaputten Funktionen → Ein Entwickler kann immer nur eine Sache gleichzeitig tun → Jede Funktion wartet darauf, dass die richtige Person verfügbar ist
Nach der Fabrik:
→ Strukturierte Kette: Recherche → Story → Exposé → bauen → verifizieren → validieren → Jeder Agent bekommt einen sauberen Kontextbereich mit nur dem, was er braucht → Falsche Annahmen werden bei der Exposé-Genehmigung abgefangen – nicht nach 10 Dateien → Ein Entwickler liefert einen kompletten vertikalen Schnitt: Backend, Frontend, Tests, Validierung → Das beste Wissen des Teams lebt in den Agenten – nicht gefangen in Personen
Der wirkliche Wandel:
Der Zahlungsspezialist baut einen Zahlungsintegrations-Agenten.
Jetzt kann jeder Entwickler im Team eine Funktion ausliefern, die die Abrechnung betrifft.
Ohne zu warten.
Ohne Übergabe.
Die Komponentenmuster des Frontend-Leads leben im Frontend-Builder-Agenten.
Die CI-Prüfungen des DevOps-Ingenieurs leben in einem Hook.
Die Randfälle des QA-Leads leben in den Test-Verifier-Regeln.
Expertenwissen, geteilt als Agenten.
Nicht gefangen in Verfügbarkeit.
WIE DU DEINE EIGENE AN DIESEM WOCHENENDE BAUST
8-Schritte-Setup-Checkliste:
1. Installiere Claude Code → code.claude.com
2. Erstelle die Ordnerstruktur: → .claude/agents/ → .claude/skills/feature-factory/ → .claude/skills/build-with-tests/ → .claude/hooks/
3. Schreibe deine CLAUDE.md (100–300 Zeilen: Stack, Befehle, Architekturregeln, Verbotene-Liste)
4. Erstelle die 7 Agenten mit dem /agents-Befehl in Claude Code. Beschreibe die Rolle jedes Agenten. Claude schreibt die Datei. Du prüfst und committest.
5. Erstelle die feature-factory-Orchestrator-Fertigkeit. Bitte Claude, sie zu schreiben – sie liest deine 7 Agentendateien und verdrahtet die Kette.
6. Erstelle die build-with-tests-Fertigkeit. Beschreibt, wie dein Team baut: vorhandene Muster befolgen, Tests zusammen mit dem Code schreiben, Typprüfung am Ende ausführen.
7. Füge einen Pre-Commit-Hook hinzu. Blockiert Commits, die .env-, .key-, .pem- oder secrets.json-Dateien enthalten. Dauert 5 Minuten. Verhindert Katastrophen.
8. Führe eine echte Funktion durch die gesamte Kette. Wähle etwas Kleines. Beobachte, wo es hakt. Füge Regeln hinzu. Die Fabrik stimmt sich selbst ein.
Gesamtzeit: 2–3 Stunden.
Dann führe ein paar Funktionen aus.
Nach 3–4 kennt die Fabrik deine Codebase.
Du wirst weniger Zeit mit Beaufsichtigen verbringen.
Mehr Zeit damit, zu entscheiden, was als Nächstes gebaut wird.
DIE 7 AGENTEN – KURZREFERENZ
→ Researcher – bildet den Code ab, bevor etwas gebaut wird (Nur Lesen) → Story Writer – verwandelt Idee in User Story mit Abnahmekriterien (Nur Lesen) → Spec Writer – verwandelt Story in technisches Exposé (Nur Lesen) → Backend Builder – baut API, Dienste, Jobs, Unit-Tests (nur Backend-Ordner) → Frontend Builder – baut Komponenten, Seiten, Hooks, UI-Tests (nur Frontend-Ordner) → Test Verifier – schreibt Abnahmetests gegen die User Story (nur Testdateien) → Validator – vergleicht Implementierung mit Story und Exposé, meldet Lücken (Nur Lesen)
3 menschliche Kontrollpunkte:→ Genehmige die Story → Genehmige das Exposé → Genehmige den PR
Alles andere läuft von selbst.
Die meisten Entwickler, die Claude Code verwenden, betreiben immer noch Vibe Coding.
Prompten → generieren → flicken → hoffen.
Das ist nicht falsch.
Es ist nur eine Obergrenze.
Die Fabrik entfernt dich nicht aus dem Prozess.
Sie entfernt dich aus den Teilen, die dich nicht brauchen.
Du bleibst in der Schleife, in der dein Urteilsvermögen zählt:
Ist das das richtige Problem? Ist das das richtige Design? Ist das sicher auszuliefern?
Die Agenten kümmern sich um alles dazwischen.
Das ist der Unterschied zwischen der Nutzung von KI als schnellere Tastatur –
und der Nutzung von KI als koordiniertes Team.
Falls das hilfreich war:
→ Teile es mit deinem Netzwerk → Folge @sairahul1 für weitere Aufschlüsselungen wie diese → Lesezeichen – du wirst auf die 7 Agenten verweisen wollen
Ich schreibe über KI, Produktentwicklung und Systeme, die arbeiten, während du schläfst.
