Für Produktteams
Anvil Coder nimmt Tickets aus deinem Backlog und setzt sie im bestehenden Repository um. Deine Architekturregeln stehen in jedem einzelnen Arbeitsschritt, jeder Schritt hinterlässt seinen Commit, und das Ergebnis kommt als Draft-Pull-Request in deine Review-Queue. Montagmorgen ist der Backlog kleiner, und dein Team entscheidet nur noch.
Dienstag, 14:00. Sechs Agenten-PRs à 800 Zeilen in der Queue, keine Spur, warum der Agent es so gebaut hat, Standup in einer Stunde. Die Werkzeuge, die helfen sollten, haben den Engpass ins Review verschoben. Du bist der Flaschenhals und weisst es.
Die Alternative ist, die Durchführung zu verlagern und die Entscheidung zu behalten. Wie viel Aufsicht du dabei behältst, ist eine Einstellung je Projekt, von jede Aktion braucht eine Freigabe bis nur die folgenreichen; ohne gesetzte Stufe läuft der Auftrag durch. Der Übergabepunkt bleibt in jedem Fall derselbe: ein Draft-Pull-Request in deinem Repository, den ein Mensch merged.
Jedes Team hat Architekturvorgaben. Die meisten stehen in einem Dokument, das beim Onboarding gelesen und danach vergessen wird, und die Abweichung fällt im Review auf, wenn sie schon gebaut ist.
Bei Anvil Coder ist die Vorgabe Teil des Auftrags. Guardrails stehen in jedem Prompt; ein Stack-Profil hält Sprache, Framework, Architektur und Versionsstände fest und wird vorn in die Prompts gerendert. Was von der Vorgabe abweicht, fällt dort auf, wo es entsteht.