You asked the model to “explain how Postgres connection pooling works”. The output is 800 words pitched at… someone. It defines what a connection is (too basic for the senior engineer you wanted), uses terms like “client/server architecture” without naming PgBouncer (too vague for the DBA reviewing this), and skips the operational tuning advice you actually needed. The model wrote for an imaginary average reader, which is no reader, which pleases nobody. Audience is the load-bearing constraint that calibrates vocabulary, depth, examples, and tone. Without it, the model picks a middling default that wastes both basics and depth.
This page walks through why omitting audience produces unusable output and how to specify audience in one line that calibrates everything else.
Common causes
1. Prompt focuses on subject, not reader
You wrote “explain X” without saying “to whom”. The model defaults to a generic educated-but-not-expert reader. That reader does not exist.
How to spot it: prompt has the topic but not the person.
2. Audience implied via context but not stated
“Our users” or “the team” leaves the model guessing who that is. Your team and the model’s training-set “team” are different.
How to spot it: audience referenced obliquely.
3. Multiple audiences in one piece
Trying to serve juniors and seniors with the same paragraph means each paragraph compromises. The output is “tutorial-with-too-much-jargon” or “reference-with-too-many-basics”.
How to spot it: you have multiple stakeholders, each unhappy with different parts.
4. No “what the audience does next”
If you do not say what the reader will do after reading, the model defaults to “comprehensive understanding” which is too broad. Reader purpose calibrates depth.
How to spot it: prompt has no verb for the reader.
5. No example of acceptable tone for the audience
You named the audience but did not anchor the voice. The model picks a default tone that may not match how your real audience prefers to be addressed.
How to spot it: tone is off even though audience is correct.
Before you change anything
- Identify who the actual reader is in 5 words: role + experience + current task.
- Find what they already know (so you can skip it).
- Identify what they will do after reading.
- Find one sentence of writing they would consider “in their voice”.
- For multi-audience pieces, decide the primary audience.
Information to collect
- Current prompt.
- The output that was wrong-pitched.
- Your real audience (role, level, context).
- What they should be able to do after reading.
- Any prior content they liked or disliked (as anchors).
Shortest path to fix
Step 1: Add an audience block
## Audience
Role: senior backend engineer at a fintech
Knows: SQL well, runs production Postgres, has tuned pools before
Does not know: PgBouncer internals
Next action: choose between PgBouncer transaction-mode and session-mode
Tone: peer-to-peer, no hand-holding, terminology assumed
(For the rest of the prompt: write accordingly.)
One block calibrates vocabulary, depth, examples, and tone.
Step 2: State what to skip
Do not:
- Explain what a database connection is.
- Walk through what SQL means.
- Use the phrase "let's start from the basics".
- Compare to MongoDB.
Do:
- Use Postgres-specific terms (WAL, MVCC, prepared statements).
- Reference PgBouncer config parameters by name.
- Cite line-level config recommendations.
Negative constraints prevent basics from sneaking back in.
Step 3: Calibrate vocabulary
Match the reader’s vocabulary. For experts, use jargon without defining it. For non-experts, define on first use. For mixed, define in a footnote so experts can skim.
Step 4: Anchor with a voice sample
Tone anchor (this is how the audience writes/reads):
"We hit pool exhaustion under load. Moved to PgBouncer transaction mode,
dropped p99 by 40%. Watch out for prepared statement compatibility."
Match this tone — direct, specific, no fluff.
Step 5: For multi-audience, split
Audience: primary = senior engineers, secondary = junior engineers
Section 1 (for senior): operational tuning, pool sizing math
Section 2 (for junior, labeled): glossary of terms used above
The label makes it usable for both without compromising either.
Step 6: Validate with a real reader
Before scaling the prompt, send one output to someone in the actual audience. If they say “this is for me”, you have landed.
How to confirm the fix
- A real reader from the target audience reads the output and says it is calibrated for them.
- Vocabulary matches what they use.
- Skipped basics are skipped; assumed knowledge is assumed.
- The reader can take the next action (the verb you specified) without follow-up.
- Output tone matches your anchor sample.
If it still fails
- The audience description may still be too vague — get more specific on role + level + task.
- Add a sample of writing they like as an anchor.
- Reduce audience scope — narrower audience produces better-calibrated output.
- For multi-audience pieces, just produce two outputs; merging is usually worse than parallel.
Prevention
- Default: every content-generation prompt names the audience in one line.
- Save audience profiles for recurring readers (senior engineer, founder, designer, etc.).
- Audit your last 5 prompts: how many specified audience? If under 5, that is your habit gap.
- For team workflows, build audience profiles as a shared resource.
- Treat “general audience” as a smell — it usually means “I have not figured out who this is for”.
- When in doubt, ask the model to propose 3 audience candidates and pick one.
Related reading
- Prompt too broad
- Prompt copied from another task
- Ambiguous evaluation criteria
- Long prompt degrades output
- AI output style drift
Tags: #Troubleshooting #Prompt #Prompt quality #Prompt engineering