What happens when AI starts writing directly to your Salesforce org at scale? In the conversation below, Albert Franquesa and Francis Pindar talk about AI code governance, breaking down both the problems and opportunities it gives to modern DevOps teams. From the hidden trap of "AI slop" to the powerful advantages of automated configuration scanning, Francis shares actionable insights on how to build a layered defense framework that keeps your deployments fast, secure, and fully auditable.

The Interview

Tell us about the talk you're preparing for London's Calling on June 5th. Where did the angle come from — was there a client conversation, a TDX session, a moment that crystallised it for you?

It came out of the same gap I kept hitting in client conversations. Everyone wants to talk about Agentforce and how to build agents inside the platform. Almost nobody is talking about how to use AI well in the day-to-day job of building, configuring and shipping Salesforce work.

The talk is about the things that actually matter when you're using AI as a delivery tool. Which agents are good for what part of the job. Where they help, and where they quietly cause problems for you down the line. That was the gap I wanted to fill.

Your talk is about AI agentic DevOps with code governance as the spine — and you frame it as a moment to draw a line in the sand on what AI is allowed to generate inside a Salesforce org. Why is that the conversation that needs to happen this year specifically, and what's different from twelve months ago?

The thing I really want people to take away is that vibe coding is not agentic engineering. Letting AI write code unsupervised is not a DevOps strategy. A structured approach to AI-assisted development, with guardrails and checks at every stage of the lifecycle, is.

There are two failure modes on the Salesforce platform specifically that weren't being talked about much a year ago.

The first is requirements inflation. AI will add features, fields and buttons that were never asked for. It builds things because it can. Nobody asked for them and nobody is going to use them, but now they're sat in your org and you have to support them.

The second is that AI doesn't follow your existing org conventions unless you force it to. If your team uses Nebula Logger for exception handling, AI won't always reach for it. If you've agreed naming conventions for fields and variables, AI will drift away from them. And it won't tell you it has.

Twelve months ago, the prevailing view was that AI-generated code was the panacea that could build anything. Then we started finding the AI slop hiding inside what we'd already shipped. Code that worked but was unmaintainable, and we only realised once it was sat in production. Now we know better. AI is powerful, but you need something else checking its work. For me that's where a tool like Quality Clouds earns its place in the stack.

Walk us through that line. You've described what sits on the other side of it as code governance — governing what AI generates before it lands in a Salesforce org. Why governance as the right frame, rather than testing, observability, or DevOps maturity? Why is that the word that matters?

Because the consequences are governance-level. They sit across security and maintainability, but also around whether the solution you've shipped actually matches the original requirement, or whether AI quietly added scope you never asked for.

I keep seeing the same thing happen. AI adds a button somewhere on a page layout. It wasn't in the acceptance criteria. Nobody knows it's there. Testing doesn't catch it because nobody's looking for it. Observability doesn't catch it because as far as the platform is concerned, the button works fine. So you've got hidden complexity that's bypassed every other control you have. That's a governance problem, not a testing problem.

The other piece is the integrity of the prompts and data flowing through the agent chain. If I'm orchestrating multiple agents and multiple MCP servers, one of them only needs to hallucinate slightly, or be deliberately fed bad input, and that lie ripples through every downstream agent. The end output looks plausible enough. The decision underneath it isn't.

What governance gives you is checkpoints at each stage of the lifecycle, asking the same question over and over again: is this still what we asked for, and is it still doing what the design said it would?

And here's the thing nobody's really said out loud yet: the development cycle has flipped on its head. We used to build first and write the design retrospectively for sign-off. With AI involved, the design spec has to come first, because AI needs a solid grounding of what it's supposed to create. Without that, you have no objective way of knowing whether it built the right thing.

Headless 360 just made it possible for Claude Code, Cursor, and Vibes 2.0 to write directly into Salesforce orgs at scale. Is that the trigger event for drawing the line, or has the line been creeping closer for longer?

Honestly, this isn't really about code at all. It's about the UI layer of Salesforce disappearing.

I saw this coming a couple of years ago when I built an agent to act as a Trailhead Ranger for me. That whole learning experience, the clicks and the progress tracking, an agent could just do all of it for me. That was the moment I realised the user-facing layer of Salesforce was up for grabs.

