Make your agent write the plan, not the code

A plan you can review is cheaper than a diff you can't.

For one of the products I work on, a panel has three ways to search. Switch tabs and the one you left unmounts. Whatever lived inside it is gone: the text, the results, the step you were on.

I had been meaning to bring in a cache for server state. TanStack Query, specifically. I was not sure the missing cache was the bug, so I asked the agent for an analysis and I said not to write code. 🤔

The first pass was the part I did not want to do by hand. It read the tree and told me which tab kept its data in the component, and which one already kept it in a context above the tabs. I checked that against the code. It held.

The bug was an unmount

A cache does not help a component React has just destroyed. It helps a screen that asks for the same page twice.

So the fix was to lift the state, above the tabs, into a small reducer the panel reads when it mounts again. The cache stayed a second plan. That one is for a set of paginated lists that each rebuild loading and page state by hand. I have not done it. The written reason is why I can still say no.

What I wanted on the page

Not a file list. A decision I could reject.

• What is actually lost, and where that state lives today.
• The options, including the one I am not taking, and why.
• What this change does not touch.
• An order small enough to stop after one step.

The option I turned down was to keep all three panels mounted and hide the inactive ones. The state would have survived. So would a live request, running inside a panel the user can no longer see. Hidden is not the same as stopped.

The second pass is the job

I approved the plan and let the agent implement it. Then I asked it to argue with the result, before I ran the build: is this actually clean, or does a step contradict the goal?

Three findings were specific enough to keep.

The new provider was still inside the condition that shows the panel. Collapse it and the provider unmounts with it. We had moved the state and left it in the thing that dies. The plan said "above the tabs." The code said "inside the panel."

It also aborted the request when the results view unmounted. That looks like cleanup. On a tab switch it cancelled a request that was already in flight, set loading back to false, and left the user on the results step with nothing on screen and no error. Before the change, the step at least reset. After it, they were stuck. Abort belongs to whoever owns the search, and only when that owner goes away or the user starts over.

// Abort with the owner. A tab unmount is not that.
useEffect(() => {
  return () => controllerRef.current?.abort();
}, []);

The third was the same shape, smaller. The plan said the fields would come back from the reducer. They did, for values already committed with "next." Characters still in the field were local state, and the tab switch still ate them. The reducer has to hear the keystroke.

I applied those. The typecheck I ran myself. The agent had already said its install was broken and the check could not be trusted. Taking that sentence as a green build would have been the actual mistake.

Read the claim, then the code

I can reject "add a cache" in a paragraph. I cannot reject it once it is a new provider, a key convention, and a pile of rewritten lists. Asking the agent to attack its own plan is the same habit: the claim is on one page, and someone has to check the code still matches it. I would rather that someone be the agent, and the decision stay with me.

A few things I would keep in mind.

Say "do not write code" when you want an analysis. If you do not say it, you will get a diff.

Keep the "not now" as its own plan. A comment that says "maybe later" is how a library sneaks into a bugfix. A second document, with what it does not fix, is something you can reopen on purpose.

Ask for the attack after the code exists. "Is this clean?" is a weak question. "Does a step contradict the goal?" is the one that returned the abort.

Run the check yourself. A model that tells you it could not verify is behaving. It has not verified.

That's it, fellows. The model can hold the whole tree. I still want the decision on one page, where I can say no.

Happy coding folks! 😎