Ein Rückblick auf Entstehung, Irrwege und Erkenntnisse — für Juristen, Techniker und alle, die sich gefragt haben, warum das so lange gedauert hat.
Ludwig Baumbach war ein deutscher Jurist, der in der ersten Hälfte des 20. Jahrhunderts lebte. Sein bleibendes Vermächtnis in der deutschen Zivilrechtspraxis ist eine Formel — die Baumbach’sche Formel — mit der geregelt wird, wer am Ende eines Rechtsstreits wie viel der Verfahrenskosten trägt.
Das klingt einfacher als es ist. In einem deutschen Zivilprozess fallen mindestens zwei Kostentöpfe an: Gerichtsgebühren (nach dem Gerichtskostengesetz, GKG) und Anwaltsgebühren (nach dem Rechtsanwaltsvergütungsgesetz, RVG). Beide richten sich nach dem Streitwert — aber nicht nach demselben, und nicht mit derselben Tabelle. Wenn dann noch Widerklage, Gesamtschuldner oder Aufrechnungen ins Spiel kommen, multiplizieren sich die Wechselwirkungen. Eine einfache 50/50-Kostenteilung ist selten; meistens muss für jede Partei und jeden Kostentopf eine eigene Quote berechnet werden, danach Saldo gezogen, und am Ende wird der Tenor des Urteils formuliert.
Manche Juristen mögen Baumbach nicht. Die Kritik läuft auf zwei verschiedenen Gleisen — und die sind, wenn man sie nebeneinanderstellt, gemeinsam komisch.
Das erste Gleis ist normativ: Die Formel ist zu simpel für das Recht. Sie reduziert eine Entscheidung, die eigentlich Ermessen verlangt — wer hat wie viel verloren, und warum? — auf bloße Arithmetik. Das Recht gibt dem Richter Spielraum; Baumbach rechnet ihn weg. Trotzdem ist die Formel Praxisstandard — weil man irgendwie rechnen muss.
Das zweite Gleis ist praktisch: Die Formel ist zu komplex für den Taschenrechner. Schon 1992 sahen Viefhues/Viefhues (JuS 1992, 944) die Notwendigkeit, „elektronische Hilfsmittel” zu empfehlen — und Referendare aller Generationen kennen die Gesamtschuldner-Falle aus dem Examen.
Die Pointe: Ein Instrument, das richterliches Ermessen durch Berechenbarkeit ersetzen soll, ist selbst komplex genug, um seit dreißig Jahren Software- projekte zu motivieren. Dieses hier ist das neueste in der Reihe — und die Existenz dieser ist ein gutes Argument für das zweite Gleis.
Genau diese Handhabbarkeit war der Ausgangspunkt dieses Projekts, gemeinsam mit der Frage: Kann ein juristischer Laie mit Hilfe von Claude etwas Nützlicheres generieren?
Die Antwort ist ja — aber der Weg dorthin war länger und lehrreicher als erwartet.
Am Anfang stand ein einfacher Versuch: Claude soll sich selbst in das Rechtsgebiet einlesen, die Algorithmen finden, und Code für einen Rechner als Webseite schreiben. Das funktionierte überraschend schnell und gut. Mit wenigen Prompts gab es eine Webseite, welche anscheinend das Richtige tat, gut aussah – aber falsch rechnete.
Die Excel-Tabelle lieferte die erste automatisierte Referenz: wenn die JavaScript-Engine für dieselben Eingaben dieselben Ergebnisse wie die Tabelle produziert, ist das zumindest ein Anfang. Aber auch das genügte nicht — die Tabelle konnte selbst Fehler haben.
Was folgte, war eine Explorationsphase, die im Nachhinein etwas chaotisch wirkt: mehrere parallele Implementierungen, jede mit eigener Logik, eigener Sprache, eigener Testabdeckung.
Alle vier Varianten (plus ein Vereinheitlichungsversuch) sind im
Repository als iteration1–iteration4
eingefroren — ein Archiv des Suchprozesses nach der richtigen
Abstraktion.
Zwangsläufiges Denglish
Das Fachgebiet zwingt zur Zweisprachigkeit — aber nicht auf die erwartete Weise. Die inhaltliche Kommunikation mit Claude muss auf Deutsch erfolgen: §§, Quoten, Tenor, Gesamtschuldner, Hilfsaufrechnung. Ein englischer Prompt über § 92 II ZPO produziert sofort Distanz zum Stoff.
Gleichzeitig ist die informatische Seite der Entwicklung unausweichlich englisch geprägt. Es gibt keine gute deutsche Entsprechung für „Claude, please commit the UX refactoring and push it upstream” — und wer es auf Deutsch versucht, klingt komisch.
Das Ergebnis ist ein unvermeidliches Denglish: juristische Sachverhalte auf Deutsch, Infrastruktur- und Architektur-Gespräche auf Englisch, und gelegentlich beides im selben Satz. Für ein Projekt über deutsches Prozessrecht, implementiert als JavaScript-Webanwendung, ist das vielleicht die ehrlichste mögliche Sprache.
Nach der Explorationsphase wurde konsolidiert: die Tests aus allen
Varianten wurden nach JavaScript übersetzt und zu einer gemeinsamen
Testsuite vereinheitlicht. Eine neue Codebase (new_ui/,
später ins Wurzelverzeichnis hochgezogen) wurde zum alleinigen aktiven
Stand.
Ein wichtiger Schritt in dieser Phase: die Gebührentabellen (GKG und RVG) wurden aus amtlichen Quellen geparst und in die Engine eingebettet. Nicht aus der Excel-Tabelle übernommen, nicht von Claude geschätzt — aus den offiziellen Kostenrechtsänderungsgesetzen. Ein Provenance-Dokument hält fest, welche Tabelle aus welcher Quelle stammt und welchen Geltungsstand sie hat. Das klingt nach Buchhaltung. Es war eine wichtige Qualitätsentscheidung des Projekts — aber das wusste man damals noch nicht.
Die produktivste Phase begann mit einem methodischen Wechsel. Statt die Engine gegen wenige vorhandene Beispiele zu prüfen, wurde ein dreistufiger Prozess eingesetzt:
Konstruktion: „Gegeben das Rechtsgebiet §§ 91 ff. ZPO — entwirf Fälle, die Wechselwirkungen zwischen Paragraphen testen.” Claude konstruierte 47 Übungsfälle: von einfach (A verklagt B und gewinnt), über Teilsiege, Widerklagen, Gesamtschuldner, Aufrechnungen, Erledigungen, Berufungen, hin zu Fällen in denen alle diese Aspekte gleichzeitig interagieren. Dieser Schritt war teils manuell (“könnte das nicht auch noch komplizierter sein?”) und nahm nur wenige Tage in Anspruch.
Lösung: „Gegeben diese Fälle — löse jeden ausschließlich mit gelerntem Weltwissen, ohne Engine, ohne Taschenrechner.” Claude produzierte für jeden Fall eine vollständige Lösung mit Quoten, Gebührenbeträgen und Tenor. Interessant war die fast vollständige Automatisierung. Claude erstellte ein Programm, welches jeden Fall einzeln an eine neue Claude-Instanz übergab. Diese Programm löste in wenigen Minuten alle Fälle.
Test-Driven Development: „Gegeben Fälle und Lösungen — verbessere die Engine, bis die Soll-Ergebnisse stimmen.” Hier steckte die meiste Arbeit. Falls die Lösung mit der Antwort der Engine überein stimmte – alles prima, nächster Fall. Aber wenn nicht, dann begann eine Suche: War die Lösung falsch? Oder die aktuelle Implementierung der Engine? Oder beide? Oder gibt es für diese Konstellation gar kein “richtig” und “falsch”, denn die Juristen streiten noch? Und wie kann man zwischen diesen Möglichkeiten unterscheiden?
Das Verfahren funktionierte. Und es produzierte sofort eine Überraschung.
Selbstwiderlegung als Methode
Was ist verlässlicher — die menschlich klingende Prosa oder die nüchternen Zahlen? Die Antwort war eindeutig und doppelt überraschend: Die Juristen-Prosa und Tenor von Claude war (meistens) richtig. Die vom LLM vorgeschlagen Zahlen waren aber fast durchgängig massiv falsch (veraltete Tabellengenerationen, Zeilenverwechslungen, und freie Halluzinationen). Die Prosa der Engine dagegen war zumindest anfänglich inhaltlich falsch und grammatikalisch sehr fraglich, die berechneten Zahlen mit amtlichen Tabellen aber schnell zuverlässig.
Die Maschine korrigiert sich dann unter Anleitung aber selbst — Claude hatte die Fälle konstruiert, Claude schrieb ein Programm um die Fälle mit Claude zu lösen. Claude schrieb die Engine, und Claude untersuchte dann die Widersprüche aus beiden Ansätzen um der Wahrheit näher zu kommen.
Das erste wirklich ernste Problem kam mit Fall 18. Die Konstellation: Klägerin klagt gegen zwei Beklagte, die als Gesamtschuldner haften. Ein typischer Fall — in der Praxis häufig.
Eine Eingabe der Engine hieß zu diesem Zeitpunkt
Prozessrechtsverhältnis (kurz: PRV). Ein PRV modellierte
eine bilaterale Beziehung: eine Partei gegen eine andere. Für
Gesamtschuldner lag es nahe, zwei PRVs anzulegen — einen für Klägerin
gegen Beklagten 1, einen für Klägerin gegen Beklagten 2.
Das Ergebnis: der Streitwert wurde verdoppelt. Statt 30.000 € rechnete die Engine 60.000 € — still, ohne Warnung, mit falschen Quoten und falschen Gebühren.
Das Tückische daran: die Modellierung fühlte sich richtig an. Zwei Schuldner, zwei Verhältnisse, zwei PRVs — intuitiv. Aber juristisch ist eine Gesamtschuldnerklage eine Forderung mit einem Streitwert, unabhängig von der Zahl der Schuldner. Die Engine hatte eine Abstraktionsebene, die nicht zur juristischen Realität passte.
Fall 19 machte es noch deutlicher: dort wies das Gericht die Gesamtschuldnerklage ab. Die Engine verbot die natürliche Modellierung ganz; es brauchte zwei separate Patches, um den Fall überhaupt rechnen zu können.
UX-Problem = Korrektheitsproblem
Man könnte denken: Das ist ein Schnittstellenproblem. Die Eingabemaske muss nur klarer beschriften, was ein PRV ist. Aber das greift zu kurz. Eine Eingabemaske, die zur falschen Modellierung einlädt — weil ihre Abstraktionen nicht mit dem juristischen Denken übereinstimmen — produziert falsche Ergebnisse, egal wie gut die Engine dahinter ist. Das ist kein UX-Schönheitsfehler. Das ist ein Korrektheitsproblem.
Die Konsequenz aus der GS-Falle war ein vollständiger Umbau des Eingabemodells. Das neue Atom heißt Forderung — ein Begriff, den jeder Jurist und jeder Sachbearbeiter kennt. Eine Forderung hat einen Forderer, eine Schuldner-Liste, einen Streitwert und einen Ausgang (voll obsiegt / teilweise / abgewiesen / Rücknahme / Erledigung / …). Gesamtschuldnerschaft ist eine Eigenschaft der Forderung, nicht ein Beziehungsnetz.
Der Umbau erfolgte in 9 Phasen, jede unter Testschutz — Strategie: Brücke statt Big Bang. Die neue API übersetzte zunächst intern in die alten Strukturen, sodass alle bestehenden Tests weiter grün blieben. Erst in den letzten Phasen wurde die alte Engine vollständig entfernt.
Das Ergebnis: baumbach.js schrumpfte von 3.329
auf 1.632 Zeilen — und machte danach mehr als vorher. Die
GS-Falle ist im neuen Datenmodell strukturell unmöglich: eine Forderung,
ein Streitwert, egal wie viele Schuldner.
§ 92 Abs. 2 ZPO sagt: Wenn eine Partei unterliegt, aber nur geringfügig, kann das Gericht sie von den Kosten freistellen. Eine Ermessensnorm — das Gesetz sagt explizit “kann”, und es gibt keine Definition von „geringfügig” (auch wenn in der Praxis wohl 10% üblich sind).
Die Engine hatte es trotzdem als harte Schwelle implementiert: Unterliegen unter 10 % → automatisch freigestellt. Fall 6 legte den Bug offen: bei exakt 10 % kippte das Ergebnis an einer Linie, die das Gesetz nicht zieht. Dazu fehlte die zweite Voraussetzung der Norm (keine höheren Kosten durch die Geringfügigkeit) ganz.
Die Lösung war die klare Unterscheidung zwischen Automatismen und juristischen Wertungen, und dazu ein Prinzip, das seitdem für das gesamte Projekt gilt: Wertungen gehören dem Nutzer, nicht der Engine. § 92 II ist seither eine Eingabe: der Benutzer markiert, welche Partei er als geringfügig unterliegend wertet; die Engine setzt das Unterliegen auf null und renormiert. Der Mensch wertet; die Maschine rechnet.
Manchmal ist die juristische Frage schlicht offen — die Literatur ist uneinig, die Rechtsprechung dünn, oder die Norm lässt mehrere vertretbare Lesarten zu. Was soll die Engine tun?
Die Antwort, zu der das Projekt gefunden hat: explizit
abbrechen. Die Engine wirft eine
EngineLücke-Exception mit einer Beschreibung des Problems,
statt stillschweigend eine von mehreren möglichen Antworten zu wählen.
Der Nutzer sieht einen klaren Hinweis: „Hier gibt es keine eindeutige
h.M. — bitte außerhalb des Rechners entscheiden.”
Auch gibt es Konstellationen, die schlicht noch nicht (oder nicht in allen Einzelfällen korrekt) implementiert sind.
Dasselbe Prinzip gilt für fehlende Pflichtangaben: fehlt die Gerichtsart, die Urteilsart oder die Gebührentabelle, bricht die Engine ab. Sie liefert lieber einen Fehler als ein plausibel aussehendes, aber falsches Ergebnis.
47 Fälle wurden systematisch gegen die Engine geprüft. Die meisten bestätigten die Korrektheit — aber einige fanden Fehler:
Fall 22 — ein Buchstabe, tausende Euro: Bei einer Hilfsaufrechnung, deren Gegenforderung scheitert, erhöht § 45 III GKG den Streitwert trotzdem um den Wert der Gegenforderung (weil das Gericht sie rechtskräftig verneint hat). Die Engine nutzte stattdessen den Erfolg der Aufrechnung — ein einzelner falscher Variablenname, der den Streitwert bei gescheiterter Aufrechnung um den vollen Gegenforderungsbetrag verfehlte.
Fall 26/29 — neue Gesetze, alter Code: Am 1. Januar 2026 trat eine Reform in Kraft, die die Berufungsgrenze von 600 € auf 1.000 € anhob. Die Engine hatte eine einzige Schwelle — und produzierte seitdem für einen bestimmten Streitwertbereich systematisch falsche Vollstreckbarkeitsklauseln. Drei neue Eckpunkt-Tests (999 €, 1.000 €, 1.001 €) fixierten das korrekte Verhalten.
Fall 38 — zu vorsichtig: Ein internes Flag
(ausWelchemRV) ließ die Engine eine EngineLücke werfen,
obwohl die höchstrichterliche Rechtsprechung die Frage längst
entschieden hatte. Ergebnis: die Engine verweigerte eine Berechnung, die
korrekt gewesen wäre. Ersetzt durch einen expliziten Bool
(streitwerterhöhend), den der Aufrufer setzt — konsistent
mit dem Prinzip „Wertungen gehören dem Nutzer”.
Fall 47 — Reihenfolge zählt: Bei der Maximumregel des § 45 I 3 GKG (wirtschaftlich identische Forderungen zählen nur einmal zum Maximum, nicht zum Streitwert addiert) gab es einen Reihenfolge-Bug: wenn die Markierung nur auf einer Seite gesetzt war, rechnete die Engine falsch. Fix: Zwei-Pass-Verarbeitung, erst Identitätspaare auflösen, dann summieren.
Sowohl der Entwickler als auch Claude haben regelmäßig danebengegriffen, wenn es darum ging vorherzusagen, wie groß eine Änderung wird. Eine kleine UX-Anpassung — „zeig die Kostengrundlage pro Forderung an” — führte zu einem internen Umbau der Vollstreckbarkeitslogik. Ein vermeintlich komplexer Fall (drei Parteien, Gesamtschuldner, Widerklage) war in zwanzig Minuten erledigt.
Gegen Ende zeigte sich der Lohn der Vorarbeit: als die Prüffälle wirklich schwierig wurden — mehrere Parteien, Aufrechnungen, gemischte Urteilsarten — passierten viele Tests die Auswertung ohne eine einzige Änderung an der Engine. Die Tests wurden grün, bevor man überhaupt anfing zu debuggen. Investitionen in Testinfrastruktur und saubere Abstraktionen zahlen sich spät aus — und dann spürbar.
Anfänglich bestand das gesamte Projekt aus einer einzigen Datei
(index.html enthielt Dokumentation, Style Sheets, Code.
Später dann auch Tests). Erst nach und nach wurden Funktionalitaeten
aufgeteilt (insbesondere die Trennung von UI-Code von der eigentlichen
Engine war nützlich), Tests separiert, Skripte geschrieben. Heute
umfasst das Projekt über 150 Dateien.
Das Projekt war von Anfang bis Ende KI-gestützt. Dabei haben sich wiederkehrende Muster gezeigt:
Claude halluziniert Gebühren — konsistent und zuversichtlich. Über alle 47 Fälle hinweg lagen die KI-generierten Gebührenbeträge daneben. Die Formulierungen klangen sicher; die Zahlen waren falsch. Das ist kein Einzelfall-Versagen — es ist ein strukturelles Muster bei spezifischen Tabellenwerten, die sich über Jahre geändert haben.
Claude übernimmt Wertungen, wenn man es lässt. Ohne
explizite Fragestellung — „Soll die Engine oder der
Nutzer diese Entscheidung treffen?” — neigte Claude dazu,
juristische Ermessensfragen stillschweigend in Code-Logik zu übersetzen.
§ 92 II als Prozenthürde, ausWelchemRV als automatische
EngineLücke. Beides war falsch, beides musste rückgebaut werden.
Claude nimmt Abkürzungen, wenn man es nicht verhindert. Bei einer Entscheidung zwischen “fast korrekt oder meistens korrekt, erreichbar mit wenig Arbeit” und “wirklich korrekt, aber viel Arbeit” tendiert Claude zu ersterem. Eine explizitere Priorisierung (“juristische Korrektheit hat immer Vorrang” in CLAUDE.md) und deren gelegentlich Wiederholung war nötig.
Claudes Abstraktionen sind hartnäckig — von der Einführung
bis zur Sackgasse. Prozessrechtsverhältnis wurde
nie explizit gewählt: Claude zog den Begriff bei einem vagen Prompt aus
juristischem Weltwissen. Er ist rechtlich echt; als Modellierungsatom
führte er direkt in die GS-Falle. Und einmal im Code, verteidigte Claude
ihn: die Frage war stets „Wie modelliert man das mit PRVs?” — nie „Sind
PRVs überhaupt die richtige Abstraktion?“. Beides muss von außen kommen:
die Wahl der Abstraktion am Anfang, und die Bereitschaft sie zu
verwerfen, wenn sie nicht passt.
Kontext-Grenzen werden sichtbar. In langen Sessions, wenn der Konversations-Kontext tausende Zeilen Code und Dokumentation enthält, verliert Claude gelegentlich den Überblick über das eigene Datenmodell. Symptom: widersprüchliche Vorschläge in derselben Session, oder Patches die einen alten Bug beheben, aber einen neuen einführen. Kleinere Sessions mit engerem Fokus waren verlässlicher.
Die baumbach-spezifische Arbeit begann Anfang Mai 2026 und konzentrierte sich auf etwa vier Wochen intensiver Arbeit.
Die Spitze in (Anfang Juni) umfasst den PRV→Forderung-Refactor und die Fallprüfungen 30–47. Ende Mai enthielt die frühen Fallprüfungen und die § 92 II-Umstellung.
Wachstum bis zum Peak (Anfang Juni), dann der markante Einbruch beim PRV→Forderung-Refactor — die Engine kann danach mehr als vorher. Seitdem wächst sie wieder, weil neue Fälle neue Funktionalität erfordert haben.
Input, Cache-Write und Output (linke Achse) sind im Vergleich zum Cache-Read (rechte Achse, gestrichelt) winzig. Cache-Read dominiert weil Claude in langen Sessions denselben Kontext immer wieder liest — zum günstigeren Cache-Preis (10 % des normalen Input-Preises).
| Kennzahl | Wert |
|---|---|
| Baumbach-spezifische Commits | 114 |
| Aktive Arbeitstage | 20 |
| Zeitraum | 8. Mai – Anfang Juni 2026 |
| Zeilen Code (gesamt) heute | >40k, davon 22k Tests und 5k für HTML und CSS |
Zeilen Engine-Kern (baumbach.js) auf dem Höhepunkt (vor
Refactor) |
3.329 |
Zeilen Engine-Kern (baumbach.js) nach dem Refactor |
1.632 |
| Automatisierte Tests heute | ~1.100 |
| Geprüfte Fälle | 47 |
| Fälle welche Engine-Problem aufzeigten | ~12 |
| Fälle mit numerisch falscher Lösung | 47 von 47 |
Die letzte Zeile verdient Aufmerksamkeit: in allen 47 geprüften Fällen waren die Gebührenbeträge in den KI-generierten Musterlösungen falsch.
Claude Code wurde auf einem Flatrate-Abonnement (Claude Pro) betrieben. Die tatsächlichen Kosten sind damit konstant (17 $ pro Monat). Die Session- und Wochen-Limite des Abos wurden regelmässig erreicht, sodass die Arbeit dann pausieren musste.
Wie hoch wäre die Rechnung bei Pay-per-Token gewesen? Aus den Nutzungsdaten aller Claude-Code-Sessions seit April 2026 (109 Sessions, teilweise Baumbach-fremde Projekte) ergibt sich anhand der veröffentlichten Anthropic-Preise:
| Modell | Tokens (Input / Output / Cache) | Geschätzte Kosten |
|---|---|---|
| Claude Opus 4 | 0,1 M / 10,1 M / 2,9 Mrd. Cache-Read | ~5.300 $ |
| Claude Sonnet 4 | 0,1 M / 11,5 M / 0,8 Mrd. Cache-Read | ~440 $ |
| Claude Haiku 4.5 | minimal | ~1 $ |
| Gesamt | ~5.800 $ |
Der mit Abstand größte Posten: Cache-Read-Tokens für Opus. In langen Sessions liest Claude denselben Kontext immer wieder neu — beim Cache-Preis (10 % des Normalpreises) sind das trotzdem mehrere tausend Dollar hypothetisch. Das Projekt war in dieser Intensität nur möglich, weil das Abonnement die Kosten vollständig entkoppelt.
Dieser Abschnitt ist anders als die anderen. Er ist keine Dokumentation, sondern Reflexion — eine ehrliche Einschätzung im Nachhinein, was funktioniert hat, was nicht, und was man beim nächsten Mal anders machen würde.
Tests als Sicherheitsnetz. Jedes Mal wenn Tests vorhanden waren, war Refactoring sicher und schnell. Der PRV→Forderung-Umbau war neun Phasen lang — weil er es sein musste, um korrekt zu sein. Dass er trotzdem beherrschbar blieb, lag daran, dass ~1.500 Tests sofort anzeigten, wenn etwas brach.
Amtliche Quellen statt KI-Schätzungen. Die Entscheidung, die Gebührentabellen aus den offiziellen Kostenrechtsänderungsgesetzen zu parsen — statt sie von Claude schätzen zu lassen oder aus der Excel-Tabelle zu übernehmen — war die wichtigste Qualitätsentscheidung des Projekts. Ohne diesen Anker wäre nie sichtbar geworden, dass die Engine bei Gebühren zuverlässiger ist als das LLM, das sie miterstellt hat.
Explizit abbrechen statt still falsch rechnen. Die
EngineLücke war die richtige Antwort auf offene juristische
Fragen. Mutig, weil es bedeutet, dem Nutzer zu sagen: „Hier kann ich
nicht helfen.” Aber richtiger als eine plausibel aussehende, aber
möglicherweise falsche Antwort.
Brücke statt Big Bang. Der schrittweise Umbau mit einer Übersetzungs- schicht hat verhindert, dass das Projekt wochenlang im halbfertigen Zustand nicht funktionierte. Jede Phase war ein kleiner, revertierbarer Schritt.
Domänengetriebene Benennung. Der Wechsel von
Prozessrechtsverhältnis zu Forderung hat nicht
nur die Benutzeroberfläche verbessert — er hat einen strukturellen
Fehler aus dem Datenmodell entfernt.
Zu späte Skepsis. Die KI-generierten Musterlösungen wurden anfangs als Soll-Werte behandelt. Das Vertrauen in autoritative klingende Prosa war falsch; das hätte von Anfang an anders sein sollen.
Vier Implementierungen vor dem richtigen Abstraktionsniveau. Die Exploration war nicht wertlos — aber ein frühes strukturiertes Gespräch mit einem Juristen über das mentale Modell hätte wahrscheinlich zwei Iterationen gespart. Stattdessen wurde das Abstraktionsproblem durch scheiternde Praxis entdeckt.
Englisch als stiller Saboteur. Englischsprachige
Prompts in einer frühen Phase zementierten eine informatische
Begriffswelt, die nicht zur juristischen Wirklichkeit passte. Der
Begriff Prozessrechtsverhältnis entstand in diesem Kontext
und überlebte zu lange.
Aufwandsschätzung systematisch unzuverlässig — auf beiden Seiten. Claude neigt dazu, die Tiefe von UX-Änderungen in die Engine zu unterschätzen. Menschen neigen dazu, Rechercheaufwand zu unterschätzen. Beide Tendenzen zusammen erzeugen regelmäßig Überraschungen.
Domain-Modell zuerst, Code danach. Vor der ersten Zeile Code: ein Gespräch mit einem Juristen führen, das mentale Modell der Zielgruppe aufzeichnen, die Schlüsselbegriffe festlegen. „Forderung” von Anfang an, nicht als Ergebnis eines schmerzhaften Refactors zwei Monate später.
Gebührentabellen als erstes. Die amtlichen Tabellen waren das Fundament der Verlässlichkeit — sie hätten nicht in der Mitte des Projekts nachgerüstet werden sollen, sondern als erstes stehen müssen.
Den Dreischritt früher einsetzen. Konstruktion → Lösung → TDD war der produktivste Ansatz. Er kam zu spät; die frühen Iterationen haben Zeit gekostet, ohne den Anker der systematischen Fallprüfung zu haben.
Kürzere Sessions, engerer Fokus. Lange Sessions akkumulieren Kontext, bis der Überblick nachlässt. Klarere Sitzungsziele und häufigere Kontextresets hätten manchen Umweg vermieden. Die produktivsten Sessions hatten ein klar umrissenes Ziel: „heute nur Fall 22” oder „heute nur der Vollstreckbarkeits-Umbau”.
Kann ein Laie mit Claude etwas Nützliches entwickeln? Ja, unter zwei Bedingungen. Man muss willens sein, Zeit und Tokens zu investieren, um sich mit der Materie zu beschäftigen. Und damit ist man hinterher kein blutiger Anfänger mehr. Heute weiß ich deutlich mehr über eine Ecke des deutschen Rechts als noch vor einem Monat. Nebenbei habe ich noch eine Menge gelernt über aktuelle Web-Entwicklung und wie man LLMs viel effektiver nutzen kann.
LLMs benötigen für größere Projekte weiterhin eine aktive Steuerung und Überwachung durch den Nutzer. Der Nutzer muss dazu nicht vollständig mit dem Sachgebiet vertraut sein, aber über eine Portion Skepsis verfügen. Damit lässt sich das LLM zu tieferen Recherchen und längerer Reflexion bringen. Als Beispiel: Man muss nicht einschätzen können, ob “Forderung” oder “Prozessrechtsverhältnis” die bessere Abstraktion ist, aber man muss die Frage stellen, ob die aktuelle Modellierung noch adäquat ist. Erfahrung mit Software-Entwicklung generell hilft ebenfalls dabei, das LLM zu dirigieren: Ab welcher Stufe Automatisierung sinnvoll wird, wann ein Refactoring ansteht, und ob sich das Projekt in die richtige Richtung entwickelt waren aktive Nutzerentscheidungen.
Bemerkenswert war der vielschichtige Einsatz von LLMs. Claude war nicht nur Sparringspartner beim Design und geduldige Quelle für die Erklärung juristischer Details, Planer komplexer Änderungen, sondern auch der fast ausschließliche Schreiber des gesamten Codes. Zusätzlich ist die Geschwindigkeit der Entwicklung beachtlich. Noch vor wenigen Monaten (Feb 2025) war Vibe-Coding kein etablierter Begriff. Heute ist es schon (fast) selbstverständlich, dass Claude ein Programm schreibt, um eine zweite Claude-Instanz aufzurufen, damit eine dritte Claude-Instanz über die Ergebnisse reflektieren kann.
Das ganze Projekt klingt nach Arbeit. War auch Arbeit. Hat trotzdem viel Spaß gemacht.
Der Rechner berechnet Kostentragungsquoten, Gerichts- und Anwaltsgebühren, Erstattungssalden und Vollstreckbarkeitsklauseln für deutsche Zivilverfahren nach §§ 91 ff. ZPO. Er verarbeitet Klagen, Widerklagen, Drittwiderklage, Gesamtschuldner, Hilfsaufrechnungen, Teilrücknahmen, Erledigungen, Berufungsverfahren, vorgerichtliche Mehrfachvertretungen, Vergleiche. Über 1000 automatisierte Tests, 47 geprüfte Praxisfälle, aktuell keine bekannten offenen Fehler.
Bewusste Grenzen bleiben: Die Engine rechnet nicht für zweistufige
Klagen mit instanzweise verschiedenen Streitwerten, für bestimmte
beidseitige § 92 II-Konstellationen oder für Fälle, in denen die
juristische Literatur uneins ist. Diese Grenzen sind dokumentiert und
explizit — die Engine wirft lieber eine EngineLücke als
still eine fragwürdige Antwort zu liefern.
Die initiale These hält: Ein juristischer Laie kann mit Hilfe von Claude etwas Nützliches bauen. Aber was „nützlich” bedeutet, hat sich über das Projekt geschärft. Der Rechner ist ein Buchhaltungswerkzeug, kein Rechtsgutachten. Er reduziert alles auf eine Primitive: mit wie vielen Euro unterliegt jede Partei? Der Rest — Quoten, Tenor, Erstattungssaldo — ist Arithmetik. Die juristische Wertung (§ 91? § 92 I? Geringfügig?) trifft der Mensch; der Rechner rechnet das Ergebnis durch.
Das ist weniger als man sich vielleicht erhofft. Und mehr, als man am Anfang erwartet hätte.