KI bedeutet Developer-Level – Agentic Coding braucht Pro-Code

Eine Weisheit aus „Vibe Coding“-Kreisen zum Thema Agenten: Sobald KI über Code-Vorschläge hinausgeht und Änderungen quer durch eine Codebase vornimmt, Tests ausführt, iteriert und ausliefert, agiert sie nicht mehr passiv. Sie agiert wie ein Developer.

Als Andrej Karpathy den Begriff „Vibe Coding“ im Februar 2025 prägte, beschrieb er einen neuen Weg, Software zu bauen: Intention in natürlicher Sprache ausdrücken und die KI den Code übernehmen lassen. Seither hat sich das Muster weiterentwickelt. Was viele Teams heute machen, lässt sich besser als Agentic Coding beschreiben: KI-Agenten analysieren Codebasen, koordinieren Änderungen, führen Tests aus, beobachten Fehler und iterieren auf ein funktionierendes Ergebnis hin.

Welche Schnittstellen ein Agent tatsächlich nutzt

Aber welche Schnittstellen nutzt ein KI-Agent tatsächlich, wenn er eine Lösung zur Prozessautomatisierung baut? Sicher nicht das Browser-UI. Er nutzt das CLI, die REST-APIs, die SDKs, die Dokumentation, das Test-Framework und das Source-Repository. Mit anderen Worten: dieselben Schnittstellen, die professionelle Developer nutzen.

Hands-on: Ein Konzert-Assistent, gebaut ohne Modeler

Ein Praxisbeispiel macht die Sache deutlich: Vor einiger Zeit habe ich einen Konzert-Assistenten gebaut, der mich über anstehende Shows informiert und Camunda für einen Ad-hoc-Subprozess nutzt. Nur mit einem KI-Coding-Agenten und einem Terminal – kein visueller Modeler, kein klickgesteuertes Setup. Nur Code, Prozessdefinitionen, Worker, Deployment und Iteration. Das Ergebnis: sechs Stunden Bauzeit, dreizehn deployte Versionen, ein laufendes agentisches System – ohne den Modeler ein einziges Mal zu öffnen.

Der Prozess startet wöchentlich per Timer oder on Demand. Er holt anstehende Konzerte in der Nähe über das Ticketmaster-API, zieht die gespeicherten Künstler aus Spotify und gleicht beide gegeneinander ab. Gibt es keine Treffer, beendet er sich sauber. Gibt es welche, übergibt er an den Konzert-Assistenten – einen KI-Agenten, der innerhalb eines Camunda-Ad-hoc-Subprozesses läuft.

Damit das Ganze funktioniert, hat die KI fünf Job Worker von Grund auf erstellt – je einen für das Abrufen der Konzerte, das Abrufen der Spotify-Daten, das Künstler-Matching, die Preisprüfung und die Buchung. Sie konfigurierte die vorgefertigten Connectors für das Senden von WhatsApp-Nachrichten und das Empfangen von Webhook-Antworten. Anschließend hat sie den AI-Agent-Connector mit System Prompt, User Prompt, Memory-Einstellungen und allen vier Tool-Definitionen verbunden. Auch das BPMN-Modell stammt von der KI – jede Form, jeder Pfeil, jede Layout-Entscheidung entstand mithilfe des quelloffenen bpmn-js-Renderers, um es darzustellen, zu inspizieren und zu korrigieren.

Der Agent führt einen echten Dialog per WhatsApp. Ihm stehen vier Tools zur Verfügung:

• Eine Nachricht senden und auf die Antwort warten
• Konzertdetails nachschlagen
• Ticketpreise prüfen
• Tickets buchen

Das erste Tool ist selbst ein kleiner Subflow – ein Service-Task, der die Nachricht sendet, gefolgt von einem Receive-Task, der auf die Webhook-Antwort wartet, bevor es weitergeht. Genau hier zeigt sich Camundas distinktivste Eigenschaft: Der Prozess erzwingt einen Schritt zwischen der Entscheidung des Agenten und seiner Aktion. Camunda orchestriert Agenten über zwei Muster – Outer Orchestration koordiniert Agenten, Menschen und Systeme über den End-to-End-Prozess, Inner Orchestration steuert, wie der einzelne Agent seine Entscheidungen ausführt. Dieser Ansatz der Inner Orchestration ist für Camunda-native Agenten in den USA zum Patent angemeldet.

Die gesamte Conversation-Loop, inklusive Memory und Kontext zwischen den Turns, wird vom Agenten verwaltet.

Warum es funktioniert hat

BPMN ist ein offener Standard, also konnte die KI Prozesse direkt lesen und schreiben. Vollständige REST-APIs erlaubten es ihr, allein aus dem Code heraus zu deployen, auszuführen und zu debuggen. Der gesamte Stack startet lokal in etwa zehn Sekunden. c8ctl – die Kommandozeile – ließ die KI das Cluster verwalten, Prozessinstanzen inspizieren und Deployments direkt vom Terminal aus erledigen. Und der Camunda Docs MCP Server gab Claude direkten Zugriff auf die Dokumentation als Live-Kontextquelle, sodass Dinge in Echtzeit nachgeschlagen werden konnten, statt aus den Trainingsdaten zu raten.

Speziell bei Camunda sind die Low-Code-Schicht und die Pro-Code-Schicht darunter dasselbe. Ein Connector ist keine Black Box – er ist einfach ein Job Worker, dasselbe Primitive, das Entwickler von Hand schreiben würden.

