Fluxtion is unusually well-suited to being written by an LLM — you author intent (nodes, wiring, audit fields) and the compiler guarantees the behaviour (determinism, audit, replay). You can't introduce a race or a non-deterministic decision by being a careless author; the source-gen step enforces. The trick is bootstrapping the model so it converges fast. Three things do most of the work.
You write nodes; the compiler wires them. Each node is ~30 lines — a few fields, a constructor naming its upstreams, one trigger method — so the model reasons locally, one node at a time, without holding the whole topology in context. Topo-sort, dispatch order and change propagation are all the compiler's job.
And the guarantees survive being machine-written. If the model tries to spawn a thread, mutate state from outside the graph, or skip a trigger annotation, the framework rejects it or the generated processor simply won't dispatch it. The author writes the specification; the compiler is the safety boundary. So the model worries about whether the spec is correct, not whether the code is "deterministic enough".
CLAUDE.md is the canonical Fluxtion author-orientation — the mental model, the source-gen triage
(symptom → fix), services, build-time generation, the dirty/else branch. In Claude Code,
drop it in as a CLAUDE.md at the repo root (it auto-loads). With
an API/agent, paste it as the system prompt. Pair it with the golden-path guide — the one blessed shape (imperative AOT + audit + named sinks + test) as copy-paste code.
Fluxtion's compile errors are directive — use @AssignToField, add @FluxtionIgnore —
but only help if the model can run the compiler and read them. The browser playground (zero install) or a local mvn build is enough. A model with a run loop beats one without it by a wide margin, because each error names the
next move — so it self-corrects instead of guessing.
LLMs pattern-match working code far better than prose. The template menu tells the model which shape to pick and whether it needs a key; the playground examples are the real code to match. Tell it: "match the closest example before improvising."
Read the Fluxtion orientation doc (CLAUDE.md) and the golden-path guide. Pick a shape from /starter-templates/index.json; match the closest example in the playground before improvising. You have a compile/run loop — Fluxtion's errors are directive, so when one fires it's telling you the fix: apply it and re-run. Reason locally per node; let the compiler handle the topology.
Then point it at the closest playground example for the task and let it iterate against the errors.
Open the playground, paste the prompt, and let it author against directive errors — no install.