DSPy turns language-model tasks into Python programs with named inputs, outputs, and tests. Start with one small decision you can judge. Improve that program before adding retrieval, tools, or agents.

This desk has two tracks: a stable learning path here, and a feed of useful new material. Subscribe to its public RSS in your reader.

First project: classify digest candidates

Use an article’s title and excerpt to choose keep, skip, or needs-review. Add a short reason. This is a proposed learning exercise, not a replacement for the live digest’s curation.

Manually label a small collection of real examples. Include ambiguous cases, irrelevant articles that mention AI, and useful pieces with unexciting titles. Keep private examples local until you choose an inference provider and understand where the data goes.

1. Make one prediction and inspect the prompt

Read the official introduction, setup, and first program.

  • A signature declares the task’s inputs and outputs.
  • A module determines how the model carries out that task.
  • dspy.Predict is the simplest starting module.
  • dspy.LM connects a model provider; dspy.configure selects it.
  • dspy.inspect_history(n=1) shows the prompt and response DSPy actually used.

Checkpoint: explain which parts came from your signature, which came from DSPy’s adapter, and which came from the model. A successful call proves connectivity, not accuracy.

2. Give the decision a precise shape

Read expanding signatures.

Use descriptive fields such as article_title, article_excerpt, decision, and reason. A class-based signature can use a Literal output for the allowed decisions.

Keep the acceptance policy in ordinary code where possible. Valid output types tell you the response has the right shape. They do not tell you that keep was the right decision.

Checkpoint: inspect both a correct classification and a plausible mistake. Save the mistakes as examples to understand, not just prompts to patch.

3. Establish a baseline before optimizing

Read metrics before optimizers and the linked official evaluation guide.

  • A metric is the function that scores an output against your task’s requirements.
  • Training examples support learning and prompt changes.
  • Validation examples guide candidate selection.
  • A separate final test set measures performance after those choices are fixed.

Keep examples from the same article or near-duplicate story in one split. Otherwise the evaluation can reward recognition rather than generalization.

Checkpoint: record a baseline score, a few representative failures, token use, latency, model identifier, and DSPy version. Treat a tiny test set as a debugging aid, not proof of production reliability.

4. Try the least complicated optimizer

Use the official optimizer guide to distinguish changes to instructions, examples in the prompt, and model weights.

BootstrapFewShot learns useful demonstrations from successful traces. MIPROv2 searches instructions and demonstrations. GEPA uses feedback to propose better instructions.

Change one thing at a time. Compare against the same baseline and keep a budget for optimization calls. The cheapest token price does not necessarily produce the cheapest completed experiment.

Checkpoint: explain what changed in the saved program and whether the gain survives on untouched examples. Keeping the baseline is a valid result.

5. Use GEPA when failures teach you something

Read GEPA and useful feedback.

Write feedback that identifies a decision error. For example: an article quotes an AI system, but its main subject is an advertising dispute. That is more useful than saying only that the answer was wrong.

Separate the model doing the task from the model reflecting on errors. Track both costs. Keep the final test set outside the optimization loop.

Checkpoint: compare failed examples before and after the change. Check whether the optimizer learned the policy or merely exploited a weak scoring rule.

6. Save, reload, then add one stage

Save the winning program and test its reload in a fresh process. Record the dependency version, model identifier, metric version, data splits, and optimization budget alongside it.

Only then try the official RAG tutorial. RAG means answering from documents retrieved at question time. Diagnose retrieval failures separately from answer-generation failures.

A tool-using agent is a later experiment. Tool permissions, deterministic checks, and human approval remain application responsibilities.

What belongs in this feed

Practical tutorials, inspectable examples, careful papers, failure reports, and releases that change how a program is built or evaluated. Each capture should say what to learn, what evidence supports it, and one small experiment to try.

Source-reported results and local experiments stay visibly separate. Learning exercises here are proposals until there is an actual run record.