Every Salesforce team I talk to has an AI horror story. An Apex class that looked perfect until it didn’t. A flow that passed review and broke in production. Someone confidently deployed AI-generated code, and someone else spent a weekend cleaning up the mess.
And yet, the gap is widening. Some teams are getting real value from AI. Shipping faster and reclaiming time for work that matters. Others tried it, got burnt, and decided AI “isn’t ready yet.” The difference between these teams lies in how they approached it.
The problem is that some are using AI incorrectly. And many don’t have the foundations in place to use it safely.
DevOps Is Not Optional Anymore
If you’re not practicing DevOps well, you’re not ready for AI. DevOps is grounded in predictable outcomes, which is the tonic to the non-deterministic output we’ve naturalized through the use of AI.
AI-generated code is probabilistic. It’s not guaranteed to be correct. It might look right, pass the “eyeball test”, and still have subtle bugs surfacing in production. A study by Notre Dame University found that developers found that AI code’s syntax is cleaner and therefore easier to read, but is weaker logically. However, this alone isn’t a reason to avoid AI.
The teams getting value from AI are the ones with deterministic safeguards already in place: code reviews that actually catch problems, automated testing that validates behavior, observability that tells them when something’s wrong, and backup that lets them recover when things go sideways.
AI accelerates whatever process you already have. If your process includes proper review, testing, and validation, AI helps you move faster through that process. If your process is “deploy and hope,” AI just helps you break things faster.
Embrace Simplicity, Then Push the Boundaries
Throwing AI your most complex work from the outset is a recipe for failure. Start with repetitive, well-defined tasks that eat up time but don’t require deep thinking.
Think about your week. How much is spent on work that’s clear, repetitive, and predictable? Writing test classes for straightforward triggers. Creating validation rules from well-documented requirements. Drafting fields and descriptions. Building the skeleton of an Apex class you’ve written a dozen times before.
This is the 20% of your work that’s perfectly suited for AI. It’s well-scoped, has predictable patterns, and you’ll know immediately if the output is wrong. And, there’s already a good chance that there’s a bunch of this work in your backlog.
Don’t hand AI the gnarly stuff first and expect it to execute. Complex integration logic, edge cases requiring deep knowledge of your org, architecture decisions that depend on context you can’t easily explain. AI, as it stands, struggles with those. But it doesn’t mean it should be avoided.
Models are improving at a rate we’re not accustomed to. In 2023, AI systems could solve just 4.4% of coding problems on SWE-bench. By 2024, that figure had jumped to 71.7%.
The things AI can handle now won’t be a limitation in the future. Continual curiosity is the order of the hour, and we should be testing the boundaries of what is possible consistently, without immediate expectations.
When AI fails on hard problems, it’s easy to lose trust. I, as I guess many of you, have bounced off using AI tools when they haven’t worked well, and am reticent to try them again. Starting with a small, well-defined scope will build confidence and repeatability, as well as give outputs you can measure.
If you’re measuring success against the gnarliest problems you can think of, then it’s easy to give up. James Dyson famously created over 5,000 prototypes before his simple idea, wrapped in complexity, was a reality. AI will get there too.
What You Could Be Doing Instead
So, if AI handles the routine stuff, what should you do with that time?
Think about what consultants do on Salesforce engagements. Sure, they build things. But a huge portion of their value comes from everything around the build.
Discovery sessions, stakeholder interviews, navigating org politics, and thinking deeply about architectural decisions and design. They’re paid to have conversations that internal teams rarely have time for. If you’ve read Jodi Hrbek’s book, some of this may sound familiar, but it’s more important now than ever.
What if you had that time?
- Run quality discovery: Most failed projects don’t fail because of bad code alone. Failure happens primarily when requirements are wrong. With less time on implementation toil, there’s space to sit with stakeholders, understand workflows in depth, and catch misalignment before it becomes rework.
- Think big picture, technically: Architectural decisions are often the biggest, most consequential decisions that you can make for your org. Doing the easy thing now in favor of “crossing the bridge when you get to it”, often due to high workloads, has bloated and overcomplicated many a Salesforce org. Make better, harder decisions now to ensure scalability in the future.
- Build cross-functional relationships: The admin or developer who understands how Sales, Finance, and Ops actually use Salesforce, or other tools for that matter, is vastly more effective than one who only sees tickets in a backlog. Building relationships takes time — time that’s usually consumed by the next urgent request in Jira.
- Scrutinize process: Speaking with software engineers who have embraced AI, they’ve told me that they spend more time on assessing processes than ever before. How things move from A to B to C is the critical path. Make sure it’s tip-top.
- User enablement: Time spent with end users helps you spot problems before they become support tickets, and ensures adoption. It builds trust and makes future projects easier.
Ultimately, the aim shouldn’t be to do more of the same work, faster. That risks being on a one-way ticket to a bloated Salesforce org. With AI efficiency gains, you finally have capacity for work that drives real change and company-wide adoption, so focus there.
Summary: Getting Started Without Getting Burned
Before you think about AI, make sure your DevOps house is in order. Can you recover if something goes wrong? Can you catch problems before they hit production? If not, start there.
Once you’ve got that foundation, pick one narrow use case where the work is well-defined and the stakes are low. Maybe it’s generating field descriptions. Maybe it’s drafting test classes for methods. Something where you can evaluate output easily.
Don’t try to revolutionize how you work overnight. Don’t hand AI your most complex problems. Don’t skip the review because “the AI probably got it right.”
Your mission, should you choose to accept it: get your team in a room and ask two questions. First, are our DevOps foundations solid enough to catch AI mistakes before users do? Second, what’s one well-defined, low-stakes task we could trial AI on this sprint, before we push the envelope?
The Salesforce teams that answer those honestly are the ones who’ll be ahead in six months.
