System prompts, user prompts, temperature, few-shot examples — the core levers of LLM behaviour.
Published September 21, 2026
A language model produces the continuation that best fits everything in its input. The input, your prompt, is therefore the main control you have over quality, format and reliability. Prompt engineering is the practice of writing that input so the model does the task you actually intend, consistently. For developers, it's less about clever tricks and more like writing a good specification: clear goal, needed context, explicit constraints, and a precise output format.
ROLE / AUDIENCE You are a senior Java reviewer. Explain for a mid-level developer.
TASK Review the method below for correctness and thread-safety.
CONTEXT It runs in a Spring Boot 3 service handling ~500 requests/s.
CONSTRAINTS Only report real problems. No style nitpicks. At most 5 findings.
OUTPUT FORMAT A Markdown table: severity | line | problem | suggested fix.
INPUT <code>...</code>
Not every prompt needs every part, but when output disappoints, the missing part is usually one of these.
Chat APIs separate system instructions from user messages:
Put durable rules in the system message rather than repeating them in each user turn. It's more reliable, and it keeps rules separate from untrusted input.
❌ "Explain Kafka."
✅ "Explain how Kafka consumer groups distribute partitions among consumers, for a backend developer
who knows REST but not messaging. Use one concrete example with 3 consumers and 6 partitions.
Keep it under 200 words."
Vague prompts get generic answers because the model has to guess the length, depth and audience.
Paste the error message, the relevant code, versions, and what you already tried. The model has no access to your codebase or environment. Missing context is the most common reason answers are generic or wrong.
Say exactly what shape you need: a list, a table, a single word, JSON with named fields. For outputs your code will parse, use the API's structured-output / JSON-schema feature where available, and validate the result anyway.
Classify the ticket. Respond with JSON only:
{"category": "billing" | "bug" | "feature_request" | "other", "urgency": 1-5, "summary": "<max 20 words>"}
When the pattern is easier to show than to describe, give 2–5 input → output examples:
Convert commit messages to changelog entries.
Commit: "fix npe when cart empty"
Changelog: "Fixed a crash when checking out with an empty cart."
Commit: "add retry to payment client"
Changelog: "Payments now retry automatically after temporary failures."
Commit: "bump jackson 2.17"
Changelog:
Examples are powerful, and the model copies them closely, including their length, tone and quirks. Use varied, representative examples, and make sure they're correct.
For calculations, planning or debugging, asking the model to work through the steps first ("First list the possible causes, then pick the most likely and explain why") often improves accuracy, because each written step becomes context for the next. See Chain-of-Thought Prompting. For simple lookups it only adds length and cost.
One giant prompt that extracts, analyzes and writes a report is harder to control and debug than a pipeline of smaller prompts (extract → validate → analyze → write), each with its own clear output. You can check or fix each step in code.
"If the answer isn't in the provided text, reply NOT_FOUND." Giving the model an explicit way out reduces invented answers.
<document>…</document>), and state that it's data to process, not instructions to follow.Q: What's the difference between zero-shot and few-shot prompting? A: Zero-shot gives only instructions. Few-shot adds a handful of worked examples of input and output. Few-shot helps when the desired format or judgement is easier to demonstrate than describe. It costs extra tokens per call and can bias the model toward the examples' specifics.
Q: Why put rules in the system message instead of the user message? A: System instructions are treated as higher-priority, persistent guidance for the whole conversation, which makes them more reliable and harder for user input to override. It also cleanly separates your rules from untrusted user content.
Q: How do you get reliably parseable output? A: Use the provider's structured-output or JSON-schema mode, give the exact schema, set a low temperature, and validate the parsed result in code. On a validation failure, retry once with the error message included, then fall back gracefully.
Q: How do you reduce hallucinations with prompting? A: Supply the source material in the prompt and instruct the model to answer only from it. Ask for citations or quotes, give an explicit "I don't know" option, and use a lower temperature. For facts the model must know from outside the prompt, prompting alone can't guarantee correctness, so add retrieval (RAG) and verification.
Q: How do you know a prompt change is an improvement? A: Evaluate it on a fixed test set of realistic inputs, with expected outputs or grading criteria, comparing old and new versions side by side, not on one or two hand-picked examples. Track accuracy, format compliance, length and cost.