Vibe Coding for Salesforce Admins: Top Use Cases and Pitfalls

I recently wrote an article that talked about why you shouldn’t be vibe coding Flows in Salesforce. Flow is designed to be a point-and-click tool, and while it is possible to write a Flow’s XML file, it doesn’t make sense to. 

That being said, I am a big fan of vibe coding, and I believe more Salesforce Admins should take advantage of it. In this article, I’ll explain why vibe coding isn’t something that Salesforce Admins should be afraid of, and give you some practical tips on how to use vibe coding in your day-to-day. 

Don’t Vibe Code Flows

My personal stance is that I don’t use vibe coding tools like Agentforce Vibes, Claude Code, or OpenAI Codex to write Flows. In fact, I wonder whether the future of Flow will be affected by the fact that it is an XML file rather than something more standardized, like Apex or LWC – but that’s not so important to this discussion. 

Given that Flows are a clicks, not code tool, and they’re typically built by declarative users in a custom builder, it doesn’t make sense to write the XML in plain text – human or AI. You wouldn’t ask a developer to write a Flow in plain text, would you? This is the same reason that I don’t think that it’s a good use of time or resources to use an agentic coding tool to build a Flow’s XML file, either.

Where Admins Should Use Vibe Coding

While the above makes it sound like I don’t like vibe coding, the opposite is true. If you know me, you’ll know that I’m a big believer in what vibe coding offers. I love that it helps developers focus on the bigger issues and leaves some of the actual code writing to the LLM. Architecture and strategic design become front-and-centre, while writing code can take a bit of a back seat.

That said, I’ve also stood by another statement – vibe coding is NOT a replacement for an experienced Salesforce Developer. Just because you can tell a vibe coding tool to go and do something, and it looks like it has done it, doesn’t mean it’s done it correctly. 

Best practice is important, as anyone who builds in the Salesforce ecosystem knows. You can build a Flow that looks like it’s doing what it’s supposed to do on the surface, but that doesn’t mean that it has been built with longevity or scalability in mind. The same applies to code written in Salesforce. It may work, but it may not survive the test of time if it’s not been designed carefully by someone who knows the technology intimately and knows what to look out for. 

So, why am I encouraging Salesforce Admins to vibe code, despite also saying that you should not build Flows, write Apex, or build Lightning Web Components? Great question! There are a lot of things that admins can do with vibe coding that are not blindly trusting the output – it can be validated.

Vibe Coding Use Cases for Salesforce Admins

Here are some examples of where Salesforce Admins may find that vibe coding is beneficial to their workflow, and using vibe coding tools is a responsible choice. 

Permission Set Generation

With Salesforce’s recommendation of moving permissions to permission sets and PS groups instead of adding them to profiles, Salesforce Admins need to carefully consider how they will approach this challenge. 

One design strategy for permission sets is to have a dedicated permission set for each object and add those to the relevant permission set groups. You may even want to consider having a Read Only and Full Access Permission Set for each, or multiple in between. That’s a lot of permission sets, and it would take a long time to build by hand. 

This is where vibe coding can save you! You can choose to pass in a spreadsheet that clearly defines the permission set development strategy you want to use (as in, do you just want a single full access permission set per object, or do you want to build multiple?), and the objects that it needs to apply them to. 

Alternatively, if there’s only a handful or if you don’t have an external spreadsheet, you can just give your tool the required information in the prompt itself. 

Example Prompt (With Reference to an External Document)

Refer to the attached Permission Set Creation Guide. Refer to the data within it to create a permission set for each of the specified objects. Do not attempt to deploy the permission sets; let me know when you are done. Do not deviate from the plan. Ask me questions if you require any further information. 

Example Prompt (Information in the Prompt)

I have built a number of Custom Objects that need Permission Sets built. For each Object, create a Full Access Permission Set and a Read Only Permission Set. 

The Full Access Permission Set should give Create, Read, Edit, and Delete permissions to the object, as well as View All Fields. It should be called “{ObjectLabel} – Full Access” (i.e. Case – Full Access) and the description should be “Full access to the {ObjectLabel} object, including View All Fields.”, replacing {ObjectLabel} with the label value of the Object.

The View Only Permission Set should give Read permissions to the object only, no further field access. It should be called “{ObjectLabel} – Read Only” (i.e. Case – Read Only) and the description should be “Read only access to the {ObjectLabel} object.”, replacing {ObjectLabel} with the label value of the Object.

The Objects (Label, then API name) are as follows:

1. Case (Case)
2. Project (Project__c)
3. Canvas (Canvas__c)
4. Server (Server__c)
5. Hatch Type (Hatch_Type__c)

Formula Writing

I’ve said in the past that I haven’t written a formula field by hand for years. Not because I can’t, but because it saves me time… and quite frankly, I’m lazy. Bill Gates famously said, “I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it”, so I take this as a positive thing!

After ensuring that my vibe coding tool of choice (could be Agentforce Vibes, could be Claude Code, or whatever you’d prefer!) is aware of how to construct a formula field in Salesforce by feeding it Salesforce’s official documentation, it’s as simple as giving it the context (any custom fields that are involved) and asking it to construct the formula for you. 

