This guide is for anyone who hands a coding agent work that takes more than one sitting: a feature, a redesign, a migration. You get the loop we use on our own projects, and the reasons behind each step.
Why a loop and not one big prompt
One long prompt with everything in it works for small tasks. For large ones it fails in a predictable way: the agent fills the gaps with guesses, the guesses compound, and you find out at the end. A loop puts a checkpoint between each guess and the next.
1. Notes first, questions at the end
Write what you want as notes, in as many messages as you need, in any order. Ask the agent not to reply with questions after each one, only to record them.
When you say the notes are finished, the agent asks all its questions at once. Asked at the end, the questions are fewer and better: half of the early ones would have been answered by a later note.
Ask for questions that can be answered with one word or one letter. “Should the panel be fixed, A, or scroll with the page, B?” gets a clear answer. “Any thoughts on the panel?” does not.
2. A plan you read before any code
The agent turns notes and answers into a written plan, saved in the project, split into steps. A plan says what will change, in which files, in what order, and how each step will be checked. It contains no code.
Read it. This is the cheapest moment to change your mind. It is also where misunderstandings show up: a step that does more than you asked, or a step that is missing.
3. One step at a time
The agent does one step, then stops. At the end of each step you get:
- what changed, and what was measured to prove it;
- a screenshot when something visible changed;
- a short recap file saved in the project;
- a commit.
You can ask for changes at any step. Because each step is small and committed, a change of direction costs one step, not the whole task.
4. A report when the plan is done
At the end the agent writes a report: what was built, what was decided along the way and by whom, and what is still open. It updates the project’s own instructions and to-do list, so the next session starts from the facts and not from memory.
Things that make the loop work
Reread the source, not the summary. Before writing code that depends on one of your answers, the agent should open the file where the answer is written and reread it. A summary keeps what the summariser found important, and an agent’s own proposal is easier to remember than the answer that rejected it.
Mark what was measured. In plans and recaps, ask for a distinction between what was observed, with the command or number that shows it, and what was reasoned. A claim without a mark should be treated as a guess.
Decisions taken alone are listed. The agent will have to decide small things you never mentioned. That is fine, as long as each one is written down for you to confirm or reverse.
A missing figure stays missing. If a number is not known yet, the text says so with a placeholder. A plausible number written with confidence is worse than a gap.
When to skip it
A typo, a single function, a one-line change: just ask. The loop pays for itself when the work is long enough that you cannot hold all of it in your head at once.