Recently, the Development Team at Nebula was tasked with testing Agentforce Vibes and its ability to generate a new piece of functionality.
Agentforce Vibes was launched as a rebrand of Agentforce for Developers in October ‘25, with an emphasis on Agentic Code Generation – being able to generate code from natural language inputs. A major feature is its ability to know about your own codebase and generate code using your org’s metadata.
Here’s how we got on…
Dan – Head of Development
Firstly, let me call this out: I don’t like VS Code. Here at Nebula, we use Webstorm & the Illuminated Cloud 2 plugin as our Salesforce IDE of choice. VS Code and its extensions are improving, but represent some way off IC2 in my opinion. Having said that, Agentforce Vibes isn’t currently available in IC2, so VS Code it is!
As my first foray into using Agentforce Vibes, I wanted to generate something familiar, something I could directly compare it with. I asked it to write an LWC date picker component with specific date ranges that also allows manual selection. I gave my instructions, including asking it to use a date handling library, momentjs.
The Good
Surprisingly, based on my request, it came up with a plan. Not only that, but it had further questions to ask! I was actually very surprised by this. From my experience with other AI code-generating tools, it would normally generate directly, and then you would need to refine to get to the output you wanted.
As it created each piece of metadata, it would ask me to confirm I was happy with it before saving it. It created the static resource for the momentjs library and the LWC with all the bundle components.
The HTML and JS generated in my test were actually pretty good. I’d say a good 80% of what you’d want. Yes, the other 20% did need some finessing, but for a few seconds of effort, this was acceptable.
The Bad
So let’s talk about that 20%. Now I’m sure some will think this is being picky, but I like a clean camp.
- It generated an empty CSS file for no reason.
- It also generated an empty connectedCallback method.
- The HTML used class=”slds-card” instead of the base card component.
- There was needless use of the @track decorator for simple variables. We haven’t needed this since Spring 2020 unless dealing with an object or array.
- The use of if:true/if:false instead of lwc:if.
Paul discovered some of the above issues are down to the ruleset being used, but seriously, why would you ship a default ruleset that is so outdated?!
The Ugly
Unfortunately, the validation for the manual entry of dates didn’t work, and as really the only bit of meaningful code, it was a bit of a let-down.
Nothing deployed automatically as part of this process. Looking at the deployment log, this was because the LWC was trying to reference the static resource that did not exist yet. I’m not sure if the deployment should be manual, and this was user error. But logging in to my scratch org, I was expecting to be able to add my newly created component to a page.
Dan’s Final Thoughts
Agentforce Vibes is good, really good. The fact that I can get 80% of LWC built in a matter of seconds is great. I can imagine creating test classes for an existing class being extremely useful.
But 80% is not production-ready; this is not code that I would want to deploy. All this code needs to be checked and tested, and despite a comment at the top of the JS file stating “Follows SLDS and LWC best practices”, it didn’t.
As a developer, am I worried about my job security because of AI? Is AI going to replace me? I don’t think so, not in its current state. For me, this is another tool that I can call upon to help me focus on the more complex problems and let the AI deal with repetitive boilerplate code we see so much of in Salesforce.
Jason – Senior Salesforce Developer
The Vibe Coding trend has significantly influenced Salesforce. My mission was to determine its limitations and assess the ease of creating new functionality with it. My initial prompt detailed information about a Kanban board, with a design similar to Trello.
Agentforce Vibes began planning the steps and posed a few initial questions:
- Is there an existing data model you would like to integrate the web component with?
- If so, which fields should be used? If no existing data model exists, would setting up mock data suffice?
I chose the second option as there was no existing data model in my scratch org. To my surprise, the component looked and partially functioned exactly as expected. It had distinct status columns and the ability to tag cards with additional information.
However, the fundamental drag-and-drop feature did not work. Debugging the drag-and-drop feature took a few attempts. After reviewing the code, I provided the tool with some pointers on where I suspected the bug might be. This clearly demonstrates that Agentforce Vibes, or any LLM tooling, still requires some developer expertise. Eventually, the bug was fixed!
Apart from new functionality, I also wanted to create an existing, advanced mapping Apex function that we use frequently at Nebula. (For more details on this, see our blog here). The function worked well and even included edge cases, which I had not elaborated on. Furthermore, it also created an extra invocable class. Upon testing the invocable class, I found some fundamental flaws, including the use of Enums as an input parameter.
I followed up with a new prompt, asking the Agent to create a Flow demonstrating the usage of this invocable class. The Agent ran into several issues, including metadata syntax errors and deployment problems. Eventually, it reached its Pro model limit.
What I found really useful was the ability to ask the Agent to document the code it had written and provide examples. The Agent proceeded to create a thorough README. One feature that particularly impressed me was the ability to directly ask the Agent to fix an error returned in the IDE terminal. This could genuinely streamline the debugging process when working with an Agent.
Overall, I think Agentforce Vibes is a great addition by Salesforce. It can significantly help in building proof-of-concepts quickly. The development landscape is slowly changing, but for now, it’s simply another weapon in your arsenal.
Libby – Salesforce Developer
I decided to see how Agentforce Vibes would deal with a pretty simple request: could it create an LWC to display all the Cases related to an Account on the Account record page? My expectation was that it should create a lightning-datatable to display the cases, make it available to add to the record page and get the data successfully.
How did it do?
The vibes were pretty good and it managed to create an LWC using lightning-datatable and several other prebuilt lightning components on its first go and make it available to add to the record page. I was also impressed to see that it managed to deploy everything successfully without my input. Although it did take several rounds of hitting deployment errors and then correcting them before it all went in properly. The UI choices were questionable but after a few rounds of prompting it with improvements it did manage to make edits to its own code and get the LWC looking much better. I would say that it was too ambitious, the agent had attempted searching, sorting and pagination but none of it worked properly and it was all implemented server-side. This could have been down to user error as I didn’t specify the functions I wanted in my table in enough detail so it’s definitely something to watch out for next time!
I didn’t like how the code was written:
- The LWC implementation had if:true/if:false all over the place and included a CSS file that wasn’t required, it also failed to use a wire adapter to get the data for the table.
- The Apex consisted of one extremely long method using a lot of unreadable variable names making it very hard to read or debug.
- Several wrapper classes for passing the data back to the LWC had been used despite a List of Cases being sufficient for the job and – crucially – much easier.
- The non-functioning search, sort and pagination code was all done in Apex whereas I would have done a lot of it client-side.
I can see the Agentforce Vibes approach being really useful for getting over blank-page anxiety – just getting the first basic implementation down and functioning in the org before you start doing anything fancy. If I were to use it again I would definitely change the ruleset first to reflect best practices and to try and encourage it towards writing code in a cleaner, more readable way. I would also plan out my prompt better and include a lot more detail to discourage the agent from making too many of its own design choices. Finally, I would definitely not let it write and deploy the whole thing before I started looking at it – it was fun as an experiment but ultimately I could not deploy that code to Production without going through it all and making significant changes. This would probably take longer than if I’d just written the whole thing from scratch, thus defeating the point of using AI.
I could see myself using Agentforce Vibes again to get the basic implementation for something down before I started implementing more complex logic but I would be reviewing the code as it was written and giving a lot of corrections as the agent worked. I wouldn’t trust it to write anything on its own just yet.
Paul – Principal Developer
Salesforce is great at hyping up new features, but sometimes they’re just not ready to prime-time. Agentforce Vibes is billed as a smarter AI which can build components and write code based on your own orgs metadata. In reality, whilst it does do that, it seems to fall short in its generated code.
Sometimes it would code a Lightning Web Component (LWC) with Lightning Base components, and sometimes it would use Lightning Design System (SLDS) classes and divs. It also seems to favour the if:true/if:false directives (instead of lwc:if/lwc:else) when conditionally rendering components, something Salesforce no longer recommends, yet Agentforce Vibes seems very keen to include.
Its ability to generate XML, such as field and object specifications, is impressive, but I’ve seen instances where the field types aren’t correct, and child objects in Master-Detail having the sharing incorrectly set. These should be fixable. If the Agent does manage to deploy the code, it can see the errors and attempt to fix them, but I’ve had instances where it has claimed to have completed all the tasks when it clearly hasn’t.
I tried a number of times to generate a flow, and it just couldn’t get the XML correct.
Every time I used it, I eventually hit an alert:
“Your org has reached its usage limit for the Pro model, so you’ve been temporarily switched to the Core model. You can switch back once the limit resets (24 hours)”
This included a link to a help guide, but I can’t see how to switch to Pro permanently, or use my own AI service.
One feature I did like was Deep Planning. Being able to task the agent to build a plan of what should be done, based on the orgs existing metadata. These plans could then be tweaked before being handed back to the agent to build. Maybe we could use the Deep Planning feature to create our own plans.
As with all LLM-based AI, you get out what you put in. Being vague results in wild assumptions. Being specific, crafting your prompts and developing a plan before you task it, and you’ll get much better results.
Resources
- Agentforce Vibes Extension | Salesforce Developers
