Prompt engineering, zero-shot, and few-shot prompting

Overview

• Prompt engineering is writing clear task instructions, inputs, constraints, and output expectations.
• Zero-shot prompting gives instructions without examples; few-shot prompting adds a small number of input/output examples.
• A prompt is part of the application contract, not a spell that makes the model infallible.

Why this matters

Ambiguous requests cause avoidable mistakes and inconsistent output.

An everyday example

Asking an employee “handle this” is weaker than giving the goal, acceptable evidence, output format, and two examples.

A technical example

“Classify as claim_status, policy_question, or other. Return other if unclear.” Add examples of “Where is my payout?” and “What does my policy cover?” for few-shot classification.

How it works

1. Define the task
2. Separate instructions from data
3. Provide representative examples if needed
4. Specify unknown behavior
5. Evaluate on held-out cases
6. Version the prompt.

Architecture and flow

Task contract + examples + input → model → validated output → eval results.

The insurance assistant example

“Explain only the provided policy passages. If no passage supports the answer, say you cannot confirm and offer escalation.”

When to use it

Start zero-shot; add few-shot examples when recurring errors concern boundaries, format, or domain wording.

When to avoid it

Do not pack examples into every request when code can perform the task or when examples contain private customer data.

Interview answer

“I write prompts as testable task specifications: clear goal, trusted context, output contract, and abstention rules. Examples help clarify difficult boundaries.”

Benefits, trade-offs, and production considerations

• Use a representative dataset rather than fixing one prompt for one memorable failure.
• Do not request hidden chain-of-thought logs; ask for a concise decision explanation and evidence references.
• Too many examples increase latency and can bias outputs.