Precision Prompting and Few-Shot Examples

Domain 4 — Prompt Engineering & Structured Output — is 20% of the exam, and its first half is about precision: getting the model to produce consistent, trustworthy output instead of a noisy stream you can’t rely on. Two techniques carry it: explicit criteria (Task 4.1) and few-shot examples (Task 4.2), and both are the CI/CD code-review and structured-extraction scenarios in miniature. These are prompting techniques whose effectiveness is a model-behavior claim, so the concrete results carry a ⚠️ for the key-based pass; the principles are the exam content, and that’s what to study.

Explicit criteria beat vague instructions

The foundational precision lesson: specific, categorical criteria outperform general instructions. Telling a code reviewer to “check that comments are accurate” is vague — the model has to invent what “accurate” means, and it will flag stylistic quibbles alongside real bugs. Telling it to “flag a comment only when the claimed behavior contradicts the actual code behavior” is a precise, checkable criterion, and it produces precise findings.

The corollary the exam presses hardest: generic hedges don’t improve precision. “Be conservative,” “only report high-confidence findings,” “use your best judgment” — these feel like they’d cut false positives, and they don’t. The model has no calibrated notion of its own confidence to threshold against, so a confidence instruction is noise. What actually reduces false positives is specific categorical criteria that define which issues to report (bugs, security vulnerabilities) versus skip (minor style, local patterns). You get precision by naming the categories, not by asking the model to be careful.

The reason precision matters so much is a trust dynamic worth internalizing: a high-false-positive category poisons the accurate ones. If a reviewer’s “style” findings are usually wrong, developers stop trusting all of its findings — including the correct security ones — because the noise trains them to dismiss the tool. So a category that fires too many false positives isn’t just locally bad; it undermines the whole system’s credibility.

That gives a concrete remediation the blueprint endorses: temporarily disable a high-false-positive category while you improve its prompt, to restore trust in the categories that work. Turning off the noisy check isn’t giving up — it’s protecting the signal. And for classification tasks, define explicit severity criteria with a concrete code example for each level, so “high” versus “medium” severity is anchored to examples rather than left to the model’s shifting judgment.

Few-shot: teaching judgment, not matching

When explicit instructions still produce inconsistent output — especially inconsistent format or wobbly handling of ambiguous cases — few-shot examples are the most effective next technique. You show the model 2–4 worked examples of exactly what you want, and it patterns its output on them.

But the exam’s framing of few-shot is subtler than “show examples,” and this is the part to get right. Few-shot examples don’t just make the model match the cases you showed — they let it generalize its judgment to novel patterns. A handful of well-chosen examples teaches the model the principle behind your choices, which it then applies to inputs you never demonstrated. That’s why few-shot beats an exhaustive rule list: you can’t enumerate every case, but a few examples that reveal the underlying judgment cover the ones you didn’t.

The highest-value examples are the ambiguous ones, shown with their reasoning:

Example — ambiguous tool selection:
Request: "What did we spend on cloud last quarter?"
Reasoning: This needs the billing tool, not the general search tool, because it asks
for a specific financial figure over a defined period. Search would return docs
*about* cloud spend; billing returns the number.
Chosen: get_billing(category="cloud", period="last_quarter")

Showing why one action was chosen over a plausible alternative teaches the model to make the same distinction on a new ambiguous request — which is exactly what a rule (“use billing for financial questions”) can’t do when the phrasing is unexpected. The blueprint calls out several places this pays off: demonstrating a specific output format (location, issue, severity, suggested fix) for consistency; distinguishing acceptable code patterns from genuine issues to cut false positives while still generalizing; and showing correct extraction from varied document structures (inline citations vs. bibliographies) so the model handles formats it wasn’t explicitly shown. (⚠️ that few-shot improves live consistency and reduces hallucination is the documented behavior, pending the key pass.)

Precision plus generalization

The two techniques compose, and understanding how is the exam-ready synthesis. Explicit criteria set the boundary: what counts as a finding, what doesn’t, at what severity. Few-shot examples teach the judgment to apply that boundary to cases you didn’t spell out, especially the ambiguous ones. Criteria alone can be rigid and miss novel-but-valid cases; examples alone can be imitated too literally without the underlying rule. Together — a clear criterion, plus a few examples showing the reasoning at the boundary — you get output that’s both precise and able to generalize. When an exam item’s prompt is producing inconsistent or noisy results, the fix is rarely “add ‘be careful’”; it’s a sharper criterion, a few reasoned examples, or both.

Final thoughts

Precision comes from specific categorical criteria, not from confidence hedges the model can’t calibrate — and it matters because a noisy category poisons trust in the accurate ones, which is why temporarily disabling a high-false-positive check is a legitimate move. Few-shot examples teach the model to generalize its judgment to novel patterns, and their most valuable form shows the reasoning behind an ambiguous choice. The pairing — explicit criteria for the boundary, few-shot for the judgment at it — is the reliable way to turn an inconsistent prompt into a trustworthy one. Next we make the output itself reliable, not just the reasoning behind it.

Next: structured output and validation loops — guaranteeing schema-compliant output with tool use, and the retry loops that fix what schemas can’t.