DEV Community: PatilRB

The dual prompt: why your AI task handoffs keep failing

PatilRB — Tue, 18 Aug 2026 15:28:01 +0000

A while back a teammate ran a task I wrote and it came back wrong. Not subtly wrong — it had refactored a file I never mentioned. The model was fine. My prompt was the problem: I had written one set of instructions for two completely different readers.

Two readers, one prompt

When you hand an AI task to someone else — they run it on their own Claude Code or Codex subscription and send you the result — there are two audiences.

The human needs to know what this is, why it matters, what "done" looks like, and what to sanity-check before sending it back.

The agent needs exact scope, hard constraints, which files or systems are in play, and what it must not touch.

A single prompt serving both ends up too vague for the agent and too jargon-dense for the person. And the second failure is the expensive one: if the person can't tell whether the output is right, they forward it unchecked. Your review becomes the only gate, which defeats the point of delegating at all.

What the split looks like

Here is the version I used to write:

Clean up the analytics module and make sure the tests pass.
Should be quick.

And here is the same task written for both readers:

## For you (the human)
We're removing the last of the legacy event names before the
rename ships Friday. There are 11 call sites.

Done looks like: `rg "track_legacy" src/` returns nothing, and
the analytics test suite is green.

Before you send it back, check the diff does not touch
src/analytics/schema.ts — another team owns that file and
changing it will block the release.

