---
titel: "How it works"
adresse: https://anvil-coder.tech/en/how-it-works
beschreibung: "Anvil Coder decomposes requirements into a directed graph of atomic work steps, runs them in parallel and delivers a finished Git repository — every step checked against the same invariants."
sprache: en
---

The engine

# From a requirements text to a finished repository

Anvil Coder is a system for autonomous software manufacturing: it decomposes requirements into a directed graph of atomic work steps, runs those steps in parallel and delivers a Git repository with working, tested code. Every single step is checked against the same invariants.

## The problem that had to be solved

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 are*decomposed*. Each TaskSlice is small enough to fit into a prompt completely — together with the context that this particular step needs.

## Two axes: phases and slices

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. It is built so that a missing or disturbed measurement never waves anything through: it reports red and sends the affected work steps into capped repair rounds. The measurement itself is optional and not yet switched on in the hosted service. 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.

**REQUIREMENTS**

The task description becomes a verified picture of requirements — open questions are recorded as assumptions and stay visible throughout the run.

**ARCHITECTURE**

Structure, interfaces and dependencies are settled before the first line of code exists.

**IMPLEMENTATION**

The actual work: each TaskSlice is exactly one AI prompt on one worker, with its own working tree.

**RECONCILIATION (optional, on in the hosted service)**

The parts built in parallel are checked against each other and merged.

**TEST**

Tests are created as work steps of their own, not as an afterthought.

**VERIFY (optional, on in the hosted service)**

The result is checked against the requirements — not against the intention that produced it.

**DOCUMENTATION**

What was built gets described while the context is still fresh.

**CONSISTENCY**

One final pass over the whole: does what was built separately fit together?

An epic pulled onto the trigger state decomposes itself into evenly cut user stories — each one runs only after a human releases it individually.

## What a worker does

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)*.

## What you see during a run

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 budget went, the answer is in the run itself, not in a reconstruction after the fact.

## The result is a repository, not a suggestion

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.

## Try it yourself or talk first?

Both work. Trying it yourself shows fastest whether the flow fits your projects; for questions about data sovereignty, operations and billing, a conversation is the shorter path.

[Start for free](https://app.anvil-coder.tech/register)[Book a demo](https://anvil-coder.tech/demo)