Do lawyers need to learn to code?

An old question with new urgency

Back in 2017, the tax law scholar Heribert Anzinger wrote that the lawyers of the future would not need to be able to code, but would need to understand how programmes work. Since then the debate has not gone away, it has shifted. The University of Hanover offers a block seminar in which law students write a Java programme that decides simple legal questions. And in February 2025, the Federal Bar (BRAK), the German Bar Association and other bodies jointly called for a reform of legal education with more digital competence.

What is remarkable about that statement is what is missing. The associations call for a critical approach to data and AI, an understanding of data quality and of algorithmic discrimination. The word coding does not appear. So the professional bodies answered the question long ago, only hardly anyone noticed.

What a coding course really teaches

I have been writing code since my school days, self-taught, without a course and without a degree. That is why I know what is valuable about a coding course for lawyers, and it is not the programming language. What is valuable is the way of thinking that coding forces on you. A programme does only what has been described. Every exception needs a rule, every rule needs an order, and whatever the author forgot simply does not happen.

Lawyers are used to this rigour, but with one difference. A brief may have gaps, because on the other side a human being is reading and thinking along. Software does not think along. Anyone who has ever tried to write out a deadline calculation as a process with all its special cases will afterwards understand why case management software so often works differently from what the lawyer expected. That insight has little to do with Java or Python. It comes from describing, not from typing.

Why nobody has to write code all the same

Coding itself is a craft, and a craft needs practice. Anyone who writes one script a year writes bad scripts. Lawyers who code on the side usually produce software that nobody maintains, that nobody has documented and that stops working with the next update of the case management system. That is not a reproach. Nobody expects a programmer to draft an employment contract on the side.

On top of that, the craft is currently changing itself. Today I code with AI support. The share of work that consists of typing code is falling. What remains, and becomes more important, is the description: what should the programme do, in which cases, with which exceptions? That is precisely the part lawyers are in principle better at than most professions. They only need to apply it to their own work instead of to a client's facts.

What law firms need instead

A survey of around 80 law firms, conducted between May and August 2025, shows the state of play: 22 per cent do not work digitally or have only laid the groundwork, 16 per cent use concrete AI tools. Half of the participants were sole practitioners. For these firms, coding is not the next step. The next step is the question of which work in the firm actually repeats itself.

Good software does not begin with code, but with the right questions. Which letters go out every week in almost identical form? Which review runs the same way in every matter? Where does the decision turn on the individual case, so that software must not make it? Anyone who can answer these questions can talk to any developer and any software provider as an equal. They can tell whether a promise made in a demo holds up in practice. Anyone who cannot answer them will not be helped by a Python course either.

The Legal Tech Monitor 2025 published by the Legal Tech Verband counts around 300 providers in the German market, more than 80 per cent of which build AI into their business model. So the software exists. What is missing are law firms that can say precisely what they want to do with it.

Where the counter-argument is right

The advocates of coding for lawyers are right on one point: anyone who has never written a line of code has no sense of what software costs. An extra field in the file sounds like an hour's work and often means several weeks. A lawyer who has experienced that first-hand phrases their requests differently and negotiates with providers more realistically.

That is why I think courses like the seminar in Hanover make sense, only for a different reason than assumed. They are not meant to train programmers. They are meant to show lawyers, once, how unforgiving a machine is towards unclear instructions. Anyone who has experienced that describes their work more precisely afterwards. And the same applies to the other side: a developer who has never calculated a limitation period builds case management software that passes by the people who later have to work with it. The gap lies between the languages, and it only closes if both sides move.