I drove down to Stanford this past Friday to attend a public lecture by Professor Amy X Zhang, on “What can CSCW teach us about how to work with agents.” I was not aware of Computer Supported Collaborative Work (CSCW) as a field prior to this, but many of the themes felt instantly familiar as a designer who had wrestled with designing collaborative interfaces.

Aligning AI at scale is a governance problem

I’m jumping straight to the part of the lecture that felt the most generative. She framed aligning AI at scale as a governance problem, and pointed to governance tools as inspiration for how we might tackle governing agent behavior. In parts of the West, societies constrain the behavior of governments and people through constitutions and case laws. Quoting from her slides:

• Constitutions are underspecified. Impossible to enumerate all edge cases. Time leads to changes in judgement and new conditions
• Case law decides new cases by grounding to past ones
• A continuous alignment loop where precedents are set, re-litigated, and overturned over time.

In her paper “Case Law Grounding: Using Precedents to Align Decision-Making for Humans and AI” (Chen & Zhang 2025) she and Quan Ze Chen call this Case Law Grounding (CLG).

At this, my mind immediately jumped to my recent work with the DSPy team, and the mechanism of prompt optimization.

System Prompts and Prompt Optimization

What is a system prompt? “Natural language instructions governing an agent’s behavior” would not be a bad answer. Open up the system prompts of widely used agents today, and you’ll see prompts with whole sections full of “shoulds”, “musts” and “nevers”. Writing system prompts is an iterative and cumulative process, and the piling on of rules and conditions are scars from bad behaviors in past iterations. In this way, prompts already look kind of like an evolving code of law. The process of writing prompts today, however, is often arbitrary and ad-hoc. There’s a reason why Breunig calls it prompt debt.

One of the most appealing ideas in the DSPy philosophy is treating the prompt as an optimization target, derived from a corpus of training examples. With enough examples, a reflective prompt optimization approach (e.g. GEPA) can tune a prompt for you. Instead of writing and guessing, the behavior is optimized, albeit in prompt space instead of weight space. DSPy makes building LM systems less like runbook writing and more like machine learning again.

Yet, there’s a sense in which using prompt optimization merely moves the locus of control to a different layer. Instead of crafting prose, the work moves to sample selection and data labeling. This is otherwise known as building evals, which is cumbersome in its own way. Consequential decisions are atomized into labels on individual samples. Keeping labels valid and mutually consistent requires rigorous and difficult data science work. It is no wonder that Hamel Husain calls it the data scientist’s revenge. I don’t want to become a data scientist just to build LM systems!

A Case Law Approach to Data Labeling

All this is why I find the Case Law Grounding idea so illuminating. Imagine a system where the inputs into a GEPA-like optimization system are:

• A constitution: a core piece of natural language instruction that outlines the behavior of the system in broad strokes. Being a relatively short, high level document, a group of humans can debate and iterate on it. It is governable on a human scale
• Case law: effectively a set of labeled agent trajectories, attached to rationales and clear rulings on what went wrong, and what should have happened instead.

In the Chen & Zhang paper, case laws are retrieved at decision time. What a DSPy style system enables instead is compiling the behavior directly into the prompt. GEPA already takes natural language feedback in its reflective step, so I expect reflective optimization can be adapted to a CLG based system.

What I find exciting is the legibility and governance affordances of such a model. (I know, what a designerly thing to say.) If I want to understand the system’s behavior, I can review the constitution and the case law directly. Given a specific misbehavior, I can write a specific case law around it, re-run the prompt optimization, and see if the system performs better on the relevant cases. Teams can review the constitution and the case law, understand the misbehavior that motivated them, and debate whether those rules should be changed.

Case Law UX over a Prompt Optimization Engine

The beauty of taking a case law approach is that the control surface stays in natural language, while still retaining a strong connection to the data that the cases are based on. Unlike a label, a case contains both a reference to a sample, and natural language rationale. That rationale can be cited, argued with, and overturned, collaboratively in a team environment. Case law has affordances for shaping and sculpting that a heap of labels simply do not have. Imagine going back and re-labeling a corpus of samples when your team changes its mind about a particular system behavior. With a case based system, the design loop becomes: iterate on the case’s language, review new behavior on the samples associated with the case, and repeat. All the while the corpus of case laws acts as regression checks on global system behavior, backed by a data science informed optimization loop via DSPy or something like it.