On the Comparability of Law and Software

Hey, I'm Martin Kurtz, attorney at law and one of the two founders of MaraDocs. Welcome to the MaraDocs blog. We write about topics at the intersection of legal practice and IT.

This is the first article in the Lawyer2Dev - A Journey series. The article series will cover my own professional story and motivation, but above all, I will explain many concepts and technologies that shape today's IT landscape from my perspective. And yes - there will definitely be some code. :)

// lawyer2dev - a journey
const SERIES_NAME = "Lawyer2Dev - A Journey"

export const tellReader = (whatDoesHeRead: string) => {
  if (whatDoesHeRead === SERIES_NAME) {
    return "There will be code, my friend :) "
  } else {
    throw new Error("you are reading the wrong stuff, buddy!")
  }
}

So, let's dive right in!

Law

I started studying law at the University of Bonn in 2005. I can't really report much about my first years at university: Prof. Puppe (a legendary criminal law scholar known for her minority opinions) was still actively teaching, and the law library still had dedicated computer rooms where students could use institutional computers.

I remember well that the first exams were at a shockingly different level than the tests I was used to from school. The law that one was allowed to learn as a student presented itself to me as a truly large and interconnected concept. It took me a while to understand that there were underlying thought structures or system models and methods that remained valid across all areas.

Certainly, the three major areas (civil law, public law, and criminal law) each have their own distinct character, almost their own flavor, that you gradually get to know as a young student over many, many hours, but nevertheless there is a recurring pattern underlying it all: step-by-step thinking.

Examination Schemas

Above all, we learned examination schemas: such as the requirements for various legal bases for claims or the legality of certain governmental actions. Behind each examination point lies a branching, and you are forced to actually stop at this branching and look carefully to see if all sub-points are fulfilled. Only then is the path to the next examination point clear.

Example: Schema for legality of an administrative act, here represented based on a fictional administrative act class in TypeScript.

I. Legal Basis (Authorization)
  1. Required?
  2. Selection of legal basis 
  
II. Formal Legality
  1. Competence
  2. Procedure
    a. Hearing
    b. Conflict of interest rules
    c. Participation of other authorities
  3. Form
  
III. Substantive Legality
  1. Requirements of the legal basis 
  2. General legality requirements
    a) Specificity
    b) No factual or legal impossibility
  3. Correct addressee
  4. Legal consequence: Discretionary or mandatory decision?
    a) Mandatory decision: Order of the prescribed legal consequence
    b) Discretionary decision:
      aa) Discretionary errors?
        (1) Failure to exercise discretion
        (2) Underuse of discretion
        (3) Misuse of discretion
        (4) Exceeding discretion
      bb) Possible reduction of discretion to zero
      cc) Possible intended discretion

This step-by-step approach is very similar to how computer programs run. The execution of a classic (single-threaded) program provides for exactly one check or work step at any given time, which can never be skipped. Conversely, a program can only answer the questions or solve the problems that were anticipated when the program was created. This requires, when creating software, the particular ability to transform the problem to be solved into a logical model that can be traversed atomically. All conceivably occurring sub-questions must also become part of the model. If unexpected states occur later (edge cases) that are not caught (e.g., using try-catch patterns), the program crashes.

The step-by-step nature of legal thinking and problem modeling in software development are thus very similar.

No Clear-Cut Solutions

Software can be executed, tested, and debugged exactly and reproducibly. An input leads (if correctly implemented) to a defined output. Legal examinations, on the other hand, are typically characterized by being based on a structured examination structure (subsumption, etc.), but always also containing value-dependent elements and being open to balancing in the result. The result is therefore not deterministic.

Software can be tested due to its deterministic nature: In a unit test, for example, a function to be tested is programmatically fed with a defined input and then checked to see if it delivers the expected output. Laws, on the other hand, are linguistically ambiguous or at least require interpretation. This means that results cannot be tested in the classical sense.

Example of a unit test (here in the style of the Jest framework)

describe('tellReader function', () => {
  test('should return success message when given correct series name', () => {
    // prepare
    const correctSeriesName = "Journey from Lawyer to Software Developer";
    const expectedMessage = "There will be code, my friend :) ";

    // execute
    const result = tellReader(correctSeriesName);

    // compare
    expect(result).toBe(expectedMessage);
  });
});

LLMs and the New Understanding of IT: Probabilities Instead of Truths?

While classical software development was long considered the epitome of deterministic logic – input in, clearly defined output out –, the use of large language models (LLMs) like Claude, LLama, or ChatGPT brings a new, perhaps softer form of IT. These systems do not operate based on hard-coded decision trees, but rather on statistical patterns they have extracted from unimaginably large amounts of data. The output is thus not predictable in the strictly mathematical sense, but moves within the realm of the probable, the typical, the contextually plausible.

In this characteristic, the results of LLMs and the results and methods of legal argumentation are similar. In law too, decisions are not purely logically deduced, but made in a tension between norm text, facts, interpretation, and balancing. The result of a legal examination is rarely "correct" in the sense of an objective value – it is rather justifiable, convincing, methodically cleanly derived. Although this (and here we return to the lack of verifiability) can only be assessed in the evaluation of a third party, who in turn must apply a vague model to evaluate what was previously found. The parallel to the answer of a language model is obvious: Here too, plausibility based on existing statistical model structures counts more than absolute truth.

This creates a new bridge between law and technology. While previously, as described above, the structural comparison between legal subsumption and detailed software design was in the foreground, today's AI development allows a deeper analogy: Working with probabilities, context sensitivity, and discursive openness has long since ceased to be exclusively the domain of the humanities.

Because the code examples look so nice visually, here's another comparison of the old and new world in the form of two TypeScript functions.

Classic and deterministic:

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Adult – purchase allowed
  } else {
    return false // Not adult – purchase refused
  }
}

console.log(isValidPurchase(17)) // false
console.log(isValidPurchase(18)) // true

Modern LLM style (or: legal argumentation as a function)

function assessPurchaseEligibility(userAge: number, maturityLevel: "high" | "medium" | "low"): string {
  if (userAge >= 18) {
    return "Purchase probably allowed – classic adulthood reached."
  }

  if (userAge >= 16 && maturityLevel === "high") {
    return "Justifiable argumentation for purchase – room for interpretation possible."
  }

  if (userAge < 16 || maturityLevel === "low") {
    return "Purchase rather not permitted – risk too high."
  }

  // return for bad prompt without input parameters
  return "I am an LLM and I'm hallucinating nonsense, and if you don't pay attention, you won't notice and will believe it's true."
}

What's Next?

After this little excursion into the similarities and differences between legal thinking and the "thinking" of computers and programs, the next article will be a bit less theoretical again.

In my own legal practice (mainly traffic law), a real frustration with ineffective processes arose that bothered me so much that over several years I engaged so intensively with software development that today I am sometimes unsure whether to introduce myself as a lawyer or a software developer when asked what I do :)

Second article in the series: Lawyer2Dev - A Journey - Digitizing Law Firm Processes