SwarmCoder
WALKTHROUGH · ONE STORY, START TO FINISH

From a brief to a delivered, traced commit

These screenshots follow a single story through the console on a small demo project, a personal bookshelf app. They are captures of one run, including the attempts that failed, because those are part of the record too.

ACT 1

Agree the scope

01

An empty project

The pipeline has five columns and a story only ever moves left to right across them. You decide twice: whether a suggestion is real work, and whether what came back delivers what was asked. Until requirements exist, the NEXT line says so, and nothing downstream can be planned or built.

An empty project
02

Requirements, drawn from a brief

Analysing a short brief for a bookshelf app produced eight requirements, each with its relationships stated: waits for, constrained by, needed by. Drafts are not scope. Agreeing one, here R3, makes it part of the scope and accepts the checks attached to it, and story S1 is planned from it.

Requirements, drawn from a brief
03

The same requirements as a graph

Laid out in dependency order, so what a requirement depends on sits to its left. The colour of a node is its state, and the legend underneath spells out every state and every kind of link, so nothing has to be inferred.

The same requirements as a graph
ACT 2

The build

04

A build that stopped to ask

The first build of S1 reached a question it would not guess at. It stopped, put the question on the story card with the button that answers it, and the NEXT line points there. Nothing restarts on its own, and answering records your call.

A build that stopped to ask
05

Workers writing code

Inside the run there are six fixed stages, from reading the story to putting the pieces together. The story was broken into tasks, each worked by two independent workers on a local model, and the timeline replay shows each worker’s activity as it happens.

Workers writing code
06

Integration, and a repair round

Every task shows its workers with the turns and tokens they used, and red marks a candidate that failed. When the last task failed in both workers, a repair round started with four further attempts rather than handing a broken result upwards.

Integration, and a repair round
07

The timeline, expanded

Every worker attempt on one axis, green where it passed and red where it failed, including the repair workers. This is the recorded session rather than a reconstruction after the fact, and it can be replayed at 1×, 4× or 16×.

The timeline, expanded
ACT 3

Judge and deliver

08

It came back

The build finished and landed in Came back with its commit named on the card. This is the second decision: accept the delivery, or send it back. Nothing behind it moves until you decide.

It came back
09

Delivered

Accepted, so the story is done, with its check verified and its commit recorded on the card. The run that produced it stays one click away.

Delivered
10

The requirement closes

Back in requirements, R3 now reads delivered, with 1/1 checks passing and S1 as the story that delivered it. The trace runs both ways: from the requirement to the commit, and from the commit back to what it was for.

The requirement closes
11

The finished run

All six stages complete. The graph and the timeline are kept as they were, failed attempts included, so whoever audits this delivery later sees what actually happened rather than a summary of it.

The finished run

Two decisions from you, everything between them done by the machine, and a record you can walk back through afterwards.

How the cycle works Get the code on GitHub ↗
SwarmCoder

Agentic software development with full traceability, built on ZeroZ4j by Franz Schöning, Principal Enterprise Architect.

swarmcoder.dev GitHub ↗ zeroz4j.com ↗ franzschoning.com ↗ ● Open source · Apache 2.0
© 2026 Franz Schöning. Released under the Apache License 2.0.