Vier KI-Agenten können ein Feature ausliefern, während du schläfst. Die meisten richten sie nie ein.
Sie feuern hier einen Reviewer an, dort einen Test-Generator, manuell, einen nach dem anderen, jeder vergisst, was der letzte getan hat. Du bleibst der Engpass.
Die Lösung: Planer → Programmierer → Tester → Reviewer, automatisch verkeitet zur Übergabe. Ein Auslöser, vier Stufen, ein fertiges Feature bis zum Morgen.
Hier ist die vollständige Pipeline mit Copy-Paste-Code 👇
Bevor wir eintauchen, teile ich tägliche Notizen zu KI & Vibe Coding in meinem Telegram-Kanal: https://t.me/zodchixquant 🧠
Warum eine Pipeline besser ist als ein Haufen Agenten
Ein einzelner Agent, der alles erledigt, füllt seinen Kontextfenster mit Planung, Code, Tests und Review-Notizen, bis die Qualität leidet.
Vier Spezialisten bleiben jeweils in einem sauberen, schmalen Kontext.
Der Trick ist die Übergabedatei. Jeder Agent schreibt seine Ausgabe dort hin, wo der nächste sie lesen kann: Der Planer hinterlegt eine Spezifikation unter .pipeline/spec.md, der Programmierer liest sie und schreibt .pipeline/changes.md, und so weiter.
Der Orchestrator, der sie der Reihe nach ausführt, ist ein einziger Slash-Befehl. Das ist das Ganze: vier Unteragenten, ein Befehl, ein gemeinsamer Ordner für Übergaben.
Agent 1: Der Planer (Unteragent, opus)
Der Planer schreibt nie Code. Er verwandelt eine vage Feature-Anfrage in eine konkrete Spezifikation, der der Programmierer ohne Ratespiele folgen kann.
Erstelle .claude/agents/planner.md:
1---2name: planner3description: Verwandelt eine Feature-Anfrage in eine Implementierungsspezifikation. Verwende dies als erste Stufe der Feature-Pipeline.4tools: Read, Grep, Glob, Write5model: opus6---78Du bist ein Planungsspezialist. Du schreibst KEINEN Implementierungscode.910Bei einer Feature-Anfrage:111. Lies die relevanten Teile der Codebasis, um die aktuellen Muster zu verstehen.122. Schreibe eine Spezifikation nach `.pipeline/spec.md` mit:13 - Dateien, die erstellt oder geändert werden müssen, mit genauen Pfaden14 - Die benötigten Interfaces oder Funktionssignaturen15 - Grenzfälle, die die Implementierung behandeln muss16 - Welche bestehenden Muster zu befolgen sind (nenne die Datei, von der kopiert werden soll)173. Markiere alles Mehrdeutige als OFFENE FRAGE am Anfang der Spezifikation.1819Halte die Spezifikation knapp. Der Programmierer liest nur dies und sonst nichts, also hinterlasse keine Lücken und erfinde keine Anforderungen, die nicht gefragt waren.
Die Planung läuft auf opus, weil diese Stufe das Qualitätslimit für alles Weitere setzt. Eine vage Spezifikation erzeugt vagen Code, egal wie gut der Programmierer ist.
Agent 2: Der Programmierer (Unteragent, sonnet)
Der Programmierer liest die Spezifikation und schreibt die Implementierung. Er plant nicht und überprüft seine eigene Arbeit nicht, er baut einfach das, was die Spezifikation sagt.
Erstelle .claude/agents/coder.md:
1---2name: coder3description: Implementiert die Spezifikation unter .pipeline/spec.md. Verwende dies als zweite Stufe der Feature-Pipeline, nach dem Planer.4tools: Read, Write, Edit, Grep, Glob, Bash5model: sonnet6---78Du bist ein Implementierungsspezialist.9101. Lies `.pipeline/spec.md` vollständig. Falls OFFENE FRAGEN vorhanden sind, stoppe und zeige sie an, anstatt zu raten.112. Implementiere genau das, was die Spezifikation beschreibt. Befolge die von ihr genannten Muster. Füge keine Funktionen hinzu, die nicht gefragt waren.123. Schreibe eine kurze Zusammenfassung nach `.pipeline/changes.md`: welche Dateien geändert wurden, was jede Änderung bewirkt und worauf der Tester sich konzentrieren sollte.1314Du schreibst Code, der zum Repository passt. Du refaktorisierst keinen unzusammenhängenden Code und „verbesserst" nichts außerhalb des Spezifikationsumfangs.
Sonnet ist hier die richtige Wahl: Implementierung gegen eine klare Spezifikation ist genau die ausgewogene Kosten-Qualitätsarbeit, die Sonnet am besten beherrscht.
Die Übergabenotiz unter .pipeline/changes.md ermöglicht es dem Tester, sich auf die richtige Oberfläche zu konzentrieren, anstatt blind zu testen.
Agent 3: Der Tester (Unteragent, sonnet)
Der Tester liest, was geändert wurde, und schreibt Tests, die beweisen, dass das Feature funktioniert, und führt sie dann aus.
Erstelle .claude/agents/tester.md:
1---2name: tester3description: Schreibt und führt Tests für Änderungen aus, die in .pipeline/changes.md beschrieben sind. Dritte Stufe der Feature-Pipeline.4tools: Read, Write, Edit, Grep, Glob, Bash5model: sonnet6---78Du bist ein Testspezialist.9101. Lies `.pipeline/changes.md`, um zu sehen, was gebaut wurde und wo.112. Lies die geänderten Dateien und die Spezifikation unter `.pipeline/spec.md`.123. Schreibe Tests, die abdecken: den glücklichen Pfad, die Grenzfälle, die die Spezifikation genannt hat, und mindestens einen Fehlerfall. Verwende das Testframework des Repositorys.134. Führe die Tests aus. Falls welche fehlschlagen, schreibe die Fehler nach `.pipeline/test-results.md` und STOPPE. Korrigiere den Code nicht selbst.145. Wenn alle bestanden sind, vermerke dies in `.pipeline/test-results.md`.1516Du testest Verhalten, nicht Implementierungsdetails. Ein fehlgeschlagener Test bedeutet, dass die Pipeline für den Reviewer pausiert, nicht dass du ihn umgehst.
Agent 4: Der Reviewer (Unteragent, opus)
Das letzte Tor. Der Reviewer liest alles, was die Pipeline produziert hat, und gibt ein Urteil ab, bevor etwas in den Hauptzweig gelangt.
Erstelle .claude/agents/reviewer.md:
1---2name: reviewer3description: Endgültige Überprüfung der gesamten Pipeline-Ausgabe. Vierte und letzte Stufe vor der menschlichen Freigabe.4tools: Read, Grep, Glob, Bash5model: opus6---78Du bist ein leitender Reviewer. Du bist schreibgeschützt. Du bearbeitest keinen Code.9101. Lies die Spezifikation, die Zusammenfassung der Änderungen und die Testergebnisse aus `.pipeline/`.112. Führe `git diff` aus, um die tatsächlichen Änderungen zu sehen.123. Bewerte: Entspricht der Code der Spezifikation? Sind die Tests aussagekräftig oder oberflächlich? Gibt es Sicherheits-, Leistungs- oder Korrektheitsprobleme?134. Schreibe ein Urteil nach `.pipeline/review.md`:14 - URTEIL: AUSLIEFERN / ÜBERARBEITUNG NÖTIG / BLOCKIERT15 - Bei ÜBERARBEITUNG NÖTIG oder BLOCKIERT liste genau auf, was zu beheben ist und wo.1617Sei die letzte Verteidigungslinie. Wenn die Tests grün sind, aber der Code falsch ist, sage BLOCKIERT. Grüne Tests sind nicht dasselbe wie korrektes Verhalten.
Schreibgeschützte Werkzeuge bedeuten, dass der Reviewer Probleme nicht durch Bearbeiten übertünchen kann – er kann nur urteilen.
Der Orchestrator: ein Befehl, um alle vier auszuführen
Jetzt das Stück, das aus vier separaten Agenten eine Pipeline macht. Ein Slash-Befehl, der sie der Reihe nach aufruft, wobei jeder die Übergabedatei aufnimmt, die der letzte geschrieben hat.
Erstelle .claude/commands/ship.md:
1Führe die vollständige Feature-Pipeline aus für: $ARGUMENTS23Führe diese Stufen der Reihe nach aus. Überspringe keine. Bestätige nach jeder Stufe, dass die Übergabedatei existiert, bevor du die nächste startest.451. Delegiere an den Unteragenten `planner` mit der obigen Feature-Anfrage.6 Warte auf `.pipeline/spec.md`.72. Falls die Spezifikation OFFENE FRAGEN hat, stoppe und zeige sie mir. Andernfalls8 delegiere an den Unteragenten `coder`. Warte auf `.pipeline/changes.md`.93. Delegiere an den Unteragenten `tester`. Warte auf `.pipeline/test-results.md`.10 Falls Tests fehlschlagen, stoppe und zeige mir die Fehler.114. Delegiere an den Unteragenten `reviewer`. Zeige mir `.pipeline/review.md`.1213Melde das endgültige Urteil. Führe nichts zusammen. Hinterlasse den Branch für meine morgendliche Überprüfung.
Dann startet eine einzige Zeile die gesamte Kette: /ship Ratenbegrenzung zum Login-Endpunkt hinzufügen.
Wo ich die Über-Nacht-Version betreibe
Dafür verwende ich Teamly: verwaltetes Cloud-Hosting, das speziell für KI-Agenten entwickelt wurde.
Du stellst ein Team ein, es läuft rund um die Uhr auf dedizierter Infrastruktur, und du berührst nie einen Server.
Der Grund, warum @Teamly speziell zu diesem Artikel passt: Das Übergabeproblem ist für dich bereits gelöst.
Alles, was wir oben von Hand gebaut haben (die Spezifikationsdatei, die Änderungsdatei, der Orchestrator, der einen Agenten an den nächsten kettet), erledigt Teamly mit einem Koordinator.
Er leitet Arbeit zwischen Agenten weiter, gibt Kontext von einem zum nächsten und führt ein gemeinsames Briefing, das alle lesen.
Derselbe Planer-zu-Programmierer-zu-Tester-Fluss, nur dass du die Übergaben nicht selbst verdrahten musst.
Der Unterschied ist, dass @Teamly nicht nur Code ist. Dieselbe Orchestrierung betreibt ein Marketing-Team, ein Forschungsteam oder ein Support-Team.
Deine Claude-Code-Pipeline liefert Features über Nacht; ein Teamly-Marketingteam liefert Inhalte auf die gleiche Weise, mit derselben Übergabelogik darunter.
Baue genau das Team, das du brauchst
Neues Feature, das gerade ausgerollt wurde: Mein Team
Jetzt kannst du dein Team mit nur 3 Fragen zusammenstellen.
Du kannst auch steuern: Sprachregeln, verbotene Phrasen, Integrationen, Team-Stil (Streng / Locker / Kreativ) und Teamgröße (2-4 Agenten).
@Teamly gibt dir ein Team mit einer echten Begründung, warum jeder Spezialist da ist, nicht nur Standardfloskeln. Tausche jeden Agenten mit einem Klick aus. Bearbeite das Briefing, falls es nicht passt.
Der Punkt ist ein strukturiertes Briefing, das Klarheit erzwingt, und dann stellt es ein Team zusammen, das du vor der Einstellung prüfen kannst.
Dieselbe Übergabe-Architektur wie bei den vorgefertigten Teams, zugeschnitten auf dein spezifisches Problem.
Teste es zuerst kostenlos
Du kannst das Ganze 3 Tage lang kostenlos auf Teamly 5 testen, keine Kosten bis Tag 4.
Wenn du bleibst, liegt der Preis bei 29 $/Monat für 5 Agenten.
Günstig genug, dass ein ausgeliefertes Feature den Monat bezahlt.
Das Fazit
Der Unterschied zwischen einem Haufen Agenten und einer Pipeline ist die Übergabe.
Vier Spezialisten, die in gemeinsame Dateien schreiben, ein Orchestrator, der sie der Reihe nach ausführt, jede Stufe baut auf der letzten auf, anstatt von vorne zu beginnen.
Baue zuerst den Planer und den Programmierer und lasse sie als zweistufige Kette laufen. Sobald dieser Ablauf solide ist, füge den Tester und den Reviewer hinzu.
Wenn alle vier verdrahtet sind, startest du ein Feature vor dem Schlafengehen und liest ein Urteil bei deinem Kaffee.
Für tägliche Notizen zu KI-Agenten, Vibe Coding und Claude Code-Setups: https://t.me/zodchixquant 🧠**
