TL;DR
- Salesforce is increasingly being operated like a codebase rather than a UI, with admins and RevOps teams moving workflows into IDEs using AI and Salesforce CLI.
- AI becomes powerful when it can reason across structured metadata and system context, not just generate code or configurations.
- As execution speeds up, the real challenge shifts to visibility, governance, and drift control across complex Salesforce environments.
***
The other day I was doing what everyone in B2B says they do and very few people actually do: reading the forums.
Not analyst reports. Not Dreamforce keynote recordings. Not the polished, post-produced version of what vendors say the capital-F Future is. I mean the messier places where practitioners talk to each other when they’re off-script and a little less guarded.
In this case it was a Reddit thread with a deceptively simple question: is anyone else moving most of their Salesforce work out of the UI and into an IDE with AI and Salesforce CLI?
The original post came from a RevOps and GTM engineering practitioner who said that over the last six months they had shifted roughly 95% of their Salesforce work out of the UI and into an IDE. (A bold claim! But let’s hang with them.)
AI plus Salesforce CLI handled most of the work: querying the data, modifying the metadata, building the flows, writing the Apex, updating the permission sets, running the bulk operations, analyzing the relationships across objects and so forth. The only time they dropped back into the UI was when the AI got stuck on something and it was faster to handle the snag manually.
Talk about a different operating model.
What made the thread interesting were the replies (and the sheer amount of them). Admins, consultants, devs, architects, people from different corners of the Salesforce ecosystem — they all chimed in with some version of the same reaction.
Yes, this is happening.
Yes, it’s faster.
Yes, it changes how you think.
And yes, once you start working this way, it’s very hard to go back to the Old Way.
I think that thread matters now because it captures something the market hasn’t fully processed yet: Salesforce is becoming a codebase.
When Salesforce Stops Acting Like an Application
This doesn’t simply mean more people are writing Apex. And it’s not just the old story that there’s a developer layer beneath the admin layer.
This shift is far bigger than that.
Teams are starting to inspect, reason over, compare, and govern their Salesforce the way software teams treat codebases. The UI is still there, and of course it’s still useful, but it’s slowly losing its status as the primary method by which people understand and operate the system.
For years, eons even, most Salesforce work happened inside a visual, click-based interface. You logged in, opened Setup, searched for what you needed, and navigated through objects, flows, page layouts and all of that until you found the right configuration.
Understanding the system meant clicking through it.
That model made sense when Salesforce was mostly understood as an application.
It makes much less sense once Salesforce becomes a large, evolving system with thousands of interdependent components. After all, complex systems are difficult to understand one screen at a time.
That’s exactly what the folks in the Reddit thread were finding out for themselves.
One commenter described how cross-object analysis became dramatically faster once they could ask an AI to query several related objects and explain the data model. Something that used to need 20 minutes of navigating Schema Builder now took seconds.
Another commenter described the mental shift more bluntly (shocking on Reddit, I know): once they started treating the org like a codebase rather than a GUI, the UI started to feel like a read-only dashboard they only occasionally checked in on.
Admittedly, that line stuck with me. When systems become legible in other ways, the interface stops being the system. It becomes just one narrow view of the system.
The Real Shift Underneath the AI Hype
Right now, a lot of the chatter around this shift focuses on tools.
People debate which assistant works best, whether Claude is better than Codex, whether the right workflow lives in VS Code, Cursor, GitHub Copilot, or some evolving stack of CLI tools and MCP integrations.
But this debate misses the deeper point: The important question isn’t which assistant writes XML or Apex the fastest. The important question is what happens when Salesforce becomes machine-readable enough that AI can reason over the system itself.
Once metadata lives in source control and an AI assistant can inspect the workspace, trace dependencies, review diffs, generate manifests, and run queries across the org, the interaction model changes. You’re no longer using AI as a chatbot layered on top of Salesforce. You’re using AI as a system operator working against structured context.
That difference is profound when AI can understand relationships. A field connected to a flow. A flow connected to an object. A validation rule that affects page behavior. A permission set that determines who can trigger a process. A report that depends on a schema decision made three years ago.
When AI has access to enough structured context, it stops guessing blindly at individual tasks and starts reasoning about the system.
And that’s where metadata suddenly becomes the most important layer in the stack.
Metadata Matters More Than Ever
One of the most interesting patterns in the thread was how often users returned to the same idea from different angles.
Several commenters mentioned that moving work into an IDE forced them to treat metadata as source. That meant configurations couldn’t live only inside the UI. They had to exist in version-controlled files that could be inspected, compared, and reviewed.
Others pointed out that documentation started to emerge almost automatically once everything lived in source control. The structure of the system became visible in a way it never had been before.
Another commenter described an internal AI setup that could read the entire repository clone, not just the file being edited. That allowed the assistant to trace where a field was referenced, map dependencies across automations, and refactor changes with a much clearer understanding of the environment.
What all of these examples share is a simple principle: AI becomes useful when systems are legible.
And in Salesforce, the thing that makes the system legible isn’t the interface. It’s the metadata.
That’s because metadata describes how your system actually works. It captures the objects, fields, automations, dependencies, and rules that determine how your data moves and how your processes behave. Once that layer becomes structured and inspectable, both humans and machines can reason about the system in ways that were previously impossible.
This is why the conversation inevitably turns toward visibility and governance.
Because once you can change more, faster, with fewer people, the real problem isn’t execution.
The real problem becomes understanding the consequences of change.
Speed Makes Governance More Important
At some point in the Reddit thread someone asked the question every serious team eventually asks: If you’re operating Salesforce through AI, CLI tools, and automated workflows, how easy is it to make catastrophic mistakes? And how easy is it to reverse them?
The answers were… telling.
People immediately started talking about version control, automated testing, pull request reviews, deployment pipelines, and drift detection. One practitioner described building an execution layer on top of Salesforce CLI that enforced dry runs before any write operation, combined with automated snapshots and environment comparison.
In other words, the safety model came first.
That instinct reflects something important about the direction enterprise systems are heading…. The more powerful AI becomes, the more important governance becomes. As Spider-man’s Uncle Ben once said: With great power comes great responsibility (to govern).
When changes become faster and easier to execute, the bottleneck shifts. The challenge is no longer making the change. The challenge is understanding what that change affects, validating it before deployment, explaining it afterward, and tracking it across environments.
When Salesforce Becomes a Codebase, Your Stack Becomes an Environment
The thread also hinted at what happens next. Let’s look into the future, shall we?
One user described pulling data from Salesforce, HubSpot, Zendesk, and enrichment tools into local datasets and analyzing them with AI-generated SQL. Instead of inspecting each system separately, they could compare pipeline activity, support interactions, and CRM records in a single session.
That example matters because it shows how insanely fast the scope expands.
Once operators expect AI to understand Salesforce like a codebase, they begin expecting AI to understand their entire go-to-market stack like an environment. Salesforce is only the starting point. The same instinct that drives someone to query metadata across an org eventually leads them to ask questions across systems.
How does pipeline data relate to support activity?
Which fields drive routing across different tools?
What breaks if we change this definition here?
Those are system-level — not product-level — questions
And answering them requires something deeper than a better interface.
It requires context.
The Boundary Between Admin and Engineer Is Blurring
One of the more revealing moments in the thread came from an admin who said something strikingly simple...
They had always been able to read code. But with AI assistance they could now write code, iterate on it, and deliver changes far faster than before.
That shift is here.
AI is expanding the surface area of what Salesforce operators can do themselves. The person who understands the business process and the data model suddenly has far more leverage. They don’t need to memorize every nuance of syntax to participate in technical work. They need context, patterns, testing, and guardrails.
In other words, they need scaffolding.
That doesn’t make fundamentals irrelevant. If anything, it makes them more vital for our purposes here. When teams operate at higher levels of abstraction and speed, the quality of their underlying system design matters even more.
Which brings me back to the main point: Salesforce is indeed becoming a codebase.
It’s UI will not disappear tomorrow. Every admin won’t become a terminal enthusiast. But the magnetic poles of the ecosystem are shifting.
The Next Problem
There’s one more teensy twist in this story.
Most of the workflows described in that Reddit thread assume a single Salesforce org with a relatively clean source repository. That’s often true for startups or smaller organizations. Good for them!
Enterprises rarely look like that.
They have multiple orgs. Regional deployments. Sandboxes. Acquirer and acquired systems. Years of accumulated customizations and automations that nobody fully remembers building.
That’s where the next challenge emerges.
If one Salesforce org can be treated like a codebase, what happens when the enterprise actually has twelve?
System orchestration. That’s what.
It’s understanding how environments relate to each other, where configurations drift, which dependencies cross boundaries, and what changes are safe to make across the landscape.
That’s the layer where AI either becomes genuinely powerful or genuinely dangerous.
Because AI doesn’t just need instructions.
It needs context.
The Best Signal
That Reddit thread revealed a new operating model, I think.
Practitioners are already sewing together AI, CLI tools, source control, documentation, testing, and deployment logic into something that looks a lot like modern software development. They’re discovering that once an AI assistant can work against structured metadata and repository-level context, the entire system becomes easier to reason about.
Faster to change.
More transparent.
More governable.
More dangerous if unmanaged.
More powerful if governed.
In other words, more like software.
So yes, Salesforce is becoming a codebase.
The system underneath it all is finally becoming visible enough for both humans and machines to understand.
And once that happens, the question shifts from “where do I click?” to something much more interesting… What does my system actually know?