--- titel: "Wie es funktioniert" adresse: https://anvil-coder.tech/wie-es-funktioniert beschreibung: "Anvil Coder zerlegt Requirements in einen gerichteten Graphen atomarer Arbeitsschritte, führt sie parallel aus und liefert ein fertiges Git-Repository — jeder Schritt gegen dieselben Invarianten geprüft." sprache: de --- Der Motor # Vom Anforderungstext zum fertigen Repository Anvil Coder ist ein System zur autonomen Software-Fertigung: es zerlegt Requirements in einen gerichteten Graphen atomarer Arbeitsschritte, führt diese Schritte parallel aus und liefert am Ende ein Git-Repository mit lauffähigem, getestetem Code. Jeder einzelne Schritt wird dabei gegen dieselben Invarianten geprüft. ## Das Problem, das gelöst werden musste 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 darauf: 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. ## Zwei Achsen: Phasen und Slices 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 Arbeitsschritte der vorigen fertig sind. Am Ende steht ein Konsistenz-Durchgang über das Ganze. Er ist so gebaut, dass eine fehlende oder gestörte Messung nichts durchwinkt: er meldet dann rot und schickt die betroffenen Arbeitsschritte in gedeckelte Reparatur-Runden. Die Messung selbst ist zuschaltbar und im betriebenen Dienst noch nicht eingeschaltet. Ein zusätzlicher Build- und Test-Durchgang über den Gesamtstand ist zuschaltbar; im betriebenen Dienst ist er an. **TaskSlices** laufen innerhalb einer Phase parallel — so viele gleichzeitig, wie die Betriebsart Worker bereitstellt. Das ist der Unterschied zwischen „schneller tippen" und „mehr gleichzeitig bauen": die Reihenfolge bleibt gewahrt, wo sie fachlich zählt, und fällt weg, wo sie nur bremst. **REQUIREMENTS** Aus der Aufgabenbeschreibung entsteht ein geprüftes Anforderungsbild — offene Punkte werden als Annahmen festgehalten und sind im Lauf sichtbar. **ARCHITECTURE** Struktur, Schnittstellen und Abhängigkeiten werden festgelegt, bevor die erste Zeile Code entsteht. **IMPLEMENTATION** Die eigentliche Arbeit: jeder TaskSlice ist genau ein AI-Prompt auf einem Worker, mit eigenem Arbeitsbaum. **RECONCILIATION (zuschaltbar, im Betrieb an)** Die parallel entstandenen Teile werden gegeneinander geprüft und zusammengeführt. **TEST** Tests entstehen als eigene Arbeitsschritte, nicht als Nachgedanke. **VERIFY (zuschaltbar, im Betrieb an)** Das Ergebnis wird gegen die Anforderungen geprüft — nicht gegen die Absicht, die es erzeugt hat. **DOCUMENTATION** Was gebaut wurde, wird beschrieben, solange der Kontext noch da ist. **CONSISTENCY** Ein letzter Durchgang über das Ganze: passt zusammen, was getrennt entstand? Ein Epic, auf den Trigger-Zustand gezogen, zerlegt sich selbst in gleich geschnittene User Stories — laufen darf jede erst, wenn ein Mensch sie einzeln freigibt. ## Was ein Worker tut Ein Worker nimmt genau einen TaskSlice entgegen, führt einen AI-Prompt aus, validiert das Ergebnis und committet es. Kein Worker sieht den Gesamtplan; er sieht seinen Schritt und den Kontext, den dieser Schritt braucht. Die Koordination liegt beim Coordinator, der den Graphen hält und die Slices über eine dauerhafte Warteschlange verteilt. Fällt ein Worker aus, geht sein Slice nicht verloren — er wird erneut zugestellt. Bleibt ein Slice unbestätigt liegen, zählt er als Bedarf und ein Worker wird nachgezogen*(zuschaltbar)*. ## Was du während des Laufs siehst Ein Lauf ist kein schwarzer Kasten. Im Cockpit lässt sich live mitverfolgen, was gerade passiert: welcher TaskSlice bearbeitet wird, welche Änderungen dabei entstehen und welche Zwischenschritte das Modell nimmt. Dazu gehören auch die Kosten — nicht am Monatsende zusammengefasst, sondern je TaskSlice einzeln ausgewiesen: welcher Schritt wie viel verbraucht hat. Wer nachvollziehen will, wo die Zeit oder das Budget eines Laufs hingegangen ist, findet die Antwort im Lauf selbst, nicht in einer nachträglichen Rekonstruktion. ## Am Ende steht ein Repository, kein Vorschlag Das Ergebnis ist kein Chatverlauf, aus dem jemand Code herauskopiert. Es ist ein Git-Repository mit Historie: jeder TaskSlice hinterlässt seinen Commit, jede Phase ihren Stand. Was dort liegt, ist prüfbar — von einem Menschen, von einer Pipeline, von einem Auditor. ## Selbst ausprobieren oder erst besprechen? Beides geht. Selbst ausprobieren zeigt am schnellsten, ob der Ablauf zu euren Aufträgen passt; für Fragen zu Datenhoheit, Betrieb und Abrechnung ist ein Gespräch der kürzere Weg. [Kostenlos starten](https://app.anvil-coder.tech/register)[Demo vereinbaren](https://anvil-coder.tech/demo)