Prompt Engineering for Developers: A Visual Cheat Sheet
Prompts are just functions (with feelings)
You already know how to write functions. You give them input, they do something, they return output. Prompts are the same — except the "compiler" is a neural network, and the "errors" are vibes.
The good news? Prompt engineering isn't magic. It's just communication with a very literal computer. Here's the cheat sheet.
The anatomy of a prompt
Every prompt has four parts. Think of them as ingredients:
┌─────────────────────────────────────────────────┐
│ YOUR PROMPT │
├─────────────┬─────────────┬───────────┬─────────┤
│ ROLE │ CONTEXT │ TASK │ FORMAT │
│ "You are" │ "Here is" │ "Do this"│ "Like" │
└─────────────┴─────────────┴───────────┴─────────┘
| Part | What it does | Example | | --- | --- | --- | | Role | Sets the persona | "You are a senior TypeScript developer" | | Context | Gives background info | "We have a Next.js app with App Router" | | Task | Says what to do | "Write a function that validates email" | | Format | Defines the output | "Return TypeScript with JSDoc comments" |
You don't always need all four. But when the output is wrong, check which part is missing.
The specificity ladder
Vague prompts get vague answers. Climb the ladder:
Level 1: "Write code"
↓ (too vague, could be anything)
Level 2: "Write a function"
↓ (better, but what kind?)
Level 3: "Write a validation function"
↓ (getting warmer)
Level 4: "Write a Zod schema that validates
a user email with max 254 chars"
↓ (now we're talking)
Level 5: "Write a Zod schema for user email.
Max 254 chars. Must contain @.
Return { success, data, error }.
Add JSDoc. Use strict TypeScript."
(specific, bounded, testable)
Each level adds a constraint. Constraints reduce the model's "search space" — the number of possible answers it could give. Fewer possibilities = better answers.
The context window is your RAM
Think of the model's context window like RAM. You have limited space. Use it wisely.
┌────────────────────────────────────────────┐
│ CONTEXT WINDOW (8K tokens) │
├──────────┬──────────┬──────────┬───────────┤
│ System │ Your │ Model's │ Remaining │
│ prompt │ question │ answer │ space │
│ 500 tk │ 200 tk │ ??? tk │ 7300 tk │
└──────────┴──────────┴──────────┴───────────┘
Bad: "Here's our entire codebase..." (7000 tokens)
→ No room for the model to think
Good: "Here's the relevant file..." (300 tokens)
→ Plenty of room for a good answer
Rule of thumb: give the model the minimum context it needs to answer correctly. More context ≠ better answers. Often it's the opposite.
Chain of thought: show your work
When you want the model to reason, ask it to think step by step. This isn't just for math — it works for code too.
Bad: "Is this code correct?"
Good: "Review this code step by step:
1. What does it do?
2. What are the edge cases?
3. What could go wrong?
4. Suggest fixes."
The model "thinks" by generating tokens. More thinking tokens = better reasoning. Asking for steps forces it to generate those tokens.
The few-shot trick
Instead of explaining what you want, show examples. The model learns the pattern.
Convert these function names to kebab-case:
getUserById → get-user-by-id
fetchData → fetch-data
calculateTotal → calculate-total
parseJSON → ???
The model sees the pattern and completes it. No explanation needed. This is called "few-shot" prompting — a few examples teach the pattern.
System prompts are your config file
The system prompt is like a config file that runs before your code. Set it once, get consistent behavior.
┌─────────────────────────────────────────────┐
│ SYSTEM PROMPT (invisible to user) │
│ │
│ "You are a code reviewer. Be concise. │
│ Focus on bugs, not style. Return markdown."│
├─────────────────────────────────────────────┤
│ USER PROMPT (visible) │
│ │
│ "Review this function: [code]" │
└─────────────────────────────────────────────┘
Good system prompts:
- Define the role clearly
- Set output format
- List constraints ("Don't explain, just fix")
- Stay short (long system prompts eat context)
Temperature: creativity dial
Temperature controls randomness. Think of it as a creativity dial.
Temperature 0.0 → "The answer is 42."
(deterministic, same every time)
Temperature 0.5 → "The answer is approximately 42."
(slight variation, mostly consistent)
Temperature 1.0 → "Well, it depends on who you ask..."
(creative, unpredictable, sometimes wrong)
| Use case | Temperature | | --- | --- | | Code generation | 0.0 - 0.2 | | Bug fixing | 0.0 - 0.3 | | Creative writing | 0.7 - 1.0 | | Brainstorming | 0.8 - 1.2 |
For code, keep it low. You want predictable, correct output — not "creative" variable names.
The debugging loop
When the model gives a bad answer, don't just retry. Debug it like code.
Bad answer received
│
v
Is the task clear? ──no──→ Rewrite the prompt
│ (add specifics)
yes
v
Is context enough? ──no──→ Add relevant code/docs
│ (but not too much)
yes
v
Is format specified? ──no──→ Add "Return as..."
│ (TypeScript, JSON, etc.)
yes
v
Is the model wrong? ──yes─→ Try a different model
│ or temperature
no
v
You might be asking
the wrong question
Common mistakes (and fixes)
Mistake: "Make it better"
Fix: "Add error handling for null values"
Mistake: "Fix this code" (no code provided)
Fix: Paste the actual code
Mistake: "Write tests" (no context)
Fix: "Write Vitest tests for this function: [code]"
Mistake: "Explain this" (pointing at nothing)
Fix: "Explain what this line does: const x = a ?? b"
Mistake: "Do the thing"
Fix: What thing? Be specific.
The prompt template
Here's a template you can copy-paste and fill in:
ROLE: You are a [specific role].
CONTEXT: [What the model needs to know]
TASK: [What to do, step by step]
FORMAT: [How to return the answer]
CONSTRAINTS:
- [What NOT to do]
- [Edge cases to handle]
- [Style/format requirements]
Example:
ROLE: You are a senior TypeScript developer.
CONTEXT: We use Next.js App Router, Zod for validation,
and Vitest for testing.
TASK: Write a function that validates a user's display name.
It must be 3-30 chars, alphanumeric + spaces only.
FORMAT: Return a Zod schema and a helper function with JSDoc.
CONSTRAINTS:
- Don't use regex (too hard to read)
- Return { valid: boolean, error?: string }
- Include 3 test cases
The one rule
If you remember one thing: prompts are instructions, not wishes.
"Write good code" is a wish. "Write a function that sorts an array of objects by date, descending, handling null dates" is an instruction.
The model doesn't know what you mean. It knows what you say. Say what you mean.
Further reading: OpenAI Prompt Engineering Guide, Anthropic Prompt Library, Google AI Prompting Guide, and Learn Prompting.