Personas

Personas don't make models smarter - they steer them toward a relevant subset of their training data. Here's how they actually work and when to use them.

March 30, 20264 min read5 / 6

Assigning a persona to a model is one of the most commonly misused techniques. Done right, it's genuinely useful. Done wrong, it's just wasted tokens.

What Personas Actually Do

The misconception: "You are a senior Google engineer" makes the model smarter.

The reality: it steers the model toward a relevant subset of its training data.

When an LLM is trained, it builds connections between concepts — the same way a neural network in your brain creates associations when you learn something new. Practicing guitar strengthens the neural pathways related to hand-eye coordination and musical patterns.

When you tell a model "you are a database expert," you're pointing it toward the area of its training that contains database concepts, vocabulary, and patterns. It doesn't become smarter — it focuses on database-relevant knowledge.

Plain text
"You are a database expert." → Model activates: indexing strategies, normalization, query optimization, replication patterns, performance trade-offs "You are a security engineer." → Model activates: OWASP, injection vulnerabilities, authentication patterns, permission models, attack surfaces Same underlying model. Different focus area.

What Personas Affect

Research on model outputs found that personas primarily affect:

  1. Vocabulary selection — terminology shifts to match the role
  2. Response structure — a technical writer structures differently than an engineer
  3. Error checking behavior — a security engineer checks for vulnerabilities; a UX designer checks for accessibility

They do not unlock knowledge the model doesn't have, nor do they dramatically improve accuracy on tasks outside the persona's domain.

Practical Examples

Code review with a security lens:

Plain text
You are a senior engineer focused on security and performance. Review the following code and identify any potential concerns. [paste code]

This surfaces: unbounded input sizes, innerHTML usage for templates, missing rate limiting, missing input sanitization — the kinds of things a security-oriented review should catch.

Same code, different lens:

Plain text
You are a UX/UI designer. Review this Prompt Library application and suggest improvements from a user experience perspective. [paste code / describe app]

Now you get: accessibility improvements, color contrast issues, button placement, keyboard navigation gaps, empty state handling — entirely different concerns, same application.

Good Use Cases

Code review with a specific focus:

Plain text
You are a performance engineer. Review this code and identify bottlenecks, unnecessary re-renders, or inefficient algorithms.

Learning a new concept:

Plain text
You are a JavaScript tutor teaching someone who knows Python. Explain closures using Python analogies where helpful.

Translating a complex code review:

Plain text
You are a staff engineer who wrote this code review comment. Explain it to a mid-level engineer in plain terms: [paste code review comment]

Documentation for different audiences:

Plain text
You are a technical writer who prioritizes clarity for non-technical stakeholders. Summarize this API endpoint in language a product manager can understand.

When Personas Fall Short

Too long a persona description creates rigidity:

Plain text
❌ Overly constrained: "You are a Python expert who only uses functional programming, avoids classes, prefers list comprehensions, never uses loops, studied at MIT, worked at Google for 15 years, prefers asyncio over threads, and never uses type hints..." → You've made the model too rigid to be generally helpful. You're restricting it more than guiding it.

The more constraints you pile on, the more the model loses its general-purpose usefulness. Keep personas short and focused on the perspective you actually need.

Plain text
✅ Focused persona: "You are a security engineer reviewing production code." → Focused, actionable, gives the model a clear direction.

Changing Personas Mid-Conversation

You can switch personas in a running conversation to get multiple perspectives:

Plain text
Message 1: "You are a security engineer. Review this auth middleware." [get security-focused review] Message 2: "Now approach this as a performance engineer. What are the bottlenecks?" [get performance-focused review] Message 3: "Finally, as a junior engineer new to this codebase, what parts of this code would be confusing to understand?" [get readability-focused review]

Three reviews from three perspectives in one chat — each focused on a different dimension of quality.

Personas for Learning

Personas are excellent for personalized studying:

Plain text
"I have ADHD and learn best through questions and immediate feedback. Act as a quiz-based tutor for JavaScript closures. Ask me one question at a time. If I answer correctly, move on. If I answer incorrectly, explain what's wrong in 2 sentences, then ask again."

One-shot the learning style:

Plain text
"Here's how I learn best: Input: you ask me a question I answer Output: you tell me if correct or incorrect. If incorrect, give a 2-sentence explanation in plain English, then ask the next question. Example: Q: What does `const` prevent? A: Reassigning the variable Output: Correct. [next question] Now quiz me on JavaScript closures."

The One-Line Rule

If you can't describe the persona in one focused sentence, you're over-constraining it.

Plain text
✅ "You are a technical writer who values clarity over completeness." ✅ "You are a senior security engineer reviewing production code." ✅ "You are a patient tutor explaining topics to a beginner." ❌ [7-sentence persona with 15 constraints]

A persona is a perspective pointer, not a character spec. Point it in the right direction, then let the model's general capability do the rest.

Enjoyed this? Get more like it.

Deep dives on system design, React, web development, and personal finance — straight to your inbox. Free, always.