Week 3: Advanced Prompting & Structured Output

1. Chain-of-Thought Reasoning

For anything with multiple steps — arithmetic, multi-part logic, "compare these three options and pick one" — asking Claude to work through its reasoning before giving a final answer measurably improves accuracy. It's not a trick; it's giving the model room to build up intermediate conclusions instead of trying to leap straight to the answer.

WITHOUT:
"A store had 120 items, sold 35% on day one and 20% of what remained on
day two. How many are left?"
→ Higher chance of a slip on the two-step percentage math.

WITH:
"A store had 120 items, sold 35% on day one and 20% of what remained on
day two. How many are left? Work through the math step by step before
giving the final number."
→ Claude shows day-one math, recalculates the new base, then day-two
math — each step is easier to get right than jumping straight to the end.

If you need the reasoning separated from the final answer (so your code can grab just the number, say), ask for it explicitly with tags — a direct application of Week 2's structuring technique:

"Work through this step by step inside <thinking> tags, then give only
the final number inside <answer> tags."

2. System Prompts & Role Prompting

A system prompt is a separate channel from the back-and-forth conversation — it sets behavior, tone and rules that hold for the entire session, instead of something you'd have to repeat in every message. Role prompting ("You are an expert code reviewer") is one common use of it, but the persona label alone does less work than people expect — Claude doesn't gain new facts by being told it's an expert. The real value comes from pairing a role with concrete rules.

WEAK:
"You are an expert code reviewer."

STRONGER:
"You are a code reviewer for a production Node.js API. For every review:
- Flag any unhandled promise rejection or missing error handling first
- Never suggest a rewrite unless the current code has a real bug
- If you see no issues, say so explicitly rather than inventing nitpicks
- Point to the exact line number for every issue you raise"

The second version doesn't just describe a role, it encodes priorities (error handling first), a constraint (no invented nitpicks), and a format expectation (line numbers) — the actual levers that change what Claude outputs, session after session, without you re-stating them every message.

3. Forcing Structured Output

Free-text answers are fine for a human to read, but fragile the moment your own code needs to parse the result. Asking for a specific structure — most often JSON — with an exact schema turns Claude's output into something you can reliably load and use.

"Extract the job title, company, and salary range from this posting.
Respond with ONLY valid JSON, no other text, in exactly this shape:

{
  "title": string,
  "company": string,
  "salary_min": number | null,
  "salary_max": number | null
}

If a field isn't present in the posting, use null."

Two details matter here: specifying the exact shape (not "return JSON with the relevant fields") and explicitly saying what to do for missing data (null, not a guess) — both close off the small ambiguities that would otherwise produce output your parser occasionally chokes on.

4. Reducing Hallucination

Because Claude is fundamentally predicting plausible text (Week 1), a confident, well-formatted, wrong answer is a real risk — especially on facts outside what was in its training data or outside the material you gave it. A few techniques measurably reduce this.

# 1. Explicitly permit "I don't know"
"If you're not confident in an answer, say so rather than guessing."

# 2. Ground answers in provided material, and say so
"Only use information from the <document> below. If the answer isn't
in it, say it isn't in the document."

# 3. Ask for a quote or citation from the source
"Answer, then quote the exact sentence from the document that supports it."

# 4. Ask Claude to check its own answer
"Before finalizing, double-check this against the document once more."

None of these make hallucination impossible — nothing does — but each one removes a path to a confident wrong answer: permission to say "I don't know" removes the pressure to always produce something, grounding removes reliance on possibly-stale training knowledge, and citation requests make it much harder for Claude to state something ungrounded without that mismatch becoming visible to you immediately.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.