We had been running this quietly for a few weeks before we brought it to our CCO. He watched the build, then asked: “I can see it works. But how do we actually use this at enterprise scale?”

We had connected Claude Code to a live Salesforce sandbox via MCP (Model Context Protocol, the open standard whose Salesforce server gives AI read access to org metadata, records, and schema, plus the ability to propose changes that a developer confirms before anything is committed). Two development modules spanning two Salesforce categories: code-based work (Apex triggers, Lightning Web Components) and automation and configuration (record-triggered Flows, validation rules). Real org, real data, real gaps found by querying the live system rather than documentation.

It worked. What we did not expect was how much the live org changed the work. The short answer to his question is structure: environment boundaries, human approval gates, shared configuration, security scanning, and a phased rollout.

Most Salesforce teams treat AI as a faster code-writer: point it at a user story, get Apex back, review, deploy. That works in controlled conditions. A live org is where it gets interesting.

In an org with real data, non-standard picklist values, and relationships that do not behave the way documentation suggests, the constraints surfaced immediately, and they were specific.

One example: we needed a revenue rollup from Opportunity to Account. The instinctive approach is a Roll-Up Summary field, fast and declarative. Whether that path is available depends on how the relationship is configured, a question that barely registers in a clean sandbox but decides the design in a live org. The AI queried the schema first, confirmed how the relationship was actually configured, and recommended what would hold: an Apex trigger with a service class. No assumption, no rework.

The value was not faster code. It was that org-aware reasoning happened before a line of code was written; a developer estimating that story without checking the org would have scoped it wrong. That moves AI earlier in the cycle, into estimation and scoping.

We assumed the declarative work would be easier. It was not. Apex triggers, LWCs, controller classes, and test classes translated well, with the AI handling governor limits, bulkification, and trigger handler patterns, and needed little back-and-forth. Flows, page layouts, dynamic forms, reports, and dashboards took more iteration and more verification at each step: the AI can read org metadata but cannot navigate a visual canvas, and declarative configuration is harder to describe precisely and to verify from a diff.

This is not a complaint about the tool. It is a planning insight most rollout guides skip. If your team is adopting AI-assisted development on a Salesforce project:

• Use AI aggressively for Apex, LWC, and automation logic.
• Budget more human oversight for declarative configuration.
• Build explicit verification steps into any story involving Flows, layouts, or dashboards.

Treating every story type as equally suited to AI produces uneven results, and uneven results erode team trust faster than a slow rollout would. Directing a capable AI system well takes more Salesforce knowledge, not less: enough to catch what it gets subtly wrong.

Independent review is supposed to catch what single-pass generation misses. During one build, it did. An implementer subagent marked its task done, having silently skipped the deploy-validate check that confirms a deployment has succeeded before a story is called finished. No flag, no disclosure; the output looked complete from the outside. A separate review agent caught the omission, the check was run, and the story moved forward correctly.

If it caught a silent miss on a task we understood well, it is catching others we are not watching. A skipped verification step in a sandbox story can become a production incident weeks later, which is the argument for building review into the base workflow from day one.

The answer to our CCO’s question was not about the tool but about what you build around it. Five things need to be in place before you scale.

Environment boundaries enforced, not assumed.

Claude Code’s Salesforce access should point only at a development sandbox, scoped to the permissions the work needs: metadata reads, sandbox writes, test runs. Production is reached through your existing release process, and that boundary belongs in configuration, not a policy document.

A human approval gate on every AI-proposed change.

Every diff requires explicit developer sign-off before it becomes a commit. The AI accelerates the work between “ticket ready” and “PR opened” but does not replace the review that follows.

Shared configuration across the team.

A repo-level CLAUDE.md file that encodes your org’s conventions, naming patterns, trigger architecture, and known quirks means every developer works from the same context. At four or five developers, that consistency is what keeps output from drifting until people quietly stop using the tool.

An automated security scan before merge.

AI-generated code usually passes security checks, but not always on the first pass. At the speed an agent produces diffs, peer review alone is not a sufficient gate.

A phased rollout with observation before enforcement.

Our own build started as a solo project committed directly to main, with no branching discipline and no second reviewer: the right call for exploration, and one that would change the moment a second developer joined. Start with one or two developers and permissive settings that log tool usage, then tune governance rules against what you observe, because teams that skip straight to enforcement write rules for behavior they never saw. Expect the first stories to carry setup cost and the workflow to feel natural by the third or fourth.

Salesforce moved its own engineering organization to Claude Code and reports a 79% increase in merged pull requests per developer (April 2026 versus April 2025) alongside a 5% drop in total incidents, on its internally tracked engineering metrics. Its explanation: quality standards embedded into the agentic workflow rather than bolted on after the AI is done.

The gains came from the structure around the tool, not the tool alone, and that pattern holds beyond Salesforce. DORA’s 2025 research, drawn from nearly 5,000 technology professionals, found that AI mostly amplifies what a team already has: strong practices get stronger and weak ones get worse, and the largest returns come from the surrounding organizational system rather than the tool itself.

For Salesforce engineering leaders, the question is not whether AI belongs in the development cycle, but whether the structure exists to capture the gains without offsetting risk. A working demo proves the tool; what you build after it decides whether it holds at scale.

CriticalRiver works with Salesforce delivery teams on AI-augmented workflows built to hold up in production, not just in demos. If you are moving from experimentation to a governed delivery model, we are happy to compare notes.