Vibe Coding oder strukturierte Automatisierung? Ein Entscheidungsrahmen für Anwälte

Anwälte und Anwältinnen haben inzwischen zwei Wege, sich ein internes Tool zu bauen, ohne auf die IT warten zu müssen. Man beschreibt es einem Vibe-Coding-Tool und bekommt noch am selben Nachmittag funktionierenden Code zurück, oder man baut es in einer strukturierten Automatisierungsplattform, die genau für diese Art von Arbeit gemacht ist. Beide Wege starten mit demselben Ausgangspunkt: Man beschreibt in normaler Sprache, was man bauen möchte, und etwas übersetzt die Worte in digitale Logik.

An dieser Stelle lohnt sich Präzision, denn der Begriff “Vibe Coding” wird oft ungenau verwendet. In seiner üblichen Bedeutung schreibt eine KI rohen Code, Python, JavaScript, je nachdem, was das jeweilige Tool bevorzugt, der anschließend eigenständig läuft, ohne dass ihn jemand Zeile für Zeile liest. Das unterscheidet sich davon, was eine Plattform wie e! by Lexemo mit demselben Eingabetext in normaler Sprache macht: Statt Code, der unsichtbar im Hintergrund läuft, entsteht ein visueller Workflow, den man öffnen, Schritt für Schritt nachvollziehen und an jemand anderen übergeben kann. Derselbe gesprächsbasierte Ausgangspunkt, aber ein anderes Ergebnis am Ende.

Die eigentliche Frage ist nicht, welcher Ansatz besser ist. Sondern welcher zur konkreten Aufgabe passt, und ob es möglich ist, die Geschwindigkeit des einen mit der Sicherheit des anderen zu verbinden. Genau diese Entscheidung fällt vielen Anwältinnen und Anwälten gerade schwer, meist weil es schwierig ist, mit dem Tempo der technologischen Entwicklung mitzuhalten, und weil niemand dokumentiert hat, wie man diese Entscheidung gut durchdacht trifft.

Wie sie sich tatsächlich unterscheiden: Vibe Coding vs. Automatisierungssoftware

Ohne das Marketing drum herum liefern beide Ansätze dasselbe Grundmuster, wenn man einen juristischen Prozess automatisieren will: einen Workflow mit einem Auslöser, etwas Bedingungslogik und einer Aktion. Eine neue Anfrage kommt herein, wird gegen eine Regel geprüft und landet bei der richtigen Person. Der eigentliche Unterschied zeigt sich nach dem ersten Einsatz des Tools.

Ein vibegecodetes Skript liegt meist als generierter Code auf dem Laptop einer einzelnen Person. Es gibt keine Versionshistorie oder ein Protokoll darüber, was das Skript tut und warum. Es sei denn, man richtet sich dies selbst ein. Wie könnte außerdem ein Kollege das Tool übernehmen, wenn die ursprüngliche Person das Team verlässt? Das ist so lange kein Problem, bis jemand anderes als der ursprüngliche Ersteller mit dem Tool arbeiten, es warten oder bei einem Audit erklären muss.

Eine Automatisierungs-Software verwandelt dieselbe Beschreibung in normaler Sprache in eine Struktur, die man einsehen kann: einen sichtbaren Ablauf, ein Änderungsprotokoll und eine klare Zuständigkeit. Man verzichtet nicht auf die Geschwindigkeit, in der man beschreibt, was man will. Man verzichtet auf die Annahme, dass Geschwindigkeit das Einzige ist, worauf es ankommt.

Nebeneinandergestellt sind die praktischen Unterschiede kleiner, als der übliche Rahmen es vermuten lässt:

	Vibegecodetes Skript	Strukturierte Automatisierungsplattform
