Transcript: Master's thesis

Alex: Welcome to another episode of ResearchPod. Today we're looking at a paper on legal education — specifically, a pedagogical model called constructivist legal engineering, which tries to close the gap between doctrinal legal scholarship and the technical systems lawyers are increasingly expected to regulate or deploy.

Sam: So the core diagnosis is that legal education is siloed. Doctrinal analysis on one side, technical implementation on the other, and very little meaningful overlap.

Alex: Right, and the authors frame that gap around what they call the automation paradox — as systems become more autonomous, human oversight becomes more critical, but the human operator tends to become less equipped to intervene effectively. That's the problem the curriculum is designed to address.

Sam: And the structural response is to require students to produce both things simultaneously — a traditional legal-doctrinal thesis and a functional, user-centered technical artifact.

Alex: Exactly. But the key mechanism isn't just doing two things at once. The authors call it doctrinal-design duality, and the logic is that students can't build a working tool without first codifying their legal theory — and that process of codification exposes the gaps. If you're building a contract review tool, you have to translate doctrinal rules into executable logic, and you find out very quickly whether your understanding of those rules is actually robust or just superficial.

Sam: So the code becomes a stress test for the legal argument. You can write a vague normative claim in a thesis and get away with it, but you can't write vague code.

Alex: That's precisely the pedagogical intent. The authors describe these as the "wicked problems" of legal design — requirements that are often contradictory, incomplete, or context-dependent in ways that don't survive implementation. The curriculum forces students to confront that friction directly rather than paper over it.

Sam: How does the assessment structure catch cases where a student builds something that works technically but misses a critical legal nuance?

Alex: That's where the design clinics come in. They're structured environments where student teams present their technical, ethical, and legal specifications to a jury — not just the code, but the documented reasoning behind every design choice. The assessment is heavily weighted toward those specifications, so the jury is grading the alignment between the legal theory and the actual output of the tool, not just whether the tool runs.

Sam: That's a meaningful design choice. It shifts the burden of proof onto the students to show that their implementation actually reflects their doctrinal claims.

And it's also where the model's main vulnerability shows up. If you're asking a law student to function as a software engineer, you risk producing graduates who lack the depth of either discipline. The authors acknowledge this directly — it's a genuine trade-off, not a solved problem.