Anvil CoderAnmelden

Für Produktteams

Du hast die Architektur dreimal ins Rules-File geschrieben. Es liest sie und baut daran vorbei.

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.

Die Durchführung abgeben, die Entscheidung behalten

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.

Governance, die nicht im Wiki steht

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.

Wie ein Auftrag ins System kommt

Der Auslöser ist eine Story
Du ziehst eine Story auf den Trigger-Zustand, im internen Board oder in YouTrack, Jira, GitHub oder GitLab. Das System übernimmt sie, plant, führt aus und setzt den Zustand am Ende auf „To Verify“.
Barrieren statt Vertrauen
Eine Phase beginnt erst, wenn alle Arbeitsschritte der vorigen fertig sind. Am Ende prüft ein Konsistenz-Durchgang das Ganze gegeneinander, bevor etwas in deine Review-Queue kommt.
Ein Commit je Schritt
Jeder Arbeitsschritt hinterlässt seinen eigenen Commit mit dem Auftrag, unter dem er entstand. Du liest den PR wie ein Protokoll, nicht wie einen Tausend-Zeilen-Diff.
Der Stack ist ein Vertrag
Sprache, Framework, Architektur und Versionsstände stehen als Stack-Profil vorn in jedem Prompt. Auf Wunsch prüft ein Gate am Ende noch einmal dagegen.