Prompt Engineering for Backend Developers: The 3-Part Rule
Context, Task, Constraint — the one rule I check before sending any prompt, plus ten techniques that turned vague answers into precise ones.
I used to write prompts like "explain this code" or "fix my bug" and wonder why the answer was too generic to use. Every good prompt actually needs three parts, and missing any one of them produces a bad result.
| Part | Question | Example |
|---|---|---|
| Context | Who are you + what situation? | "I am a Spring Boot developer building JWT auth" |
| Task | What exactly do you want? | "Explain line 49 in JWTAuthenticationFilter.java" |
| Constraint | How do you want the answer? | "5 sentences, no code, beginner level" |
Point to an exact location, not "this code"
"Explain this code" forces the model to guess what matters. Exact file + exact line + the pasted line gets you an answer aimed at the right thing.
Bad vs. good
Bad: "Why do we check authentication == null?" — Good: "In JWTAuthenticationFilter.java line 51: if (userEmail != null && authentication == null) — why do we check authentication == null? What happens if we remove it? One paragraph, no code."
Iterative prompting beats one giant prompt
One big question produces one shallow answer. Four small ones build real understanding:
- What does this do? (basic understanding)
- Go deeper on one specific part.
- "I think X is true. Is that correct?" — test yourself.
- Ask for a real scenario or edge case.
Constrain the output, every time
Without a constraint the model gives you everything it knows, and you spend more time reading than you saved by asking. "Answer in 3 sentences max", "no code examples", "only explain X, ignore Y and Z" are the highest-leverage words in any prompt.
The "I think" prompt
After an explanation, I write: "I think [my understanding]. Is that correct? Just yes or no, then one sentence why." This forces me to actually think before I move on, and it shows the model exactly where I misunderstood — so the correction is narrow instead of a full re-explanation.
Role prompting for honest reviews
“Act as a strict senior Spring Boot developer reviewing my code. Do not rewrite it. Only point out what is wrong and ask me how I would fix it.”
The role changes the tone of the response. A default assistant tends toward encouragement; a "strict senior reviewer" role gives harder, more honest feedback — closer to what an actual PR review looks like.
One topic per prompt
"Explain JWT, SecurityContextHolder, and how filters work in Spring" in one message gets you three shallow paragraphs. Three separate prompts, one topic each, gets you three focused, usable answers — and each one is small enough to actually read carefully.
Checklist before sending any prompt
Context given? Specific task with exact file/line? A length or format constraint? Exactly one topic? Exact code pasted, not summarized? If any box is unchecked, fix the prompt before sending.
These techniques cost nothing extra to apply and the difference in answer quality is not subtle — a prompt with all three parts routinely replaces three or four follow-up messages.
How I Use Claude Code Every Day — As a Mentor, Not an Autopilot
NextMyBatis Dynamic SQL: The Tags That Actually Matter
Related articles
How I Use Claude Code Every Day — As a Mentor, Not an Autopilot
I built a strict-mentor system prompt that refuses to hand me finished code. Here's why I made AI harder to use, not easier.
Setting Up a Repo So AI Actually Knows Your Project
How I structured AuthHub's CLAUDE.md and .claude/ directory — rules, prompt templates, and context files — so an AI agent starts every session already knowing the architecture, the standards, and what not to touch.