Von der Vergleichbarkeit von Recht und Software

Hey, ich bin Martin Kurtz, Rechtsanwalt und einer der beiden Gründer von MaraDocs. Willkommen auf dem MaraDocs Blog. Wir schreiben über Themen aus der Schnittmenge zwischen Rechtsanwaltschaft und IT.

Dies ist der erste Artikel der Serie Anwalt2Dev - A Journey. In der Artikelserie wird es um meine eigene berufliche Geschichte und Motivation gehen, aber vor allem werde ich in unterschiedlicher Tiefe viele Konzepte und Technologien erklären, die die heutige IT-Landschaft aus meiner Sicht ausmachen. Und ja - es wird sicher auch ein bisschen Code geben. :)

// anwalt2dev - a journey
const SERIES_NAME = "Anwalt2Dev - 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, nun aber in medias res!

Jura

Ich habe im Jahr 2005 angefangen, an der Universität Bonn Jura zu studieren. Ich kann über meine ersten Jahre an der Universität gar nicht so viel berichten: Frau Prof. Puppe (eine legendäre Strafrechtlerin, die für ihre Mindermeinungshoheit bekannt ist) lehrte noch aktiv und im Juristischen Seminar geba es noch dedizierte Computerräume, in denen Studenten Institutscomputer nutzen konnten.

Ich erinnere mich gut daran, dass die ersten Klausuren ein erschreckend anderes Niveau hatten als die Prüfungen, die ich aus der Schule gewöhnt war. Das Jura, das man als Student lernen durfte, präsentierte sich mir als wirklich großes und zusammenhänges Konzept. Ich habe eine Zeit gebraucht, um zu verstehen, dass es zugrundeliegende Denkstrukturen bzw. Systemmodelle und Methoden gibt, die ihre Gültigkeit in allen Bereichen behielten.

Sicherlich haben die drei großen Bereiche (Zivilrecht, Öffentliches Recht und Strafrecht) ihrerseits einen ganz eigenen Charakter, fast schon einen eigenen Geschmack, den man als junger Student Stück für Stück in vielen, vielen Stunden kennenlernt, aber dennoch liegt dem Ganzen ein wiederkehrendes Muster zugrunde: Kleinschrittigkeit.

Prüfungsschemata

Wir lernten vor allem Prüfungsschemata: Etwa die Vorraussetzungen verschiedener Anspruchsgrundlagen oder der Rechtmäßigkeit bestimmten staatlichen Handelns. Dabei verbirgt sich hinter jedem Prüfungspunkt eine Abzweigung und man ist gezwungen, an dieser Abzweigung auch wirklich Halt zu machen und genau hinzuschauen, ob alle Unterpunkte erfüllt sind. Nur dann ist der Weg zum nächsten Prüfungspunkt frei.

Beispiel: Schema Rechtmäßigkeit eines Verwaltungsaktes, hier auf Basis einer fiktiven Verwaltungsakt-Klasse in TypeScript dargestellt.

I. Ermächtigungsgrundlage (EGL)
  1. Erforderlich?
  2. Auswahl der EGL 
  
II. Formelle Rechtmäßigkeit
  1. Zuständigkeit
  2. Verfahren
    a. Anhörung
    b. Mitwirkungsverbote
    c. Mitwirkung anderer Behörden
  3. Form
  
III. Materielle Rechtmäßigkeit
  1. Voraussetzungen der Ermächtigungsgrundlage 
  2. Allgemeine Rechtmäßigkeitsvoraussetzungen
    a) Bestimmtheit, § 37 I VwVfG
    b) Keine tatsächliche oder rechtliche Unmöglichkeit
  3. Richtiger Adressat
  4. Rechtsfolge: Ermessensentscheidung oder gebundene Entscheidung?
    a) Gebundene Entscheidung: Anordnung der vorgesehenen Rechtsfolge
    b) Ermessensentscheidung:
      aa) Ermessensfehler?
        (1) Ermessensnichtgebrauch
        (2) Ermessensunterschreitung
        (3) Ermessensfehlgebrauch
        (4) Ermessensüberschreitung
      bb) Ggf. Ermessensreduzierung auf Null
      cc) Ggf. intendiertes Ermessen

Diese Art des kleinschrittigen Vorgehens ist dem Ablauf von Computerprogrammen sehr ähnlich. Der Ablauf eines klassischen (single threaded) Programms sieht zu jedem Zeitpunkt genau einen Prüf- oder Arbeitsschritt vor, der niemals übersprungen werden kann. Andersherum kann ein Programm auch nur die Fragen beantworten bzw. Probleme lösen, die zum Zeitpunkt der Erstellung des Programmes vorgesehen sind. Dies erfordert bei der Erstellung von Software in ganz besonderem Maße die Fähigkeit, das zu lösende Problem in ein logisches Modell zu überführen, das atomar durchschritten werden kann. Dabei müssen alle denkbar vorkommenden Teilfragen auch Teil des Modells werden. Treten zu einem späteren Zeitpunkt unerwartete Zustände auf (edge cases), die nicht abgefangen werden (z.B. mittels try catch patterns), stürzt das Programm ab.

Die Kleinschrittigkeit juristischen Denkens und die Problem-Modellierung im Softwaredevelopment sind sich also sehr ähnlich.

Keine eindeutige Lösungen