Zeit bis zur ersten funktionierenden Version	Minuten bis Stunden	Minuten bis Stunden
Versionshistorie	Nur, wenn selbst eingerichtet	Standardmäßig vorhanden
Protokoll über Änderungen und deren Gründe	Standardmäßig nicht vorhanden	Standardmäßig vorhanden
Wer es warten kann, wenn die erstellende Person geht	Wer den generierten Code lesen kann	Wer den Workflow lesen kann
Verhalten bei geänderter Datenstruktur	Scheitert unbemerkt, sofern keine Prüfung eingebaut wurde	Meldet sich zur Prüfung, je nach Konfiguration
Am besten geeignet für	Einmalige, risikoarme Tools mit einer verantwortlichen Person	Wiederkehrende, compliance-nahe Workflows mit mehreren Beteiligten

Die erste Zeile wird meist falsch eingeschätzt. Vibe Coding ist nicht schneller als eine strukturierte Plattform, beide starten mit demselben Prompt in normaler Sprache. Der eigentliche Unterschied zeigt sich in allem, was passiert, nachdem die erste Version funktioniert.

Wann Vibe Coding für Anwältinnen und Anwälte die richtige Wahl ist

Für schnelle, einmalige Aufgaben ist Vibe Coding tatsächlich das bessere Werkzeug. Ein Skript, das einen einzelnen CSV-Export umformatiert. Ein Rechner, den man zweimal nutzt, bevor sich der zugrunde liegende Prozess ohnehin ändert. Ein Prototyp, mit dem man testet, ob eine Idee überhaupt tragfähig ist, bevor sich jemand zur Wartung verpflichtet.

In diesen Fällen zählen niedriges Risiko und schnelles Iterieren mehr als ein Änderungsprotokoll, das ohnehin niemand je einsehen wird. So etwas auf einer strukturierten Plattform zu bauen, wäre nicht falsch, nur mehr Aufwand, als die Aufgabe verlangt.

In unserem früheren Beitrag zu Vibe Coding im Legal Tech haben wir uns bereits damit befasst, wie einzelne Anwältinnen und Anwälte solche Tools auf eigene Faust bauen, und welche Risiken entstehen, wenn die Struktur fehlt.

Wann Vibe Coding nicht die richtige Wahl für Ihre Rechtsabteilung ist

Die Rechnung kippt, sobald das Tool etwas mit echten Konsequenzen berührt. Ein paar Fragen trennen zuverlässig ein Wegwerf-Skript von etwas, das wie Infrastruktur behandelt werden sollte:

• Wird sonst noch jemand das nutzen, und wird es in sechs Monaten noch im Einsatz sein?
• Verarbeitet es Mandanten- oder Falldaten oder etwas, das einer Compliance-Pflicht unterliegt?
• Bleiben Fehler eine Weile unbemerkt?
• Ist es jedermanns Problem und niemandes Aufgabe, wenn das Tool ausfällt?

Ein Tool-Skript, bei dem die meisten dieser Fragen mit Ja beantwortet werden und das weder Versionshistorie noch klare Zuständigkeiten hat, funktioniert meistens nur bis zum ersten Stolperstein gut. Dann erinnert sich niemand mehr daran, wer es aufgesetzt hat oder warum es jetzt nicht mehr funktioniert.

Wer jetzt denkt, die letzten Sätze wären an den Haaren herbeigezogen und eine Ausnahme: Eine KPMG-Umfrage unter 715 Unternehmen in Europa, dem Nahen Osten und Afrika ergab, dass 73 Prozent der Low-Code-Planer und 65 Prozent der aktuellen Nutzer noch keine Governance-Regeln für ihre gebauten Tools festgelegt haben. Der Großteil der Branche baut schnell und kümmert sich, wenn überhaupt, erst später um Governance.

Ein Praxisbeispiel: Legal Intake auf zwei Wegen

Angenommen, ein Rechtsteam erhält laufend NDA-Anfragen aus dem operativen Geschäft, und jemand baut einen Intake-Router: gegenseitige NDAs gehen an eine Vorlage und werden automatisch versendet, einseitige NDAs von neuen Vertragspartnern werden zur Prüfung markiert. Ein kleiner, klar umrissener Prozess. Genau die Art von Aufgabe, die beide Automatisierungsansätze problemlos bewältigen.

