SwarmCoder

How it works

You learn four words. Everything else — runs, sessions, workers, candidates, decisions — is detail inside a build: recorded, openable, and never required reading.

DOCUMENT
What you upload — specs, notes, transcripts, a PDF from a client.
REQUIREMENT
A durable statement of what must be true, carrying its checks.
STORY
A slice of work that delivers named checks.
BUILD
One attempt at a story.

One board. Five columns. Nothing vanishes.

A story appears when the planner suggests it and stays on the board until it is delivered or dropped. Health — building, paused, stopped, needs you — is a badge and a sentence on the card, never a different screen to go find.

SUGGESTED
The planner wrote these. Real work?
READY TO BUILD
Agreed work. Build when ready.
● BUILDING
Agents at work. Nothing to do unless it asks.
CAME BACK
Judge it. Did it deliver what was asked?
DELIVERED
Done. Evidence stamped.
stories move left to right · a rejected delivery is sent back with a note, on the board

The requirements pool is always open

Upload specifications, notes, transcripts, a PDF from a client. SwarmCoder extracts requirements as objects, each one traceable back to the sentence it came from. You agree the ones that are real; you park the ones that aren't, visibly and reversibly. Nothing about being mid-build closes intake — new requirements, re-analysis and mid-build discoveries land as drafts at any time.

Between your two clicks

Every build runs the same pipeline — designed once, machine-checked every time, so no run ever improvises the process.

design review plan tests first swarm · verify · select integrate deliver
Design writes into fields, not an open chat
A bounded, structured interview. Its output includes explicit contracts between components — contracts are what make parallel work safe. A second, independent review pass runs against a fixed rubric, loops at most twice, then proceeds with objections recorded.
Plans are checked by a machine, not trusted
Work decomposes to the smallest unit that still has a mechanically verifiable test and clean file ownership. A plan that violates an invariant is rejected and regenerated, never accepted with a warning: disjoint files, an executable check per task, token budgets, no cycles.
Tests are written first — where workers can't touch them
Acceptance tests land in a path the sandbox mounts read-only, and are proven to fail against the unchanged codebase before a single attempt is dispatched. Enforced by the mount, not requested in a prompt.
The swarm is filtered cheaply before it is judged
A file that doesn't parse is rejected before the build runs; a candidate that doesn't compile never reaches a judge; a worker that writes outside its files is killed and its slot reused. Survivors are clustered by behaviour — agreement between independent attempts is itself a signal — and only then does a model rank a handful of genuinely different diffs against real test results.
One winner. Never a blend.
Selection picks exactly one candidate — blending two implementations of the same intent produces plausible code that no test suite ever ran against. Losers are archived with their diffs and reports, never deleted. Integration is verified after every merge.
Not every kind of work gets a swarm
Bug fixes reproduce mechanically and author a failing test before any generation. Refactors assert current behaviour first, then prefer the smallest change that preserves it. Documentation gets a single worker and a review — a swarm would buy nothing but noise.

Why the process is compiled in, not prompted

Give a generic agent a task and watch where the expensive tokens go: it rediscovers that it should read the code first, re-derives that a plan might help, reinvents testing — or doesn't. Every run improvises the lifecycle from scratch, and because the process was improvised, there is no artifact to audit afterwards. No place where "the design" lives.

SwarmCoder's lifecycle is code, with invariants 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 — not in prose an agent can misread next time. So the expensive models are only paid for judgment; every run follows the same path, making a defect findable and fixable once; and every decision has a place to live before it is made.

The trade is deliberate: generality is given up to buy reliability. No plugin system, no user-defined agent graphs, no workflow DSL — the moment the workflow becomes configuration, every invariant 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.