Salesforce’s low-code philosophy has always been one of the platform’s biggest selling points, opening the door for more people to build on the platform without needing traditional development skills. The “clicks not code” ideology has been a genuine gateway into the ecosystem, especially for admins.
But Salesforce is growing – both in size and complexity – as has the conversation around low-code development. Flow has become the center of Salesforce automation, Salesforce continues to promote the “citizen developer” role, and many teams are now responsible for maintaining years of messy customizations created by multiple admins, consultants, and so on. At the same time, AI coding assistance is making it easier than ever to generate Apex and other code, raising questions about where declarative development fits into the future.
So, has Salesforce’s low-code vision “failed”? Or is the problem less about the technology and more about how it’s been adopted? To find out, I spoke to Salesforce consultant Vuk Stajic about the state of low-code development today. I also spoke with SF Ben Technical Content Writer Christine Marshall, who argued that part of the problem is how loosely the ecosystem sometimes talks about “citizen developers”, admins, and business users as if they are the same thing.
Low Code Was Never the Problem
It’s quite easy to look at today’s Salesforce ecosystem and come to the conclusion that low-code may have failed. After all, It’s not hard to find stories of sprawling Flows, difficult-to-maintain orgs, or years of declarative automations left behind by admins or consultants who are long gone. There’s a really entertaining Reddit thread called “What Is Your Most Controversial Salesforce Opinion?” which details some of the org horror stories caused by low-code.
But according to Vuk, solely blaming the platform itself misses the point. “In any technological implementation, it’s always strategy that needs to come before that implementation action,” he told SF Ben. “Even in 2026, I’m still a huge proponent of the clicks-not-code idea.”
This certainly goes against the current narrative when it comes to low code. Much of the recent debate we’ve observed at SF Ben has been centered around whether Flow and other declarative tools have become too powerful. More businesses are building these complex solutions without the governance and discipline traditionally associated with software development. However, Vuk argued that the flexibility Salesforce offers is still one of its greatest strengths.
“As somebody who’s been leading clients on change initiatives over the last eight years, I’ve definitely seen the negative sides of clicks not code – the technical debt, the wasted spend, building the wrong things, and no documentation,” he said. “But if I compare that to other, more closed technological ecosystems, I’d still much rather have the risk of building the wrong thing while still having the power to build exactly what I need.”
In essence, making it easier to build doesn’t remove the need for planning or governance. If anything, it makes that discipline even more important. More people now have the ability to shape how a Salesforce org evolves over time.
Christine made a similar point, arguing that the issue is rarely whether something was built with clicks or code, but whether it was “designed, governed, and maintained properly.”
“Poor Documentation and Staff Turnover”
So if low-code isn’t the sole problem, then what really is? For Vuk, it really does come down to poor governance rather than anything else.
“I think it’s definitely a combination of things,” Vuk said. “But the two biggest things that combine to create issues are poor documentation and staff turnover.”
According to Vuk, those two factors create the perfect conditions for technical debt to creep into a Salesforce org. Admins move on, consultants finish projects, and new people inherit whatever is left. This means the original thinking behind what’s been built gets gradually lost.
“The staff turnover is both internal people responsible for the platform, and when you have turnover of external consultants,” he explained. “Those things are what create the conditions where our systems do not evolve while our internal process and strategy does evolve.
Vuk also mentioned that he doesn’t think this is a Flow problem: “I believe that this problem exists both with clicks-not-code, low-code solutions, and with development solutions, where in reality I think even in those solutions it’s even more complex.”
He instead argued that organizations often focus too much on how they’re building and not enough on why they’re building in the first place: “The reality is we have to put process and strategy and design and business analysis ahead of when we build, and as the system evolves.”
This thought process actually emerged in a recent experiment my colleague Tim Combridge did with Anthropic’s Claude Fable model. Tim found that AI could successfully build Flows from scratch before even converting them into scalable Apex, prompting him to question whether the future debate is really about Flow versus code anymore.
Instead, he suggested the bigger question may be how well organizations maintain and govern whatever AI helps them create, which may be low-code’s biggest sticking point.
Vuk’s argument about governance also raises another important question – who should actually be building these low-code solutions in the first place?
Are We Confusing Admins With Citizen Developers?
When discussing low-code in Salesforce, it’s important to distinguish who we’re talking about when we refer to “low-code builder”. Is it just Salesforce Admins, or non-technical business users also?
According to Christine, it’s important that these two parties are separated, and she pointed out how the term “citizen developer” is often used too loosely, particularly when applied to admins.
“If you asked a developer, they might describe a Salesforce Admin as a citizen developer,” Christine said. “Personally, I think that significantly undersells what an admin does and is qualified to do.”
Interestingly, despite Salesforce promoting citizen development for several years, Christine believes the concept is still far from mainstream.
“I have yet to encounter an organization that is using citizen developers,” she said. “From my perspective, citizen development within Salesforce is still very much in its infancy.”
Instead, Christine argued that Salesforce Admins are trained professionals who have expertise across every corner – requirements gathering, automation, security, etc. In contrast, Christine sees citizen developers as non-IT business users building solutions with low-code tools.
“Salesforce Admins are not simply end users who happen to click around in Setup,” she said. “They are trained professionals, often with multiple certifications and years of platform experience.”
Christine also warned against treating citizen development as a replacement for experienced Salesforce professionals. “A business user who believes they know what they need is not a substitute for proper requirements gathering, process mapping, solution design, or governance.”
While Flow has undoubtedly made automation more accessible, Christine believes businesses should be careful not to mistake accessibility for simplicity. “Building a Flow safely and effectively is about much more than simply dragging components onto a canvas,” she explained.
Interestingly, despite Salesforce promoting citizen development for several years, Christine believes the concept is still far from mainstream.
Ultimately, empowering more people to build on Salesforce doesn’t remove the need for skilled professionals. If anything, it makes good governance, solution design, and long-term ownership even more important.
AI Is Changing the Conversation
Just as Salesforce users and teams get to grips with governing low-code development, AI is beginning to blur the line between declarative and programmatic altogether.
As Christine told SF Ben: “At a time when technical debt is becoming a major challenge – and increasingly limiting organizations’ ability to take advantage of AI and automation – it seems risky to encourage practices that are likely to create even more of it.”
That warning feels particularly relevant as AI lowers the barrier to building software. If we go back to Tim’s Claude Fable experiment, he began to question what the future of Salesforce Flow might look like in a world where AI can generate both declarative and programmatic solutions with relatively little prompting.
“The reason I fell in love with Salesforce Flow in the first place is that it made configuration and customization more accessible,” he wrote. “In 2026, I’m beginning to wonder if the opposite is happening. AI is doing the same thing but isn’t limited in terms of output.”
Vuk told SF Ben that he has already started seeing that shift in his own consultancy.
“I don’t think it’s a matter of what I think,” he said. “Because in reality, even today, my consultants are using AI to solve problems that normally would have escalated to my developers.”
He pointed to a recent example where one of his consultants, who wasn’t a developer, used AI to build a Lightning Web Component for an Experience Cloud site. Traditionally, that work would have required a specialist developer, but AI has now significantly lowered that barrier. But rather than making governance less important, Vuk believes AI has had the opposite effect.
“It’s never been easier to build,” he said. “So it’s always going to be harder and harder to build the right thing. We need to be more clear about the real business needs than ever before because if we rely on AI to build our solutions, it’s not always clear to us what has been built.”
Perhaps that’s where Salesforce’s low-code vision ultimately lands. The future may not be about choosing between Flow and Apex at all. Instead, success will depend on whether organizations understand the problems they’re trying to solve, can govern what gets built, and can confidently maintain it long after the first prompt (or first Flow) has been created.
Final Thoughts
Saying Salesforce’s “clicks not code” vision has failed probably doesn’t paint the full picture. Low-code has helped countless organisations move faster and made the platform more accessible than ever.
The bigger challenge seems to be everything around it – governance, documentation, and knowing what should be built in the first place. As AI continues to change how Salesforce teams work, those fundamentals may end up mattering far more than whether a solution was built with Flow or Apex.
