CodeFlux
Verified atoms. Better software.
prototype · experimentalA coding agent that assembles a program out of small, separately verified pieces instead of writing it in one pass and hoping.
Most coding agents write a program and then try to check it. CodeFlux builds one from the bottom up out of atoms — reusable units with a typed signature, a contract, declared effects and the evidence that they work. Atoms compose into molecules, molecules into control flow, control flow into a program, and every layer names the pieces that discharge its guarantees.
Brand artwork for CodeFlux. The product is real and the code is linked above; the poster is a design exercise, not a claim.
What you get.
You read the plan before anything runs
It proposes scope, steps and the checks it intends to satisfy. You describe an outcome in your own words; no specification required.
Verified work is meant to become project capital
The design: a proven atom is recalled rather than rebuilt, and re-verified against the new run's contract, because reuse without that would inherit the old blind spot. Registration works; recall across runs has not fired yet, and the repository tracks that as an open ticket rather than a feature.
Authority comes from what an action is
Permission is derived from the tool and its declared effects, not from what the model says it needs. A poisoned file can persuade a model to propose something; it cannot make it authorized.
Known, ambiguous and recommended stay separate
A forecast is a range, an unreported price stays unknown instead of becoming zero, and a passing check means those checks passed and nothing more.
What it runs on.
Including the two libraries underneath it that are my own work — the framework the interface is written in, and the transport it talks over.
What was actually difficult.
The problems worth describing, and what the measurement said. Not the technology list — that is above.
Making authority structural instead of conversational
Prompt injection stops being a category of attack when permission is not something a model can talk its way into. Authority is a property of the action — the tool, its ordered arguments, its declared effects — so the worst a poisoned file achieves is a proposal you see and decline.
Re-verification, not just reuse
The cheap version of atom reuse is a cache. The correct version re-derives tests from the new run's contract and makes the atom earn its place again, which is what keeps a reused component from carrying an old assumption into a new context.
Writing down the kill criterion in advance
The project is explicitly a bet — on functional decomposition into pure atoms, and on verified reuse compounding into lower cost. The plan states what result would kill it: no measurable improvement in defects, review time or total cost. Whether it holds is not settled, and the README says so.
Counted, not estimated.
Figures taken from the repository itself. No line-of-code count — it rewards duplication and every reader knows it.
Where this really is.
A prototype, and the least finished of the five. It exists to test a hypothesis rather than to be adopted, and the README states the hypothesis, the two bets underneath it, and the condition that would end the project.
These are personal projects, built on nights and weekends with AI agents in the loop — that is how one person ships this much surface area at once. Most of them are early: alpha or prototype, with polish that varies a lot by area. What is not early is the architecture, the test suites, and the measurements — every number on this page is counted from the repository and every claim is one you can check against the code.
