If you’re evaluating AI-assisted development for your Salesforce org, you’ve probably seen the pitch: describe what you want, AI writes the code, ship it. And that pitch isn’t wrong, exactly. I’ve shipped production apps this way — a trade program management system and custom quote-to-cash functionality — using thousands of AI messages.
But if I only told you the success stories, I’d be selling you a fantasy version of this technology.
So here’s the honest post. The one where AI was confidently, sometimes spectacularly, wrong — and where two decades of Salesforce platform experience was the only thing standing between “shipped on time” and “shipped with bugs nobody would have caught until a sales rep called screaming.”
The 2800% Bug
This is my favorite example because it’s so perfectly illustrative of how AI fails.
I was building the trade program management system. Margins are central to the entire application — every decision the sales team makes depends on knowing their margin percentages. The AI wrote the calculation logic, the LWC components, the formatting. It all looked right in the code.
Then I looked at the screen and saw 2800% where there should have been 28%.
Here’s what happened: Salesforce stores percent fields as whole numbers internally — 28% is stored as 28, not 0.28. But in certain contexts, when you access that value through Apex or in an LWC, the behavior varies. The AI wrote code that multiplied by 100 to “convert to percentage display” — a perfectly reasonable thing to do if you’re working with a decimal-stored value. Except the value was already 28, not 0.28. So 28 x 100 = 2800%.
The AI didn’t know it was wrong. It couldn’t know. This is a Salesforce platform-specific behavior that isn’t consistently documented, varies by field type and access method, and trips up experienced developers too. The AI had no way to reason about it from first principles — it would need to have actually worked with Salesforce percent fields to know the gotcha.
I looked at the output and immediately knew what was wrong. Not because I’m smarter than the AI — because I’ve been burned by this exact behavior before, probably more than once, across twenty years of building on this platform.
The fix took about two minutes once I identified it. But identifying it required experience that no amount of training data can fully replicate.
And here’s why this matters beyond the code: if that bug had shipped, every margin calculation the sales team relied on would have been wrong by orders of magnitude. Deals would have been approved that shouldn’t have been. The team that already didn’t trust their old tool would have had even less reason to trust the new one. A two-minute technical fix prevented what could have been a months-long credibility problem.
The Overengineered Formula Workaround
This one taught me something about how AI approaches problem-solving on constrained platforms.
We hit the 15-object limit in Salesforce cross-object formulas. This is a hard platform limit — you can’t reference fields across more than 15 object relationships in a single formula. We needed data from objects that pushed past that boundary.
The AI’s suggestion? A complex architecture involving calculated fields, scheduled Apex jobs, and what amounted to a miniature ETL pipeline to pre-compute and cache the values. It was technically sound. It was also massively overengineered for what we needed.
The right answer — the one any experienced Salesforce architect would reach for first — was denormalization. Copy the value you need onto a closer object with a simple field update. One flow, one field, done. It’s the kind of pragmatic platform decision that comes from knowing what scales on Salesforce and what turns into a maintenance nightmare.
The AI didn’t suggest this because, I think, it was optimizing for architectural purity rather than platform pragmatism. In a generic software engineering context, denormalization is a code smell. On Salesforce, it’s Tuesday. It’s how you work within the platform’s constraints without building a Rube Goldberg machine.
If I’d followed the AI’s suggestion, the system would have been more fragile, harder to maintain, and slower — solving an imaginary purity problem while creating real operational ones. And the next consultant who inherited the codebase would have spent their first two weeks untangling architecture that didn’t need to exist.
The Verbosity Problem
This one is more subtle but arguably more important for anyone building production code.
AI writes defensively. Very defensively. Every method gets null checks on every parameter. Every query gets wrapped in try-catch blocks that catch generic exceptions. Every calculation gets validated before and after. The code works, but it’s often two to three times longer than it needs to be.
In a one-off script, that’s fine. In a production application with dozens of classes, it creates real problems. More code means more to maintain. More to test. More surface area for bugs. And ironically, the defensive patterns sometimes masked actual errors — a null check that silently swallowed a problem instead of surfacing it.
I spent meaningful time across both projects pruning AI-generated code. Not fixing bugs, exactly — removing code that was technically correct but operationally unnecessary. Tightening methods. Removing redundant validation. Simplifying error handling to match what the platform actually needed versus what a paranoid generalist might assume.
This is the kind of editing that requires knowing the platform’s built-in protections. Salesforce already handles certain null scenarios, already validates certain inputs, already catches certain exceptions at the framework level. The AI didn’t know what was already covered, so it covered everything again.
When Tribal Knowledge Is the Only Knowledge
The AI can’t sit in a meeting with your sales ops team. It can’t watch a rep demonstrate the workaround they invented because the official tool was too slow. It can’t hear the VP say “we never actually use that field for what it was designed for.”
Both projects had significant business logic that lived entirely in people’s heads. Which account types use trade framework lookups. How lump sum rebates should be distributed across products. Which validation rules the team had been disabling manually because they blocked a legitimate workflow.
No screenshot or error message could communicate this knowledge. I had to learn it the old-fashioned way — conversations, questions, watching people work — and then translate it into specifications the AI could execute.
This is the part of AI-assisted development that doesn’t show up in demos. The demos show you the magic: describe what you want, get working code. What they skip is the hours spent figuring out what you actually want — the requirements gathering, the domain understanding, the organizational knowledge that makes the difference between code that compiles and code that solves the right problem.
What This Means for You
If you’re evaluating whether AI-assisted development is right for your next Salesforce project, here’s my honest assessment after shipping production apps this way:
AI dramatically accelerates the parts of development that are about translating known requirements into working code. If you know what you want built, and the requirements are clear, AI will get you there faster than you thought possible.
AI does not replace the expertise needed to know what should be built, how it should be architected for your specific platform, or where the platform’s quirks will bite you. That knowledge — platform experience, domain understanding, organizational context — is actually more valuable in an AI-assisted workflow, not less, because the speed of code generation means architectural mistakes compound faster.
The builders who will get the most out of this technology aren’t the ones who trust it blindly. They’re the ones who know enough to catch what it gets wrong, redirect it when it’s heading down a bad path, and bring the contextual knowledge that no training dataset contains.
Your expertise directs the build. AI is the engine. You’re the driver. And if you don’t know the roads, a faster engine just gets you lost faster.
If you’re weighing whether AI-assisted development is right for your next Salesforce project — or if you’ve already started and are hitting walls that feel like the ones I’ve described — that’s exactly the kind of conversation I like having. Find me on LinkedIn.