Iterative refinement
Prompt Engineering
Most people use Claude like a search engine: one prompt, one response, move on. That works for quick lookups, but it misses the most productive way to work with an AI — as a back-and-forth collaboration where each exchange builds on the last. This chapter is about getting significantly better results by treating the conversation as a process, not a transaction.
Why Iteration Beats a Perfect First Prompt
There's a common belief that better prompting means writing a longer, more detailed first message. That's sometimes true, but it has a ceiling. The problem is that you often don't know exactly what you want until you see something that isn't it. The first response gives you information — about how Claude interpreted the task, what it assumed, what it emphasised — that you can then use to redirect precisely.
A second targeted message is almost always more efficient than trying to anticipate every possible misalignment in message one. And critically, Claude retains everything in the conversation — you don't have to re-explain the whole situation, just the delta.
A Refinement Workflow
Send a good-enough first prompt
Don't spend ten minutes perfecting it. Apply the four pillars from Chapter 2, send it, and see what you get. The response is information.
Diagnose specifically
What exactly is wrong or missing? Too long? Wrong tone? Right approach but wrong level of detail? Missed a constraint? Name it precisely — vague feedback produces vague revisions.
Give targeted follow-up
One specific correction per message is more effective than a list of complaints. Claude acts on the most recent instruction most strongly — be specific about what to change and what to keep.
Confirm and lock in what's working
If something in the response is exactly right, say so. "Keep the structure but change X" signals clearly what's preserved. This prevents Claude from throwing out the good parts in revision.
Converge to done
Most tasks reach a good result in two or three iterations. If you're still not happy after five, the problem is usually the task framing — consider starting fresh with what you've learned.
A Full Refinement in Practice
The Refinement Move Library
These are the follow-up patterns that work most reliably:
That's too long. Cut it to three bullet points covering only X.
When Claude over-explains. Be specific about what to keep and what to drop.
Too formal. Rewrite it in plain conversational English — as if explaining to a colleague over coffee.
Tone corrections. Always say what you want, not just what you don't want.
Keep the structure and examples. Just change the conclusion paragraph to recommend option B instead.
The most useful move. Explicitly tells Claude what's preserved so it doesn't discard good work.
Redo this but assume the reader has no Linux experience. Avoid all command-line instructions.
When the first response made a wrong assumption you didn't specify upfront.
Give me two more versions of the opening paragraph with a different angle each.
When the output is fine but you want options before committing. Generates variation without starting over.
Expand just the third point — that one needs more detail and a concrete example.
When most of the response is good but one section is too thin. Surgical rather than wholesale.
You've argued for it well. Now steelman the opposite position.
Useful for decisions and reviews. Forces examination of assumptions from a different direction.
Good template. Now apply it to this specific case: [paste your actual data].
Get a general framework first, then instantiate it with specifics. Often cleaner than providing specifics upfront.
Anti-Patterns to Avoid
| Anti-pattern | What happens | Instead |
|---|---|---|
| Vague dissatisfaction | "That's not quite right" — Claude doesn't know what to fix and guesses | Name the specific thing that's wrong: "The tone is too formal" or "You missed the budget constraint" |
| Starting over instead of refining | You paste a new prompt from scratch, losing all the context and good parts of the previous response | Build on what's there. "Keep X, change Y" is almost always faster than starting fresh |
| Approving and then complaining | "Great!" followed by "actually this is wrong" — Claude anchors on the approval and the correction lands weakly | If something is wrong, say so directly. Reserve praise for when you're genuinely done |
| Too many corrections at once | Claude addresses some of them and misses others, or makes the changes inconsistently | One or two specific corrections per turn. If there's a lot to fix, prioritise the most important one first |
| Iterating past the point of diminishing returns | Five or more rounds of minor tweaks with no clear improvement — often means the original framing is wrong | After three turns without convergence, start fresh with a better-informed prompt based on what you've learned |
Using Context to Your Advantage
Because Claude retains the full conversation, you can build up shared understanding over several turns that would be unwieldy to establish in a single prompt:
When to Start a New Conversation
Iterating within a conversation is powerful, but there are times to start fresh:
- The task has genuinely changed. If you've moved to a completely unrelated problem, a new conversation keeps things clean and avoids earlier context bleeding in unhelpfully.
- You've accumulated a lot of wrong turns. If you've tried five approaches and rejected them all, the conversation history is now mostly noise. A fresh start with better-informed framing is faster.
- You need an unbiased take. Earlier exchanges can anchor Claude's responses. If you want a genuinely fresh perspective on something, a new conversation without the prior framing gets you one.