With the new Agentforce Vibes hot off the press just shy of two weeks before Dreamforce, it’s no wonder it was such a popular demo! Many lined up and were keen to get their hands on the brand new tool.
I was one of those who lined up, had a go, and experienced a guided Agentforce Vibes hands-on demo. Below is a quick summary of my thoughts!
Lining Up For the Demo
As soon as my colleague Peter Chittum told me there was a hands-on experience in the developer section, I ran to go and check it out. It’s a secret of mine that I actually quite fancy the concept of ‘vibe coding’ – I know many developers aren’t so keen, and there have been some issues with it in the past, but that doesn’t slow my enthusiasm.
As I joined the back of the line, I realized it didn’t seem to have slowed many people down at all! The line went on forever, with my other esteemed colleague Christine Marshall also mentioning that the line was long every time she went to get involved – three separate times throughout the day.
This was intriguing to me, as I wasn’t sure how people would realistically react to a product that invokes the concept of ‘vibe coding’. My doubts were put to rest when I saw the number of people lined up throughout the day.
Getting Started With Agentforce Vibes
When I finally made it to the front of the line, I was guided to one of the MacBooks that were set up on a line of tables. I was told that I would be flicking back and forth between Google Chrome, which had a Heroku site set up that contained Trailhead-like guidance, and VS Code, which had been set up in advance for me.
I wish I had the opportunity to take some real notes during this session, as there were some great gems of information on the Heroku site.
I learned that Salesforce is pioneering the term ‘enterprise vibe coding’, which is like vibe coding but with additional governance, security, and trust layered on top as well. This is a brilliant move given vibe coding’s sketchy recent history, and it’s good to see Salesforce doubling down on security, given how 2025 has panned out so far.
Hands-On Time
After getting a refresher on the key concepts of vibe coding and learning how Salesforce intends to do it differently, I finally got to the first hands-on step: getting Agentforce Vibes to create an LWC with a basic button on it that changed colors when clicked.
Nothing too fancy, and it explained how it worked as it went. It also pointed to a set of rules that governed how Vibes should work – more on that later.
And after entering the provided prompt… it worked without an issue! A few seconds later, I opened the Local Dev Preview in VS Code to see how it looked and functioned, and it was exactly as I would have imagined it to be based on the requirements in the prompt – a button that changed colors when clicked. Marvelous!
Next up, a slightly more complex project: a to-do list. The Heroku site explained that a to-do list has all the key elements of programming, and if you could build a to-do list, then you could build anything. I love the confidence!
Yet again, the prompts were carefully curated for me, and I worried this was going to be a “golden rails” demo that would only work under strict circumstances, but I pressed on. I gave it the prompt, and before my very eyes, a to-do app was built! The Todo__c custom object was created, a custom interface using freshly built LWCs was displayed, and all seemed to be going smoothly.
This, however, is where things took a slight turn.
Deployment Problems
To see everything that we had built in action, I needed to deploy it from VS Code to the preconfigured scratch org. For some reason, there were issues when it came to pushing it all up into the scratch org. I was impressed with how the tool tried to handle it – once it identified the error was related to the HTML formatting of the LWC, it attempted to clean it up and try the push again on its own.
Unfortunately, it still wasn’t successful, and it came back with a partially completed task.
Luckily, I quickly skimmed the code and tidied it up myself manually, and then manually retried the deployment. Looking back, I should have asked Vibes to deploy it just to see how it handled it.
This time, no errors were displayed, and I was able to launch the scratch org and test that everything was working as expected, which it was! All super simple, minus the small bug, and the majority of the code worked the first time – brilliant.
Further Tinkering
The final page of guidance on the Heroku site was what surprised me the most, given my earlier assumption. It told me to go bananas and try editing it myself. I asked Vibes to adjust the alignment of a few visual elements, which worked perfectly.
It even deployed it into the scratch org again for me automatically. I’m not quite sure was the right move necessarily, but technically speaking, I retained control of what actions were taken and what were rejected the whole time – more on that later.
I was impressed! As I mentioned earlier, I was concerned that this would be a “golden path” demo, but I was given the freedom to make a mess of things (or, rather, a lack thereof, due to how well the tool performed).
My Opinion After Using Agentforce Vibes
As I mentioned earlier in the article, I do like dabbling in a bit of vibe coding here or there. I love seeing just how far I can push tools like this to take my vision and turn it into a reality, and seeing where they stumble.
Agentforce Vibes impressed me a lot. I was able to build Salesforce-specific technical assets with just a few utterances, and it more or less went exactly as it should have from beginning to end.
I was grateful for the guided tour. While I have used vibe coding tools like this one before, it was great to see the care that Salesforce is taking to ensure their tool is as error-free, safe, and controlled as possible to avoid causing issues.
Their guidance explained that everything that Vibes recognized as an action that it needed to take was broken down as a ‘Task’ (not like a CRM Task, but just a separate point in the output that you could see being actioned or not actioned).
It also explained that there was a rules JSON file that you could use to store additional prompt content that would apply across the board. I opened this file up and had a read through, it basically was putting up some pretty tight guardrails (which was good in this case) for things like “The custom object that is created MUST be called “Todo__c”.
Final Thoughts
Overall, I liked it. However, I did have questions about just who the audience is for this, like all vibe coding tools. I don’t believe vibe coding tools are bad, nor do I believe they are perfect. I believe that, just like with any powerful Salesforce tool (Flow, I’m looking at you), with great power comes great responsibility.
My opinion is that Agentforce Vibes should be used only if you have the skills and knowledge to at least read the code enough to identify what it is trying to do. The last thing you want is to be using a tool that is creating powerful code under the covers that you’re not aware of, or creating test classes that test to pass rather than test to test.
I know this is a heated topic, so tell me: what are your thoughts on Agentforce Vibes, or vibe coding in general? Can you see the value in a tool like this, or are you only able to see a future where code is generated but not understood, which will lead to further issues? Be sure to reach out to me on LinkedIn or drop a comment below!
Comments: