Because here's what we are actually seeing in the market right now, and it isn't the story being told on LinkedIn.

The activity trap

Anyone can build software today. That's not a bold claim anymore. It's just a fact. Open a browser, type a prompt, and within ten minutes you have something that looks like, acts like, and mostly works like a real application. The barrier to creation has effectively hit zero.

And yet.

One of our customers has 4,000 AI initiatives running across their organization. Four thousand. Know how many made it to production? Five.

That's not a failure of imagination. It's not even a failure of technology. It's a failure of control. All that activity (the Copilot experiments, the AI-infused apps, the vibe-coded prototypes built on a Friday afternoon) created noise. A lot of it became what I've started calling zombie software: nobody knows it's there, nobody owns it, nobody knows what it's connected to. It's just running somewhere, consuming resources, touching data, and generating costs that nobody can actually project anymore.

What makes this worse is the timing. The subsidization era of AI is ending. The free stuff is going away at the exact moment that token costs are rising. If you thought projecting AI costs was hard last quarter, wait until next quarter. It's a double whammy, and most enterprises are only beginning to feel it.

The problem isn't the technology. The problem is that all this creation is happening disconnected from the real world: from real data, real integrations, real organizational accountability. There's a useful concept here: AI is great at personal apps. When an application is only for you, it works fine. The moment it needs to work for two people, it starts to break down. And the moment it needs to live inside an enterprise, touching systems, governed by compliance, owned by a team, it breaks down completely.

So you end up with 4,000 initiatives and five in production. And a CIO who has absolutely no idea what is running on his infrastructure.

Speed became table stakes overnight

Low code, for the last decade, was fundamentally about speed. Build faster. Iterate faster. Ship faster. That was the promise, and we delivered on it.

That value proposition is gone. Not because we failed, but because the entire market caught up overnight.

You don't need a platform, a training program, or even a developer to get to something functional anymore. The speed is accessible to anyone with a laptop and an idea. Which means the battlefield has moved, and almost nobody in the industry has caught up to that reality yet.

If speed is table stakes, control becomes the differentiator. And "control," I'll be honest, is not the sexiest message to take to market. When we talked about governance and control in the citizen development era, it was met with, let's say, limited enthusiasm. But something has changed. The urgency is different now.

The CIO of a large European engineering firm, active across 15 countries and tens of thousands of employees, reached out to me recently. Not to talk about building faster. He said: I see everyone building all the time. I don't care about that. Tell me how you help me control this.

That conversation is happening everywhere. It's not a future problem anymore. 

Low-code's unfinished promise

Here's the uncomfortable truth that those of us who built our careers in low code need to own: we didn't fully deliver on the promise.

The original pitch was that anyone in an organization could build software that enterprises would trust, run, and maintain at scale. What we actually delivered was often fast, but also proprietary. Vendor lock-in was the norm, not the exception. Pricing models punished you for succeeding: build something in nine months, use it for five years, keep paying the same license for the four and a half years you're just running it. And the citizen development story, the idea that business users would become builders, never quite landed with the CIOs who needed to sign off.

We became fast. We didn't become accountable.

Now AI is about to make the same mistakes at a much larger scale, and at a much higher speed. The generate-everything tools are brilliant at the creation phase. They hit a wall at everything that comes after: integration, security, maintenance, compliance, ownership. The moment an application touches another system, real data, real APIs, real enterprise infrastructure, is the moment "just prompt it" becomes a liability.

And unlike the low code era, where the blast radius of a bad decision was relatively contained, unchecked AI generation is enormous in scale. We're already hearing about companies getting surprise bills that make you check whether you're reading the comma in the right place. We're already seeing applications in production that nobody can explain, nobody can maintain, and nobody will claim ownership of.

The problem that killed low code's promise is back. And it's wearing a much bigger coat.

What comes next

The category that needs to emerge, and that I believe is genuinely taking shape, isn't low code 2.0. It's AI Application Generation. And it has a fundamentally different set of priorities from the ground up.

It starts before the building even begins. The first question shouldn't be "how do I build this faster?" It should be: "does this need to exist?" Organizations with thousands of software vendors and thousands of running applications already have more software than they can manage. A smart platform should help surface that: check an idea against what already exists, route people to existing solutions before a new initiative even gets started. Preventing sprawl is more valuable than accelerating it.

When building does make sense, the approach matters. There's a meaningful difference between generating code directly from a prompt (fast but opaque) and going through a structured layer that captures intent, validates requirements, and produces something auditable. Not because the output looks different on day one. Because on day 400, when something breaks or needs updating or the person who built it has left the company, you need to be able to understand what you're looking at.

And after the build comes the part everyone skips: tracking whether the thing is actually delivering value, who owns it, whether it's still in use. These sound like obvious things to manage. They are almost never managed.

What leaders actually want, and I think this is the sharpest way to frame it, is predictable outcomes. Not just speed. Not just control for control's sake. The ability to look at what AI is generating inside their organization and say: I know what this is. I know what it costs. I know what it returns. I know who's responsible for it. That's what makes sustainable innovation possible. And right now, almost no one can say that.

The second shot

Here's what is genuinely exciting about this moment, despite everything.

All the problems that AI is now creating at scale (sprawl, security gaps, hidden costs, abandoned ownership, zombie software) are problems the low code world has been wrestling with for years. We have the scar tissue. We made the mistakes. We learned what happens when you democratize software creation without building in accountability.

That's not a small thing. The companies and platforms that understand this deeply are better positioned to get it right this time than the ones starting from scratch with a blank canvas and a very fast code generator.

This is a second chance to deliver on the original promise: that software creation inside enterprises can be fast and trustworthy. That the people closest to a business problem can build solutions for it, without creating a new class of problem in the process.

Low code isn't dead. Its original ambition is finally being taken seriously, and it has a new name: AI Application Generation.

The shift is happening. The question is whether the platforms that emerge from it are built around speed, or built around outcomes.