Let’s be honest, many developers roll their eyes when they hear low code. It’s often dismissed as—excuse my German—klicki-bunti: shiny tools that promise automation without acknowledging the underlying complexity. I used to feel the same way. I once even coined the term “death by properties panel.”

But the reality is that low code is inevitable. Not because it’s trendy, but because organizations simply need to automate much much more than traditional IT can deliver. Face it, most IT teams already run at capacity, yet business keeps generating new requirements. And it’s not about adding “golden tabs”—it’s about staying in business by adapting to changing market conditions every single day. If IT doesn’t offer a sustainable path making the required changes, businesses need to (and will) find ways—just without involving IT.

You can find clear signs of this trend, for example in Gartner data:

“Business technologists, formerly ‘shadow IT,’ now account for 41% of employees who conceptualize, design, develop, test, and produce technology.” (Gartner: “Top Strategic Technology Trends for 2022: Hyperautomation”)

This data is from 2022, but newer reports show that this number increases:

“47% of boards have moved digital-business budgets into business functions (away from a central IT budget,” and “81% of IT leaders say business technologists are more involved in technology innovation now than two years ago.” (Gartner: “Practice Consensus Decision Making to Improve the Quality of Software Investment Strategies”, 2024)

So, should IT just surrender and let the business shape automation on its own? Probably using a wild mix of low code tools? I don’t think this is a good idea, and the countless shipwrecked low code approaches and chaotic RPA bots catastrophes we see with some of our customers prove that point.

Instead, we need a more nuanced picture to low code, where IT and business work together, each contributing their strengths.

And just to mention it briefly: “vibe coding” isn’t yet relevant here. It won’t reach business departments anytime soon, as it still requires a high level of technical understanding.

A concrete example: opening a bank account

Let’s look at this through the lens I know best: process orchestration. Think of a typical bank account opening process. Without orchestration, it’s usually a chaotic mesh of point-to-point integrations:

• Collecting customer data
• Running credit and KYC checks
• Generating an account number
• Updating multiple core systems
• Sending welcome letters
• …

It works, but it’s brittle and opaque. A classic spaghetti integration.

Now, let’s introduce process orchestration. Suddenly, the entire flow becomes explicit, visible, and controllable. An orchestration engine (like Camunda) coordinates the steps end-to-end, manages long-running states, and provides operations tooling out of the box.

That’s not magic—it’s solid engineering.

If you model the process in BPMN, you might feel you’re already halfway into low-code territory. It’s a graphical notation, after all. But in practice, BPMN is also some kind of code, focusing on long-running process flows, but with a visual representation.

In Camunda, for example, you can do everything in code if you want. Write your integrations in Java, embed it in your CI/CD pipeline, unit test it… the whole software engineering toolbox applies.

At the same time, you’re using an orchestration engine to not reinvent the wheel for already solved problems. It gives you built-in persistence, retries, visibility, and much more. You wouldn’t write your own database, either. This is about reusability, which makes projects faster, cheaper, and increases quality at the same time.

So why not increase reusability even more?

Where pro code meets low code

In the above Java code, you could see that a REST endpoint is called. But not every process step needs to be implemented in Java. Sometimes, it’s faster to use a prebuilt connector.

For example, consider Camunda’s out-of-the-box REST connector. No need to reinvent HTTP handling, which can get hairy like when a multistep OAuth handling is needed. Instead you can just configure the connector in the BPMN model and go.

If you need something more specific, build your own connector on top (or choose one from the Marketplace, where Camunda, its community, and their partners contribute connectors). That might be a small Java component that encapsulates a business-specific integration—for instance, calling your core banking platform or CRM. Or it could be a preconfigured REST connector with all the details baked in: endpoints, payloads, retry logic.

The important thing is that you’re not forced into one way of working. Developers can stay in code, business technologists can work with prebuilt connectors, and both can reuse each other’s work. It’s a layered system—composable, flexible, and scalable across teams. You can go as deep or as shallow as you need with:

• Pro code: Write your own integration, for example in Java.
• Mid-code: Configure an existing protocol connector e.g. for REST.
• Low code: Reuse a prebuilt system connector, e.g. for Twilio, as SaaS service that can send SMS. Under the hood, REST is used.
• No code: Stitch together curated, easy-to-configure connectors, no programming needed. An example could be an SMS connector, where under the hood Twilio is used.

This multilayer coding experience is the real sweet spot. It enables reuse, accelerates development, and makes process automation accessible to nondevelopers—without locking engineers out!

I’ve focused on connectivity so far. But of course the same multilayer approach applies to other parts of a solution you need to build. Take the oft-referenced employee experience, where you want to push a task to a human who uses a task form to complete their work. Camunda provides a built-in form builder that lets you drag and drop form elements and bind them to your process data, including externally managed documents. It’s straightforward to use, even for nontechnical folks.

But you can also go even more low code by plugging in the app builder of your choice to create the frontend. Or you can go fully pro code and build a custom UI in whatever technology you prefer; React, for example. Thanks to its composability, Camunda supports all of these scenarios.

Now let’s look at why you actually want a single platform that covers the whole spectrum, from pro code to low code.

A practical model: red, yellow, green

In most organizations, automation use cases fall into three categories:

• Red: Mission-critical, complex, tightly governed (e.g., compliance-heavy core processes; in banking that could be money transfer or trading)
• Yellow: Medium complexity, moderate risk (e.g., customer onboarding, HR workflows)
• Green: Simple, local automations (e.g., marketing or finance self-service tasks)

IT naturally focuses on the red ones. They’re simply the most important. But that leaves yellow and green requests piling up in backlogs—especially as there are a lot of those use cases—the well-known long tail of automation projects. The business can’t wait, so they turn to “shadow IT” or buy the next no-code platform that promises salvation.

Unfortunately, many of those tools look great in demos but crumble when complexity or scale kicks in. A better approach is to build a platform that can tune in or out as much low code as a use case needs. This allows you to start with low code for speed, but then move to pro code when complexity demands it. And you can always mix both when that’s the pragmatic answer.

This flexibility even lets you evolve solutions as requirements change: a new regulation, forgotten requirements, or simply scaling pains if a business grows more successful.

The role of IT: from gatekeeper to enabler

If IT prepares reusable assets—connectors, templates, tested patterns, best practices, blueprints—they can empower business technologists instead of blocking them.

That’s the real win, a collaboration model that scales. IT focuses on building the foundation; business teams build on top. Everyone moves faster safely. And IT can finally get out of saying no to a clear enablement path where the business can self-service to some extent.

The pressure increases: AI and agentic orchestration

Solving this challenge is becoming more urgent by the day. With AI entering the scene, the number of automations we need to manage is about to explode. Processes that used to be too unstructured or too dynamic can now be orchestrated with the help of intelligent agents. In the last few months alone, we at Camunda have run more than 50 proof-of-concepts for agentic automation use cases with customers—some already running in production. All of them used AI to automate processes that would have been considered “unautomatable” just a few years ago.

The risk with the current AI wild west is obvious: business teams will start running their own isolated initiatives again, and we’ll end up with a patchwork of disconnected point solutions. That quickly turns into technical debt—or worse, it decreases the efficiency of your end-to-end processes.

Now is exactly the time to put a proper foundation in place so you can leverage AI cleanly and sustainably in your processes: business-led, backed by IT, and grounded in solid architecture. It’s not just about automating more—it’s about preparing your organization for the next generation of automation altogether.

Takeaway

Low code isn’t a toy anymore. It’s a spectrum. If we design our architecture to support both pro code and low code, with clear boundaries, shared foundations, and collaboration built in, we can automate responsibly and at scale. From a developer’s perspective, that’s not something to fear. It’s something to help shape.

Let’s stop debating whether low code is good or bad. The real question is: how do we do it right? To answer that, start experimenting. Try a multilayer coding approach and see how it feels to let business teams move faster without losing control. Maybe even explore Agentic Orchestration while you’re at it—it’s the next defining topic in automation.

So start now. Experiment with Camunda. Build a connector. Reuse one. And see how far you can take it. Then tell me how it went.