Iterative Refinement

Almost no first response from Claude is exactly what you need — and that's fine. The real skill is knowing how to give feedback that moves the output toward what you want without wasting turns or going in circles. This page covers the patterns that work.

Giving Feedback Claude Acts On

The most important thing about feedback is being specific about the problem, not just expressing dissatisfaction:

When you can't articulate what's wrong, try: "What I liked: [X]. What needs to change: [Y]. Specifically, [Z]."

Point at the Problem vs Ask for a Full Redo

When something is partially right, asking for a full rewrite risks losing the parts that worked. Point at the specific problem instead:

• "Keep everything except the final paragraph — rewrite that paragraph to be more actionable."
• "The structure is right. Just change the tone throughout from passive to active voice."
• "Only change the error handling in the fetchData function — the rest of the code is fine."
• "The logic is correct but the variable names are unclear — rename them to be self-documenting without changing anything else."

A full redo is appropriate when the output missed the goal entirely — not when one part needs adjustment.

Additive Iteration: Building on What Works

The most efficient iteration pattern is additive: accept what's good, add to or adjust what isn't:

1. Get the structure right before worrying about content detail
2. Get the content right before worrying about wording and tone
3. Get the wording right before worrying about formatting and polish

Working in layers prevents you from polishing a section that will later be restructured. It also makes each iteration request smaller and more targeted — which produces fewer unintended side changes.

For Artifacts, use version history to your advantage: each update creates a new version. You can always navigate back if a later iteration went in the wrong direction.

When to Accept Good Enough vs Keep Iterating

More iteration doesn't always produce a better result. Signs that it's time to stop:

• You've made the same correction twice and the issue keeps returning — Claude may not be able to satisfy this constraint without more explicit instruction or a different approach
• Each new version fixes one thing but breaks something else — you're in a refinement loop with no forward progress
• The remaining issues are minor enough that manual editing would be faster than prompting
• The output is "good enough for the purpose" — not perfect, but fit for what it needs to do

In these cases: take the output, make the remaining small edits yourself, and move on. Claude is a collaborator that gets you 80–90% of the way — the last 10% is often faster to finish yourself.

Tracking Changes Across Iterations

For multi-iteration work, it helps to keep track of what has been settled and what is still being refined:

• Checkpoint in conversation: "The introduction and section 2 are final — don't change those. Focus all remaining edits on sections 3 and 4." This prevents Claude from accidentally revising settled parts.
• Use Artifact versioning: Artifact version numbers correspond to conversation messages — you can see exactly what changed at each step by navigating the version history.
• Name your milestones: "This is a good checkpoint — structure is locked. Now let's add the data for each section." Naming milestones makes version history navigable.
• Copy settled sections out: For long documents, paste final sections into a separate note with "FINAL:" to remind yourself not to request changes to those parts.

Checklist: Do You Understand This?

• Specific feedback (what's wrong and why) produces better corrections than vague dissatisfaction
• Point at the specific problem rather than asking for a full redo when parts are already right
• Work in layers: structure → content → wording → formatting — don't polish what may change
• Stop iterating when you're in a refinement loop with no progress, or when manual editing would be faster
• Checkpoint settled sections explicitly so Claude doesn't accidentally revise them in later iterations