Now scale that thinking up to the whole platform. The user doesn't log into Salesforce anymore. Their agent reads their emails, their call transcripts and their calendar. It cross-references the internal sales playbook. And then it just goes and creates the opportunity, straight at the API, without the user ever touching the UI.

So where does the governance layer sit in that world? The answer has to be Flow. Flow becomes the place where you enforce that records get created the right way, with the right information on them, the right downstream actions firing, and nothing being manipulated in transit.

That's why I think Headless 360 is the right architecture for Salesforce in this agentic era. A lot of the other tooling I see is still about prompt-engineering data into a database. Headless 360 lets you draw a hard line that actually says: this is where my agent stops, and my Flow actions start.

Let's talk about what happens when companies don't draw that line. Start with the technical side: in an org where AI-generated Apex, flows, and Agent Script are landing in production with no code governance in place, what breaks first — and how visibly?

Business logic bypass. And it's a worse problem than it sounds.

I had a client with an LWC component that did a specific piece of work, and the business logic lived in the component itself. Users went through that component, the logic ran, the data landed in the right shape. All fine. Then you flip into the headless world.

Now the user's agent goes straight at the API. The LWC is never touched, so the logic never runs. The LWC logic that should have fired didn't fire, because that data was only ever supposed to arrive via the component. The permissions allow it. The agent succeeds. And nobody knows anything has gone wrong.

This is going to be the pattern. Years of business logic baked into visual components and user-facing flows, designed on the assumption that records could only get created or fields could only get updated through that path, and an agent that bypasses all of it through the API. We're going to see holes appear in production orgs because of this exact scenario, and the worst ones won't be visible until something downstream breaks.

Now the audit and trust side. With no line drawn and code governance missing, when that same AI-generated code touches customer data, regulated workflows, or anything that needs an evidence trail. What's the conversation that goes wrong with auditors, with the customer's own security team, with regulators?

The conversation goes wrong on auditability. Specifically, who actually made the decision?

In a multi-agent architecture, by the time something lands in Salesforce, it's just a prompt. But behind that prompt is an orchestration agent that's been talking to half a dozen other agents, pulling in structured data, unstructured data, transcripts and policy documents from across the business. The user kicked the whole thing off, yes, but the actual decision was assembled by the chain.

So when a regulator asks how a customer ended up in a particular regulated workflow, what do you point at? There's no transaction ID that runs end-to-end. No correlation reference that ties the source data through every agent hop into the final record being written into Salesforce. The audit trail goes cold the moment it leaves the user's prompt.

And right now it really is the Wild West. People are wiring agents up to data, splattering unstructured content into orgs in the name of acceleration, and very few are stopping to think about provenance or what an auditor will ask in eighteen months' time. That bill is going to come due, and probably sooner than people think.

And the business side. What's the 18-to-24-month bill for a Salesforce team that doesn't draw that line, that skips code governance now? Is it slow degradation, or is there a cliff?

It's more slow degradation than a cliff. The bill builds up quietly until you can't afford to keep paying it.

And it isn't only code debt either. There's config debt sat on top, and requirements debt sat on top of that. All those features AI added that nobody asked for and nobody uses, that the team now has to maintain forever. All the conventions that drifted away from what was agreed. All the flows that almost-but-not-quite match the standard pattern. Maintenance turns into a nightmare, and the team that was supposed to be moving faster ends up spending all its time untangling AI slop instead.

The teams that put the guardrails in now, at requirements, at design, at code and config review, and at test and deploy, pay a small cost up front and stay fast. The teams that don't are going to be paying for what they shipped this year for a long time.

Flipping it round, what does drawing that line actually look like in practice? What does a team with strong code governance for AI-generated Salesforce code have, that a team without it doesn't?

The line operates in layers rather than as a single gate.

The first layer is the architectural decisions you bake into the agents themselves. If your org uses Nebula Logger for exception handling, the agent has to know that and use it. If you've got agreed naming conventions, those go into the agent's context as well. You aren't relying on AI to guess at the right answer; you're giving it the house rules up front.

