Prompt engineering is the manual process of changing a prompt to improve a language model’s response. A summary might omit an important fact; rewording the request may fix that omission but introduce another. Because small wording changes can produce different results, a prompt that works once needs testing across multiple inputs. This matters especially when software, rather than a person at a chat interface, must make reliable model calls. section 1.0 section 2.0
Manual revisions can change both the wording and the structure of a prompt:
- Add, remove, reorder, or reword sections such as task instructions, response choices, output format, and demonstrations. section 2.1 section 2.1.1
- Try a persona, a request for step-by-step reasoning, positive or negative examples, or a model-generated critique. These are possibilities to test, not reliable fixes for every task. section 1.2.3
- Inspect results after each change, preferably across more than a tiny test set. Otherwise an apparent improvement may reflect only the inputs tried. section 2.1.1 section 1.2.3
Classifying customer messages
A customer-intent prompt can name five allowed labels, specify a JSON response, and include a labeled message before presenting a new one. If the classification is unreliable, prompt engineering means manually revising those instructions or examples and checking the resulting classifications. Choosing demonstrations also takes care: examples covering only one class may suggest that most messages belong to it. section 2.1.1 section 5.1
The main cost is the search. Many plausible changes must be tested, and the work may need repeating for each language model. Prompts can grow long enough that it becomes hard to remember why a phrase was added. Prompt programming offers a different workflow: specify inputs, outputs, and evaluation criteria, then use DSPy to generate and evaluate candidate prompts. Its modules express techniques such as chain-of-thought without requiring manual editing of the full prompt. Demonstrations and instructions can both be optimized, though optimizing demonstrations is often a useful starting point. A manually added instruction can still provide a baseline; extensive phrase-by-phrase tuning risks returning to the same trial-and-error process. section 1.1.2 section 2.6 section 5.7 section 7.4.1
Figure 1.2 Prompt optimization for a customer service intent classifier. The optimization process generated three candidate prompts, each of which is evaluated. In the end, the best prompt is selected. In this case, that is the second prompt, which has the highest score: 90%. DSPy also supports processes that modify and reevaluate prompts over several iterations.
The customer-service classifier diagram contrasts manual trial and error with evaluating candidate prompts and selecting the highest-scoring one. section 1.1.2
