Coding agents didn't kill low code. They made it matter more.

The last few months have produced a confident new narrative: coding agents are so powerful that anyone can write code now—which means the era of low-code agent building is essentially over. If a non-developer can describe what they want in plain English and watch working Python materialize, why would they ever need a visual canvas?

It’s a clean argument. But it’s missing something important.

The shift is real—but so is what it created

Let’s give the argument its due. Coding agents have genuinely lowered the floor. Developers who once spent hours on syntax and scaffolding can now move at a different pace entirely. And people who never considered themselves builders—product managers, operations leads, finance analysts—are discovering they can construct working automations when an AI is translating their intent into code.

UiPath Chief Technology and Product Officer Raghu Malpani described this as a generational shift in how software gets built. Developers who once spent weeks or months building a single mission-critical automation can now deliver many times more in the same window. “Software just eats the world faster,” he put it simply. And as coding agents mature from handling small, discrete tasks to taking on complex features autonomously, that acceleration will compound.

That’s the acceleration story. But acceleration creates its own problems—and that’s where the low-code narrative gets more interesting.

The question isn’t who can build. It’s who can govern.

When more people can build agents, faster, enterprises don’t have fewer agents to govern. They have more. And most of the people accountable for those agents—the compliance officer, the operations manager, the department head who owns the process—cannot read Python.

This is the part of the conversation that gets skipped. The “low code is dead” argument focuses entirely on the build phase. It doesn’t account for everything that happens after an agent ships: the incident that surfaces at 2:00 am, the audit request that arrives six months later, the question of what exactly the agent was authorized to do and when that authorization was granted. When something fails in a process that spans multiple departments and systems, someone needs to understand it quickly. A visual process flow is something an ops manager, a compliance officer, or a business owner can actually read. Code is not.

The value of low code was never just about making building accessible. It was always about making processes legible to the full range of people who have a stake in them. That value doesn’t diminish as coding becomes easier. It compounds—because the population of agent builders is growing faster than the population of people who can audit their output.

Malpani named this directly: “I actually think that the value of low code increases in this world where somebody who doesn’t understand code can understand a low-code experience; to make sure that the English intent is translated into business logic in a visual way that they would understand.”

The visual canvas isn’t a training-wheels version of code. It’s a legibility layer—the artifact that makes an automated process comprehensible to the people responsible for it.

Complex processes need to be visible by design

There’s another dimension that holds especially at scale. For simple, single-task automations, the governance argument may feel abstract. But the complex process orchestration that large enterprises actually run—workflows that span multiple systems, multiple departments, multiple human decision points—is a different problem entirely.

Malpani made a point that gets to the heart of it: when it comes to complex multi-step processes, even experienced developers prefer a visual representation of the overall structure (even when the individual components are built in code). Visibility into what a process does, how it branches, and where humans are in the loop isn’t a concession to non-technical stakeholders. It’s a design requirement for anything running at enterprise scale.

There’s also a build-time dimension worth noting. Visual tooling can enforce constraints that code doesn’t catch until runtime. Design-time linting flags problems before deployment. Built-in guardrails shape what an agent is permitted to do before it ever goes near production. These aren’t features that only matter to non-coders. They matter to anyone accountable for what happens after an agent ships.

The false choice at the center of the debate

Here’s what actually makes this a false choice: on a modern business orchestration and automation platform, low code and code first aren’t competing entry points that lead to different destinations. They’re two doors into the same building.

A team can start in a visual, low-code canvas and move to code without losing anything—the logic, the structure, and the intent all carry forward. A developer who prefers working directly in code can still surface a visual process flow for review and approval. The question of which path to start on doesn’t force a permanent architectural decision or require anyone to start over.

That’s the premise that most of the “low code is dead” conversation misses. It treats these paths as either/or because that makes a cleaner argument. Enterprises building agents at scale can’t afford that framing.

The right question for teams building agents now

The right question isn't: should we go low code or code first? The right question is: does our platform support both—and can we govern everything that gets built, regardless of how it was built?

The enterprises that get there first won't be the ones that picked the right build path. They'll be the ones that made what they built understandable, governable, and visible to the people responsible for it.

The era of coding agents isn't ending low code. It's clarifying what low code was always for.

Not as an easier way to build, but as a way to understand, govern, and improve what gets built when software creation is no longer limited to developers.