Building Salesforce with Claude Code

The constraint on Salesforce delivery is no longer how quickly developers can write code. Claude's coding agents can produce production-ready Salesforce components in minutes. The new constraint is whether enterprises can make the right architectural decisions fast enough to keep AI moving in the right direction.

The real opportunity is not simply that AI writes code faster. It is that software delivery can now run at a fundamentally different cadence. Teams can evaluate more options, iterate more quickly, and spend more of their time on architectural decisions rather than manual implementation. That changes how Salesforce programmes should be designed, governed, and led.

Governor limits, declarative-first design, managed package boundaries, and sharing and security models all shape what “correct” means on the platform. Code that runs and passes a demo can still be the wrong solution: brittle under load, expensive to maintain, or quietly out of step with how the org is meant to work. Speed doesn't remove that defect. It just relocates it, usually into UAT or production, where it costs the most to fix.

So the question isn't whether to bring Claude Code onto a Salesforce project. It's how to nurture speed without losing the discipline good delivery has always required: scalable data models, maintainable automation, and integrations that don't break at the next release.

Claude is trained to say when it isn't sure about something rather than presenting unfinished work as complete. On a Salesforce project that matters most, because something set up incorrectly can turn into a costly problem once real users and real data hit it. The division worth aiming for: architects own the decisions, Claude carries out the work. Claude Code is built around exactly that split and works incredibly well with Salesforce:

Picture two teams starting the same implementation. One spends the first few days giving Claude Code the required context and capturing the org's conventions. The other skips straight to the build. By week three, the difference shows: the first team ships components that match house style on the first pass; the second is re-explaining the same naming conventions and error-handling patterns in every session, because nothing was written down for the agent to work from.

Three things worth getting right early

• Coding standards: Apex, LWC, and Flow naming conventions, error-handling patterns, and test-class requirements, plus known constraints such as existing managed packages or technical debt.
• Connected tools: MCP servers for Git, Jira, and CI/CD, so Claude Code can read tickets, check history, and see pipeline status directly instead of working from assumptions.
• Repeatable workflows: reusable instructions for tasks the team runs often, such as environment refreshes, metadata retrieval, or release notes.

A common assumption is that a coding agent will push a project toward more custom code, since writing code is what it's built to do. In practice, the opposite is just as achievable. Across our Salesforce engagements at Myridius, we've consistently found Claude Code particularly effective at evaluating multiple implementation paths before development begins, helping teams choose between declarative capabilities and custom code based on long-term maintainability rather than implementation speed. Claude can lay out whether a requirement is better served by Flow, Dynamic Forms, a validation rule, or a permission set before any Apex is written.

Take a requirement to auto-populate a field based on record type and ownership. It can be built with a couple of Flow elements, or as a hundred-plus lines of Apex with its own test class. Both pass QA. Only one is maintainable by an admin two years later without a developer on standby.

For Claude Code to make an informed call, it needs visibility into what already exists in the org. Feed it the current automation inventory and platform limits, and have it lay out the declarative and custom options side by side before committing to a build approach. The business case is straightforward: given sufficient architectural context, Claude Code consistently recommends approaches aligned with Salesforce platform best practices: declarative solutions and out-of-the-box features, rather than Apex code, as the default answer.

Claude Code can write bulkified, governor-limit-aware Apex when asked. What it cannot do is know your org's data volumes, transaction patterns, or peak load, unless someone tells it. Consider a batch job that runs cleanly against a few hundred sandbox records, then hits a SOQL limit on its first production run against hundreds of thousands. That failure is entirely avoidable, but only if the check happens before the code ships.

MuleSoft, middleware, external APIs, and adjacent clouds are usually in scope, and Claude Code needs full context on the integrating systems and the integration's purpose to be useful here. Through MCP, it can read live context from connected systems instead of working from stale documentation.

Why data privacy deserves real attention, not a footnote

• Data: Is the sandbox data masked, or is it a production copy?
• Access: Does the assistant need write access to the integration layer, or is read access enough to draft the mapping logic?
• Governance: Who reviews what gets exposed through an MCP connection before it goes live?

None of these questions is new. Scope the connection the way you'd scope any third-party access request: to the minimum needed for the task.

When code took a sprint to build, a flawed data model or an under-designed sharing architecture surfaced slowly, one release at a time, with room to course-correct along the way. Claude Code removes that buffer. A decision an architect gets right now gets implemented and propagated across the org in hours. A decision they get wrong does the same.

That's the real shift. Architects aren't a checkpoint that AI makes optional; they're the safeguard that keeps velocity from becoming a liability. The data model's ability to scale three years out, the sharing and security design the org will be judged on, the integration patterns that decide whether the platform stays extensible or turns brittle, the build-versus-configure calls that shape total cost of ownership long after go-live: these decisions carry more weight than they used to, not less.

Claude Code cannot make those calls. It can implement a decision well once an architect has made it, but it has no stake in whether the business is judged on that decision in three years. That accountability doesn't transfer, no matter how good the model gets.

A defect that used to take a developer an afternoon of stepping through logs can now surface a root cause in minutes. Teams find out they're wrong, or right, within the same day instead of the same sprint, and that changes the whole rhythm of a project.

AI fundamentally changes engineering velocity. When implementation accelerates significantly, architecture, governance, and decision-making become the limiting factors. When code was slow to produce, most of the effort went into writing it. When code is fast to produce, the value shifts to knowing whether what got produced is actually correct: whether it holds up under real data, real edge cases, real usage. Engineering teams start to look less like coding teams and more like validation teams: the job becomes defining what “correct” looks like for the org, and checking that Claude Code's output clears that bar, rather than producing the first draft by hand.

That's the thread running through all six practices: give Claude Code the context to execute well, and give architects the room to focus entirely on the decisions only they can make: how the system scales, where it's governed, and how it serves the business. Encode that once, on a single workstream, and let it set the standard before scaling further.

In the era of AI-native software engineering, competitive advantage won't come from writing more code. It will come from making and governing stronger architectural decisions, faster than everyone else.