SwarmCoder
Overview How it works Agents Principles Status About
APACHE 2.0 GITHUB ↗ ● IN DEVELOPMENT

How it works

You only need to learn four words to use it. Everything else (runs, sessions, workers, candidates, decisions and so on) is detail inside a build, and while it is all recorded and you can open it whenever you want to, you never actually have to.

DOCUMENT
What you upload, e.g. specifications, notes, transcripts or a PDF from a client.
REQUIREMENT
A durable statement of what must be true, together with the checks that prove it.
STORY
A slice of work that delivers a named set of checks.
BUILD
One attempt at building a story.

One board with five columns, and nothing disappears from it.

A story appears when the planner suggests it and it stays on the board until it is either delivered or dropped. The health of a build (building, paused, stopped or needs you) is shown as a badge and a sentence on the card itself, so there is never a different screen that you have to go and find.

SUGGESTED
The planner suggested these. Is it real work?
READY TO BUILD
Agreed work, to be built when you are ready.
● BUILDING
The agents are working. There is nothing for you to do unless it asks.
CAME BACK
Your turn to judge whether it delivered what was asked.
DELIVERED
Done, with the evidence stamped on it.
stories move left to right · a rejected delivery is sent back with a note, on the board

The requirements pool is always open

You upload specifications, notes, transcripts or a PDF from a client, and SwarmCoder extracts the requirements as objects, each one traceable back to the sentence it came from. You then agree the ones that are real and park the ones that are not, visibly and reversibly. Being in the middle of a build does not close intake, so new requirements, re-analysis and things discovered mid-build land as drafts at any time.

Between your two clicks

Every build runs the same pipeline. It was designed once and it is machine checked every time, so no run ever gets to improvise the process.

design→ review→ plan→ tests first→ swarm · verify · select→ integrate→ deliver
Design is a structured interview, not an open chat
The design stage is a bounded interview that writes into fields. Its output includes explicit contracts between components, and these contracts are basically what make it safe to have several workers building in parallel. A second, independent review pass then runs against a fixed rubric, loops at most twice, and proceeds with any remaining objections recorded.
Plans are checked by a machine before they are used
The work is broken down into the smallest units that still have a mechanically verifiable test and clean file ownership. Four rules are checked (concurrent tasks own disjoint files, every task has an executable check, every task fits its token budget and the graph has no cycles) and a plan that breaks one of them is rejected and regenerated rather than accepted with a warning.
Tests are written first, in a place the workers cannot touch
The acceptance tests are written to a path that the sandbox mounts read-only, and they are proven to fail against the unchanged codebase before a single attempt is dispatched. This is enforced by the mount itself and not just requested in a prompt, which matters more than you might think.
The swarm is filtered cheaply before it is judged
A file that does not parse is rejected before the build runs, a candidate that does not compile never reaches a judge, and a worker that writes outside its assigned files is killed and its slot reused. The survivors are then grouped by behavior, since agreement between independent attempts is a useful signal in itself, and only after that does a model rank a handful of genuinely different diffs against the real test results.
One winner, and never a blend of two
Selection picks exactly one candidate, because blending two implementations of the same intent produces plausible looking code that no test suite has ever actually run against. The losers are archived with their diffs and reports rather than deleted, and integration is verified after every merge, not just at the end.
Not every kind of work gets a swarm
Bug fixes reproduce the problem mechanically and write a failing test before any code is generated. Refactors first write tests that assert the current behavior and then prefer the smallest change that preserves it. Documentation gets a single worker and a review, because there is nothing executable to verify and a swarm would just add noise.

Why the process is built in and not prompted

Give a generic coding agent a task and watch where the expensive tokens go. It rediscovers that it should probably read the code first, it works out again that a plan might help, and it reinvents testing (or it does not). Every run improvises the development lifecycle from scratch and slightly differently, and because the process was improvised there is no artifact to audit afterwards and no place where the design actually lives.

In SwarmCoder the lifecycle is code, with rules that a machine checks. Each stage asks its model the one question that stage exists to answer, and the answer lands in a typed object (a Requirement, a Story, a Task) rather than in prose that the next agent can misread. So the expensive models are only paid for judgment, every run follows the same path so that a defect in the process can be found and fixed once, and every decision has a place to live before it is even made.

The trade off is deliberate. SwarmCoder gives up generality to buy reliability, so there is no plugin system, no user defined agent graphs and no workflow language. The moment the workflow becomes configuration you have essentially rebuilt a generic agent with extra steps, and every rule that makes this trustworthy is gone.
Continue: the principles →
SwarmCoder

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

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