It’s always surprising when the CEO of a low-code company tells you that low-code is becoming unnecessary.

Which wasn’t quite how Appian CEO Matt Calkins put it, of course.

His point was actually narrower and much more interesting — that as natural language becomes the easiest way to build applications, the drag-and-drop interfaces that once defined the low-code category start to matter much less.

But that what remains — the architecture underneath them — starts to matter much more.

Because Calkins’ argument is effectively that his company’s low-code interfaces were never Appian’s fundamental product, but just a set of contingent tools through which customers unlocked its deeper value — the process, data, integration, security, governance and runtime infrastructure it offered to power reliable enterprise applications.

And while AI may now make some of those tools obsolete, Calkins remains sanguine — because he also believes that AI cannot succeed without the more fundamental infrastructure that was always hidden beneath them.

To illustrate this shift, Calkins starts by separating Appian’s applications from the interfaces used to create them — arguing that Appian’s real mission has always been to help people get scalable applications into production:

The most important thing about Appian is the applications it creates and the power it gives to those applications. So we’re going to do whatever we can to reduce the barrier to entry so that people can build and use Appian applications.

That distinction is important to his argument because, in his telling, low-code was never an end in itself but rather Appian’s answer to accelerating the delivery of robust enterprise systems. And as he goes on to explain, for a long time, visual tools were just the most visible manifestation of that mission:

In the past, we did what we could to make it easy by creating interfaces that allowed you to drag and drop the objects that would become part of your application. That was the easiest thing we could do. But now there’s an easier way — and that’s going to obsolete some of the interfaces we used to use [because] the ‘building’ interfaces are much less important now. But they were never the heart of the product.

Calkins’ point is that while AI might change the interface used to build applications, it does not remove the need for the platform necessary to run them — it simply makes Appian’s underlying mission of getting robust applications into production and keeping them there more visible:

AI puts the spotlight squarely where I think the spotlight has always been — on the power we give to our users when they run an Appian application. That’s really what the product is for. Our strength is most of all in [runtime] power and reliability — and not merely how fast you can create the application.

But Calkins’ argument only holds if the “power and reliability” offered by that infrastructure is something AI cannot reliably provide for itself.

Calkins’ answer to this question begins with his perspective on Artificial Intelligence. Because, in his view, Large Language Models (LLMs) are powerful precisely because they are probabilistic — which also makes them a poor foundation for anything that requires reliable outcomes:

AI is empirically probabilistic. Everything it says — really everything — is a guess. If you ask it what one plus one is, it will guess. That’s just the nature of the technology. It’s not a condemnation. It’s marvelous technology, but it has certain characteristics that we need to account for and design around.

He illustrates the distinction with the apparently mundane example of a spreadsheet:

Somebody was telling me the other day that they were using AI to add up the cells in a spreadsheet. There’s simply no justification for that because formulas do that perfectly, and AI will never reach 100% accuracy adding up the cells of your spreadsheet. These days, of course, people throw AI at every problem, whether it’s suitable or not.

This example not only neatly captures a bit of the AI mania currently running amok, but also the dividing line it supports in Calkins’ worldview. From his perspective, AI only adds value where probabilistic interpretation can enhance a well-defined process or procedure — but is absolutely not suitable as a replacement for deterministic execution when results must be guaranteed, repeatable and trustworthy.

And that means that the challenge, in Calkins’ framing, is not to replace every deterministic application with a probabilistic alternative — but to pair powerful probabilistic capabilities with equally powerful deterministic control structures:

As we come to grips with the technology — its strengths, its weaknesses and its needs — I think one of the first things we should realize is that it needs structure, and that its outputs are not and never will be 100% reliable.

Calkins presents this philosophy as “East Coast AI” — an approach which is less starry-eyed about AI’s potential than, he would argue, the more idealistic denizens of California and other Pacific-coast US states, and more hard-nosed about its value. Because as he goes on to explain, when you want to do consequential work in the strategic operations of governments, banks and pharmaceutical companies, questions of trust, control and reliability become central to the conversation:

I think they [large enterprises] understand that they need this East Coast approach. They need our reliability-focused approach to AI, and that’s the missing piece that will allow them to deploy AI in strategic applications within businesses.

This worldview leads Calkins to divide the emerging AI market into two distinct layers — the models themselves and the structures that turn them into something operationally useful for serious enterprise workloads:

There are really two different markets. There’s the AI Large Language Model itself. And then there’s whatever you want to call it — it could be a process or a harness or a structure. So if there’s a market for a framework within which AI can be regulated and governed, we’re going to be really good at that — and the fact that you get your AI in one place doesn’t mean you need to get your structure from the same place.

