The engine
Anvil Coder plans a ticket and divides implementation into small work steps. These produce commits and, in the hosted service, a draft pull request. Build and tests are optional, enabled in the hosted service and require a matching toolchain; results that cannot be verified remain labelled as such.
Follow a Laravel bug fix through a recorded run, including the test that could not be executed in its sandbox.
A language model has a context window. A real software project does not fit inside it — not the requirements, not the existing code, certainly not both at once. Put a whole project into one prompt anyway and you get a sketch back, not a program.
Prompt slicing is the answer: the requirements are not summarised, they aredecomposed. Each TaskSlice is small enough to fit into a prompt completely — together with the context that this particular step needs.
Not every order starts as a finished ticket. For the text that is not one yet, the cockpit has the Spec Studio: a guided specification in seven sections — from goal through roles and flows to the stack profile — each with its own follow-up chat that names gaps instead of papering over them. At the end the studio turns it into real tickets: epics and stories in the chosen tracker, on request together with a newly created repository.
The studio writes tickets, not code — the run still starts where it always starts: at the ticket, triggered by a person. The guide (in German) lives in thedocumentation.
Execution runs on two crossing levels. Phases run one after another, separated by barriers: a phase starts only when every work step of the previous one is done. At the end stands a consistency pass over the whole. If it measures a regression, it sends the affected work steps into capped repair rounds. If it cannot measure, it lets the run through like the VERIFY gate and records an error on the gate — nothing was checked then. The measurement itself is available in the hosted service and is switched on per project. An additional build-and-test pass over the full state is optional; the hosted service runs it. TaskSlices run in parallel within a phase — as many at once as the deployment provides workers.
That is the difference between "typing faster" and "building more at the same time": order is preserved where it matters and dropped where it only slows things down.
A worker takes exactly one TaskSlice, executes one AI prompt, validates the result and commits it. No worker sees the overall plan; it sees its step and the context that step needs. Coordination sits with the coordinator, which holds the graph and distributes slices through a durable queue.
If a worker dies, its slice is not lost — it is redelivered. If a slice sits unacknowledged, it counts as demand and a worker is scaled up (optional).
A run is not a black box. The cockpit shows live what is happening: which TaskSlice is being worked on, which changes it produces and which intermediate steps the model takes.
That includes cost — not summarised at the end of the month, but itemised per TaskSlice: which step consumed how much. If you want to know where a run's time or cost went, the answer is in the run itself, not in a reconstruction after the fact.
The result is not a chat transcript someone copies code out of. It is a Git repository with history: every TaskSlice leaves its commit, every phase its state. What sits there is verifiable — by a human, by a pipeline, by an auditor.