Two people ask Claude to write a product description for the same pair of running shoes. One gets three flat, generic sentences that read like they came from a thousand other listings. The other gets a specific, punchy paragraph that mentions the exact cushioning technology, calls out who the shoe is wrong for, and matches the brand’s actual tone. Same model. Same task, on paper. The difference wasn’t luck, and it wasn’t that one person is “better with AI” in some vague sense — it’s that one of them wrote a prompt that gave the model something to work with, and the other typed a sentence and hoped.
In every prompt I’ve helped someone fix, the failure looks like a model problem right up until you look at what was actually asked. It almost never is one. The model didn’t guess wrong because it’s unreliable — it guessed wrong because the prompt left the actual decision up to guessing. This isn’t a list of generic tips. It’s the handful of techniques that consistently separate a prompt that works from one that doesn’t, in the order that actually matters when you’re staring at a blank chat box.
Use the Restart Button
The single biggest advantage you have over almost any other form of iteration is that a chat with an AI model has a restart button. Nothing you tried five minutes ago is stuck in the system, quietly interfering with what you try next. That’s not true of most iterative work — edit a spreadsheet formula badly enough and you’re cleaning up the mess even after you fix it. A bad prompt just gets abandoned. You open a fresh conversation and try again with nothing carried over.
That changes how you should actually iterate. Don’t nudge a failing prompt with one more sentence tacked on the end, hoping the twelfth qualifier fixes what the first eleven didn’t. Isolate the variable that’s actually causing the problem, and test it clean. If you’re not sure whether the issue is your instructions or your example, strip the example out entirely and run it again. A prompt that’s accumulated six rounds of “no, also don’t do X” patches is usually worse than a prompt rewritten once from a clear idea of what went wrong.
Know Whether You’re Writing a One-Off or a Production Prompt
A prompt you type into a chat window only has to work once. You’re in the loop — if the output is close but not quite right, you read it, catch the problem, and correct it in the next message. That’s a completely different bar from a prompt that’s going to sit inside a chatbot, an automated workflow, or a tool that other people will use without you watching over their shoulder.
A production prompt has to hold up across the entire range of inputs it will ever see, with no human there to catch a bad output before it reaches someone. If you’re writing a support-bot prompt or an automated content pipeline, test it against the weird edge cases on purpose — the ambiguous question, the hostile input, the request that’s technically valid but nothing like what you had in mind when you wrote the instructions. A prompt that works great on the three examples you tried while writing it can still fail badly on the fourth thing a real user types.
Write for a Layperson You’ve Never Met
Philosophy journals have a specific editorial standard worth borrowing: a paper should be written so that an educated reader off the street could pick it up and fully understand the argument, with nothing lost and nothing assumed. That’s a harder bar than it sounds, and it’s almost exactly the discipline a good prompt needs. The model has no shared history with you, no sense of your team’s internal shorthand, and no way to guess what “the usual format” means unless you’ve told it.
This is where most weak prompts actually fail, and it’s rarely the wording. It’s tacit knowledge — the assumptions and context you’re carrying around in your head that feel obvious to you and are invisible to anyone, or anything, without it. The real skill isn’t writing eloquent instructions. It’s the harder, less glamorous work of sitting down and asking: what do I actually know about this task that the model has no way to see? Who is this for, what does “good” look like here, what would make this wrong even if it’s technically correct? Most people write down the parts of that answer that feel important. Fewer people systematically write down all of it, and that’s usually the entire gap between a mediocre prompt and a good one.
Structure the Prompt With Tags, Not Just Prose
Claude is specifically tuned to pay attention to XML-style tags as structural markers, which makes them a genuinely useful tool once a prompt has more than one moving part — instructions in one place, background documents in another, examples in a third. Wrapping each piece in a tag like <instructions>, <context>, or <examples> does something a wall of undifferentiated prose can’t: it tells the model exactly where one kind of information ends and another begins, instead of leaving it to infer the boundary.
This matters more as a prompt grows. A two-sentence request doesn’t need it. A prompt that pastes in a support ticket, references a style guide, and asks for three different things in sequence gets meaningfully more reliable once each part is clearly labeled, because the model isn’t spending any of its attention trying to work out where your instructions stop and your example text starts.
If You’re Building a Tool, the Tool Description Needs the Same Care
Anyone building an AI agent that calls tools or functions runs into a specific, avoidable mistake: they’ll spend real effort polishing the system prompt and then leave the tool’s own parameters named things like param_a and param_b, with no description of what the tool actually does or when to use it. The model doesn’t have an engineer’s intuition for what an ambiguously named parameter probably means — the tool definition is just more context in the same window, and if it’s underspecified, it sabotages an otherwise well-written prompt.
A useful habit here is to deliberately imagine operating with only the model’s own context and tools available — nothing you know from having built the system yourself. If a parameter’s purpose wouldn’t be obvious to someone reading only the tool’s name and description, it won’t be obvious to the model either. Treat every tool definition with the same prompt-engineering discipline as the instructions themselves, not as plumbing that doesn’t need writing.
When the Output Is Wrong, Debug It Like Code
Prompting is an empirical discipline, not something you get right by reasoning about it in the abstract. It takes a willingness to actually run the prompt, look closely at what came back, and treat an unexpected result as a bug to be diagnosed rather than a reason to just rewrite the whole thing from scratch. When an output is wrong in a specific, surprising way, the fastest fix is usually to ask the model directly why it interpreted the request that way, or to work backward through your own prompt and identify which line most plausibly caused the misread.
This is a distinct skill from writing the first draft of a prompt. It’s a debugging habit, and it’s the one that separates people who get steadily better at prompting from people who plateau after their first few attempts — the difference is whether a bad result gets investigated or just patched over.
The Mistakes That Show Up Most Often
A few failure patterns come up often enough to name directly. Assuming the model can infer intent it was never given — the tacit-knowledge problem above, dressed up as a “the AI just didn’t get it” complaint. Overloading a single prompt with several unrelated tasks at once, which tends to produce a mediocre result on all of them instead of a good result on one. Being vague about what success actually looks like, then judging the output against a standard that was never written down anywhere the model could see it. And treating every prompt as a one-shot attempt — not giving feedback on what was wrong with a previous response before asking for another pass, even though a model with the actual correction in front of it will usually fix precisely what you point at.
None of this is about finding a magic phrase or a clever trick. It’s the same discipline as writing clear instructions for a new hire who’s smart, fast, and has zero context on your business — except this one restarts clean every time you ask it to, which means there’s really no excuse not to iterate until the prompt actually says what you mean.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.