Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten

Mit jedem großen LLM-Release wird AI merklich besser darin, BPMN zu generieren und zu bearbeiten. Mit einem soliden Setup (wie agent-skills, passenden Code-Beispielen und Guardrails) funktionieren einfache Änderungen an einem Prozess oft schon im ersten Versuch. Die technische Konfiguration stimmt, der Prozess ist von der Engine ausführbar.

Doch eine Ebene hinkt beharrlich hinterher: die visuelle. Ein Modell, das ein Agent bearbeitet, enthält häufig unsichtbare Elemente oder ein chaotisches Layout, weil der Agent nie sieht, was er gezeichnet hat.

Dieser Post zeigt den Loop, mit dem ich solche Modelle lesbar halte: erst die Probleme erkennen, dann beheben und am Ende die Checks erzwingen. Und darunter liegt eine größere Frage: Wenn AI nun gut genug ist, um einen Prozess fast im Alleingang zu modellieren, zu implementieren und zu prüfen, was sollte ein Mensch dann trotzdem nicht aus der Hand geben?

🤖 Warum sieht AI nicht, was sie zeichnet?

Bitten wir einen Agenten, einen Service Task zu einem Prozess hinzuzufügen oder eine Routing-Bedingung an einem Gateway zu definieren, ist das entstehende XML beim ersten Versuch immer öfter korrekt. Und trotzdem erzählt die Visualisierung oft eine andere Geschichte. Das Element ist technisch zwar da, aber auf dem Canvas ist es nicht sichtbar, überlappt mit seinen Nachbarn oder sitzt einfach schief. Der Prozess läuft, aber ein Mensch kann das Modell nicht einfach ansehen und verstehen. Und genau dieses Verständnis ist der Punkt: BPMN ist eine Notation für Business-IT-Alignment. Etwas, auf das sich beide Seiten tatsächlich einigen.

Warum zeichnet der Agent also immer wieder falsch? Standardmäßig arbeitet er nur auf Text und XML; ein visuelles Feedback fehlt ihm. Er kann nicht auf das gerenderte Diagramm schauen und bemerken, dass ein Element nicht gerendert wurde oder dass zwei Flows ein Label kreuzen. Er arbeitet blind.

🧩 Zwei Ebenen, zwei Fehler

Dieser blinde Fleck hat eine strukturelle Ursache. Laut der OMG-BPMN-2.0-Spezifikation trägt eine BPMN-Datei zwei unterschiedliche Arten von Informationen. Zum einen das semantische Modell: die Tasks, Events, Gateways und Sequence Flows, die festlegen, was der Prozess tatsächlich tut. Daneben liegt die BPMN-DI-Ebene (Diagram Interchange), ein separater XML-Block, der beschreibt, wie das Modell gezeichnet wird: die Position und die Bounds jedes Shapes, und die Waypoints der Verbindungen dazwischen.

Die Engine liest nur das semantische Modell, Menschen sehen nur die DI. Und genau da bricht es. Bearbeitet ein Agent das Modell, vermasselt aber die DI, läuft der Prozess einwandfrei weiter, während die Zeichnung fehlerhaft aussieht.

Zeigen wir es konkret an einem Beispiel: der Anmeldung für ein Membership-Programm eines Fahrrad-Shops, aus meinem easy-zeebe-Repo. Fast jeder Branch schließt mit einem End Event. Nur der Happy Path nicht: Nach Send Welcome Mail hört der Flow einfach auf.

Also bitten wir einen Agenten, eins hinzuzufügen. Im semantischen Modell ist das ein Einzeiler. Aber genau bei diesem können die Fehler auftreten – auf zwei typische Arten:

👻 Das unsichtbare Element

Der Agent fügt das End Event hinzu, gibt ihm aber nie ein BPMNShape. Der Branch ist vollständig, das Modell läuft, aber auf dem Canvas sieht Send Welcome Mail immer noch wie eine Sackgasse aus. Das neue Event wird schlicht nicht gezeichnet:

<!-- Semantic model: the new end event exists and completes the branch -->
<bpmn:endEvent id="endEvent_MembershipActivated" name="Membership activated" />

<bpmndi:BPMNDiagram id="BPMNDiagram_1">
  <bpmndi:BPMNPlane bpmnElement="miravelo-membership">
    <!-- A BPMNShape exists for the preceding Send Welcome Mail task... -->
    <bpmndi:BPMNShape bpmnElement="serviceTask_SendWelcomeMail">
      <dc:Bounds x="1110" y="290" width="100" height="80" />
    </bpmndi:BPMNShape>
    <!-- ...but there is NO BPMNShape for endEvent_MembershipActivated.
         Result: the event fires, but never appears on the canvas. -->
  </bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>

🌀 Das chaotische Layout

