I have spent the last few months handing real work to coding agents, and particle effects turned out to be an unexpectedly good test case. Not because the task is hard, but because it fails in a specific, informative way.
Ask an agent to "add a fire burst to the boss intro" in a project it has not been taught about, and you get code that looks right and is wrong. Plausible imports. Invented option names. An update call in the wrong place in the host lifecycle. It compiles, it renders nothing, and the failure gives you no hint about which of the four layers broke.
The failure is a vocabulary problem
The agent is not confused about JavaScript. It is guessing at three things it has no way to know:
- Where authored assets live in this project, and what a valid effect file looks like.
- Which capabilities the backend actually supports — a 3D world effect and a 2D UI effect are not interchangeable, and the constraint is not visible from the call site.
- Where in the host lifecycle loading, per-frame simulation, and cleanup belong. This is the one that produces silent no-ops: the code is fine and it runs in the wrong place.
None of that is inferable from a function signature. It is project knowledge, and if you do not supply it the model supplies a guess.
Splitting authoring from integration
What worked was refusing to treat this as one task. Authoring an effect and wiring an effect into a game are different jobs with different failure modes, and giving the agent one combined instruction sheet made both worse.
NixieFX ships two agent skills split exactly on that seam:
- authoring — create project-safe effect files, check them against what the backend supports, produce the export bundle.
- runtime — load an exported bundle, wire the providers the engine owns, keep simulation and cleanup in the right lifecycle hooks.
Naming the one you want is what makes the run predictable:
Use the authoring skill to create, validate, and export a fire burst for a PixiJS boss intro in this project.
Use the runtime skill to load the exported fire-burst effect from
out/vfx, wire its texture provider, and update it once per frame.
Two prompts, two reviewable diffs. When something is wrong you know which half to look at, which is most of the value.
The validator is what makes it safe
The reason this works better than a longer prompt is that there is a machine-checkable step in the middle. The authoring loop is create, edit, validate, export — and validate is read-only and exits non-zero on error.
That gives the agent a ground truth it can act on instead of a vibe. It is also the difference between reviewing an agent's VFX work in thirty seconds and reviewing it by launching the game and squinting. If validate passes and export produces a bundle, the authoring half is done; anything still broken is integration, and integration is the other skill's problem.
I would generalise this past VFX: any task you want to delegate to an agent needs a check the agent can run itself. Not a test you run afterwards — a command it can invoke, read the exit code from, and iterate against. Tasks with that property go well. Tasks without it produce confident, plausible, unverifiable diffs, and you end up doing the work twice.
What I would not delegate
Judgement about whether the effect is any good. An agent can produce a valid fire burst that matches the spec and still looks wrong for the scene, because "reads clearly at 400 px on a phone during a screen shake" is not a property a validator can check.
Authoring and wiring: delegate. Deciding it looks right: still a person, still watching it in context.
Curious whether others have found the same pattern — that the deciding factor in agent-delegated work is the presence of a self-service validation command rather than the quality of the prompt.
