I spent a long evening writing a build plan so detailed it was almost the code. Every task in order, every test named, chunks of exact code pasted in. The idea was to hand it to AI agents one task at a time and let them build while I worked on something else.
That mostly worked. What I didn't expect was how often the report that came back amounted to "your plan is wrong."
The bugs were mine
Task one built fine. Task two contradicted it: two different shapes for the same piece of data, both written by me, about three hours apart.
It kept going from there. One step told the agent to watch a test fail before writing the fix, but the test I'd written could never fail. A job that got stuck had no way back to a normal state. I'd planned how it gets in and forgot how it gets out. A fix I'd scoped to one case turned out to cover three.
By the end, the build had five tasks that were never in the plan. Every one came from an agent reading its own work, or my instructions, and saying plainly that something didn't add up.
One agent reported that its own acceptance test failed and stopped there. It didn't loosen the test until it passed.
Why I couldn't see it
I wrote the plan top to bottom, and each piece made sense at the moment I wrote it. Contradictions don't live inside one task. They live between task two and task eleven, forty minutes apart when I wrote them and a long scroll apart when anyone reads them.
The agent hits them in a different order. It has to make task eleven run while task two is already built and sitting there, and that's when a wording difference turns into something that won't run.
I could have typed all that code myself, slower. The valuable part was having something read the whole plan closely enough to catch where it contradicted itself, and then say so instead of quietly picking one version and moving on.
You have to ask for honesty
That last part doesn't come for free. Give almost any assistant a failing test and no other instruction, and it'll make the red thing go green: adjust the assertion, widen the check, mark it skipped. It looks like progress, and you find out weeks later.
So I wrote the opposite into the plan itself: if the acceptance test fails, report that it failed. Do not change the test. After that I started getting honest failures, and each one was a lot cheaper to hear about that night than it would have been later.
If you're handing a plan to agents
- Assume the plan is the buggy part. You're using the agents to find where you contradicted yourself.
- Write the honesty rule down. Reporting a failed test instead of editing it is not the default behavior.
- For anything that can get stuck (a job, a queue, a state), make the plan say how it gets unstuck. That's the gap I miss most.
- Let new tasks show up. A plan that finishes exactly as written usually means nobody read it closely.
- Read the objections carefully. The most valuable output of the whole run was one paragraph telling me two of my tasks disagreed.