There’s a prompting technique that sounds gimmicky the first time you hear it and quietly becomes one of the things you reach for most: before you ask your actual question, you tell the model who it’s supposed to be.
Not in a roleplay sense. More like: “You’re a skeptical editor who cuts anything that doesn’t earn its place” or “You’re a senior developer who’s allergic to over-engineered solutions.” Then you ask your question.
It works better than it should, and understanding why is actually useful — because the same reason it works tells you exactly when it won’t.
Why a Role Changes the Output
Without a role assignment, a model defaults to helpful-generalist mode: accurate, reasonably thorough, inoffensive. That’s not wrong, but it means the output gets calibrated toward nobody in particular. Assigning a role doesn’t trick the model — it collapses a huge space of possible responses down to a narrower slice that’s actually suited to your situation.
“Explain this to me” is underspecified. “Explain this to me as someone who teaches introductory statistics to undergrads who’ve never touched calculus” is not. The second version gives the model a real constraint to work against, and constraints produce better outputs than vague requests for quality.
The same mechanism applies to tone and judgment. Asking for “feedback” usually gets you a polite list of strengths and one gentle suggestion. Asking a “blunt technical reviewer who cares more about correctness than feelings” for feedback gets you something more useful — not because the model is being harsh, but because the role gives it permission to prioritize differently.
Where This Is Actually Useful (With Examples)
The obvious use cases are editing and feedback. A few that come up less often:
Planning and scoping decisions. “You’re a consultant who’s seen a lot of projects like this fail — what are the three things most likely to go wrong?” gets a different and usually more honest answer than “what could go wrong?” The open version invites a brainstorm. The first invites a pattern-match against failure modes, which is what you actually want.
Learning something technical. “You’re a patient teacher who uses concrete analogies and checks understanding before moving on” changes how explanations are structured — shorter steps, more examples, fewer assumptions about what you already know. Default responses on the same topic often front-load jargon because they’re targeting a general audience that statistically already knows some of it.
Drafting communications. “You’re a lawyer who drafts emails that are firm but not aggressive” and “You’re a customer success manager trying to retain a frustrated client” will produce very different versions of the same message. Both might be technically correct — but only one is right for your situation. The role is how you tell the model which one you need without writing a 200-word brief about your relationship with this particular person.
Pressure-testing ideas. “You’re a skeptical investor who’s heard a hundred pitches like this — what’s your first objection?” is almost always more valuable than “what are the weaknesses of this idea?” The investor framing implies a specific kind of skepticism: pattern recognition, commercial viability, incentive alignment. The generic question invites almost any answer.
The Limitations Are Real
Roles improve prioritization and tone — they don’t inject expertise the model doesn’t have. If you ask Claude to behave like a specialist cardiologist and then ask something that requires current clinical knowledge, you’ll get a plausible-sounding answer with the confidence of a specialist but without access to recent literature or case-specific judgment. The role is a frame, not a knowledge injection. For high-stakes factual questions, verify with primary sources regardless of what role you assigned.
Roles also backfire when they’re too theatrical. “You are a grizzled 1940s newspaper editor” is a fun experiment but rarely produces the best editing feedback, because you’ve introduced aesthetic constraints that compete with usefulness. The best roles are specific about judgment criteria, not personality. “An editor who cuts any sentence that doesn’t add new information” is more useful than “a terse editor.”
One more real limitation: the role only holds for that session. Each new conversation starts fresh. If you’ve dialed in a role that works for a recurring task — reviewing client proposals, say — write it down and paste it in each time rather than rebuilding it from scratch.
How to Write a Role That Actually Works
A useful role assignment has three parts: who they are, what they care about, and (optionally) what they’re allergic to.
“You’re a senior engineer” is too vague. “You’re a senior backend engineer who cares about reliability over cleverness and who will push back on any solution that adds a dependency unnecessarily” is specific enough to actually constrain the output.
The allergy part — what the role-player actively dislikes — is often the most powerful piece. This mirrors something I kept running into building automated pipelines on top of Claude: telling the model what a bad output looks like does more work than describing what a good one looks like. A role that includes explicit dislikes gives the model a concrete negative to avoid, not just a vague positive to aim for.
Start short and iterate. Give the role, ask your question, see where the output still misses, and add one specific constraint to the role description. Three or four iterations usually gets you something worth saving.
One Honest Caveat
This technique is not a shortcut past knowing what you actually want. The reason most people get mediocre outputs isn’t that they forgot to assign a role — it’s that they haven’t thought clearly enough about what a good output would look like. Role assignment helps when you have a real use case and a real standard in mind. It can’t manufacture those things for you.
If your output is still generic after assigning a role, the role itself is probably generic. Sharpen it the same way you’d sharpen a prompt: find the specific thing that’s missing from the output and name it explicitly as something the role-player cares about.
If you want to actually test whether this is worth your time: pick one task you use AI for regularly, write a three-sentence role description for it — specific, with at least one “this person is critical of X” — and use it every time for two weeks. After enough sessions it becomes obvious whether the technique is earning its keep, or whether the real problem was somewhere else in your prompt all along.
