Salesforce Flow Demonstrates Why Vibe Coding Isn’t Enough

Highlights

• When Salesforce introduced Flow Builder, it empowered non-programmatic users to build complex automations using clicks, not code.
• As Flow Builder became more powerful, it led to the accidental creation of new technical debt. 
• While Salesforce Flow has come a long way, it still opens the door to poorly built flows, which can cause issues for the Salesforce org.
• Vibe coding has a similar problem – it allows non-programmatic users to generate code without understanding it.
• Vibe coders can learn from the mistakes and lessons of those who have come before them by taking on board the wisdom of those who learned the hard way with Salesforce Flow.

Salesforce Flow was a revolutionary tool with a big promise: anyone can build automation, no programming required. Clicks, not code, was the mantra. If you’ve been following my work for the last decade, you’d know that it was Flow Builder (or Cloud Flow Designer back then) that made me fall in love with the Salesforce platform. Years on, we can see the major impact that having a declarative automation tool has had on the Salesforce ecosystem.

However, I’ll be the first to admit that not everything is perfect. We’ve learned a lot over the years as more and more flows have been built, and some of these lessons should be applied to vibe coding as well. In this article, I’ll highlight what went wrong with Salesforce Flow, and how history has begun to repeat itself with vibe coding. I’ll also point out what you can do to ensure that you don’t make the same mistakes.

What Happened With Flow

It pains me to speak ill of Salesforce Flow, but given that it’s in the spirit of making better Salesforce builders, it’s important for me to do so. Salesforce Flow was, and is, a revolutionary tool that empowered non-programmers to build complex automations on the Salesforce platform. 

Using clicks, not code, was the way that we were encouraged to build our business automations. Salesforce’s continual investment in the tool, including its major evolution from Cloud Flow Designer to Flow Builder in 2019, shows that the cloud giant is very much committed to this vision.

However, one problem that emerged was that people were building flows while not understanding some pretty basic engineering principles. For example, in my earlier days of building flows, I guarantee that I was putting pink DML elements within loops. In my decade of consulting experience, I’ve seen all sorts of anti-patterns when working with flows too. If it saves, tests fine, and activates, that’s often enough for a junior Salesforce builder. 

Flow Builder Didn’t Create Engineers

When you’re given a canvas as easy to navigate as Flow Builder’s, and you’re able to click and create powerful automations, it’s easy to forget some of the major underlying factors that Salesforce actually functions on. What I’m referring to here are things like the architecture, performance thinking, error handling, proper testing, and lifecycle management. 

If you’re very new to Salesforce, and you’ve been given a business problem to solve, it makes sense to jump into Flow Builder and start building.

While there have been enhancements to Flow Builder that make these concepts easier to keep in mind as you build, they’re still not technically a requirement before you press Activate. Hell, you can even build a flow directly in production and activate it without having to perform any testing whatsoever. Unless you’ve learned from mistakes – or you’ve spent the time to learn more about how flows should be built – you’re kind of just given this powerful tool and encouraged to go wild in many ways.

All of these concepts are important, but unfortunately they’re still not a requirement for building flows in Flow Builder. Over time, you hone in your skills and understanding, and you engineer your flows in a much better way. The tool itself doesn’t teach you these things; experience does. Engineers, who know these concepts like the back of their hands, teach you as well. 

Vibe Coding Is the Same, But Bigger

The same problem exists when vibe coding. With LLM tools acting as a translator between your natural language and programming languages like Apex, you’re not required to have that deep, intimate understanding of the language and the underlying platform that Salesforce Developers have had for years. Just like Flow Builder, vibe coders are given the keys to the car without needing to know how it works, what its limitations are, or how to properly maintain it. 

While I’m a big fan of AI coding tools, I know they’re introducing new problems that didn’t exist before. Junior Salesforce Developers had to understand how to write code, as well as acquire at least a basic understanding of how the platform functions. Many Salesforce Developers had prior programming experience as well, and many common engineering concepts were brought in from that prior experience. 

Many vibe coders don’t have that same level of understanding. They simply prompt their LLM to achieve a goal, build a solution, and often will blindly trust the code that it spits out. This is something that I call out often: if you don’t understand the code that your LLM has written, you should be extremely wary of using it in production. 

Another thing that vibe coders don’t tend to understand is the architecture that Salesforce is built on, and why it matters how their code is written. Salesforce isn’t just the applications that you interact with – it’s the complex multi-tenanted infrastructure that powers it as well. 

There is so much that goes on behind the scenes that those who build on the platform don’t see, and it plays an important role when you plan how to build on the Salesforce platform.

Below the Surface of the Iceberg

There’s also the discussion of vibe coding your own CRM platform. This is something that we’ve discussed in detail, and it’s a topic that many are interested in (or actively trying to achieve). However, as I mentioned earlier, it’s not as simple as building a CRM application and calling it a day. Salesforce as an offering is immensely more than just the applications that you interact with; it’s the underlying infrastructure that you don’t need to manage yourself as well.

Even if vibe coders were willing to tackle the infrastructure challenge, it may not necessarily be something that they’re overly familiar with. Just like Flow Builder gave us the tools to build automations, it didn’t give us the knowledge, experience, and wisdom that programmers have had before us.

Vibe coders need to consider the infrastructure and environment management that will underpin their vibe-coded platforms. They’ll also need to consider their security review when they’re building because Claude and other tools like it don’t necessarily have the same degree of caution that a seasoned Salesforce Developer would. 

They’ll also need to consider their testing strategy beyond just their golden path. They’ll need to consider outliers and all the different possibilities that could arise from the solution that’s been built to ensure that there are no unconsidered edge cases.

Code review is also a critical step when writing any form of code. Given that vibe coders don’t typically understand the code that they’ve generated, it’s more critical than ever that they have it reviewed properly by somebody who does (to ensure that there are no problems or future issues that will arise). 

Last but not least that I’ll mention here is the documentation and long-term ownership. Just because you’ve had an LLM generate you a module doesn’t mean that you’re finished. There is a high chance that it will need maintenance in the future, and somebody needs to own that code. 

Given that vibe coders don’t typically understand the code that has been written, they may need some assistance in terms of ownership and maintenance in the future. One big benefit, however, of vibe coding is that documentation can be relatively easily generated as long as someone is there to make sure that the documentation is accurate to what’s been built. 

What Flow Veterans Already Know

Over the many years of evolution of the Flow Builder tool, we’ve all learned many lessons regarding best practices, anti-patterns to avoid, the importance of testing and naming conventions, and more. While the lessons are different, there is a lot of hard-won judgment that can be applied directly to vibe coding.

We’ve all learned to set up design guidelines for our organizations to ensure that flows are always built the same way. We’ve learned to set up naming conventions so that flows are named in a way that makes them easier to organize. We’ve learned what to do and what not to do, and we can apply that to vibe coding as well. 

Ultimately, I would approach these challenges in a positive way. As non-programmatic Salesforce professionals, we’ve experienced this journey before when it came to building good flows. We know what to look out for; we understand that AI coding tools are just that – coding tools, not a replacement for a Salesforce Developer who understands the code. We know that we have a lot to learn, and AI coding tools can help us to accelerate that learning.