A process designed for agentic development from the start, with economics that survive the end of subsidized tokens, human guardrails, mechanical governance and evidence for everything it does.
Every frontier token you buy today is sold at a market share price and not at a cost price. Inference is priced below its fully loaded cost, and the models, the training runs and the data centers behind them are financed by venture capital and hyperscaler balance sheets betting that subsidized usage now buys lock-in later. You do not have to predict a bubble bursting to see the problem here, because prices that sit below cost eventually correct. The only open questions are when it happens and how fast.
Agentic development turns this from a background risk into an acute one, because agents are the most token hungry way that software has ever been written. A single agentic task can easily burn hundreds of times the tokens of a chat exchange, and the industry's answer to every quality problem is basically to spend more, i.e. longer sessions, more tool calls, more retries and more orchestrating agents, all of it running on frontier models in someone else's cloud. So token consumption per unit of delivered software is rising steeply while the price per token is held artificially low, and two curves like that cannot both continue for very long.
When the correction comes it will probably not arrive as a polite annual increase. Having watched a few subsidized platforms withdraw their subsidies over the years, I would expect the usual pattern of sudden repricing, aggressive rate limits, cheaper models being deprecated in favor of expensive ones and "unlimited" plans quietly becoming metered. Organizations that have wired agentic development into their delivery pipeline on frontier economics will find that the cost of building software has become a number somebody else controls, and they will find this out after their processes, their tooling and their teams have grown around it. That is an architectural dependency, it is being taken on today, and it is mostly going unexamined.
Token cost is an architectural constraint and should be treated as one. Design for post-subsidy prices before they arrive.
SwarmCoder was built as a pre-emptive answer to this. The architecture splits the work according to what it costs to verify, and prices each side accordingly. Judgment (the analyst, architect, reviewer, test author and judge) is a handful of small, structured frontier calls per story, enforced by a hard per-run cap, and that cost scales with the number of tasks. Volume (the worker swarms that actually read your repository and write the code) runs on hardware you own, and that cost scales with implementation tokens, which are priced in electricity. Over 95% of the tokens in a run never touch a cloud meter.
The exposure also runs down as well as up. Model selection is per-role configuration, so as local models improve, roles can migrate off the frontier one at a time (the judge is the obvious next candidate, since it only ever ranks a handful of candidates that have already compiled and passed). The direction of travel is essentially the opposite of the industry's, with less frontier dependence with every release rather than more.
The result is an asymmetric bet. If frontier pricing stays cheap, SwarmCoder costs a little less than the alternatives and you keep the traceability. If the pricing becomes real, say a 10× correction, the capped judgment slice rises with it, the local 95% does not move at all, and the platforms built on ever more frontier usage become prohibitively expensive. So you give up very little to be positioned for the second case, and I would suggest you at least keep this in mind when choosing your tooling.
Requirements documents and backlogs were both designed for teams of humans, and each is good at what it was built for, i.e. the document describes the system and the backlog sequences the work. Agentic development changes the shape of the problem somewhat. When machines generate the code, the scarce resource is no longer typing, it is human judgment, together with a durable and trustworthy statement of what the system must do that a machine can be held against.
So SwarmCoder keeps one durable requirement layer and stops it from rotting by binding every acceptance check to an executable test. The specification cannot drift away from the system, because the build fails when it does. A requirement is only marked as implemented on evidence (the commit and the wording revision it passed against) and not on anyone's say so, and if you edit the wording the evidence is automatically marked as stale.
The requirement graph is the only source of truth. A story is a scheduled slice of it and never a second description of it.
A story carries no requirement content of its own. It claims check identifiers rather than paraphrases, so there is no second wording that can diverge from the first. Requirements own the meaning and stories own the scheduling and the state, and in three years the requirements are still there while the stories are long gone.
The result is a living pool feeding frozen slices. Intake never closes, so the plan can always learn something new. But once a story has claimed its checks and started, that slice is protected and the swarm builds against a fixed target. Editing a claimed requirement is still allowed, but it is a deliberate act that shows you the consequences first, e.g. "2 passing checks go stale; S2 will be sent back." Work that is in flight is never churned silently, and the loop back is drawn honestly on the board rather than happening off screen.
Every step of every agent session is recorded as data rather than as log lines, i.e. the prompts, the responses, the tool calls, every kill with its reason and the token usage. The chain from prompt to commit stays intact and queryable, so months later you can still answer questions like these:
A build that stops because the work is genuinely hard and a build that stops because a server blinked are not the same event, and treating them as the same is how agent systems end up wasting both money and your attention.
Twenty autonomous processes editing code and running builds is a security posture whether you designed one or not. Keep in mind that repository contents are untrusted model input, i.e. a README, a test fixture or a dependency's install script can all redirect a small model.
Policy is resolved from a tree the restrained party cannot write.
Agentic software development with full traceability, built on ZeroZ4j by Franz Schöning, Principal Enterprise Architect.