Als vibegecodetes Skript umgesetzt, läuft das Ganze vielleicht als kleines Programm auf dem Laptop einer Person, ausgelöst durch eine geplante Aufgabe, die eine geteilte Tabelle liest und Vorlagen-E-Mails versendet. Monatelang funktioniert es einwandfrei. Dann benennt jemand aus einem völlig unabhängigen Grund eine Spalte in der geteilten Tabelle um, und das Skript beginnt, die falschen Zeilen zuzuordnen. Drei Wochen lang gehen NDAs, die eigentlich zur Prüfung vorgesehen waren, automatisch unterschrieben hinaus, weil keiner auf diesen Fehler geachtet hat und die Person, die das Skript geschrieben hat, inzwischen die Abteilung gewechselt hat.

Auf einer strukturierten Plattform gebaut, ist dieselbe Routing-Logik von Anfang an für mehr als eine Person sichtbar. Ändert sich die Struktur der Tabelle, meldet der Workflow entweder einen Fehler, weil die erwarteten Felder nicht mehr passen, oder jemand entdeckt die Abweichung beim Blick ins Änderungsprotokoll, bevor sie ein echtes NDA erreicht. Der Unterschied liegt nicht darin, dass eine Version klüger wäre. Er liegt darin, dass in einem Ansatz vorgesehen ist, dass Fehler sichtbar werden, bevor er zum Compliance-Problem wird.

Beide Ansätze eignen sich gleichermaßen, um eine erste Version zu erstellen. Der feine Unterschied zeigt sich in dem, was nach dem ersten Monat passiert.

Genau in dieser unbequemen Lage stecken viele Legal-Operations-Teams. Man möchte die Unmittelbarkeit, einen Prozess einfach zu beschreiben und ein fertiges Tool zurückzubekommen, kann sich aber keinen Compliance-Fehler leisten, der drei Wochen lang unbemerkt bleibt. Die beiden Ziele stehen eigentlich nicht im Widerspruch zueinander, sie wurden bisher nur meist als Paket verkauft: entweder die gesprächsbasierte Geschwindigkeit oder die Sicherheit in Form von bspw. Änderungsprotokollen, aber nicht beides zugleich.

Vom Entweder-oder zum hybriden Ansatz

Damit ist Vibe Coding keineswegs aus dem Rennen. Es ist die Erkenntnis, dass Geschwindigkeit und Beständigkeit keinen Kompromiss erfordern müssen, sie wurden bisher nur selten in ein und demselben Werkzeug zusammengeführt. Eine neuere Generation juristischer Workflow-Plattformen schließt genau diese Lücke, indem sie den gesprächsbasierten Ausgangspunkt von Vibe Coding beibehält, aber daraus einen strukturierten, prüfbaren Ablauf statt eines einmaligen Skripts erzeugt.

Die AutoMate-Funktion von e! by Lexemo funktioniert genau so. Man beschreibt den Prozess (etwa eine NDA-Prüfung, ein Anfragen-Routing oder einen Genehmigungsablauf) in normaler Sprache, und die Plattform macht daraus einen visuellen Prozess statt generierten Code auf dem Laptop einer einzelnen Person. Lexemo bezeichnet diesen Ansatz in e! auch als Vibe Coding, weil es genau das ist: der gesprächsbasierte Einstiegspunkt mit einem nachvollziehbaren, kontrollierbaren Ergebnis. Was den Workflow darüber hinaus handhabbar macht, ist eine separate Funktion namens “Historie”: diese Funktion speichert im Zeitverlauf Schnappschüsse der Automation, während sie gebaut und bearbeitet wird. Wenn eine Person heute mit einem Bot beginnt und ihn an eine Kollegin übergibt, die ein paar Tage später weiter daran arbeitet, ist “Historie” das, womit beide zurückblicken und nachvollziehen können, was wer wann geändert hat. In der konkreten Bearbeitung wird diese Historie granularer: Man sieht, welche Nodes hinzugefügt, geändert oder gelöscht wurden. Einen Bot zu bauen schafft man weiterhin an einem Nachmittag.

