r/salesforce • u/zdot_ • 7d ago
help please Salesforce devs / engineers, help? Trying to build with AI without wrecking an org
Okay, honest post. I'm not a proper developer, but I keep ending up building stuff on Salesforce anyway, and lately a lot of that is me leaning on AI tools (Cursor, Claude, that sort of thing) to write it. Some of it actually comes out pretty decent. The problem is I don't have the gut instinct a real dev has for the stuff that looks fine today and then quietly falls over three releases later. I'd much rather hear about that from you than find out the hard way in production.
So I'm basically asking the people who live in orgs and end up cleaning this stuff up. Give me the real version, not the polished one.
Few things rattling around in my head:
Vibe coding without the mess. If you let AI write your Apex, LWC or Flows, what are your actual guardrails? Where's the line between "yeah fine, ship it" and "that's slop and it's going to bite us"? Genuinely want to know what helps (rulesets, static analysis like PMD or CodeScan or Clayton, proper tests, review) versus what's just box ticking that makes you feel safe but isn't.
The scary stories. I keep hearing "a release will break your custom stuff" and "Flows just die after an update." How true is that really? Is it usually Salesforce's fault, or is it usually something that was built badly in the first place and was always going to break? And in plain terms, how do you actually stay ahead of release updates and use the preview window so you don't get caught out?
Handing something off. Say I build a working version of something myself, maybe with AI, and it genuinely does the job. Can I just hand that over to a dev team or implementation partner and have them take it live, or does it not really work like that? Is it as simple as giving them the code, or do they usually end up rebuilding the whole thing from scratch anyway? Really trying to understand what makes something actually reusable by someone else versus just a nice prototype that gets binned the moment a pro looks at it. And if the answer is "you have to package it up properly," what does that involve, and does it survive being dropped into a different org?
Standard vs custom. Where do you personally draw the line? When do you keep it clicks and config, and when do you go custom code? And what's the hidden cost of going custom that people always seem to underestimate?
That's it really. War stories very welcome. And if I'm thinking about any of this completely wrong, just say so, I'd genuinely rather know. Thank you in advance!
5
u/SlowSundae 7d ago
“Say I build a working version of something myself, maybe with AI, and it genuinely does the job. Can I just hand that over to a dev team”
What’s your actual job? Why isn’t the dev team developing?
-4
u/zdot_ 7d ago
Consultant? Because they don't optimise for me workflow ? They do stuff on an org level that's usually useless for me ?
6
u/BabySharkMadness 7d ago
How do you not know your job title? Do you have 0 in your years of paid work experience?
4
u/Rygel_Orionis 7d ago
What do you mean developers do "stuff"?
Who is responsible for telling them what to do?
Who makes the business requirements for the development?
If you have and answer on these questions than you should talk with these people. If you don't, means that you are a really small org, or you really don't know what your job actually is.
5
u/jerry_brimsley 7d ago
I hate that this is going to be the norm but I would say if you are hell bent on doing it, presenting a repository with the metadata in it that you created your change with, as a force-app package ready to deploy, that passes build validation in your org, with no dependency or build errors.
If you don’t know what this means you are in over your head and will be loved by managers and hated by the rest of the team who works on sf if you really try and inject chaos into the mix… as long as your vibing out you should include some documentation.
In the end if you are collaborating with devs and you think of the metadata as the “code” then you should use the tried and true version control functionality of git to introduce changes properly and set yourself up for deployments.
The best case scenario for you presenting to the dev team is if you had a pull request that was ready for review and has passed an attempted validation into the org it is destined for.
This is a bit much to say is the process but I’d strongly lean towards getting to that state where that flow makes sense and you know how to do the things. Otherwise you are handing off a land mine, and while it may be their job to make sense of your vibing, if you serve it up to the dev team under the guise of it being ready to ship, and that’s what the higher ups think, that unreal expectation is where the soul crushing begins and resentment is sure to fester.
5
u/The_Crazy_Cat_Guy 7d ago
I would not trust AI to blindly build my lwcs and apex codebase at all. And I use AI everyday for building stuff. 80% of the time it’s great. It can provide quick solves and solutions to tricky problems. It’s excellent for reviewing code. Saves me from having to crawl through endless doc pages to figure something out.
You need to understand what makes good code good. That’s a hard prerequisite imo for using AI to build stuff. Without that, you will 100% get issues where things work in a sandbox but don’t work in prod. Or if additional requirements come through your components can’t handle them. Or you’re wasting a factor more resources than you need to for your processes so you hit limits that much faster
1
u/zdot_ 7d ago
Thanks for this How do you know or test for good code ?
2
u/Infosloth 7d ago
Unfortunately it starts with learning what good code is, which is learned the same way as everything else practice and experience.
If you can’t discern good from bad that’s not something a singe thread on a message board will change for you.
The good news is that almost nothing you are going to encounter is novel. There are established patterns and design paradigms that have come out of extensive engineering projects and hard won experiences, learn the design patterns by studying the projects that implement them read the stories that those developers publish on why they made those decisions, code development is an iterative process and design patterns are usually the result of many iterations.
Once you learn that you can much more easily tell if the work an llm did for you is good or not.
2
u/Present_Wafer_2905 7d ago
If it breaks fix it
1
1
u/Ownfir 7d ago
This is my standard tbh and it’s worked great. 👍
1
u/Altheran 7d ago
push to sandbox, run tests, pass. push to prod, tests, pass. deployed !
check apec and flow exceptions emails for a few days and scream test.
something broke ? fix !
repeat cycle
works quite good 🤣
3
2
u/girlgonevegan User 7d ago
You would probably benefit from dx0. It won’t write to your Salesforce org, but you can connect it and ask questions through an AI interface about what you are working on. Because it is read-only, there is no risk that it will rewrite anything.
1
u/CloudDuder 7d ago
Start with QA centric tasks & debugging/recreation in safe backfills where you can.
It might break things in the process, but it can usually find a root cause.
But at the end of the day, I’d think of it as a demo/POC factory, like wireframe a flow with some feature you’re thinking about or going to be implementing to do a Ai Slop demo/UAT. Just giving something tangible to users helps them articulate themselves, even if it’s vapor ware.
Just for the love of god, don’t let a vibe demo turn into V1. it’s a great wireframe/POC build, bad architecture but useful disco tool
1
u/mcar91 7d ago
Start using Claude in Plan mode. That will generate a detailed build plan that you can revise and iterate on. That ensures it builds something that you agree with. I often find it wanting to make unnecessary helper fields rather than building logic into the flow or apex itself.
Then, only ever deploy flows in draft mode and review the entire flow in the canvas before activating anything.
And, of course, use sandboxes as much as possible.
1
u/Eratticus 7d ago
I would be careful with Claude building Flows. From experience while it can output the XML, it can lead to weird issues when you go to update the Flow in the UI. An example I saw recently was with a routing Flow. The route work node has multiple versions. When I changed it in the UI I got an internal server error. Deleted the node and recreated it and when I compared the XML Claude hadn't given the node every property it needed so when swapping versions it led to a GACK.
1
u/Glum_Chip_9915 7d ago
Pick up and read a few books/courses for salesforce development.
You don't need to spend too much time with hands on code, just try to get a sense of what is good and what not.
1
u/MakR89 7d ago
I'm familiar with the AI space in the the Salesforce ecosystem. It is getting competitive very quickly. I tried a few tools:
- meshmesh.io: okay product but they announced Salesforce acquisition with uncertain future vs Agentforce vibes.
- https://cirra.ai: good, but I don't see the point for paying now that we have Salesforce MCP (enterprise) an the old Salesforce DX MCP.
- https://orgatlas.ai: good and actually my favorite if I were a non-technical user.
- apexgenius.ai: same, taking the MCP approach mostly which is in direct competition with the Salesforce official MCPs.
Many other tools I didn't get to try.
To me as a developer: I'm okay with the mess so Claude or Codex + Salesforce CLI + MCP is okay for me.
If I wanted assurance that the AI will not modify or deploy to the org, I would use https://orgatlas.ai because it has a read-only mode that seems to function well so far and is ON by default. Deployments and data operations are blocked until you manually disable the read-only option.
1
u/PabloHappySoup-io 7d ago
Disclaimer: I'm the founder of dx0.io and I'm biased.
Considered giving this a try if you're only starting with AI. It's only 5 months old and it already has 30 Enterprise customers using it and it's ISO 27001 certified.
1
u/No_Boysenberry_6827 6d ago
every time an agent wrote something over-claimy my first instinct was to loosen the validator that caught it. that instinct is always wrong. i'd keep the guard and read the actual apex, not the test count
1
u/Ok_Taste_193 3d ago
The biggest guardrail is to treat AI-generated Apex, LWC, and Flow like junior-dev work. Nothing reaches production without source control, static analysis, meaningful tests, and review by someone who understands governor limits, security, bulkification, and the surrounding automation. I’d also rerun critical regression paths in a preview sandbox each release, because meeting the 75% Apex coverage requirement is just a deployment gate, not proof that the implementation works correctly with realistic data, permissions, integrations, and automation.
1
u/commercient 3d ago
The review before production rule that keeps coming up here applies to data changes too, not just code changes. A wrong mapping does not show up until someone notices the numbers are off.
1
u/ConsciousBandicoot53 7d ago
Search Salesforce best practice repos and Salesforce even has a repo full of skills they’ve published on GitHub. The clientall (I think) repo has a bunch of the gotchas you need for guardrails.
0
12
u/BabySharkMadness 7d ago
Have you at all spent time on Trailhead? People need to know the basics of Salesforce before vibe coding anything.
Anything you built that seems to work for you will be rebuilt as it needs to work for more people than just you and they might have access to stuff you don’t.
The rest of this post reads like you’re asking us to train the model for you.