Vibe Coding is a term coined originally by Andrej Karpathy back in 2025 that ultimately means letting your LLM coding companion take the wheel and become the primary programmer. You sit back, guide it to build whatever your heart desires, and watch a robot build the output.
In theory, this is fantastic. As you can imagine, however, there are some drawbacks to this style of programming. I love vibe coding, but it is dangerous – and you probably shouldn’t be doing it.
Why I Love Vibe Coding
I’ve been working in the Salesforce space for over a decade now, and a majority of my experience has been purely declarative – meaning clicks, not code, are how I can add value to businesses. While I did manage to learn the basics of programmatic customization in Salesforce and achieve my Platform Developer I Certification back in 2018, I’m certainly more confident with a mouse than a keyboard when it comes to Salesforce.
To say that I was excited to learn that I could simply type my vision into a tool like Agentforce Vibes, click ‘generate’, and it would come to life in front of me would be an understatement. Developing Flow Builder was a brilliant move for Salesforce, and it gave admins and functional consultants the ability to make real changes to how Salesforce customers used the platform.
Agentforce Vibes feels like it could potentially be the next step in this evolution. Where Flow Builder lets declarative builders build their own automations, Vibe Coding promises to empower those same declarative builders to build using the same tools that programmatic developers use – Apex and LWC.
This promise is why I personally love the idea of vibe coding. Anything that empowers more people to do more good for a business can only be good, right?
When the Vibe Shifts
In short: there’s a very good reason that Salesforce Developers are respected for what they do. There’s so much to keep track of when working with Apex or building out a LWC from the languages themselves, to the best practices that should be followed, to the data model that you are working with, and of course, the other competing functions and processes that you don’t want to conflict with. Developers need to prioritize all of this when building for Salesforce.
This is where the vibe can shift for tools like Agentforce Vibes (and other vibe coding/AI coding tools). With all these complexities, not to mention failing to keep aligned with best practices and ignoring some pretty simple anti-patterns, Vibe Coding tools can begin to lose sight of what makes a seasoned developer. They begin to miss small things, which then lead to bigger problems.
When a Vibe Coding tool is given a new instruction, it doesn’t tend to notice issues with the way the previous code was written. Typically, you’ll open up a tool like Agentforce Vibes or Claude Code, give it a prompt or set of commands, and it will take action on those instructions. Unless you’ve explicitly told it to go back and compare specific assets against best practices or to look for issues, it won’t proactively do so.
An experienced developer will be able to identify code that needs work while they go about another task and take appropriate action.
Another thing to consider is how a developer reacts to a breach compared to how a Vibe Coding tool would. Let’s take the Axios breach as an example. A popular JavaScript library was injected with a vulnerability that would install some malware and hide it well. Even an experienced developer would struggle to catch this sort of thing quickly, and would be aided by the community discussing it.
AI coding tools are not as proactive when it comes to community news, and someone using one of these tools but not keeping track of the plugins it is using is opening themselves up to all sorts of chaos.
This is why I repeatedly say that vibe coding tools should only be used by people with the skills and experience to understand what the code is doing, and someone who would be confident in troubleshooting any issues themselves. Vibe coding is NOT a replacement for an experienced Salesforce Developer.
Moving from Builder to Auditor
There is a mindset shift that is required when working with Vibe Coding tools. As I’ve said above (and many times before), the first thing you need to do is remember that these tools are just that: tools. Vibe Coding does not replace an experienced Salesforce Developer. If you are not comfortable fixing problems caused by the code, or are not across what the Vibe Coding tool is doing, then I’d strongly suggest reconsidering whether you are using it correctly or responsibly.
Another big shift is moving from a builder to an auditor. What this means is that, ultimately, you aren’t the one doing the building per se, but instead you are responsible for making sure that your Vibe Coding ally has built what it was instructed to build correctly. You become responsible for checking what was built, rather than building it. You are not shirking the responsibility altogether, but instead are shifting your focus to checking rather than actually creating.
Ignoring the reviewing step is like deploying a Flow without fully testing it. It’s senseless and creates technical debt that you, your team, or the business will need to address at a later date and on a greater scale.
Verify, Don’t Vibe
There’s a saying in the Bitcoin enthusiast community: Don’t trust, verify. Ultimately, this is because of the blockchain design – everything that happens on it is verifiable by everyone, which requires a different mindset than traditional ledger systems. This is a great saying that I’ve adopted whenever I am vibe coding as well.
LLMs are taught to fill you with confidence, both in yourself and in the tool and its outputs, but the trust should not be inherent – it needs to be verified, and this is your most important role when it comes to vibe coding.
You should consider developing a series of prompts to test what is being created against best practices and common anti-patterns. Also, develop a set of rules to ensure your business standards are being conformed to. These will act as guardrails to help your vibe coding tool stay on track and give it the guidance required to do the work properly. This is not foolproof, but it is a start.
You should also use a secondary LLM to verify the work done by the primary vibe coding tool. Just like a human who is told to test their own work will have a harder time seeing any error in what they’ve built, an LLM will also struggle to test its own work properly. For example, if you’ve used Agentforce Vibes to develop a LWC, you should consider asking Claude Code to verify that what was built will do what it is supposed to, not do anything that it shouldn’t, and won’t clash with anything else in the system.
Summary
With great power comes great responsibility. This applies to many different technologies that we are blessed with in the Salesforce space, and with none more than vibe coding. Having an LLM receive a set of instructions and build whatever your heart desires is like a siren – an extremely enchanting offer, but with potentially deadly consequences if you’re not careful.
Can you see how vibe coding can be both extremely powerful and extremely dangerous if not governed correctly? Please consider any products that you’ve created with vibe coding, and how they could negatively impact your business if you’re not carefully verifying the output.
