'Vibe coding' usually brings to mind AI churning out Apex or LWC, but for a Salesforce Admin the useful applications sit somewhere else entirely. These are the pragmatic ones: the places where AI-assisted work saves real time without demanding deep coding expertise.
What 'vibe coding' actually means for admins
There is a difference between asking AI to write Apex or LWC and asking it for declarative or metadata work. It can produce output either way. What does not change is that someone has to understand and validate what comes back. For Admins, the technique earns its keep when it is pointed at the work they already own.
When not to 'vibe code'
- Flows. Flow is a point-and-click tool. Its underlying structure is XML, but trying to 'vibe code' a whole Flow through that XML is inefficient and error-prone. The visual builder exists for declarative users, and manipulating the XML directly, even with AI helping, adds unnecessary complexity and invites syntax errors.
- Complex Apex or LWC. Admins without a foundational understanding of Apex or LWC should not use AI to generate those components for production. They are worth playing with in a sandbox, for learning and experimentation. Deploying unverified, complex code is where it goes wrong.
Where admins should use 'vibe coding'
It earns its place when it accelerates metadata creation, generates formulas, and helps with data architecture, as long as you validate the output properly.
1. Permission set generation
Salesforce's strategic recommendation to use Permission Sets and Permission Set Groups instead of assigning permissions directly on Profiles creates a lot of work for Admins. Building granular permission sets for every object, often with varying access levels (Read Only, Full Access), is slow, repetitive manual work.
AI can ingest a spreadsheet that already defines the permission set strategy and target objects, or it can work straight from a prompt that spells out object names, access levels and naming conventions.
A prompt with the information in it:
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:
Case (Case)
Project (Project__c)
Canvas (Canvas__c)
Server (Server__c)
Hatch Type (Hatch_Type__c)
What you get back is the time: you stop hand-building permission set after permission set and spend that effort on the strategic grouping and assignment instead.
2. Formula field writing
Plenty of Admins write soql-where-clause-best-practices/" class="auto-link">formula fields comfortably, but it is still slow going for complex logic or when a lot of custom fields are involved.
AI can read a natural language description of the calculation you want, apply Salesforce's own formula syntax and documented practices, and structure the logic to cope with nulls and other edge cases. That last part is exactly where you need to check its work.
A prompt for 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.
A prompt for a 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.
This gets you to a working formula faster and keeps your attention on the business logic rather than the syntax. Review and test whatever comes back.
3. Data architecting and data model building
As the Salesforce Admin role evolves, architectural decisions come with it, and AI can help define and generate custom object and field metadata.
Flows and object/field definitions are both XML underneath, but object and field creation is less nuanced and more straightforward than complex Flow logic, which is why it works here and not there. Bulk creation and new data models are where it pays off most.
Use 'Plan Mode' in your AI tool to preview the intended metadata changes before anything executes. Misunderstandings surface there, while they are still cheap to correct.
A prompt for an 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.
Equipment (Equipment__c). Description: The actual asset that is being rented out.
Rental Agreement (Rental_Agreement__c). Description: References the Customer and the Equipment, and manages the relationship between the two.
(Equipment__c) object called Equipment (Equipment__c). Do not use Lookup for these fields.
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.
A prompt for 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.
Type (Type__c), Picklist field (Values: Maintenance, Repair, Warranty). Description: What type of maintenance is this?
Maintenance Date (Maintenance_Date__c), Date field. Description: When did the maintenance occur?
Status (Status__c), Picklist field (Values: Scheduled, In Progress, Complete, Cancelled). Description: The completion status of the maintenance instance.
The gain again is speed: new objects, or a pile of fields across existing ones, leaving the strategic data design to you.
Responsible 'vibe coding' for admins
The primary concern with AI-assisted work is building things in a technology you do not understand well enough to validate. If you cannot read Apex, do not rely on AI to write Apex for production.
Point it at permission sets, formulas and data models instead, where your declarative knowledge is enough to tell good output from bad, and it becomes a genuine productivity gain. Use it to go faster inside your own domain of expertise, not to skip learning how the thing works.
Leave a Comment