A prompt that produces a good article summary once may miss a key fact on the next attempt. Manually rephrasing it can become a slow, hard-to-track cycle. Prompt programming replaces much of that trial and error with code: specify the language model’s input, the expected response, and how to judge that response. A framework such as DSPy generates and tests prompts from those specifications. section 1.0 section 1.1.2
The developer works primarily with task-level code rather than prompt wording or direct model API calls. That code can be kept readable, testable, and modular; it can also be rerun when trying another language model or prompting technique. Prompt programming does not remove the need to decide what a good answer looks like. section 1.1.1 section 1.2.2 section 1.2.5
A practical development loop is:
- Build a baseline application that states the task and the response it expects. section 1.8
- Collect representative test data and define a function that scores responses consistently. Repeated model calls matter because the same input may yield responses of different quality. section 1.2.5
- Evaluate the baseline, then let the optimizer propose and assess candidate prompts. It can refine candidates over multiple iterations and select the strongest measured result. section 1.8 section 1.1.2
Customer-service intent classifier
Suppose an application must classify the intent of customer-service requests. Instead of choosing one instruction by intuition, evaluate several generated prompts against the classification task. In the illustrated comparison, the second of three candidates scores highest at 90% and is selected. That score is a result of the example evaluation, not a guarantee for another task or model. section 1.1.2
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 diagram makes the generate–evaluate–select loop concrete, including the three candidates and their winning score. section 1.1.2
This approach is especially useful when an application has many model requests, complex prompts, or a long life in production. Rerunning the same evaluation setup can make it practical to test smaller, potentially less costly models. The trade-off is upfront work: useful test data, a meaningful scoring function, and framework code. For a casual request where response quality is not critical, a manually written prompt may be enough. section 1.4 section 1.2.7 section 1.2.5
