There is a simple idea behind the recent excitement around vibe coding: once AI moves beyond code suggestions and starts making changes across a codebase, running tests, iterating, and shipping, it is no longer acting passively. It is acting like a developer.
That has an important consequence for enterprise automation.
Simply put, if your platform was not built for developers, it was not built for AI agents, either.
Camunda is a natural fit for teams exploring vibe coding. Whether the industry calls it vibe coding, agentic coding, or something else is secondary. The real question is more simple: When an AI agent builds a process automation solution, what interfaces does it actually use?
The answer won’t be the browser UI. It uses the CLI, the REST APIs, the SDKs, the documentation, the test framework, and the source repository. In other words, it uses the same interfaces professional developers use.
That distinction matters.
Vibe coding is becoming agentic coding
When Andrej Karpathy coined the term vibe coding in February 2025[1], he described a new way of building software: expressing intent in natural language and letting AI handle the coding. Since then, the pattern has matured. What many teams are now doing is better described as agentic coding: AI agents analyzing codebases, making coordinated changes, running tests, observing failures, and iterating toward a working result.
Same direction. Higher stakes.
For process automation, the implication is straightforward. If an AI agent is going to build something useful, it needs programmatic access to the platform it is building on. If the primary interface is still a human-centered GUI, the agent is forced into an awkward approximation of development rather than development itself.
What this looks like in practice
A concrete example helps.
In March 2026, I built a complete agentic orchestration scenario (a concert assistant) using an AI coding agent and a terminal. No visual modeler. No click-driven setup. Just code, process definitions, workers, deployment, and iteration.
The result included Ticketmaster and Spotify matching, a WhatsApp AI conversation agent, webhook correlation, and five job workers. It was deployed 13 times without ever opening the Modeler.
What made that possible was not a special “AI mode.” It was the fact that Camunda exposes the interfaces developers need:
- Full REST APIs to deploy, run, inspect, and debug processes
- The
c8ctlCLI for cluster management from the terminal - A Docs MCP server that provides live, authoritative product context to the coding agent
That is the key point. Camunda does not need to be retrofitted for AI-driven development because the platform was already built around programmatic access.
Open by design, agentic by nature
Agentic coding succeeds when two things are true.
- First, the platform offers the right interfaces: open, stable, scriptable APIs and tools that an agent can use reliably.
- Second, the agent has the right context: accurate documentation, conventions, and runtime feedback so it can build correctly instead of guessing.
This is where many low-code platforms run into problems. They were designed primarily around a visual authoring experience for humans. Their APIs often exist, but they are secondary. Their automation surfaces are frequently shaped by the GUI rather than the other way around.
Camunda was built differently. The APIs are not an afterthought. The platform was designed for professional developers who need to integrate systems, orchestrate long-running processes, manage failures, and operate at scale. The UI matters, of course, but it sits on top of a developer-first foundation of open standards.
That turns out to be exactly what AI agents need as well.
What pro-code means for AI agents
When an AI agent builds on Camunda, it finds a set of capabilities that map naturally to how agentic coding actually works.
1. A CLI it can script
`c8ctl` gives an agent a clean command surface for deployment, cluster interaction, and runtime inspection. That means the agent can work from the terminal, which is still the most natural operating environment for code-centric automation.
2. SDKs in the languages agents already use
Java, Node.js, Python, and C# matter here. Agents code in real languages. They also use real frameworks like LangChain, Spring AI, and LangChain4j. They produce real artifacts, not click-throughs. They work best when they can use established frameworks and libraries in real programming languages.
3. Context and runtime through MCP
This is where things get especially interesting. Camunda provides two distinct MCP-based capabilities:
- Docs MCP gives an AI coding agent live documentation context while it builds. That reduces guesswork and avoids stale assumptions about APIs or features.
- Cluster MCP Server gives agents runtime access to a live Camunda cluster. Agents can inspect process instances, create instances, resolve incidents, search user tasks, and more.
Together, these provide both build-time knowledge and runtime interaction. That combination is powerful because it closes the loop between authoring and operating—a combination no low-code platform can replicate, because first-class open APIs have to exist before MCP can surface them.
4. A project context layer
High-quality agentic coding does not start from a blank prompt. Teams provide project-level instructions that encode BPMN conventions, connector usage, deployment patterns, and architectural constraints. Whether this lives in AGENTS.md, CLAUDE.md, or another format, the principle is the same: start the agent with the right local context.
5. A test framework agents can use
This is nonnegotiable.
Camunda Process Test gives agents the same kind of feedback loop human developers rely on. The agent can write a test, run it, see what failed, change the implementation, and rerun. That is how you move from plausible output to reliable output.
Without that loop, the agent is generating process automation blind.
6. GitOps-native deployment
In a production setting, the output of the agent must remain a normal software artifact: versioned, reviewable, testable, and deployable through CI/CD. Camunda fits that model. Workers, process definitions, and supporting assets move through environments the same way any serious engineering artifact does.
That is exactly what enterprises need if they want AI-assisted development without bypassing governance.
One investment, two payoffs
There is also a broader strategic point here.
The work required to make a platform better for developers is very often the same work required to make it better for AI agents:
- Better APIs
- Better documentation
- Better testability
- Better visibility into runtime behavior
- Better metadata around connectors and process state
These are not separate investment tracks. They reinforce each other.
That means organizations do not need one platform for human builders and another for AI builders. They need a platform that treats software development as the primary interface, because that benefits both.
Immediately, human teams move faster.
Over time, AI agents become more capable because they inherit the same well-designed interfaces.
Why this matters
A lot of AI-generated automation looks impressive in a controlled environment. That is not the same as being production-ready.
Enterprise processes are long-running, stateful, exception-heavy, and deeply connected to compliance, auditability, and customer outcomes. Loan origination, claims processing, fraud detection, or medication workflows are not just chains of API calls. They involve durable state, human oversight, external events, and business-critical recovery paths.
That is why the “vibe coding versus serious coding” debate misses the point. The real question is whether the underlying platform can support serious outcomes when the implementation happens through AI.
An agent building on a lightweight automation tool may produce something that looks good in a demo. However, an agent building on Camunda can produce something designed to survive production reality: retries, incidents, long-running execution, human-in-the-loop checkpoints, and governed orchestration across systems and agents.
The next step: processes as MCP tools
This direction becomes even more compelling as the platform evolves.
With Camunda 8.10, the next logical step is exposing deployed BPMN processes as MCP endpoints. At that point, a process is no longer just something your application invokes internally. It becomes a discoverable tool that external AI agents can call through a standard protocol.
That closes an important loop:
- Agents use Docs MCP to understand how to build on Camunda.
- Agents use Cluster MCP to interact with running systems.
- Your own deployed processes become callable tools for other agents.
This is the shift from an orchestration platform to agentic infrastructure. Once that happens, your Camunda environment is not just a place where developers model processes. It becomes a governed execution layer that AI systems can discover, invoke, and rely on.
And again, that is only possible because the platform was open and API-first from the beginning.
What teams should do now
For teams adopting agentic coding seriously, the practical guidance is fairly simple:
- Point your coding agents at authoritative product context.
- Give them the CLI and programmatic interfaces they need.
- Encode project conventions explicitly.
- Require tests.
- Treat the output as production software, not as a one-off automation artifact.
That approach aligns naturally with how Camunda is built.
The larger takeaway
AI agents are not replacing software engineering. They are changing how software engineering is performed. That makes architecture matter even more.
The platforms that will benefit most from agentic coding are the ones that already respect the fundamentals: open interfaces, strong developer tooling, executable models, durable runtime behavior, and clear operational visibility.
That is why I believe this moment favors pro-code platforms. Not because visual tooling is unimportant. But because when the builder is an AI agent, the system still has to be built the way serious software is built.
And that has been Camunda’s design philosophy from the start.
[1] Karpathy, A. (2025, February), Post on X introducing the term “vibe coding”
Start the discussion at forum.camunda.io