Response: Law Isn’t Code


The idea of “law as code” isn’t new. There has long been a body of thought which posits there are significant benefits if the law can be expressed as computer code. On the other hand, there are challenges both practical and theoretical in expressing law as code.

The Argument in Law Isn’t Code

Artificial Lawyer recently posted an article titled Law Isn’t Code – And That’s A Good Thing. In response, I am writing this post. I don’t believe in either end of the spectrum, but it’s simpler than choosing a middle ground. I think there are ways to reap the benefits of both sides and we simply need to learn from how computer code has evolved in the past decades.

The crux of Richard Troman’s argument in Artificial lawyer is that a rigid set of rules misses all the nuances of the real world. Creative expression, common sense, and varied interpretations allow for some flexibility in something like a contract. It also follows that ambiguity is an important tool for lawyers. You can reach a consensus without detailing every end, and capture the imprecise nature of human relationships.

Benefits of Law as Code

As someone who started the journey into legal tech thinking naively the world would be a better place if contracts were all written in code, I can see the appeal. The moment contracts are machine-readable, we can rid ourselves of a lot of the expensive legal tech SaaS products. If we could turn contracts into code, you can model the outcomes and calculate the optimal choices. There would be far fewer and less demanding needs for digitizing, transferring, managing, and storing documents. You can gain better and more frequent insight and analyses into your contracts and it’d be easier than ever to pull information out of them in a systematic way.

But I was naive. I missed all of the points brought up in the article and more. In the real world, ambiguity exists and contracts reflect the real world. Even more pressing, practically, lawyers aren’t coders and they require two different skill sets.

The Solution: Hybrid Languages

What I settled on is what’s known as a hybrid language. These exist in computer science already. The idea is you can mix two languages at once, sort of like interchangeably speaking in French and English. Theoretically, you can select the language that is better suited and you get the best of both worlds.

In contracts, a hybrid language might be regular legalese with splashes of computer code. You would draft up your contract as you currently do, just a long document in English typed up in Microsoft Word. However, certain sections really do lend themselves to code. For example, fees and pricing might be better modeled than typed up in a paragraph. Once in a while, I see a mathematical formula to express pricing, there’s no reason why it can’t be executable code. You can include a complex model right in the document. Other areas that have discrete, finite possibilities might be timelines and penalties.

There are more mundane uses as well. As lawyers, it can’t be said that we don’t speak in code already. Terms of art and archaic legalese are all ways lawyers have codified their peculiar approach to writing. It may not be computer code, but they are shorthand for a longer statement. Odd phrases like “including, but not limited to” and “for and only for” come to mind. Interpretation provisions already serve this purpose, but if we can truly codify this on a global level, this could be another hybrid language approach.

Clever lawyers are already been circling around hybrid approaches. I find it unhelpful to continue arguing about whether law is code or not.