Part 2 of the Architecting Claudeforce series. New here? Start with Part 1 →. — Last time we looked at the doors for using your org. This one’s for building it — and it turns out builders come in two flavours, through two very different doors.
In the last post, we met the four MCP servers that let people — including the rep who never logs in — reach into your org’s data. But I skipped the obvious question: who built the org those servers reach into?
An admin did. A developer did. Someone defined the objects, wrote the automation, set the permissions. And here’s the part that reframed the job for me: those people don’t open Setup the old way anymore either. There’s a door for them too — except it’s really two doors, because a developer and an admin want completely different things.
First, keep the two jobs separate
Two completely different acts share the same org:
- Building the org — creating objects, writing automation, deploying, configuring. That’s this post.
- Operating the org — read a record, update an opportunity, run a process. That’s the end user’s door — and it gets its own post next (Post 3).
The MCP servers we mapped in Post 1 sit underneath both — they’re the plumbing, not the door. But “ask the org to do something” and “change what the org is” are different jobs — and the builder’s door splits again, by who’s walking through it.
The two lanes of the builder’s door
Here’s the distinction nobody states plainly, and it matters because picking the wrong lane is how good people end up frustrated:
- Developers want to get their hands dirty. CLI, git, a project on disk, control over every file. They’ll happily live in a terminal.
- Admins are — rightly — UI-comforted. They’ve spent careers in Setup: point, click, configure. Their AI-native door should not be a command line. It should be a conversation.
Salesforce ships a door for each. Let me take them in turn.
The dev lane: Claude Code + the DX MCP Server
The workhorse here is the Salesforce DX MCP Server — an npm package (@salesforce/mcp) that runs locally on your machine and talks only to the orgs you’ve already authorized through the Salesforce CLI. No new hosted surface, no fresh credentials — it rides the auth you set up months ago.
Point a code-first client at it — Claude Code, Cursor, VS Code — and you get 60-plus tools in toolsets: metadata (deploy and retrieve between your org and your DX project), orgs, data, testing, code analysis. In practice: “create a Warranty_Claim__c object with these fields, write the service class, deploy it to my scratch org, run the tests” — and it happens, as DX commands, against the org you chose.
In August, Salesforce shipped its first official plugin for Claude Code, which turns it from a general coding assistant into a Salesforce one: roughly 40 skills plus three MCP servers (salesforce-api-context, salesforce-metadata-experts, and salesforce-lsp — local Apex and SOQL validation as the model writes). It even ships an architecture-review agent that grades your project against the Well-Architected pillars. The assistant that writes your Apex can also tell you the Apex is a bad idea.
What makes this the dev lane — and the thing worth protecting: the output lands in your DX project. Metadata in a folder you can diff, review, and commit. Source-tracked by construction — if you keep it that way.
The admin lane: a chat window, no terminal in sight
Now the lane nobody’s writing about, and the one that matters for the thousands of admins who are never going to npm install anything.
An admin doesn’t need the CLI. They point a chat client — Claude on the desktop — at the org’s hosted MCP servers through a connector, and configure by talking. “Create a permission set that gives the support team read on these objects.” “Walk me through setting up this approval process.” No project on disk, no git, no terminal — the same point-and-click instinct, expressed in sentences.
The servers behind this lane are the hosted ones: the SObject servers from Post 1, plus two config-focused ones — Metadata Experts (metadata generation) and Headless 360, whose Discover / Describe / Dispatch tools find and run complex setup operations without a browser.
One honest caveat, because it’s exactly the thing that burns someone who took the demo at face value: those two config servers are still Beta. The admin’s no-CLI door is real and arriving fast, but it’s less mature than the dev lane, which is GA. If you’re an admin planning around this today — use it, enjoy it, but don’t hang a go-live date on the Beta pieces. Set expectations accordingly.
The villain: the over-scoped builder door
Here’s where it stops being a demo and starts being architecture — and this villain stalks both lanes.
Everything above is a good security story: local execution and your existing auth in the dev lane; runs-as-user on the hosted servers in the admin lane. But that safety is about the door, not the discipline — and the discipline is on you.
Because it’s so easy now, the temptation is to swing the door too wide: authorize the production org “just to check something,” let the model deploy straight past the DX project, click “yes” on a config change you didn’t fully read. That’s the villain — the over-scoped builder door. The same conversational speed that makes you fast makes a mistake fast, and in prod, against metadata, “fast” is not the adjective you want.
The fixes are boring, non-negotiable, and the same in both lanes:
- Build in scratch and sandbox orgs; reach prod only through your real pipeline.
- Dev lane: keep the work in the source-tracked DX project — that’s your diff, your review, your undo.
- Admin lane: read the change before you confirm it, and lean on least-privilege permissions so the model can’t exceed what you could.
- Let the architecture-review agent and the gated skill library do their jobs.
The tool removes the typing. It does not remove the judgment — and the judgment is the part they’re paying an architect for.
The shift
So the builder’s job isn’t “click through Setup faster.” It’s that building the org becomes a conversation — a coding conversation if you’re a dev, a configuring one if you’re an admin — and the thing separating an architect from someone who can write a good prompt is the discipline wrapped around it: least privilege, source control, reading before you confirm.
The builders made the doors. Next, we walk through the one the end user uses — and I’ll make the case that you hand them verbs, not raw CRUD.
That’s Post 3.
📬 This is part of the Architecting Claudeforce series — more landing soon. New here? Start with Part 1 →.
Until next time! 🙂