Software lässt sich exakt und reproduzierbar ausführen, testen und debuggen. Ein Input führt (sofern korrekt implementiert) zu einem definierten Output. Juristische Prüfungen hingegen zeichnen sich in der Regel dadurch aus, dass sie zwar auf einem strukturierten Prüfungsaufbau (Subsumtion etc.) aufbaut, aber immer auch wertungsabhängige Elemente enthält und im Ergebnis abwägungsoffen ist. Das Ergebnis ist also nicht deterministisch.

Software lässt sich auf Grund ihrer deterministischen Natur testen: In einem unit test beispielsweise wird eine zu testende Funktion programmatisch mit einem definierten Input gefüttert und daraufhin überprüft, ob sie den erwarteten Output liefert. Gesetze hingegen sind sprachlich ambig oder zumindest auslegungsbedürftig. Dies führt dazu, dass man Ergebnisse nicht im klassischen Sinne testen kann.

Beispiel eines unit test (hier im Stile des Jest-Frameworks)

describe('tellReader function', () => {
  test('should return success message when given correct series name', () => {
    // vorbereiten
    const correctSeriesName = "Reise vom Rechtsanwalt zum Softwareentwickler";
    const expectedMessage = "There will be code, my friend :) ";

    // ausführen
    const result = tellReader(correctSeriesName);

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

LLMs und das neue IT-Verständnis: Wahrscheinlichkeiten statt Wahrheiten?

Während klassische Softwareentwicklung lange als Inbegriff deterministischer Logik galt – Input rein, klar definierter Output raus –, bringt der Einsatz großer Sprachmodelle (LLMs) wie Claude, LLama oder ChatGPT eine neue, vielleicht weichere Form der IT mit sich. Diese Systeme operieren nicht auf Grundlage fest kodierter Entscheidungsbäume, sondern auf Basis statistischer Muster, die sie aus unvorstellbar großen Datenmengen extrahiert haben. Der Output ist somit nicht im mathematisch-strengen Sinne vorhersehbar, sondern bewegt sich im Rahmen des Wahrscheinlichen, des Typischen, des Kontextuell-Plausiblen.

In dieser Eigenschaft ähneln sich die Ergebnisse von LLMs und die Ergebnisse und Methoden der juristischen Argumentation. Auch in der Juristerei werden Entscheidungen nicht rein logisch deduziert, sondern in einem Spannungsfeld aus Normtext, Sachverhalt, Auslegung und Abwägung getroffen. Das Ergebnis einer juristischen Prüfung ist selten „richtig“ im Sinne eines objektiven Werts – es ist vielmehr vertretbar, überzeugend, methodisch sauber hergeleitet. Wobei dies (und hier kommen wir wieder auf die fehlende Überprüfbarkeit zurück) wieder nur in der Wertung eines Dritten zu beurteilen ist, der seinerseits ein vages Modell anwenden muss, um das zuvor gefundene zu evaluieren. Die Parallele zur Antwort eines Sprachmodells ist offensichtlich: Auch hier zählt die Plausibilität auf Grundlage vorhandener statistischer Modellstrukturen mehr als die absolute Wahrheit.

So entsteht eine neue Brücke zwischen Recht und Technologie. Während früher wie zuvor beschrieben der strukturelle Vergleich zwischen juristischer Subsumtion und kleinteiligem Softwaredesign im Vordergrund stand, erlaubt die heutige KI-Entwicklung eine tiefere Analogie: Das Arbeiten mit Wahrscheinlichkeiten, Kontextsensitivität und diskursiver Offenheit ist längst nicht mehr nur Domäne der Geisteswissenschaften.

Weil die Code-Beispiele optisch so schön sind, folgt noch ein Vergleich der neuen und der alten Welt in Form von zwei TypeScript-Funktionen.

Klassisch und deterministisch:

function isValidPurchase(userAge: number): boolean {
  if (userAge >= 18) {
    return true // Volljährig – Kauf erlaubt
  } else {
    return false // Nicht volljährig – Kauf verweigert
  }
}

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

Moderner LLM-Style (oder: juristische Argumentation als Funktion)

function assessPurchaseEligibility(userAge: number, maturityLevel: "hoch" | "mittel" | "niedrig"): string {
  if (userAge >= 18) {
    return "Kauf wahrscheinlich erlaubt – klassische Volljährigkeit erreicht."
  }

  if (userAge >= 16 && maturityLevel === "hoch") {
    return "Vertretbare Argumentation für Kauf – Auslegungsspielraum möglich."
  }

  if (userAge < 16 || maturityLevel === "niedrig") {
    return "Kauf eher nicht zulässig – Risiko zu hoch."
  }

  // return bei schlechtem Prompt ohne Input-Parameter
  return "Ich bin ein LLM und ich halluziniere einen Schrott zusammen, und wenn du nicht aufpasst, merkst du es nicht und hältst es für wahr."
}

Wie geht's weiter?

Nach diesem kleinen Ausflug in die Ähnlichkeiten und Unterschiede der juristischen Denkweise und der "Denkweise" vom Computern und Programmen wird es im nächsten Artikel wieder etwas weniger theoretisch.

In meiner eigenen anwaltlichen Praxis (viel Verkehrsrecht) ist eine regelrechte Frustration über ineffektive Prozesse entstanden, die mich so stark gestört hat, dass ich über mehrere Jahre mich so intensiv mit Softwareentwicklung auseinander gesetzt habe, dass ich heute manchmal unsicher bin, ob ich mich als Jurist oder als Softwareentwickler vorstellen soll, wenn ich gefragt werde, was ich mache :)

Zweiter Artikel der Serie: Anwalt2Dev - A Journey - Digitalisierung von Kanzleiprozessen