And this separation is also useful in underlining the point that, for Appian, becoming an AI company does not mean becoming a foundation model provider.

Instead, Calkins wants Appian to become the production structure into which ‘serious enterprises’ place those models — repositioning its existing process infrastructure as the harness that makes AI useful by restricting what it can do, connecting it to enterprise data and actions, and ensuring that the resulting application behaves predictably.

And this is where Appian’s claim about the value of its platform becomes concrete, because Calkins’ argument is that the company’s opinionated architecture and process orchestration infrastructure make it ideally placed to go after the second AI market — by acting as a reliable AI harness for strategic enterprise applications:

Our enterprise approach is to create reliable applications — four nines, five nines.

Because Calkins argues that without this kind of AI harness, the burden of providing “five nines” reliability around unpredictable models falls back on the person building the application — leaving them to work out not only what they want it to do, but also enough about architecture, controls and failure modes to build in the reliability they need:

You have to know more than generally what you want. You have to know exactly what you want. The application can’t have more nines than you have.

Taken together, this begins to sound less like Appian adding AI to a low-code platform, and more like the company repositioning itself to become the kind of enterprise infrastructure Calkins argues is necessary to safely absorb AI:

AI is going to transform businesses, but it cannot do it alone. AI needs support for its shortcomings — for reliability, tracking. When we hear predictions about how AI is going to rewrite enterprises around the world, I amend those predictions to ‘AI, with its necessary coupled technology, will do those things.’

In Calkins’ view, that “coupled technology” is the harness around the model — supplying the orchestration, permissions, governance and reliable execution necessary to control probabilistic models. And, for Calkins, the best way of describing these control structures is via structured process models:

I don’t believe that models will resist or circumvent the structure if you set it up in order to work together. You put AI in a process, then the structure will prevail.

And this need for constraining infrastructure is not, in Calkins’ telling, merely a temporary response to immature models, but a consequence of their probabilistic nature — one which means that deterministic platforms will likely always be required to use AI safely within strategic operations.

And as Calkins explains, that belief is at the heart of Appian’s strategic bet — that demand for AI harnesses will scale with demand for enterprise AI:

I see us as an AI vehicle. Wherever AI is going, we’re going with it because we’ve got a product that I believe is necessary for the success of AI. We’re not just a SaaS vendor that AI could replace, [because] if AI replaces an application, it will need to replace it with our help. We could be enabling AI to replace a vast number of applications.

And unlike some of his customers, Calkins suggests that he is not especially sentimental about the applications being displaced because, in his eyes, they represent a legitimate expansion target for his platform — which perhaps highlights the ambiguous position low-code platforms have always occupied in the hinterland between coding environment and finished application:

I don’t sympathize with the legacy applications. We’re on the side of the replacement.

Appian’s ambition, then, is not to defend low-code from AI systems, but to make itself an indispensable infrastructure layer for the AI systems that threaten to displace it — and a broad range of other kinds of software.

What surprised me most during the discussion was how openly Calkins talked about Appian effectively becoming an AI infrastructure company — focused on making models usable in a serious enterprise context — while also acknowledging that some of its existing low-code tooling might become less important as a result.

But it does feel like a credible shift — at least in principle — given that the company’s customer base includes a significant number of large organizations in regulated industries and government agencies, many of which already work with Appian because they value the control provided by workflow orchestration, structured integration and concrete governance.

And it’s also true that, more generally, enterprise AI is not struggling because models cannot generate enough output, but because organizations do not yet know how to steer and control it. If the answer — at least for some organizations — is to wrap probabilistic models inside deterministic control structures, as Calkins argues, then Appian already has many of the capabilities — and customers — required to make that strategy stick.

But Appian is not making this bet in an empty market. A new ecosystem of model-native orchestration, governance and integration technologies is growing up around AI, raising the possibility that the harness Calkins describes may indeed be necessary — but assembled from new components rather than inherited from existing application platforms.

Which makes the harder question one of architecture — whether Calkins is right to believe that Appian’s existing process infrastructure can become the foundation for that new AI layer, or whether a distinct AI infrastructure layer emerges alongside it and captures the growth opportunities he outlines — leaving Appian in its existing role rather than making it central to the new stack.

But Appian does not necessarily need to own the entire emerging layer for Calkins’ strategy to make sense. Because even if its process infrastructure becomes just one specialized element in its customers’ AI operating landscape, repositioning it as AI infrastructure still gives the company a plausible reason to matter — and a credible path to sharing in the growth created by enterprise AI.

And so while AI might, over the long term, erode the low-code category that made Appian successful, Calkins is betting that facilitating rather than resisting that erosion — by repositioning Appian as the infrastructure that enables it — could give the company an entirely new growth path.