Is Low-Code Dead?

Inheriting someone else's Power App usually means reverse engineering it first.

Before you can change anything, you have to figure out what it does, why it does it that way, and what breaks if you touch it. That archaeology has always been the real cost of taking over a low-code application.

I skipped it.

The application was an internal business directory used across multiple locations. It handled contacts, role-based views, and reporting lines. It had been built by one team and extended later by another, and both had done good work. The goal wasn't to replace Power Apps. The goal was to get the application into an architecture that would hold up better over time.

I exported the solution, dropped it into Claude Code, described the target architecture, and watched it rebuild as a SharePoint Framework (SPFx) web part.

Cleaner architecture. Easier to extend. Easier to integrate. For this use case, simply a better fit.

That was the moment the question changed for me.

We've Been Here Before

When I entered the industry in the early 2000s, people still talked about first, second, third, and fourth generation programming languages.

You don't hear that terminology much anymore, but the idea behind it still matters.

Every generation raised the level of abstraction.

Assembly abstracted binary.

High-level languages abstracted hardware.

Fourth-generation development platforms such as Magic, PowerBuilder, Microsoft Access, and later Power Apps abstracted much of the programming itself.

The goal was always the same: spend less time telling the computer how to do something and more time describing what you wanted it to accomplish.

AI is the next step.

The Code Never Went Away

One misconception about low-code platforms is that they eliminate code.

They don't. They relocate it.

In Microsoft Access, logic lived inside forms, reports, macros, and VBA.

In Magic, a fourth-generation platform that powered the operations of a real estate software company I worked for in the early 2000s, business logic lived inside object definitions, embedded expressions, and merge forms that generated HTML.

Power Apps follows the same pattern. Logic lives in control properties, connectors, and event handlers, scattered across the control tree.

Which is exactly what makes inheriting one expensive.

AI Doesn't Think in Languages

Humans think in programming languages because we've always had to.

AI doesn't.

To a large language model, Power Fx, C#, TypeScript, React, SPFx, Python, and SQL are all different representations of the same underlying intent.

That's why a Power Apps solution can become an SPFx web part.

It's why a Figma mockup can become a React application.

It's why an API specification can become a working client library.

AI isn't translating code. It's translating intent.

That's a fundamentally different capability than anything previous generations of development tools gave us.

The Cost Curve Just Changed

For decades, implementation dominated the cost of software development.

Every advancement in tooling tried to reduce that cost.

Visual designers.

Frameworks.

Code generators.

Low-code platforms.

Reusable components.

AI changes the equation.

Not because developers suddenly became dramatically more productive.

Because implementation itself is becoming dramatically cheaper.

The bottleneck moved.

The New Scarce Resource

If implementation isn't the expensive part anymore, what is?

Understanding the business.

Designing the architecture.

Making governance decisions.

Knowing how systems should integrate.

When I rebuilt that application, the AI didn't choose SharePoint Framework.

It didn't understand the governance model the application had to live inside.

Those decisions were mine.

The AI executed them.

Is Low-Code Dead?

No.

Power Apps remains an outstanding platform, and for many organizations it will continue to be the right choice.

But the economics that made low-code revolutionary have shifted.

The question is no longer:

“Should we build this in Power Apps or custom code?”

The more interesting question is:

“What architecture best serves the business, knowing AI can build either?”

That is a fundamentally different conversation.

One focused less on implementation speed and more on long-term ownership, governance, maintainability, integration, and business fit.

Looking Ahead

Give it five years.

Debating Power Apps versus custom development may feel like arguing C versus assembly.

Historically interesting.

No longer the decision that determines the outcome.

The scarce skill won't be building software.

It'll be understanding a business well enough to decide what should exist.