Diesmal bekommt das Event sogar ein Shape. Aber der Agent rät bei den Koordinaten und platziert es zu weit oben. Membership activated landet in der Ecke, deutlich verschoben gegenüber dem Task, zu dem es gehört. Das BPMN stimmt, das Bild nicht.

Um das zu lösen, betten wir den Agenten in einen Loop ein, den ein sorgfältiger Reviewer von Hand durchlaufen würde: erst das kaputte Layout erkennen, dann beheben, und am Ende einen Check in der Pipeline erzwingen, damit nichts nach main rutscht.

🕵️ Erkennen

Viele Probleme lassen sich mit festen, deterministischen Regeln festnageln. Fehlt einem Element seine DI? Trägt jeder Node ein Label? Hat jedes Element genau einen eingehenden Flow? Jede Frage ist ein klares Ja oder Nein. Das lässt sich direkt aus dem XML ablesen. Visuelles Verständnis braucht es dafür nicht.

Für solche Fälle können wir einen Linter nutzen. Und zum Glück gibt es einen schon, sogar Open Source: bpmnlint vom bpmn.io-Team. Er fängt Dinge wie fehlende Shapes und Überlappungen out of the box. Dank eines recommended-Presets bleibt eine minimale Config eine einzige Zeile, die ein Agent nach jeder Änderung laufen lassen kann:

{
  "extends": "bpmnlint:recommended"
}

Was die Defaults nicht abdecken, können wir mit eigenen Regeln ergänzen. Zwei habe ich selbst geschrieben: no-crossing-flows markiert Sequence Flows, die sich kreuzen, und flow-through-element einen Flow, dessen Pfad mitten durch ein Shape läuft, mit dem er nicht mal verbunden ist. Beide arbeiten rein mit der Geometrie des Modells, und beide hängen in der .bpmnlintrc, neben den geerbten Defaults.

Nicht alles lässt sich jedoch in eine Regel fassen. Wirkt der Happy Path prominent? Sind verwandte Aktivitäten sinnvoll gruppiert? Ist ein Label wirklich gut, nicht nur vorhanden? Dafür braucht es ein Auge. Ein multimodales LLM kommt dem schon nahe, aber nur, wenn es das Modell tatsächlich sehen kann. Also geben wir ihm die fehlende Hälfte des Loops: Wir rendern das Modell mit bpmn-to-image zu einem Bild und lassen es über das Bild urteilen, zusammen mit dem XML.

Damit das verlässlich wird, können wir das Review in einem agent-skill festhalten. Das LLM, das ihn ausführt, bleibt nicht-deterministisch, aber der Skill legt fest, wie jeder Check abläuft, sodass bei jedem Modell dieselben Schritte greifen.

Mein verify-model-visually-Skill macht genau das, und geht noch einen Schritt weiter: Ein einziger Aufruf verkettet beide Netze nacheinander, erst der Linter, dann das Augenpaar.

🔧 Beheben

Ein Detector ist noch keine Reparatur. Der Linter, der einen kreuzenden Flow erkennt, hat ihn nicht entkreuzt, und das LLM, das ein schwebendes Event entdeckt, hat es nicht verschoben. Irgendetwas muss die Änderung also noch vornehmen, und diese Arbeit teilt sich genauso auf wie das Erkennen: die mechanischen Fälle an ein Script, die subjektiven an die AI.

Die mechanischen Fälle sind reine Geometrie. Ein kreuzender Flow lässt sich gezielt umleiten, etwa mit dem ManhattanLayout von diagram-js. Ein verworrenes Modell lässt sich komplett neu layouten, etwa mit bpmn-auto-layout – beides, ohne den Prozess je zu verstehen.

Was jedoch nur subjektiv feststellbar ist, muss die AI beheben. Etwa, ob sich das Bild wirklich gut liest. Aus den Findings und dem gerenderten Bild verschiebt sie die Shapes und Waypoints, die das Script nicht richtig gesetzt hat, und rendert danach neu, um die eigene Arbeit zu prüfen.

Um beides zusammenzubringen, können wir wieder auf einen agent-skill setzen, der die Reihenfolge festlegt: erst der billige, deterministische Reroute, dann die AI, und ein volles Auto-Layout nur als letztes Mittel. Das ist die Aufgabe meines fix-model-layout-Skills. Angewendet auf mein Modell sitzt das End Event am Ende genau da, wo es hingehört:

🚧 Erzwingen

Beide Phasen helfen allerdings nur, wenn sie auch aufgerufen werden. Öffnet jemand einen Pull Request nach main, gibt es keine Garantie, dass die Modelle in Ordnung sind. Und sich darauf zu verlassen, dass ein Reviewer den Fehler bemerkt, reicht nicht: Ein Reviewer liest meist nur das Diff und schaut sich nicht zwingend das zugehörige gerenderte Bild an. Ein kaputtes Layout ist im Diff praktisch unsichtbar.

