Anubhav hat ein halbes Jahr damit verbracht, sein Agenten-Setup zu optimieren, und beschreibt den achtschichtigen Stack, der nach seinen Worten «finally worked»: eine kurze Projekt-Memory-Datei (er besteht darauf, sie «under 500 tokens on purpose» zu halten, um Cache-Treffer zu sichern), pfadgebundene Regeln, den Planungsmodus, einen einzigen schreibgeschützten Reviewer-Subagenten auf einem günstigen Modell, Skills, Hooks, fünf MCP-Server sowie parallele Worktrees mit Headless-Modus in der CI. Sein Fazit ist schroff: «The stack is the workflow. The workflow is the multiplier. The prompt is just the last five percent.» Diesem Schlusssatz stimme ich vollständig zu. Mein Einwand liegt woanders: Ich baue an einem ähnlichen Stack seit deutlich länger als sechs Monaten — mit Multi-Agent-Teams, parallelem Review und Tests, Kontext-Routing und Schichten harter Regeln —, und ausgerechnet die erste Schicht, die Anubhav das Fundament nennt, bricht bei meiner Größenordnung zusammen.
Meine These ist einfach. Der Rat «halte die Memory-Datei winzig» stimmt für einen einzelnen Entwickler in einem einzigen Repository. Doch sobald man Compliance-Regeln aus mehreren Organisationen hat, die sich nicht an Dateipfade binden lassen, hört eine kleine flache Datei auf, eine Tugend zu sein, und wird zu einer fehlenden Fähigkeit. Anubhav vermengt zwei verschiedene Probleme: die Token-Kosten des Hintergrundkontexts und die Autorität und Vorrangstellung von Regeln. Sein Achtschichten-Rezept löst nur das erste.
Wo er recht hat, und zwar wirklich
Fast alles in seinem Artikel ist der Punkt, an dem ich einst begonnen habe, und es sind die richtigen Primitive. Pfadgebundene Regeln sparen Token genau so, wie er es beschreibt: Eine Datei mit Migrations-Konventionen sollte nicht laden, wenn der Agent das Frontend anfasst. Der Planungsmodus mit einem schreibgeschützten Subagenten, dem write und edit ausdrücklich verweigert sind, ist saubere Hygiene — Exploration und Prüfung leben in einem isolierten Kontext, nicht in der Hauptschleife.
Besonders gut ist sein Fokus auf Deferred Permissions. Einen Agenten mitten im Headless-Lauf pausieren zu können, die Aktion außerhalb des Prozesses zu genehmigen und exakt an derselben Stelle fortzusetzen, ist das richtige Primitiv für nächtliche Jobs. Zuvor lief, wie er treffend bemerkt, ein nächtlicher Lauf, der nach main pushen musste, entweder mit deaktivierten Berechtigungen oder scheiterte um drei Uhr morgens. Auch seine Subagenten mit enger Tool-Allowlist, heruntergestuft auf ein günstiges Modell, sind sinnvoll: Das teure Modell bleibt beim schweren Schlussfolgern, während der Reviewer günstig im Hintergrund läuft. Hier widerspreche ich nicht — ich nutze das.
Wo es an seine Decke stößt
Die Decke beginnt genau dort, wo Anubhav das Fundament legt. Seine erste Schicht ist der Rat, die Root-Memory-Datei winzig zu halten, weil «Cache hit rates drop noticeably past ~500 tokens». Das Token-Argument stimmt. Doch er setzt stillschweigend «günstiger in Token» mit «besser strukturiert» gleich — und das sind verschiedene Achsen.
Bei mir kommen Regeln zugleich aus mehreren Organisationen und Teams. Einige sind harte Compliance-Regeln: was in Commit-Nachrichten für bestimmte Remotes auftauchen darf und was nicht, welche Produktiv-Aktionen eine namentliche Freigabe erfordern, welche Organisationsregel eine engere Team-Schicht nicht überschreiben kann. Diese Regeln lassen sich nicht per Dateipfad globben. Sie müssen nach Organisation, Team und Funktion auslösen — danach, wo man sich befindet und in wessen Auftrag man arbeitet, nicht danach, welche Datei man bearbeitet. Anubhavs pfadgebundener Mechanismus greift hier schlicht nicht: Es gibt kein Glob, das ausdrückt «diese Organisationsregel überschreibt die Team-Regel».
Deshalb stopfe ich nicht alles in eine Datei und schrumpfe sie nicht — ich route die Regeln beim Sitzungsstart entlang dreier Achsen: Organisation, Team, Funktion. Nur das relevante Tripel lädt in den Kontext. Das löst beide Probleme zugleich: Token und Vorrangstellung. Anubhav löst nur die Token; seine «kleine Datei» beseitigt die Hintergrundkosten, sagt aber nichts darüber, welche Regel gewinnt, wenn zwei Schichten einander widersprechen. Bei seiner Größenordnung stellt sich die Frage nie. Bei meiner stellt sie sich am ersten Tag.
Der zweite Punkt, an dem es an die Decke stößt, ist sein einziger schreibgeschützter Reviewer. Ein Reviewer-Subagent ohne Terminierungsgarantie ist gerade deshalb gefährlich, weil er stillschweigend annimmt, ein Review-Durchlauf konvergiere. Bei mir laufen Review und Tests parallel, und sie geraten gelegentlich in Konflikt — der Reviewer sagt «blocker», der Tester sagt «grün». Wer hat recht? Ein einzelner Subagent hat darauf keine Antwort und keine Obergrenze für Iterationen. Deshalb hat meine Architektur einen harten Guard von fünf Iterationen und einen Lead-Orchestrator, der den Konflikt zwischen Reviewer und Tester schlichtet. Genau das ist der teure Teil, den eine Team-Architektur übernimmt — und den ein einzelner Reviewer auf einem günstigen Modell nicht abdeckt.
Noch ein Detail zu seinem Approval-Gate. Sein Schutz-Hook für Pushes nach main ist ein String-Match: case "$cmd" in *"git push"*" main"*). Er fängt die vertraute Form des Befehls. Doch ein String-Match wird trivial umgangen — durch einen anderen, gleichbedeutenden Befehl, eine Variable, einen Alias. Meine Approval-Gates sind semantisch: Sie lösen auf eine Aktionsklasse aus (ein Schreibzugriff auf ein gemeinsam genutztes externes System, eine destruktive Operation in der Produktion), nicht auf einen konkreten String. Das ist der Unterschied zwischen «Schutz vor einem Tippfehler» und «Schutz vor einer Umgehung».
Was man dagegen tun sollte
Wer solo in einem einzigen Repository arbeitet, übernehme Anubhavs Rezept ganz — es ist präzise. Eine kleine imperative Memory-Datei, zwei, drei pfadgebundene Regeln, ein Formatierungs-Hook, der Planungsmodus für alles Riskante. Deferred Permissions: Pflicht.
Doch sobald Regeln aus mehreren Organisationen ins Spiel kommen, hör auf, über die Dateigröße nachzudenken, und fang an, über Routing und Vorrangstellung nachzudenken. Trenne die beiden Achsen, die Anubhav verklebt: Token betreffen den Cache, Autorität betrifft, welche Regel welche überschreibt. Verlagere harte Compliance-Regeln in eine Schicht, die nach Sitzungskontext lädt, nicht per Glob. Und sobald das Review mehr als einen Durchlauf umfasst, gib ihm eine ausdrückliche Iterations-Obergrenze und einen Schiedsrichter für Konflikte — sonst dreht der «günstige Reviewer» eines Tages eine Endlosschleife in einem teuren Lauf.
Im Wesentlichen sind wir uns einig: Der Stack schlägt den Prompt. Anubhav hört nur an der Grundlinie auf, von der ich gestartet bin. Seine achte Schicht ist meine Schicht null.