Prompt engineering

Beginner — What makes a good prompt?

• A clear task, trusted constraints, explicitly separated input, expected output, and a defined response when information is missing.
• For policy answers, I require supporting evidence and forbid inventing unsupported policy conditions.

Intermediate — Zero-shot or few-shot?

• I begin with clear zero-shot instructions.
• If errors concern category boundaries or formatting, I add a few representative reviewed examples and evaluate them on separate cases.
• Examples should cover ambiguity, not just easy successes.

Senior — How do you maintain prompts?

• I treat prompts as versioned configuration with an owner, evaluation dataset, release gate, and trace tag.
• I investigate patterns in failures instead of accumulating conflicting instructions for individual anecdotes.
• Provider/model upgrades rerun the same contract tests.

Scenario — Adding many examples improved a demo but slowed production. What next?

• I measure which examples actually help and remove redundancy.
• I test a smaller prompt, provider-supported schemas, deterministic preprocessing, or a better model.
• I optimize latency and cost while preserving held-out quality.