The second layer is automated scanning before any human code review even starts. For me that's where Quality Clouds does the heavy lifting: security issues, governance issues, naming conventions, field-level permission checks, all the bread and butter that takes a human reviewer ages and that AI is genuinely prone to missing.

The third layer is the human code review itself. By the time it gets there, you're not hunting for trivial security holes or convention violations anymore. You're looking at intent and logic. The review goes faster and sharper, and you can deploy with real confidence in what you're putting in.

A team without that line in place is trying to do all three layers in a single exhausting human pass. Or, more honestly, not doing them at all.

When you survey the tooling landscape for AI Code Governance on the Salesforce platform today, what's mature, what's still emerging, and where are the real gaps?

The thing I'd put in front of every Salesforce leader right now is what's happening with platform security itself. Between Mythos LLM and the wave of platform security changes Salesforce has been pushing out recently, the security community is genuinely running scared, and that's why we're seeing so many changes coming through. Some of them look over the top. They aren't.

My view is that everyone should be doing what Salesforce is suggesting, and then some. Salesforce will tell you that certain controls, like passkey enforcement, should only be for admins or highly permissioned users. I'd go further and say every user. The threat surface is moving fast enough that the more conservative read is the correct one.

On the actual tooling: Quality Clouds is the one I trust to catch security and compliance issues across both config and code, which is the bit a lot of tools miss. Salesforce's own Security Scanner is OK but lets quite a few things through. Apex PMD is great as a free open-source option, but again, it’s code-only. They don't look at the config side of an org, and that's where a fair chunk of the real risk now sits. Anything that calls itself AI code governance for Salesforce but ignores config is solving half the problem.

You'll be using the phrase "AI Code Governance" in the talk. Is that the right name for what's emerging, or do you think the market settles on something different, agentic DevOps, AI assurance, code trust? What does the language need to become for a CIO to actually fund it?

I'd actually change the name. "Code governance" undersells it.

What we're really doing is AI application governance, or security governance, depending on which CIO you're talking to. It's defensive application development for a world where people have become the weakest link in the build process. AI is doing the building, and you need something else checking AI's homework.

That's the frame a CIO will actually fund. You walk in with this: we have AI writing code at speed, the post-go-live cost of unmanaged AI output is real and getting worse, the security picture is shifting underneath us, and we need a system that checks AI's work before it ships. That sentence pays for itself the first time it stops something bad going to production.

We'll hear the full talk at London's Calling, but for those who can't be there, what's the one thing you most want a CTO or VP of Engineering to walk away thinking, and where do you most want them to draw the line?

With great power comes great responsibility, and AI is genuinely powerful right now.

The catch is that the volume AI can produce makes it almost impossible for humans to review and check at the same speed it's coming out. That mismatch is the problem. You can't out-review AI by hiring more reviewers.

So the line you draw is this: you need a governance framework that does the first pass for you, that you can configure with your own rules, and that gives you real confidence in your DevSecOps pipeline before a human reviewer even sees it. The aim is to make sure your guardrails keep pace with AI, not to slow AI down.

Your talk is one reason to be in London on June 5th, but you've been running London's Calling for years. Beyond your own session, what makes that day worth being in the room for — and what's the part of it you most look forward to as the organiser?

For me it's a day in a room full of people who eat, drink and breathe Salesforce every day. That's pretty rare. Nine tracks this year, which is a bit mad, and a genuinely huge amount of content. Everything's recorded, so you can catch up later on the sessions you missed.

But what really makes the day worth turning up for in person is the people. New connections, old friends, problems you've been chewing on for weeks getting solved over a coffee between sessions, ideas you wouldn't have had in any other room. I always come away with three or four conversations I couldn't have had anywhere else.

That's the part I look forward to most as the organiser. Watching all of that happen in the room.

Join the Conversation at London’s Calling

Want to dive deeper into AI code governance and the future of Salesforce DevOps? Don't miss Francis Pindar’s full session at London’s Calling on June 5th.

It’s more than just a presentation; it’s a day to connect with people who live and breathe Salesforce, solve complex problems over coffee, and gain insights you won't find anywhere else.