Also brauchen wir eine Ebene, die die Checks automatisch ausführt und den Merge blockiert, wenn etwas nicht stimmt. Eine CI-Pipeline ist diese Ebene. In meinem Beispiel-Repo läuft sie als GitHub-Actions-Workflow mit zwei Gates auf jedem Pull Request: Erst der deterministische Linter, und das AI-Review nur, wenn der Linter grün ist:

on:
  pull_request:
    paths: ['**/bpmn/*.bpmn']      # only when a model changed
jobs:
  lint-bpmn:                        # Gate 1 — deterministic geometry, blocks the PR
    # ... npm ci ...
    - run: npm run lint:bpmn
  visual-review:                    # Gate 2 — AI judgment
    needs: lint-bpmn                # runs only once the linter is green
    # ... claude-code-action runs verify-model-visually ...

Und über das reine Scheitern hinaus hinterlässt das Review einen Kommentar am Pull Request, der erklärt, was nicht stimmt:

Meine Haltung dazu: Ein deterministischer Linter, der den Merge blockiert, ist für mich gesetzt. Das AI-Review nehme ich dazu, aber ich lasse es nicht den Build scheitern. Sein Urteil kommt von einem LLM, bleibt also nicht-deterministisch, und die Pipeline wegen eines Checks rot zu schalten, der sich selbst widersprechen kann, fühlt sich wackelig an. Vorerst postet es seine Findings nur als Kommentar am Pull Request.

🔮 Was bedeutet das für BPMN?

Stellen wir uns jetzt ein Projekt vor, das stark auf AI setzt. Es übernimmt die komplette Arbeit des Modellierens und Implementierens und prüft dabei die eigene visuelle Arbeit. Ein menschlicher Touchpoint bleibt kaum noch übrig.

Darüber nachzudenken, lohnt sich. BPMN war nie nur ausführbarer Code. Es ist eine Methode für Business-IT-Alignment: ein Diagramm, das beide Seiten lesen und dem beide zustimmen. Lassen wir AI das Diagramm schreiben, prüfen und ausliefern, und liest es nie jemand, verschwindet dieses Alignment leise, selbst während der Prozess korrekt weiterläuft. Die eigentliche Frage ist dann nicht nur, welchem Zweck ein Modell noch dient. Sondern wer tatsächlich weiß, dass es stimmt, und wer noch das Wissen hat, einzugreifen, wenn es falsch ist.

Chris Banes nennt eine Version davon „the disappearing middle”: Geben wir genug der Arbeit ab, bekommen die Leute, die sich das Verständnis für ein kritisches Review erarbeiten würden, nie die nötige Routine. Wie er es formuliert: „if you cannot review the output with confidence, you should not delegate the work.” Und diese Zuversicht bleibt nicht bestehen, wenn wir alles abgeben.

Mein Fazit: Wir sollten trotzdem so viel wie möglich abgeben. Das Modellieren, die Implementierung, sogar die visuellen Checks der AI. Halten wir zu viel zurück, verlieren wir die Vorteile, die AI bietet. Aber wir dürfen es nicht blind tun. Wir müssen im Loop bleiben, bei jedem Schritt mitarbeiten und die richtigen Guardrails setzen. In gewisser Weise rücken wir dabei in eine begleitende, prüfende Rolle, statt in die eines reinen Umsetzers. Nur so behalten wir das Wissen und treffen die Entscheidungen. Genau die sollten wir nicht abgeben.

🎬 Fazit

AI ist inzwischen wirklich gut in der Logik eines BPMN-Prozesses. Wo sie noch stolpert, ist die visuelle Ebene: der Teil, den sie nie wirklich sieht und den auch ein Diff-lesender Reviewer übersieht. Diese Lücke zu schließen, braucht einen ganzen Loop, kein einzelnes Tool: erst das kaputte Layout erkennen, dann beheben und am Ende die Checks erzwingen.

Alle Bausteine, die Linter-Regeln, die beiden agent-skills und der CI-Workflow, liegen ausgearbeitet in easy-zeebe: ein Startpunkt zum Forken und Anpassen an die eigenen Modelle. Die agent-skills und Guardrails, die darunterliegen, sind das Thema meines Begleit-Posts. Der Loop selbst ist dabei der leichte Teil. Schwerer wiegt die Frage dahinter: bei den Entscheidungen zu bleiben, auch wenn das Tooling gut genug wird, um sie uns abzunehmen.

👉 Wo zieht ihr die Grenze? Schreibt es gern in die Kommentare.

This post was originally published in English on Medium.com.