Pro-Code-Capabilities im Detail

Was im Konzert-Assistenten zusammenspielt, lässt sich verallgemeinern. Agentic Coding gelingt, wenn zwei Dinge zutreffen: Die Plattform bietet die richtigen Schnittstellen – offene, stabile, skriptbare APIs und Tools, die ein Agent verlässlich nutzen kann. Und der Agent hat den richtigen Kontext – korrekte Dokumentation, Konventionen und dauerhaftes Runtime-Verhalten sowie klare operative Sichtbarkeit. Es sind dieselben Fundamente, die Agentic Orchestration im Unternehmensmaßstab erst tragfähig machen.

CLI als skriptbare Befehlsoberfläche

Wer eine Plattform wie Camunda mit einem KI-Agenten steuern möchte, greift am besten auf ein Kommandozeilen-Interface zurück. c8ctl (ausgesprochen „Cocktail“) gibt einem Agenten eine saubere Befehlsoberfläche für Deployment, Cluster-Interaktion und Runtime-Inspektion. Damit kann der Agent vom Terminal aus arbeiten, was nach wie vor die natürlichste Betriebsumgebung für codezentrierte Automatisierung ist. Dabei coden Agenten in echten Sprachen – Java, Node.js, Python, C# – und nutzen echte Frameworks wie LangChain, Spring AI oder LangChain4j. Sie produzieren echte Artefakte, keine Klick-Konfigurationen, die sich nicht diffen, versionieren oder reviewen lassen.

Model Context Protocol: Kontext und Runtime für Agenten

Camunda bietet zwei eigenständige MCP-basierte Capabilities. Docs MCP gibt einem KI-Coding-Agenten Live-Dokumentationskontext beim Bauen. Das reduziert Rätselraten und vermeidet veraltete Annahmen über APIs oder Features. Der Cluster-MCP-Server ist direkt in den Orchestration-Cluster eingebaut und stellt den laufenden Cluster als KI-aufrufbare Tools bereit – ohne individuellen Integrationscode. Jeder MCP-konforme Agent kann searchProcessInstances, createProcessInstance, resolveIncident, searchUserTasks, getClusterStatus und mehr automatisch entdecken und aufrufen. Die Anbindung erfolgt über c8ctl mcp-proxy, der OAuth automatisch handhabt.

Zusammen geben die beiden Server Agenten sowohl das Wissen, um korrekt zu bauen, als auch den Runtime-Zugriff, um auf einem Live-System zu handeln – eine Kombination, die keine Low-Code-Plattform replizieren kann, weil offene First-Class-APIs existieren müssen, bevor MCP sie nach außen tragen kann.

Test-Framework als Feedback-Schleife

Camunda Process Test (CPT) ermöglicht echte Unit-Tests, Integrationstests und End-to-End-Szenariotests – dieselben Primitives, mit denen Agenten ihren eigenen Output validieren. Ein Agent kann einen Test schreiben, ihn ausführen, das Scheitern beobachten, den Code reparieren und erneut ausführen. Das ist die Feedback-Schleife, die Agentic Coding auf Produktionsqualität bringt. Plattformen ohne sie lassen Agenten im Blindflug. So gelingt der Übergang von plausiblem Output zu verlässlichem Output.

GitOps-natives Deployment

Vom Agenten gebaute Worker werden als Container-Images verpackt, gemeinsam mit Prozessdefinitionen und Tests gebündelt und unverändert vom Laptop über Staging bis in die Produktion über Standard-CI/CD deployt. Das gleiche Artefakt, das der Agent erstellt, läuft in der Produktion – keine Re-Konfiguration, keine Portal-Klicks dazwischen.

Warum Low-Code an dieser Stelle scheitert

Es liegt nahe zu meinen, Vibe Coding ließe sich gut mit Low-Code-Plattformen kombinieren. Aber diese wurden für eine menschliche UX entworfen – um Menschen schöne Drag-and-Drop-Erlebnisse zu bieten. Ihre APIs entstanden nach dem GUI, nachträglich aufgesetzt. Agenten, die darauf bauen wollen, stoßen gegen eine Wand: kein CLI, kein SDK, keine Test-Hooks, keine verlässliche Dokumentations-Oberfläche.

KI-Agenten funktionieren am besten, wenn sie Code direkt schreiben, Spezifikationen lesen, APIs aufrufen und in Terminals arbeiten können. Sie brauchen eine Plattform mit echten programmierbaren Fundamenten – offene Standards, vollständige APIs, ein ordentliches SDK und etwas, das sie tatsächlich steuern können. Bekommen sie stattdessen einen geschlossenen visuellen Builder ohne API-Oberfläche darunter, fehlt ihnen jeder Halt. So wird der Layer, der das Coden eigentlich erleichtern sollte, stattdessen zum Hindernis.

Fazit

KI-Agenten ersetzen keine Softwareentwicklung. Sie verändern, wie Softwareentwicklung ausgeführt wird. Damit zählt Architektur umso mehr.

Die Plattformen, die am meisten von Agentic Coding profitieren werden, sind jene, die die Fundamente bereits respektieren: offene Schnittstellen, starkes Developer-Tooling, ausführbare Modelle, dauerhaftes Runtime-Verhalten und klare operative Sichtbarkeit.

Am Ende gilt: KI ist ein Developer. Wer nicht für Developer gebaut hat, hat nicht für KI gebaut.