Fareed Khan beschreibt, wie er aus Claude-Code-Subagenten eine Engineering-Organisation gebaut hat (Originalartikel): ein Orchestrator in der Rolle des Staff Engineers, ein Roster spezialisierter Rollen, ein „Employee Handbook" aus mehr als vierzehn Skills und harte Gates an jedem Übergang der Pipeline design → plan → execute → review → ship. Ich betreibe eigene Subagenten-Teams — vier Rollen, verpflichtendes paralleles Review plus Testkontrolle, Isolation in Git-Worktrees, maximal fünf Iterationen pro Korrekturzyklus — und habe den Artikel als fremdes Production-Setup gelesen, nicht als Manifest. Punkt für Punkt: wo ich zustimme, was ich übernehme, was ich nicht glaube.
Kontextisolation ist der Kern, und sie funktioniert
Die zentrale These: Ein Subagent erbt nicht die Session-Historie, sondern bekommt genau das, was die Aufgabe braucht. Der Autor nennt das Schutz vor dem „müden Senior", der nach einer Stunde Arbeit die Anforderungen benachbarter Features verwechselt. Meine Erfahrung bestätigt das: Im Vier-Rollen-Team findet ein Reviewer, der den Austausch zwischen Orchestrator und Entwickler nie gesehen hat, Probleme, die ein eingelaufener gemeinsamer Kontext zuverlässig übersieht. Frischer Kontext pro Rolle ist der günstigste Hebel für die Qualität von Multi-Agent-Arbeit — günstiger als jeder Prompt-Trick. Was diese Isolation an Tokens kostet, ist ein eigenes Thema.
Verification-before-completion: übernehme ich als Regel
Die Formel des Autors: „Arbeit ohne Verifikation für abgeschlossen zu erklären ist Unehrlichkeit, keine Effizienz." Dazu gehört eine Tabelle Behauptung → erforderlicher Beleg: „Tests bestanden" heißt frische Kommandoausgabe in derselben Nachricht — nicht „sie sollten bestehen" und nicht „gestern liefen sie durch". Bei mir lebte diese Disziplin als Gewohnheit, nirgends als Regel fixiert — und eine Gewohnheit rutscht unter Deadline-Druck als Erstes weg. Die Formulierung wandert fast wörtlich in meine Team-Templates.
TDD für Dokumentation: die beste Idee des Artikels
Ein Skill gilt erst als fertig, wenn er einen RED/GREEN-Zyklus auf einem frischen Subagenten bestanden hat: Erst wird festgehalten, dass der Agent ohne den Skill die Regel unter Druck bricht, dann, dass er sie mit dem Skill einhält. Kaum jemand testet Dokumentation so, obwohl Skills Code sind, den ein LLM ausführt. Dazu eine präzise Beobachtung: Die Description eines Skills muss die Frage „wann anwenden" beantworten, nicht „was er tut" — sonst liest das Modell die Beschreibung, hält die Sache für verstanden und öffnet den Volltext nie. Ich habe meine eigenen Skills geprüft: Die Hälfte der Descriptions ist genau in diesem Sinn falsch geschrieben.
Die 1%-Regel: elegant, aber ich glaube nicht daran
Die Regel — „besteht auch nur ein Prozent Chance, dass ein Skill anwendbar ist, muss der Agent ihn aufrufen" — schützt den Prozess vor Erosion durch Rationalisierungen („ist doch nur eine Frage"). Das Problem ist der Preis: Totale Verbindlichkeit macht aus jeder Kleinigkeit eine Prozession von Skill-Lektüren. Routing ist billiger: Ein Skill triggert nach Aufgabentyp, nicht nach Anwendbarkeitswahrscheinlichkeit. Prozesserosion fängt ein gelegentliches Session-Audit zuverlässiger ab als eine Steuer auf jede Aktion.
Die Delete-Regel: lasse ich ebenfalls aus
Die Forderung, sämtlichen vor dem Test geschriebenen Code zu löschen — ohne „als Referenz behalten" — ist als Iron Law deklariert. Als Manifest nachvollziehbar: Tests-after prüfen, was implementiert wurde, Tests-first prüfen, was implementiert werden soll. Als Alltagspraxis ist es verschwenderisch: Einen funktionierenden Entwurf wegzuwerfen, um dasselbe gegen einen Test neu zu schreiben, lohnt sich im Übungsszenario und fast nie in einer echten Aufgabe mit Budget.
Fazit
Ein starres Gerüst mit Iron Laws lohnt sich dort, wo mehrere Agenten lange und unbeaufsichtigt arbeiten: Vorhersagbarkeit ist mehr wert als Tokens. Für ein persönliches Setup übernimmt man besser drei Dinge — Kontextisolation pro Rolle, ein Verification-Gate vor jedem „fertig" und den RED/GREEN-Test für die eigenen Skills — und lässt das Gerüst zurück. Der Autor streitet dabei fair: Das System liegt als offenes Repository vor, Widerspruch lässt sich also per Experiment klären statt per Rhetorik. Was mit diesem Rahmen passiert, wenn die Regeln zunehmen — Tuning im Maßstab.