Give the Model a Role

Here is the technique, first:

You are a senior security reviewer with 15 years auditing
authentication systems for government deployments. Review the
login function below. Flag anything you would not let ship,
ordered by severity, with the specific risk for each.

[paste the code]

Compare that to “review this login function.” Same task, same code. The first version produces a deeper, more skeptical, more domain-aware review — because the opening line told the model who it is being before it read the task.

Why a role changes the output

A role is not roleplay. It is a fast way to point the model at a region of its training. “You are a senior security reviewer” pulls the response toward the vocabulary, priorities, and caution of security reviews — threat models, severity ordering, defense-in-depth — without you having to spell each of those out. The same task framed as “you are a friendly tutor explaining to a beginner” pulls toward analogies, gentle pacing, and no jargon.

You were taught the coworker mental model back in Module 1: treat the AI like a brilliant but literal new hire. The role is how you tell that new hire which expert showed up for work today.

Generic role vs. specific role

The mistake people make is stopping at the job title. A title alone barely moves the output. The specifics are what work.

Weak (a label):

You are a UX designer. Improve this signup form.

Strong (a label with the context that shapes judgment):

You are a senior UX researcher who specializes in SaaS onboarding
and has watched hundreds of users abandon signup flows. Review this
signup form for friction. For each issue, name the drop-off risk and
the smallest change that would reduce it.

The second version did not just rename the model — it told it what to care about (drop-off, friction, minimal change). A good role answers three questions:

1. Who — the expertise (“senior security reviewer,” “clinical data manager”)
2. What they care about — the lens (“flag anything you would not let ship,” “optimize for reproducibility”)
3. How they communicate — the register, if it matters (“explain it so a non-engineer can sign off”)

A worked contrast

Same request — “summarize this incident” — under two roles:

Role A:

You are an SRE writing a blameless post-incident review. Summarize
the incident below for the engineering team: timeline, root cause,
contributing factors, and follow-up actions. No blame language.

Role B:

You are a communications lead writing a customer-facing status update.
Summarize the incident below for non-technical customers: what was
affected, for how long, and what we are doing about it. Reassuring,
no internal jargon, under 120 words.

Same source text. The SRE version produces a structured technical timeline; the comms version produces a short, calm, jargon-free notice. You did not write two different sets of instructions — you cast two different experts.

When a role helps — and when it does not

Roles earn their keep on judgment-heavy, open-ended tasks: reviews, analysis, writing, advising, anything where expertise changes the answer.

They add little to mechanical, well-specified tasks. “Rename this variable across the file” does not get better because you said “you are a senior engineer” — the task has one correct output and no room for expert judgment. Adding a role there is harmless but pointless noise.

Key takeaways

• Role first, task second. Telling the model who it is before what to do shifts depth, vocabulary, and judgment for free.
• A title alone is weak. Add what the expert cares about and how they communicate — that is what moves the output.
• Put it where it persists. System prompt if you have one; top of the prompt or the project context file in a CLI.
• Roles shine on judgment work, not mechanical tasks. Don’t bother role-casting a rename.
• A role is a lens, not a credential. It shapes reasoning; it does not guarantee correctness. Verify anyway.

Next: Show, Don’t Tell