Things to consider before you Vibe code with Salesforce!
Blog
The landscape of Salesforce development is changing fast as we now have numerous AI tools available that can help admins, developers and even business owners to create both declarative and coding solutions on Salesforce very quickly.
Tools like Salesforce’s own Agentforce Vibes, Cursor, OpenAI’s Codex, and, more recently, Google’s Antigravity can all be used to create code and config with a few keystrokes.
This new wave of development methods is known as “Vibe Coding”. The term itself was coined by an AI research scientist named Andrej Karpathy, and refers to a practice where you describe what you want in natural language, and the AI builds it. But while the output from vibe coding often looks correct, how can you be sure the solution that comes out of these tools is always correct? And can you trust it in your Salesforce org?
These are some of the key questions we want to answer in this article to help our clients and others who want to experiment and make use of this new technology for Salesforce development.
The hidden risks of Vibe Coding on Salesforce
AI development tools are designed to provide solutions and often deliver responses that appear confident, well-structured, and thoroughly considered. However, what may initially look like a polished solution, or a well-commented and structured piece of code may not always fully meet your business requirements or the nuances of your Salesforce org. For our clients whose fundraising activities are essential to their business operations, the risks of getting it wrong are significant. In other words, if you don’t have the expertise and knowledge to validate the code or config that the AI produces, you might not realise it’s wrong until a bug bites you when the feature is released to the live system.
Real world examples of AI missing the mark
Example 1
At Giveclarity, we are actively reviewing the potential of AI tools and have also observed an increasing number of our clients testing this new technology in their own Salesforce orgs. One such example was when one of our Technical Architects asked Agentforce Vibes to generate a Flow to populate the last name of a Contact field with the word ‘Vibey’ (I know this is a bad use case but bear with me). Agentforce Vibes repeatedly attempted to generate the XML metadata for the Flow but it kept failing deployment due to issues in the metadata structure. We ended up in a deployment attempt > fix > deployment attempt > fix loop until Agentforce Vibes suggested to change the Flow-design to an Apex trigger because it is better trained at writing Apex code than it is in writing the complex XML required for creating Flows.
I’ll get back to why this suggestion is a problem…
Example 2
Another example was from a client who asked an AI tool to make it possible to display donation details for donors on their Experience Cloud site. The AI’s solution to this problem was to generate a Lightning Web Component to display the donor information. Our client reached out to us as the solution was not working as expected when deployed to the Experience Cloud site. When our Technical Architect reviewed the requirements and looked at what the AI had created it was clear that a Flow and a simple data table component could have been used to meet the requirement – and it would’ve worked!
To a less experienced Salesforce developer or system administrator the coded solutions the AI tools suggested in these cases might seem like good solutions for the requirements. But is it best practice to use code for simple solutions that could be done using a Flow? I would argue that it is not. It incurs more technical debt and a maintenance overhead when we introduce code into an org for something that could be covered with a simple declarative solution like Flow.
Why having an experienced Salesforce partner is still important
Both examples above highlight why using AI for Salesforce development still needs an experienced human-in-the-loop to stop it going rogue. Why? Because AI is a powerful assistant, not a seasoned Salesforce professional. AI can indeed speed up Salesforce development. But only when it is used by the people who can provide the oversight and context and who “know what good looks like”.
Here is where a partner like Giveclarity adds value that an LLM (Large Language Model) cannot match:
1. Industry Expertise
Giveclarity work exclusively with nonprofits and have delivered Salesforce fundraising solutions for hundreds of organisations, from small local charities to global NGOs. Our team includes former charity fundraisers and nonprofit CRM experts, so we speak your language and understand the nuances of fundraising and marketing. This knowledge and experience help us guide and provide the AI with the correct context and direction it needs to help us deliver solution that best meet our client’s requirements.
2. Deep Salesforce Knowledge
Large Language Models (LLMs) are primarily trained on generic, publicly accessible data. The training data sets are typically based on information available up to a certain point in time, meaning that any recent Salesforce releases or new features may not be recognised or utilised by the AI unless they are explicitly referenced or the tool is directed to current documentation or resources that are available online.
When requirements become more complex such as those spanning multiple Salesforce clouds (Sales and Marketing Cloud for example) or involving a chain of different components (Apex, Flow and Batch processing), LLMs may not always know how best to provide the best answers.
While LLMs can answer Salesforce questions, they are best used in cases that don’t require the deep expertise of an experienced Salesforce implementation partner who know the gotchas and nuances to be able to pick up problems or design flaws early in the process.
3. Protecting Your Org Strategy
Every Salesforce implementation we do is unique. Our clients have business process and automations that are specific to their requirements. This knowledge is not something that an LLM will just know without feeding it a lot of additional context which we as the Salesforce partner are already aware of.
We also know what best practices to follow when implementing changes in a client org. For example, is there a process automation “kill switch” required to be added to any automation so that it can be easily enabled and disabled without effecting the whole system? If so, how does that kill switch work, and how do you enable it? This is only one of the best practices our consulting team is trained to do for all our projects and yes, we can make an LLM do the same, but we first need to ask it to do so.
4. The “Big Picture” Architecture
Our clients typically don’t only work with Salesforce. They likely have a wider technology stack that can include email marketing tool like Mailchimp or Marketing Cloud, a payment gateway that integrates with FinDock, a website or volunteer management system, perhaps even legacy databases. One of Giveclarity’s strengths is seeing the big picture architecture. We design Salesforce solutions that fit into that puzzle seamlessly. This includes understanding data flows, integration points, and the overall system performance. Our architects consider questions like: How will the new feature impact the nightly data sync with Finance? Could this automation slow down the website donation data reaching Salesforce? Is there already a tool in the AppExchange that achieves this function better than building from scratch in Salesforce? These are architecture-level considerations that our consulting team handle routinely.
An AI response is very likely to give answers in isolation. If you ask, “How do I implement X in Salesforce?” it will tell you how to do X in Salesforce. It won’t tap you on the shoulder and say, “Actually, you might not need to do this in Salesforce at all, given you have System Y,” or “Be careful when implementing X this way as it could strain your integration with System Z.”.
In short, Giveclarity can see the forest, while AI often sees just the tree in front of it. By understanding your entire architecture and business ecosystem, we ensure any enhancements (AI-generated or not) play nicely together. This prevents costly issues, rework and technical debt, and results in a more cohesive, efficient tech environment.
Conclusion
So, can you be sure the solution that comes out of these tools is always correct? And can you trust it in your Salesforce org?
My answer is “not unless you can read and understand exactly what it has produced for you.”
AI tools like Salesforce’s Agentforce Vibes and other coding assistants are here to stay, and they can provide tremendous value when used in the correct manner. At Giveclarity, we’re not telling you to avoid them. In fact, we are embracing these tools to achieve results faster and more cost-effectively for our clients.
As you venture into “vibe coding” by all means, have fun with it and see what AI can do. But remember that ensuring a successful, reliable solution is a team effort and not something expect an AI to get right on its own. When you partner with Giveclarity, you’re not choosing between AI or experts – you’re getting the benefits of both worlds.
If you’re curious or concerned about how to leverage AI in your Salesforce org, let’s chat. We’re happy to share what we’ve learned (we have plenty of stories, good and bad!) and we can help you innovate safely.
About the author:
Mark Richmond is Head of Technical Architecture at Giveclarity