Prompt Engineering Fundamentals

How to craft instructions that reliably produce the outputs you need.

Introduction

Prompt engineering is the practice of designing and iterating on natural-language instructions to guide a large language model toward producing the output you want. While LLMs are remarkably capable, they are also remarkably literal: they do exactly what you ask, and if you ask imprecisely, you get imprecise results.

This lesson introduces a structured framework (RTCF) for constructing prompts, explores why specificity matters more than almost anything else, and catalogs the failure modes that trip up beginners and experienced engineers alike.

The RTCF Framework

The RTCF framework breaks every prompt into four components. You do not need all four in every prompt, but you should deliberately decide which ones to include or omit.

RTCF in Practice

Here is the same task written without RTCF and then with it:

WITHOUT RTCF:
"Explain machine learning."

WITH RTCF:
Role:    You are a data science instructor at a community college.
Task:    Explain the concept of supervised machine learning.
Context: Your audience is business analysts with no programming background.
Format:  Use exactly 3 paragraphs. End with one concrete business example.
         No jargon without definition. Maximum 200 words.

The RTCF version takes longer to write but almost always produces a better first response and requires fewer follow-up clarifications.

Specificity: The #1 Lever

Of all the things you can do to improve a prompt, adding specificity has the highest return on effort. Vague prompts force the model to make assumptions, and those assumptions are rarely what you wanted.

Consider the prompt "summarize this article". The model must guess:

• Target length (one sentence? one paragraph? five bullet points?)
• Target audience (technical? general? executive?)
• What to preserve (key facts? emotional arc? action items?)
• What to omit (boilerplate? caveats? citations?)

A specific version: "Summarize this article in 3 bullet points. Each bullet must be one sentence. Focus on the practical implications for software engineers. Omit background history."

Rule of thumb: if a new intern would ask at least one clarifying question before starting, your prompt is under-specified.

Controlling Output Format

LLMs can produce virtually any text format on demand. The key is to ask explicitly. Implicit format expectations ("I assumed it would return JSON") are a leading cause of production bugs.

Length control

Use hard constraints: "in exactly 150 words", "no more than 3 sentences", "a minimum of 5 bullet points". Models are reasonably good at hitting word counts within ±10–15%.

Structure control

Name the format explicitly: "Return a JSON object", "Use a markdown table with columns X, Y, Z", "Numbered steps", "Plain prose, no headers". For JSON, include an example schema or field names to eliminate ambiguity about keys.

Tone control

Tone is often underspecified. Options include: formal/casual, enthusiastic/dry, empathetic/clinical, first-person/third-person. "Write in a warm, encouraging tone suitable for a junior developer receiving feedback."

Common Failure Modes

1. Ambiguity

The prompt has more than one reasonable interpretation. "Write something about our product." — marketing copy? technical docs? a haiku? Fix: specify the genre, audience, and purpose.

2. Under-specification

Critical information is missing. "Summarize this" with no document attached forces the model to either hallucinate a document or refuse. Fix: always include the input data in the prompt.

3. Over-constraining

Too many constraints that cannot all be satisfied simultaneously. "Be comprehensive. Cover all 15 subtopics. Keep it under 100 words." Fix: prioritize constraints. Decide which ones are hard limits and which are preferences.

4. Conflicting instructions

Instructions that contradict each other. "Be formal and professional. Use lots of slang and emojis." The model will follow whichever instruction appears more recently or more prominently — unpredictably. Fix: read your prompt aloud. Contradictions will be audible.

5. Implicit assumptions

You assume the model knows your organizational context, internal jargon, or what "good" means for your use case. It does not. Fix: state every assumption explicitly in the Context component.

Zero-Shot vs Few-Shot (Teaser for Lesson 04)

Everything covered so far is zero-shot prompting: you describe the task without providing examples of completed outputs. This works well for straightforward tasks.

For complex tasks — especially classification, style matching, or structured extraction — few-shot prompting (providing 2–8 worked examples) often produces dramatically better results. Lesson 04 covers this in depth, including how to select good examples and how many to provide.

Iterative Prompt Development

Treat prompts like code: write a first version, test it, measure the failure cases, and improve. A disciplined iteration loop looks like this:

1. Write a minimal prompt (just the Task).
2. Run it 3–5 times. Note what varies and what fails.
3. Add the component (R, C, or F) that addresses the most common failure.
4. Repeat until outputs are consistently acceptable.
5. Stress-test with edge case inputs.
6. Freeze the prompt and put it in version control.

Avoid the temptation to add every possible constraint upfront. Each constraint you add can interact with others. Build up incrementally.

Further Reading

• Anthropic Prompt Engineering Overview
• Prompt Engineering Guide (DAIR.AI)
• Brown et al. (2020) — "Language Models are Few-Shot Learners" (GPT-3 paper — foundational reading on prompt sensitivity)
• Zamfirescu-Pereira et al. (2023) — "Why Johnny Can't Prompt" (HCI research on common failure modes)