Iterative Prompt Design: The Engineering Workflow

One of the most common mistakes beginners make is trying to write the "perfect prompt" in one sitting. Prompt engineering is not a creative writing exercise; it is an Iterative Engineering Process.

In this lesson, we will move away from "vibes-based" testing (just asking the model a question and seeing if the answer "feels" right) and move toward a rigorous, data-driven workflow.

---

1. The Iteration Loop

Every professional LLM Engineer follows this cycle:

graph TD
    A[Initial Prompt] --> B[Test on 10+ Examples]
    B --> C{Failure Detected?}
    C -- Yes --> D[Common Error Analysis]
    D --> E[Refine Prompt instructions]
    E --> B
    C -- No --> F[Deploy to Staging]

Why 10+ Examples?

LLMs are probabilistic. Just because a prompt works once doesn't mean it works every time. You need a "Test Suite" of edge cases to verify that fixing one problem doesn't break something else.

---

2. Analyzing Failures: The Three Root Causes

When a model fails, it usually falls into one of three categories:

A. Lack of Context (RAG Problem)

• Symptom: The model makes up a fact (Hallucination).
• Fix: Don't change the prompt instructions; give it better data in the context section.

B. Conflicting Instructions

• Symptom: The model follows one rule but ignores another.
• Fix: Use hierarchy. Use words like "TOP PRIORITY" or "CRITICAL: Never do X." Move the most important rules to the end of the prompt (the "Recency Bias").

C. Complexity Overload

• Symptom: The model gives a garbled or incomplete response.
• Fix: Break the prompt apart. Use Chain-of-Thought or split the task into two separate model calls.

---

3. The "Golden Dataset" - Your Testing Suite

To build a reliable product, you need a "Golden Dataset"—a collection of inputs and the expected outputs.

Input (User Query)	Expected Output (Gold Standard)	Current Model Performance
"What's my balance?"	Ask for Account ID.	FAIL (Attempted to guess).
"Send $50 to Bob."	Insufficient funds error.	PASS.
"Who are you?"	Customer Support Bot.	PASS.

The Workflow: Every time you change your system prompt, you run the entire Golden Dataset through the model. If your "Pass Rate" drops, your change was a mistake.

---

4. Prompt Versioning: Git for Instructions

Prompts are code. You should never "just change it" in the dashboard. You should:

1. Store prompts in your repository (as .txt or .yaml files).
2. Use Git to track changes.
3. Include a "Prompt ID" in your logs so you know which version of the prompt generated which hallucination in production.

---

5. Security Iteration: Red Teaming

Finalizing a prompt means trying to break it. This is called Red Teaming.

• Ask it to ignore your rules.
• Ask it to output instructions for something illegal.
• Feed it massive amounts of gibberish.

If the model stays in persona, it's ready. If it breaks, you need more Guardrails (Lesson 4.3).

---

Code Concept: Automated Evaluation Script

In Module 9, we will look at professional tools like LangSmith. For now, here is a simple conceptual Python script for automated prompt testing:

test_cases = [
    {"input": "Hi", "expected": "Greeting"},
    {"input": "Delete my account", "expected": "Escalate to Human"}
]

def evaluate_prompt(prompt_version):
    pass_count = 0
    for case in test_cases:
        response = call_llm(prompt_version, case["input"])
        if case["expected"] in response:
            pass_count += 1
    
    accuracy = (pass_count / len(test_cases)) * 100
    print(f"Prompt {prompt_version} Accuracy: {accuracy}%")

---

Summary of Module 4

• Principles: Use Task, Context, Persona, and Delimiters (4.1).
• Techniques: Few-Shot for consistency, CoT for logic (4.2).
• Structure: Use System Prompts for rules and Guardrails for safety (4.3).
• Process: Test on datasets, analyze failures, and iterate (4.4).

You have now mastered the "Programming" of LLMs. In the next module, we move into RAG (Retrieval-Augmented Generation), where you will learn to give your models "Searchable Brains" filled with massive amounts of company data.

---

Exercise: The Failure Post-Mortem

You built a prompt that summarizes legal contracts. It works for 9 out of 10 contracts. For the 10th one (a 50-page giant), it returns "Error: The context is too long."

Identify the Fix:

1. Is this a Prompt Engineering problem?
2. Is this a System Design problem?
3. How would you solve this using the "Complexity Overload" strategy from this lesson?

Hint: If a document is too long for the "Engine," you need to split it into chunks—this is the foundation of RAG!