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.
Instead of writing nodes, describe the app to an LLM and let it emit a Spring XML file. Drop that file on the project starter and it generates a runnable skeleton — event records, node classes, wiring — for you to fill in. The LLM is a design-time partner; the running app is deterministic Java with no model in it.
Help me design a Spring-defined Fluxtion application. We'll discuss it, then you emit one Spring XML file I can drop on the Fluxtion project starter to generate a runnable skeleton. Read these first, in order. If you cannot fetch a link, say so and I'll paste its contents — do not proceed from memory. 1. Orientation — the core Fluxtion model (nodes, events, compile-time graph, determinism): https://fluxtion-playground.dev/CLAUDE.md 2. Authoring skill — how to run this conversation (describe -> events -> nodes -> wiring -> emit): https://fluxtion-playground.dev/spring-authoring/skill.md 3. XML contract — the exact FluxtionSpringConfig shape you emit and the starter imports: https://fluxtion-playground.dev/spring-authoring/contract.md 4. Worked example — a full run (conversation -> XML -> generated skeleton): https://fluxtion-playground.dev/spring-authoring/example.md Then act as my design partner: ask what the app does, pin the input events, the nodes and which node handles which event, and the dependencies between nodes. Confirm the design in plain English — including anything that will NOT be generated — then emit one valid Spring <beans> XML per the contract: - events as eventTypes (FQCN strings, not eventClasses); - nodes in nodeBeans, and which node handles which event as eventHandlers bindings; - dependencies between nodes as constructor-arg ref; - singular role packages (<base>.node.MyNode, <base>.event.MyEvent — never .nodes/.events); - external services in serviceTypes (FQCN interfaces) + serviceRegistrations (attach each to its consuming node) — never as beans, never constructor-wired; the starter generates @ServiceRegistered callbacks + interface stubs. ignoredBeans is only for genuine non-service support/config beans. Emit exactly one XML file and no Java; the starter generates the stub classes I'll fill in.
The prompt points the model at these — or read them yourself:
FluxtionSpringConfig shape the LLM emits and the starter imports.Read the orientation doc first for the core model; the skill layers on it.
Open the playground, paste the prompt, and let it author against directive errors — no install.