As usual, it is important to validate the output and make sure that the formula is behaving the way you expect it to. You can also review the formula output of the LLM to confirm that it is structured the way you would expect it to, including handling any outlier values. 

Example Prompt (Net Revenue)

Create a formula that takes the Amount field, subtracts the Discount Amount field value, then adds the Shipping Fee (if there is one). The output needs to be a currency value. 

Example Prompt (Quick Lead Score)

Write a formula that gives a numeric score. Give them 50 points if the Rating field is ‘Hot’, 30 if ‘Medium’, and 10 if ‘Cold’. Give them 25 points if their Industry field is ‘Technology’, 20 if it is ‘Health’, 20 if it is ‘Education’, and 10 if it is ‘Construction’. Give them a bonus 10 points if their Annual Revenue is over one million, otherwise don’t give any bonus points. 

Data Architecting and Data Model Building

With the Salesforce Admin role changing rapidly, an admin needs to know how and when to make an architectural decision for their business. That being said, you don’t need to actually do the build manually anymore. This is where you can leverage the power of AI to build your object and field metadata for you.

Now, I can hear what you’re saying: I’ve previously said that it doesn’t make sense to build Flows because the underlying code is XML, and Flows are designed to be built with clicks. Object and field building is also designed to be built by clicks, and objects and fields are also XML files. What gives?!

Put simply: Flow has a lot of nuance, and objects and fields are relatively straightforward. You may find that it’s quicker to build the Flow yourself because you’ll spend less time fixing syntax errors. Objects and fields are significantly simpler, and it is likely going to save you time leveraging AI for building these in bulk. 

Use Plan Mode in Agentforce Vibes or your preferred vibe coding tool to ensure that the tool understands exactly what it needs to build before taking action. This will save you time in unpicking any mistakes it makes or misunderstandings it has.

Example Prompt (Equipment Rental Tracking Data Model)

Build the following custom objects, and relate them using standard lookup fields. Make sure to populate the description on the object itself. These are all brand new objects, and they do not currently exist in the org.

1. Equipment (Equipment__c). Description: The actual asset that is being rented out.
2. Rental Agreement (Rental_Agreement__c). Description: References the Customer and the Equipment, and manages the relationship between the two. 
3. (Equipment__c) object called Equipment (Equipment__c). Do not use Lookup for these fields.
4. Equipment Maintenance (Equipment_Maintenance__c). Description: A log of any repairs or maintenance made to a piece of equipment.

The Rental Agreement needs to have a Master Detail field referencing the Account object called Customer (Customer__c), and another Master Detail field referencing the Equipment. Also, this needs to look up to an Equipment__c record.

Example Prompt (Adding Fields to an Object)

Add the following fields to the Equipment_Maintenance__c object. When you’ve created the fields, add them to the existing Permission Set called Equipment Maintenance Full Access, granting Read and Edit permissions to that Permission Set for each field.

1. Type (Type__c), Picklist field (Values: Maintenance, Repair, Warranty). Description: What type of maintenance is this?
2. Maintenance Date (Maintenance_Date__c), Date field. Description: When did the maintenance occur?
3. Status (Status__c), Picklist field (Values: Scheduled, In Progress, Complete, Cancelled). Description: The completion status of the maintenance instance.

Responsible Vibe Coding for Salesforce Admins

There is a lot to consider when you’re using vibe coding in your Salesforce Admin world. There are many warnings as to how you should or should not use it. Some even suggest that admins should not vibe code at all. I disagree with this statement, but I do believe that you need to be very specific in how you use it.

The reason that some say you should not vibe code is that they assume you’ll go off and try to build something in a technology that you do not understand, and cannot verify properly. For example, if you don’t understand how Apex works and cannot write a single line of code yourself – nor can you read it and understand what it does – then you should not get a vibe coding tool to build Apex for you (at least not for a Production environment – in a learning setting is fine). 

Using vibe coding to speed up the development of things that you DO understand, and CAN validate yourself, is exactly what you should be using it for. If it will take you a few hours to build a handful of custom objects, fields, and permission sets, and only a few minutes to pass your templates into a vibe coding tool and instruct it to do it for you, great! Just make sure you check the output once it is done, and ensure it sticks to what you’ve instructed it to do. 

This is how you can responsibly use AI and vibe coding as a Salesforce Admin, and also evolve your strategic and architectural skills as you go. Hand off those repetitive tasks that take you ages to do, but confirm along the way that you are doing things properly.

Do not try to get it to build things that you don’t understand if your goal is to do it in a Production org. I specifically say this because I strongly believe in AI as a great teaching tool – getting it to walk you through how a specific Apex function works is a great way to learn as you go. 

Asking it to guide you through writing your own Apex Method to do a simple function in a Developer Edition is a fantastic way to get practical experience as you learn. 

Summary

Vibe coding is not something to be scared of! It’s not here to replace you or take your job. It’s not going to do anything silly and dangerous if you’re not dabbling in unknown technologies. It’s here to help you speed up your workflows, once you learn to use it properly.

How do you learn how to use it properly? By giving it a go yourself. I highly recommend you jump in and practice some vibe coding in a Developer Edition org. Give it a challenge – see how quickly it can build something trivial for you. Use it to help you understand a concept you’re not super familiar with. It’s a tool, use it!