Der Motor
Du ziehst ein Ticket auf den Start-Zustand, Anvil Coder plant, zerlegt und baut. Zurück kommt ein Draft-Pull-Request in deinem Repository, mit einem Commit je Arbeitsschritt und einem Laufbericht, der sagt, was geprüft wurde.
Einen echten Lauf nachlesen: ein Laravel-Bugfix, drei Commits, Fix und Regressionstest in 24 Minuten.
Das Ergebnis ist kein Chatverlauf, aus dem jemand Code herauskopiert. Es ist ein Git-Repository mit Historie: jeder Arbeitsschritt hinterlässt seinen Commit, jede Phase ihren Stand. Du liest am Commit, unter welchem Auftrag er entstand, statt zu rekonstruieren, was sich ein Agent gedacht hat. Und was dort liegt, ist prüfbar: von dir, von deiner Pipeline, von einem Auditor.
Ein Sprachmodell hat ein Kontextfenster. Ein echtes Software-Projekt passt nicht hinein, nicht die Anforderungen, nicht der bestehende Code, nicht beides zugleich. Wer trotzdem ein ganzes Projekt in einen Prompt legt, bekommt eine Skizze zurück, kein Programm.
Prompt Slicing ist die Antwort: die Anforderungen werden nicht zusammengefasst, sondern zerlegt. Jeder TaskSlice ist klein genug, dass er vollständig in einen Prompt passt, mitsamt dem Kontext, den genau dieser Schritt braucht. Darum bleibt die Qualität beim zweihundertsten Schritt dieselbe wie beim ersten.
Nicht jeder Auftrag beginnt als fertiges Ticket. Für den Text, der noch keiner ist, gibt es im Cockpit das Spec-Studio: eine geführte Spezifikation in sieben Abschnitten, vom Ziel über Rollen und Abläufe bis zum Stack-Profil, jeder mit einem Rückfrage-Chat, der Lücken benennt statt sie zu überschreiben. Am Ende entstehen echte Tickets: Epics und Stories in deinem Tracker, auf Wunsch samt neu angelegtem Repository.
Das Studio schreibt Tickets, keinen Code. Welche Story läuft, entscheidest du, Story für Story. Die Anleitung steht in der Dokumentation.
Die Ausführung läuft auf zwei Ebenen, die sich kreuzen. Phasen laufen nacheinander und sind durch Barrieren getrennt: eine Phase beginnt erst, wenn alle Schritte der vorigen fertig sind. TaskSlices laufen innerhalb einer Phase parallel. Das ist der Unterschied zwischen „schneller tippen“ und „mehr gleichzeitig bauen“: die Reihenfolge bleibt, wo sie fachlich zählt, und fällt weg, wo sie nur bremst.
Am Ende prüft der Konsistenz-Durchgang das Ganze. Misst er eine Verschlechterung, schickt er die betroffenen Schritte in gedeckelte Reparatur-Runden; kann er nicht messen, lässt er den Lauf durch und vermerkt das am Gate, damit du es im Laufbericht siehst statt es zu übersehen.
Zwei Dinge solltest du wissen: Abgleich, Verifikation und der Build-und-Test-Durchgang sind je Projekt schaltbar und im gemieteten Dienst eingeschaltet, und fehlen deinem Projekt die Build-Werkzeuge in der Sandbox, markiert der Lauf das Ergebnis als unverifiziert, statt es grün zu nennen.
Ein Worker nimmt genau einen TaskSlice, führt einen Prompt aus, validiert das Ergebnis und committet es. Kein Worker sieht den Gesamtplan; er sieht seinen Schritt und den Kontext, den dieser Schritt braucht. Den Plan hält der Coordinator, der die Slices über eine dauerhafte Warteschlange verteilt.
Fällt ein Worker aus, geht sein Slice nicht verloren, er wird erneut zugestellt. Staut sich die Warteschlange, kommen Worker dazu; ist sie leer, fährt die Flotte auf null.
Ein Lauf ist kein schwarzer Kasten. Im Cockpit verfolgst du live, welcher Schritt gerade bearbeitet wird, welche Änderungen entstehen und welche Zwischenschritte das Modell nimmt.
Dazu gehören die Kosten: nicht am Monatsende zusammengefasst, sondern je Schritt einzeln ausgewiesen. Wo die Zeit oder das Geld eines Laufs hingegangen ist, steht im Lauf selbst, nicht in einer Rekonstruktion danach.