If you’ve been following Liferay for the last few years, you should have noticed the continuing and increasing focus on low-code and no-code capabilities in the platform. Features like Objects, Fragments, and Client Extensions aren’t just side tools anymore, they’re becoming a core part of how solutions are built on the platform.

They’re faster. They reduce complexity. And in many cases, they allow “citizen developers” to step in and contribute in ways that used to require a full development cycle.

Which naturally leads to a question I was asked during a recent client training:

“Is this meant to replace Liferay developers?”

It’s an honest question.

But the answer is still simple:

No. Not even close.

This Is About Removing Friction

Low-code and no-code in Liferay aren’t about removing developers, they’re about removing the parts of development that slow developers down.

If you think back a few years, a lot of what we did as Liferay developers wasn’t actually solving business problems. It was scaffolding. Setup. Wiring things together so we could eventually solve the problem.

Take theming as an example.

There was a time when building or updating a theme could easily take weeks. Not because the design was complicated, but because of everything required to get there: structure, integration, testing, and maintenance.

Today, that same effort looks very different. With fragments and modern tooling, a CX-focused developer can spend their time on what actually matters: the experience itself. Styling, layout, responsiveness, and refinement.

The work didn’t go away.

It just became more valuable.

Less Plumbing, More Problem Solving

The same shift is happening on the backend.

Traditionally, if you wanted to build a feature, you started with Service Builder. You defined entities, generated services, managed persistence, and often added RESTBuilder on top to expose APIs. It worked well, but it also meant spending a significant amount of time building infrastructure before you could even start delivering value.

With Liferay Objects, a lot of that groundwork is already handled.

You define your data model. You get APIs. You plug into workflows. And you can move forward without spending weeks building the foundation first.

What changes here isn’t the need for a developer, it’s where the developer starts.

Instead of starting with infrastructure, you start with the business problem. You spend your time modeling solutions, not building plumbing.

That’s a big shift, and it’s a good one.

Citizen Developers Don’t Replace Developers

Low-code and no-code also make it possible for non-developers to contribute more directly. Business users can define objects, manage content, and build simple workflows without needing to wait on a full development cycle.

At first, that can feel like overlap.

In practice, it’s the opposite.

It removes the constant stream of small requests that turn developers into bottlenecks. Instead, developers can focus on the bigger picture: how everything fits together, how to scale, how to integrate, and how to ensure the solution is maintainable.

The role shifts from “doing everything” to “making everything possible.”

There’s Still Plenty That Requires Developers

Even with all of these tools, there’s no shortage of work that requires experienced Liferay developers.

As soon as you move beyond straightforward configurations, you’re back in developer territory. Custom fragments with advanced logic, OSGi components for integrations, Commerce implementations, Client Extensions, FreeMarker templates... These aren’t going anywhere.

And beyond the specific technologies, there’s the architectural side of things.

Knowing how to design a solution that will scale. Understanding how to integrate multiple systems cleanly. Making decisions that balance flexibility, performance, and maintainability.

Those aren’t low-code problems.

They’re developer problems, and they always will be.

This Looks a Lot Like the AI Conversation

If all of this sounds familiar, it should.

We’re having almost the exact same conversation around AI right now.

There’s a lot of noise about AI replacing developers. In reality, what we’re seeing is that AI is great at accelerating tasks, generating code, and reducing repetitive work, but it still relies on developers to guide it, validate it, and integrate it into real solutions.

Low-code and no-code follow the same pattern.

They make it easier to build faster. They reduce the overhead. But they don’t replace the need for someone who understands the system and can turn requirements into working solutions.

If anything, they make that role more important.

A Real Question From the Field

Last week, during a training session, one of the developers asked me directly if low-code and no-code were intended to replace their job.

It wasn’t a theoretical question, it was a real concern.

My answer was straightforward: these tools aren’t here to replace you. They’re here to remove the parts of your job that don’t add value.

The scaffolding. The repetition. The delays.

What’s left is the part that actually matters: solving problems and delivering solutions.

Where Liferay Is Headed

Liferay is clearly investing heavily in low-code, no-code, and AI-driven capabilities. That’s not a short-term experiment, that’s the direction of the platform.

The goal isn’t to reduce the role of developers.

The goal is to make it easier to build, easier to iterate, and easier to deliver value.

And to do that, you still need developers, just not doing the same things they were doing five or ten years ago.

Final Thoughts

Low-code and no-code don’t mean “no developers.”

They mean better use of developers.

Less time building the foundation.
Less time on repetitive tasks.
More time solving real problems.

For Liferay developers, that’s not something to worry about.

It’s something to lean into.