One Change per Prompt

You ask for three things at once: "add settle up, redesign the balances page, and rename the amount column". Twenty minutes later the app starts, but the balances are wrong. Was it the new feature, the redesign or the rename? You cannot tell, and neither can the assistant. Bundled requests make bundled bugs.

The rule

Ask for one change, review it, then ask for the next.

One change at a time gives you three things:

• A readable review. A small change fits in your head. A giant one gets skimmed, and skimming is where bugs hide.
• A clear cause. If something breaks, the last change broke it.
• A clean undo. You can throw away one bad step without losing three good ones.

For anything bigger than a single file, add a step before the code: ask for a plan. "Before writing code, list the files you would change and why." A plan is short, cheap to read, and easy to correct. Fixing a bad plan costs one sentence; fixing bad code costs an evening.

When a step comes back wrong, give feedback the way a good bug report does: what you did, what you saw, what you expected. "It doesn't work" gives the assistant nothing to go on.

The shortcut

Follow the rhythm plan, one step, review, next. Treat each step as finished only when you have read the change, tried it, and saved the working version.

The trap is the helpful extra. Assistants often tidy, rename or "improve" things near the code they are changing. Each extra is harmless on its own, but together they turn a small, readable change into a large one.

Drills

Answer fast — trust the rule.

Remember

• Rule: ask for one change, review it, then ask for the next.
• Shortcut: plan, one step, review, next. Plans are the cheapest place to fix mistakes.
• Trap: helpful extras that quietly turn one change into several.