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.
Top comments (0)