At this year’s TrailblazerDX, Salesforce made sure that every keynote, every session, and every sign in the hall delivered the same carefully crafted message about its AI solutions: “Trust us.”
Salesforce knows customers won’t embrace AI until they believe fully that their data is safe. Thus we’re told that its Einstein AI solutions don’t use or even see customer data. “Your data is not our product,” goes the mantra.
Terrific. That’s what we want to hear.
But there’s another capability of Einstein AI where this data-blindness trust model doesn’t fit - and it’s not really talked about. So let’s surface it here.
We can now use Einstein AI solutions to generate Apex code and create Salesforce Flows. How tempting is that? Just prompt Einstein in natural language and - poof! - instant solution. Soon we’ll be able to develop applications nearly as fast as we can describe them.
And that’s the problem.
It’s not that we shouldn’t trust AI. It’s that we shouldn’t trust ourselves.
“We Have Met the Enemy and He Is Us”
You may have seen the truth in this from your own experience. Any Salesforce developer or admin who’s been around for awhile has seen errors that caused havoc for the organization. In my own years as a senior developer, a consultant, and now as CEO of Pharos, I’ve witnessed some doozies:
- Broken flows that kept a financial company from processing millions of dollars in transactions.
- Critical emails that didn’t trigger for weeks, so that hundreds of customer contracts were never sent
- Home-grown logging designed to catch a serious error - but never reported one because the logging program itself had a bug.
Such havoc is always caused by a bit of bad code or failed flow logic. It happens. To err is human.
But if human-generated code can’t be trusted, can we trust code generated by AI?
Hell no! But history suggests we will anyway.
The problem resides in our flawed response to processes. We expect newly crafted code to be buggy. That’s why we test. And there will be scenarios we can’t anticipate, those “unknown unknowns,” that break programs we thought were bullet-proof. That’s why we troubleshoot.
Yet, in spite of knowing these things, we humans sometimes take shortcuts. Perhaps we’re under pressure to deliver new features on a crazy timeline. Or maybe we make reasonable assumptions and skip performance testing, only to find out the hard way that our assumptions were dead wrong.
Sometimes we break the rules. Of course, you would never do this, but maybe you’ve heard of developers who didn’t have time to run their freshly minted Apex code through compulsory unit testing. So, to achieve 75% code coverage before deploying, they gamed the system. (Not recommended.)
As for Flows, well, heck. Unlike Apex code, Flows have no guardrails at all. No compulsory testing, no mechanism to enforce QA. Admins can build and activate a Salesforce Flow directly in production.
Take that last fact and add AI to it, and you have this plausible scenario:
Our imaginary admin Ken is pressed by the VP of Sales to create a new feature, “needed yesterday.” Like a lot of admins, Ken often works closely with stakeholders and in some ways is accountable to them. So, under pressure, Ken commits to adding the capability “in a couple of hours.” He soon learns his developers can’t get to the request for two weeks. But then he has an epiphany: he realizes he can build a Flow that would solve the problem in a jiffy.
It’s a complex Flow and doing it manually would take time and probably be outside his comfort zone. So he dives into Einstein and uses AI to generate what he needs in no time. Done! Flow deployed!
Wow, it was so easy that the next day he uses AI to build another Flow request right in production. So efficient! He can hardly wait to share the technique with his office mate and fellow admin Barb. Before long, Ken and Barb are using AI to crank out several untested flows a week.
Ken and Barb celebrate their increased efficiencies after using AI to generate Flows, even though the lack of QA cost Barb a leg and warped time and space.
When Not to Go with the Flow
On the surface, all this efficiency sounds great. Except Ken and Barb are not taking into consideration the holistic magnitude of the changes they are introducing to the overall architecture. Or the unintended consequences that might not get triggered for a week or a month. And they aren’t taking into account the time it will take to troubleshoot errors when the org breaks, spectacularly, later on.
This is where we should be focusing our paranoia. The trust we need is larger than just being assured that our company data isn’t getting sucked into an LLM. It’s our processes that protect us from expensive problems and this is where we need to build a trusted framework.
Yet even in large and mature organizations, our processes can be sorely lacking or, with all good intentions, ignored. Processes can feel like friction, especially when you’re under the gun. But without a rigorous process, AI will only enable you to introduce more problems faster.
Now is a good moment in time to take a hard look at how your organization tests code and deploys flows - before AI gets too deeply embedded. Be candid in assessing how committed and faithful you and your team are to that process. Give AI output the same scrutiny—or more—that human output gets.
AI can make life easier but no matter how good the output looks, no matter how tempting it may be to skip steps with AI generated solutions, take the advice of Ronald Reagan when he quoted an old Russian proverb:
“Trust, but verify.”
