The engine
You pull a ticket onto the start state, Anvil Coder plans, slices and builds. Back comes a draft pull request in your repository, with one commit per work step and a run report that says what was checked.
Read a real run: a Laravel bug fix, three commits, fix and regression test in 24 minutes.
The result is not a chat transcript someone copies code out of. It is a Git repository with history: every work step leaves its commit, every phase its state. You read on the commit which assignment it came from instead of reconstructing what an agent was thinking. And what sits there is verifiable: by you, by your pipeline, by an auditor.
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 this particular step needs. That is why the quality of the two-hundredth step is the same as the first.
Not every assignment 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 a follow-up chat that names gaps instead of papering over them. At the end real tickets emerge: epics and stories in your tracker, on request together with a newly created repository.
The studio writes tickets, not code. Which story runs is your call, story by story. The guide (in German) lives in the documentation.
Execution runs on two crossing levels. Phases run one after another, separated by barriers: a phase starts only when every step of the previous one is done. TaskSlicesrun in parallel within a phase. 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.
At the end the consistency pass checks the whole. If it measures a regression, it sends the affected steps into capped repair rounds; if it cannot measure, it lets the run through and records that on the gate, so you see it in the run report instead of missing it.
Two things you should know: reconciliation, verification and the build-and-test pass are switchable per project and switched on in the rented service, and if your project's build tools are missing in the sandbox, the run marks the result unverified instead of calling it green.
A worker takes exactly one TaskSlice, executes one prompt, validates the result and commits it. No worker sees the overall plan; it sees its step and the context that step needs. The coordinator holds the plan and distributes slices through a durable queue.
If a worker dies, its slice is not lost, it is redelivered. If the queue backs up, workers are added; when it is empty, the fleet scales to zero.
A run is not a black box. In the cockpit you follow live which step 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 step. Where a run's time or money went is written in the run itself, not in a reconstruction afterwards.