Keep it on the rails
An agent that wants to help will help with things you never asked about, and it will deliver a vague answer in the same confident voice it uses for a good one. Two habits deal with both: fence the request before it spreads, and refuse anything that will not name a file, a screen or a setting.
- Name one outcome and say plainly that everything else stays
- Take what the agent noticed as a list, not as work already done
- Reject an answer that does not name what it touched
Ask for one thing, and say plainly that everything else stays as it is.
Give an agent a job and it will often find a second one on the way. It notices something untidy nearby, fixes that too, and mentions it at the end as good news. Sometimes it is good news. More often a change you did not ask for is now sitting in the same pile as the change you did, and pulling them apart is your evening.
The name for this is drift. It is not carelessness; the agent is trying to help and nothing told it where your request ended. So say where it ends. Name the one outcome, then say that anything else it spots gets reported rather than touched.
Drift also builds up across a long conversation. Twenty messages in, what you agreed at the start has been quietly renegotiated by ten small "while I was in there" moments, none of which looked like much on its own. A fresh session with a fresh brief costs almost nothing and resets all of it.
- 1
State the one outcome, and close the door on the rest.
Say what should be different when this is finished, and that nothing else changes.
CheckThe agent repeats back a single outcome rather than a list of improvements.
- 2
Ask for whatever else it noticed as a list, not as work.
It keeps the observation. You keep the decision about whether it becomes a task.
CheckExtra findings arrive at the bottom of the reply with nothing done about them.
One thing only this round: [state the single outcome].
Do not fix, tidy, rename or improve anything else, even where it looks wrong to you. Do not touch [name anything you want protected].
If you notice other problems while you are in there, do not act on them. Put them at the bottom of your reply as a numbered list and I will decide which ones become their own task.
When you are finished, tell me exactly what changed, and nothing else.The tell that it worked: a short list of changes, and a separate list of things left alone.
What if the thing it noticed is actually serious?
Then you want to know, and the rule already gives you that. It reports, you decide. What you are refusing is not the information, it is having the fix arrive folded into work you were halfway through checking.
Take the serious ones and give each its own task and its own before and after. A security hole fixed on its own is one you can point at later. The same fix buried inside a screen redesign is one nobody will ever find again.
Demand specifics, and reject work that is vague or off-plan.
Read replies like a product person. Good replies name files and screens, show short code with one purpose, explain why, call out risks, and say how to test. Hand-wavy replies say “should work,” skip filenames, and change extra things without warning.
When a reply is soft, ask sharp questions: Which files change, what lines move, what is the rollback, what is the test. If you still get fog, reject the plan and say why. Name the gap and the fix you expect. A clean “no” now saves a messy revert later.
Praise tight work. Note what was clear. Then ask for the next small step. The tone you set gets mirrored back in the next round.
- 1
Ask for missing specifics when a reply is vague.
Request filenames, exact changes, test steps, and rollback notes.
CheckThe agent adds concrete details or admits it needs to revise.
- 2
Reject an off-plan proposal with reasons and a constraint reminder.
State what broke the plan and restate the constraint it missed.
CheckThe agent proposes a revised plan that fits your constraints.
Your last reply is too high-level. Provide:
- Exact filenames and paths you will change
- A bullet list of the lines or blocks you will add or remove
- A one-sentence why for each change
- A human-runnable test
- A simple rollback
If you cannot, say what you are missing so I can fill the gap.I am rejecting this plan because [reason]. It violates [constraint from context packet]. Propose a new plan that does only [narrow goal], names the exact files to touch, and includes one human test. Wait for approval before code.