Wer Plattformen dieser Kategorie breiter vergleichen möchte, findet in unserem Vergleich der Legal-Automation-Tools e! neben vier weiteren Anbietern anhand derselben Kriterien: Eigenverantwortung, Dokumentenautomatisierung, Integrationen, Verlässlichkeit und Hosting.

Die Entscheidung für die nächste Automatisierung

Bevor Sie das nächste interne Tool bauen, prüfen Sie es anhand der Fragen oben, statt automatisch den Ansatz vom letzten Mal zu wiederholen. Ein Wegwerf-Skript und ein wiederkehrender, mandantennaher Workflow sind nicht dieselbe Art von Problem. Beide gleich zu behandeln führt entweder zu einem verkomplizierten Rechner oder zu einem unbeaufsichtigten Skript, das im Hintergrund einen echten Prozess steuert.

Die Teams, die von diesem Moment am meisten profitieren, entscheiden sich nicht für eine Seite. Sie werden gut darin, zu erkennen, in welche Kategorie eine bestimmte Automatisierung fällt, und wählen das passende Werkzeug für die jeweilige Aufgabe.

Häufig gestellte Fragen

Ist Vibe Coding für die juristische Praxis sicher genug?

Das hängt davon ab, was das Tool tut. Für risikoarme, einmalige Aufgaben ist Vibe Coding gut geeignet: ein Skript, das eine Tabelle einmalig umformatiert, ein interner Rechner, den man zweimal nutzt. Riskant wird es, sobald das Tool mit Mandantendaten arbeitet, dauerhaft und unbeaufsichtigt läuft, oder länger bestehen muss als die Person, die es gebaut hat, im Unternehmen bleibt.

Was unterscheidet ein Tool, das durch Vibe Coding gebaut wurde, tatsächlich von einem Tool in einer Automatisierungs-Plattform?

Beide können mit demselben Prompt starten: den Workflow in normaler Sprache beschreiben. Der Unterschied liegt im Ergebnis. Ein vibegecodetes Tool ist meist generierter Code ohne eingebaute Versionshistorie oder Änderungsprotokoll. Eine strukturierte Plattform macht aus derselben Beschreibung einen Workflow, den man einsehen, bearbeiten und an Kolleginnen und Kollegen übergeben kann, inklusive Protokoll zu Änderungen.

Wie entscheide ich, ob eine juristische Automatisierung eine strukturierte Plattform braucht?

Fragen Sie: Wer außer mir nutzt die Automation noch? Wie häufig läuft sie? Was passiert, wenn etwas schief läuft? Wer ist verantwortlich, wenn der Bot ausfällt? Lauten die Antworten “nur ich”, “gelegentlich”, “nichts Ernstes” und “niemand Bestimmtes”, reicht Vibe Coding. Läuft das Tool wiederkehrend, verarbeitet es Mandanten- oder Falldaten, oder muss es prüfbar sein, sollte es wie Infrastruktur behandelt werden, nicht wie ein Skript.

Bedeutet die Nutzung einer Automatisierungssoftware den Verzicht auf die Geschwindigkeit von Vibe Coding?

Nein, genau das ist der Sinn von Plattformen, die auf demselben Prinzip aufbauen. Die AutoMate-Funktion von e! by Lexemo lässt Sie einen Workflow in normaler Sprache beschreiben, genau wie bei einem Vibe-Coding-Tool, das Ergebnis ist jedoch ein strukturierter, bearbeitbarer Ablauf statt eines einmaligen Skripts.

Wie verbreitet ist es, dass Teams Automatisierungen ganz ohne Governance bauen?

Sehr verbreitet. Eine KPMG-Umfrage unter 715 Unternehmen in Europa, dem Nahen Osten und Afrika ergab, dass 73 Prozent der Low-Code-Planer und 65 Prozent der aktuellen Nutzer noch keine Governance-Regeln für ihre gebauten Tools festgelegt haben. Unregulierte Automatisierung ist kein Ausnahmefall, sondern eher der Standard (gerade auch durch die Nutzung von “Schatten-KI”). Genau deshalb lohnt es sich, diese Entscheidung bewusst zu treffen und entsprechend zu kommunizieren.