For anything larger than a small change, do not ask for code. Ask for the plan.
Before you write anything: how would you add tags to Readlist?
List the steps and which files you would change. No code yet.
Ten seconds to read. Ten seconds to reject. Compare that with reading four modified files and trying to work out what happened.
What a good plan contains
Plan for tags:
1. Change the saved item shape from a plain string to an object
with a url and a tags array. Add a migration so existing saved
items still load.
2. Add a second text box next to the URL box for comma-separated tags.
3. Show tags as small labels under each list item.
4. Add a filter row at the top: clicking a tag shows only matching items.
Files: readlist.html only.
Not doing: editing tags after saving, tag autocomplete, tag colours.
Open question: should an item with no tags be hidden when a filter
is active, or always shown?
Four things make this a good plan, and you can check all of them without knowing a line of code:
- Ordered steps in plain language.
- Which files get touched.
- What it is deliberately not doing — this is the line that catches scope creep before it exists.
- An open question where a real decision is needed.
That last one is worth its weight. The plan surfaced a decision you had not thought about, at the only moment when answering it is free.
Quick check
Which line in a plan is most valuable for preventing scope creep?
The two questions that catch a bad plan
“Which files will you change?”
If the plan for a delete button mentions the save logic, the styling and a new file, one of two things is true: it understood something different from what you meant, or it is bundling in work you did not ask for. Both are worth a sentence right now.
“What could go wrong with this approach?”
Asked directly, agents are surprisingly good at naming the weak point of their own plan. They rarely volunteer it, because nothing rewards volunteering doubt — but they will answer honestly when asked.
For the tags plan above, the honest answer is the migration: everyone who already has links saved will break if the loading code does not handle both the old shape and the new one.
Quick check
You ask what could go wrong and the agent names a real risk. What does that tell you?
Approving, redirecting, restarting
Three responses, all short.
Approve:
Plan looks right. Items with no tags stay visible when a filter is on.
Go ahead, and do step 1 first so I can check the migration.
Redirect:
Steps 1-3 yes, step 4 no — no filtering yet. And do not change how
items are stored; keep the plain string and put tags in a separate list.
Restart:
That is more than I want. Simplest possible version: one optional
tag per link, shown as text. No filtering, no data migration.
Every one of those is cheaper than reading the code that would have come from the wrong plan.
Tip
If a plan has more than about five steps, it is probably two tasks. Ask for the first one only. Plans that grow past a handful of steps produce changes nobody reviews properly.
When to skip the plan
Not every request needs one. Skip it for:
- Cosmetic changes — colours, labels, spacing.
- Anything you can verify by looking at the screen in two seconds.
- Fixes where you already know the cause and the change is one line.
Ask for one for:
- Anything touching how data is stored.
- Anything touching more than one file.
- Anything involving money, accounts, permissions or deletion.
- Anything you would find hard to undo.
Important
The rule of thumb: if being wrong would cost you more than five minutes, spend thirty seconds on a plan.
Quick check
For which change should you definitely ask for a plan first?
Some tools have this built in
A few agents ship a mode that plans first and waits for approval before touching anything. If yours has one, use it for anything structural — it makes the good habit the default.
If yours does not, the sentence “plan first, no code yet” does the same job. This is a habit, not a feature.
Try it yourself
A plan arrives. Read it, question it, or skip it — and see where each choice lands.