# I told one AI to demolish the handoff prompt I wrote for another AI. It found a test that passes even when it's empty > Source: > Published: 2026-08-02 00:00:00+00:00 # I told one AI to demolish the handoff prompt I wrote for another AI. It found a test that passes even when it's empty I’m building an app with Claude Code right now. The setup is a little unusual. **One “commander” session writes the instructions, and separate “worker” sessions implement them in parallel.** The commander never touches the keyboard itself. Its whole job is to turn “what to do next” into a handoff prompt that a worker can read and just run with. And that handoff prompt is quietly the scariest thing in the whole loop. The moment I hand it over, the worker trusts it as the spec and starts sprinting. If the spec is wrong, the wrong thing gets built. Fast, and with confidence. ## Before handing it over, I did my usual ritual I’ve picked up a habit lately. Before I throw the instructions at a worker, I run them past **a subagent whose entire job is to demolish them.** It’s defined to never approve, to hunt for holes, and to never, ever close with “this looks broadly reasonable.” What was different this time: this thing didn’t just read the prose of my prompt. **It went and read the actual code.** And the reply it came back with made my stomach drop a little. ## Objection 1: I wrote “make the test pass (go green)”, but that test’s green meant nothing In the instructions, I’d written this as a definition of done: **“Get the XX test passing (green).”** The demolition agent’s answer: “That test **goes green even when the thing it’s testing fails.**” I read it. It was true. The test only checks “did the process run all the way to the end.” It never checks **the one thing that matters: did it succeed?** Fail, and as long as it “returned a failure result and finished running,” green. On top of that, the batch path was swallowing exceptions, so no matter what blew up, still green. So even if a worker reported back “DoD met, tests green!”, **nothing was actually proven.** The completion criterion I wrote myself was an empty pass. ## Objection 2: I wrote “just flip a flag”, but that switch didn’t exist One more. I’d written “**flip a config flag and it swaps in the real component**”, as if it were a feature that already existed. The demolition agent traced the code and replied: “That wiring **is never called from anywhere.** The function exists, but nothing connects to it.” Also true. The swap-in function was there, but nothing in the UI ever reached it. The worker was one step away from either **spending an hour hunting for a switch that doesn’t exist**, or getting tired of hunting and fabricating something “close enough.” ## What scared me was that I’d stated both as fact Both times, I wrote it with total confidence. “The test passes.” “The flag swaps it in.” At the time I wrote them, I genuinely believed it. **The demolition agent just read the code I hadn’t re-read.** That was the whole difference. A handoff prompt is a spec, really. And the lie tends to sneak in at exactly **the moment work is handed over** — human to AI, AI to AI, or today-me to next-week-me. An empty-but-green test. A wire that’s “supposed to be there.” A review that reads the prose, nods, and approves won’t catch this. Only **a review that reads the actual code and comes swinging** will. ## The takeaway **“The test is green” only guarantees that the test is correct.** And the completion criteria you wrote yourself are the ones you’re least likely to doubt. So maybe the thing you should demolish before you start typing isn’t the code. It’s **the instructions.** Finding out “that green meant nothing” after running the implementation for ten hours is a lot more expensive than a three-minute adversarial review before you hand it over.