## For the agent
Scope: src/analytics/**, excluding src/analytics/schema.ts

Task: replace every `track_legacy(<name>)` call with
`track(<name>)`, preserving arguments and ordering.

Constraints:
- Do not modify schema.ts
- Do not reformat or touch unrelated lines
- Run `npm test -- analytics`; report failures rather than
  fixing ones outside this scope

Out of scope: renaming events, the dashboard package.

The second is four times longer. It is also the difference between a delivery you can merge and one you have to redo.

The "for you" half matters more than it looks

The reflex is to skip it. The human is just going to paste the agent half anyway, right?

But the human half does something the agent half cannot: it gives the person enough context to reject a bad result. An agent will confidently hand back something plausible. If the person running it has no idea what correct looks like, plausible and correct are indistinguishable. One sentence — "check the diff does not touch schema.ts" — turns a passive relay into an actual reviewer.

That is the whole return on writing the second half.

The constraint underneath

There is a reason this pattern comes up at all. You cannot hand someone else's Claude or Codex subscription a task without handing over the login. So the work has to travel as instructions, not as access — and that is exactly why the writing quality carries so much weight. With shared access you can course-correct mid-run. With a handoff, the prompt is the entire interface.

We have been building Wagglet at Rockbite Games around this shape of work (disclosure: I work there). The dual prompt is a pattern we kept re-deriving by hand until we made it the default structure of a task. If you want the longer reasoning there is a write-up on the dual prompt, and the full request-to-delivery workflow if you want to see where it sits end to end. For wiring an agent in directly there is an MCP endpoint.

None of that is required to use the pattern, though. It is just two headings in a markdown file.

A checklist that mostly works

Before sending a task for someone else to run:

Can they tell, without asking you, whether the result is wrong?
Have you named at least one thing that must not change?
Is scope stated as paths and systems, not as a description?
Have you said what to do on failure — report it, or fix it?
Would this still make sense to them in three days?

If any of those are a no, the prompt is not finished. It will come back wrong and you will blame the model.

Curious whether other people have landed on the same split, or something better — particularly anyone running handoffs across a team rather than solo.

Authoring particle VFX for Three.js — and the delta-time bug everyone hits

PatilRB — Tue, 18 Aug 2026 14:31:09 +0000

If you have added particle effects to a Three.js scene, you have probably done it the hard way: a Points geometry, a custom shader, and a tweak-recompile-refresh cycle every time someone says "more sparks, less smoke."

The recompile cycle is the real problem. Particle work is iterative by nature — you have to see a change to judge it. When the effect lives in code, every iteration costs a rebuild, so in practice you stop iterating long before the effect is actually good.

Game engines solved this years ago by splitting authoring from runtime: design the effect in a visual tool, export it as data, load the data at runtime. That split works fine on the web too, and the runtime half is the part worth writing about.

I have been using NixieFX for this lately (disclosure: I work at Rockbite Games, which builds it — it is MIT-licensed and free). The code below is Three.js specific, but the pattern is not.

An exported effect is just data

A manifest plus some JSON per effect plus texture files. Nothing you cannot inspect by hand:

import * as THREE from "three";
import { loadVfxExportBundle } from "nixie-fx/export";
import { ThreeVfxRenderer, ThreeVfxTextureStore } from "nixie-fx/three";

const BUNDLE_URL = "/vfx";

async function json(url) {
  const response = await fetch(url);
  if (!response.ok) throw new Error(`Failed to load ${url}`);
  return response.json();
}

const manifest = await json(`${BUNDLE_URL}/manifest.json`);
const effectsByPath = Object.fromEntries(
  await Promise.all(
    manifest.effects.map(async (entry) => [
      entry.path,
      await json(`${BUNDLE_URL}/${entry.path}`),
    ]),
  ),
);

const bundle = loadVfxExportBundle(
  { manifest, effectsByPath },
  { requiredBackend: "three3d" },
);

Wire up the renderer

const textures = new ThreeVfxTextureStore({
  resolveUrl: (path) => `${BUNDLE_URL}/${path}`,
});

const effect = bundle.effectsById.get("impact-burst");
await textures.preload(effect.assets.filter((a) => a.type === "texture"));

const vfx = new ThreeVfxRenderer({ scene, camera, textureProvider: textures });

That preload line matters more than it looks. Skip it and the first spawn of an effect pops in a frame or two late while its texture decodes — which is exactly the moment the player is looking at it.

Spawn it

const burst = vfx.createEffect(effect, {
  position: [0, 1, 0],
  seed: 42,
});

// later, on a hit:
burst.setTransform({ position: [x, y, z] });
burst.restart();

The seed is worth knowing about: same seed, same randomisation. Useful for deterministic replays, for screenshot tests that do not flake, and for making sure a reviewer sees the same thing you did.

The gotcha: delta seconds, not milliseconds

const clock = new THREE.Clock();

renderer.setAnimationLoop(() => {
  vfx.update(clock.getDelta());   // seconds, not ms
  renderer.render(scene, camera);
});

update() wants seconds. If you are used to doing your own performance.now() bookkeeping you will reach for milliseconds out of habit, pass 16.7 where 0.0167 was expected, and every effect will fast-forward through its entire lifetime inside a single frame.

The symptom is genuinely confusing, because nothing throws. You get a one-frame flash and then nothing, so it looks like the effect never played, and you go hunting in the wrong place — checking whether the bundle loaded, whether the texture resolved, whether the position is behind the camera. It is none of those. It already played, 400 times faster than you wanted.

THREE.Clock().getDelta() returns seconds already, so use it and move on. Driving your own loop? Divide by 1000.

While you are on that line, clamp it:

vfx.update(Math.min(clock.getDelta(), 0.05));

Otherwise the first frame after a backgrounded tab or a long GC pause arrives with a delta of several seconds, and every live effect in the scene jumps to its end state at once. Same bug, different trigger.

Clean up

vfx.destroy();
textures.destroy();

Is the split worth it

Honest trade-off: you take on a dependency and a build step, and you get back not writing shader code plus the ability to iterate on look-and-feel in seconds. If you need exactly one simple puff of smoke, hand-rolling Points is still less total work — genuinely, do that. Past two or three effects, or the moment someone who does not write code needs to adjust them, the data-driven split wins clearly.

If you want to dig further:

Three.js runtime API reference
Full mobile 3D + particle VFX walkthrough
The editor — runs in the browser, nothing to install
Source on GitHub

Happy to answer questions about the runtime side in the comments.