ResearchPod Summary
The Master's thesis course (IDRS147) is designed to bridge the gap between traditional legal scholarship and the practical application of technology in the legal sector. It requires students to balance individual academic rigor with collaborative innovation, preparing them for the evolving demands of the legal profession.
The course is divided into two primary components. First, students conduct an individual legal-doctrinal thesis on a topic related to law and technology. Second, students work in groups to develop a functional legal tech or AI tool. This development process utilizes design thinking methodologies, requiring students to engage in master sessions, design clinics, and skills workshops. The final output for the group project includes a presentation to a jury and a comprehensive document detailing the technical, ethical, and legal specifications of the tool.
The course aims to equip students with the ability to reflect on the ethical implications of technology, collaborate effectively in a professional environment, and translate complex legal and technical requirements into actionable tool specifications. Assessment is multifaceted, weighing the doctrinal research paper (40%), the final tool specifications (35%), jury presentations (15%), and course participation (10%), alongside pass/fail evaluations for technical exercises and group contributions.
As the legal profession undergoes digital transformation, there is an increasing need for practitioners who can navigate both the doctrinal nuances of law and the technical realities of software development. By combining academic research with a hands-on design project, this course prepares students to act as intermediaries between legal practice and technological innovation, ensuring that future legal tools are both ethically sound and legally compliant.
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.
AI-generated third-party summary by ResearchPod. Not official content or an endorsement by the paper authors or affiliated organizations.
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.
Alex: 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.
Sam: How do they handle the technical rigor side? Is there a floor on what students are expected to actually understand, or does the technical component risk becoming a black box they gesture at without really grasping?
Alex: The curriculum uses what they call master sessions — foundational instruction in cybersecurity and risk management — to establish that floor. But the burden of integration rests on the student team's collaborative process. The skills sessions are designed to support that, but the authors are candid that the model is high-friction. Its success depends substantially on group dynamics and on students' ability to bridge disciplinary gaps themselves.
Sam: Which means the pedagogy is doing something ambitious but also something that's hard to quality-control at scale. The variance in outcomes probably tracks the variance in team composition.
Alex: That's a fair inference, and it's one of the places where a careful referee would push back. The paper describes the curriculum's design in detail, but the evidence base for its effectiveness is limited. We don't get systematic outcome data — no controlled comparison against a conventional legal curriculum, no longitudinal tracking of whether graduates actually perform differently in practice. What the paper offers is a detailed design rationale and a theoretical argument for why the integration should work.
Sam: So the contribution is more architectural than empirical at this stage.
Alex: Precisely. The long-term implication the authors point toward is a model where legal practitioners are what they call legal engineers — people who can audit and interrogate the systems they deploy, not just use them. The thesis becomes a forkable project: both a document and a working artifact that can be iterated on.
Sam: That framing makes sense given where the field is heading. If legal education doesn't produce people who can engage with these systems at a technical level, the practical consequence is that the design of legally consequential tools gets handed entirely to engineers who don't have the doctrinal training.
Alex: And that's the risk the curriculum is explicitly trying to mitigate — not just producing technically literate lawyers, but maintaining meaningful human agency in an increasingly automated legal landscape. Whether this particular pedagogical model is the right vehicle for that is still an open question, but the problem it's responding to is real and the design logic is coherent.
Sam: Worth watching as more law schools start grappling with the same pressures. Thanks for walking through it.
Alex: Thanks for listening to ResearchPod.