Salesforce’s TrailblazerDX 2026 introduced several significant changes last week, most notably the “Headless 360”. While the keynote presentations highlighted a future centred around APIs and AI agents, I want to look past the announcements to see what this means for day-to-day development.
Over the last few years, the platform has been heavily coupled with the Lightning UI. These new updates suggest a shift back toward treating Salesforce as a backend engine that developers can interact with more flexibly.
1. A Renewed Focus on Backend APIs
The concept of a “headless” architecture isn’t new; we’ve used REST and Bulk APIs for years to decouple the front-end from the database.
What’s different about this announcement is Salesforce’s apparent optimisation of the backend developer experience. By placing more emphasis on APIs, CLIs, and MCPs, Salesforce is acknowledging that many enterprise teams want to use the platform as foundational infrastructure.
Despite the hyperbole, this doesn’t mean there’s no more need for a Salesforce UI - it adds more flexibility by opening up the platform and giving developers more options. They’re giving reasons for developers to stick with Salesforce with its already robust platform features rather than jumping ship to other platforms.
2. Exploring React and GraphQL Integration
One of the more notable updates is the introduction of Multi-Framework Support, beginning with native ReactJS hosting.
For a long time, building natively on the platform generally meant using Lightning Web Components (LWC), and Aura before that. Opening the door to React offers teams the ability to tap into a wider talent pool and utilise the vast ecosystem of existing NPM packages and UI components.
The interesting part of this approach is its reliance on the Salesforce GraphQL API. By utilising GraphQL, React applications can query nested relational data structures in a single request. This decoupled approach could allow teams to build highly customised Single Page Applications (SPAs) while relying on Salesforce primarily for data.
Note, it’s not yet Generally Available (GA). While this looks promising, we will need to wait and see how stable it is and how it compares to native LWC when it is officially released.
3. Evaluating Agentforce Vibes and Claude
Salesforce is upgrading their cloud-hosted IDE - Agentforce Vibes 2.0. It’s now powered by Claude Sonnet 4.5 as the default, which is significantly better than whatever it was they had in there before.
This is great for devs to get their feet wet. I’ve spoken to lots of developers who haven’t tried this yet. Now that Claude is free - try it now. There’s a billing update coming in June, so you can only use this free in sandboxes now, and only developer sandboxes from June 1.
In my own testing, whilst it is a step up from the previous version, it’s still not quite there yet. All the prompts go through their Trust Layer and via the Claude API making it feel a lot slower than just using Claude Code directly.
4. AgentExchange and the ISV Experience
Salesforce also announced AgentExchange, a marketplace designed for sharing and distributing AI agents.
While a dedicated marketplace makes sense, ISVs and AppExchange partners will likely approach this cautiously. Historically, packaging and distributing complex configurations across different tenant environments has been a challenging process. I will need to see how robust the packaging and deployment tools are for these new agents before giving this the thumbs up for ISVs.
5. What I Want to See Next
If Salesforce is really pivoting “back to the core” and making Salesforce a truly agentic platform, this is truly music to developers’ ears. Is Parker finally winning over Marc? We’ll have to wait and see how this stacks up at Dreamforce! Now, to make this actually work in the trenches, here are key things I want to see Salesforce do next:
- Stop Renaming Products: When you rename Pardot to Account Engagement, or Einstein Copilot to Agentforce, you actively break Retrieval-Augmented Generation (RAG)! LLMs rely on historical training data. If we want AI to effectively debug the platform, Salesforce must stop muddying the vector space with marketing-driven name changes.
- Implement a Proper LLM for Help Docs: help.salesforce.com has improved, but it’s still not enough. Why am I still jumping out to Gemini, Claude, or ChatGPT to debug? Salesforce needs to implement an aggressive, semantic RAG pipeline on their own portal to make their native agent the undisputed best.
- Attack the IdeaExchange with Agentic Dev: Salesforce claims AI accelerates development. Prove it! Use Claude Code and Agentforce internally to obliterate the 10-year-old backlog of metadata-level IdeaExchange requests (the “low-hanging fruit”) by Dreamforce.
- Machine-Readable Release Notes: Stop burying release notes in heavily styled HTML and iframes designed only for human eyes. When an AI agent tries to scrape this, context is lost. If the future is “Headless 360”, documentation must be headless. Agents need an API endpoint or
.mdschema to natively pull the raw context of version changes! - Dynamic Agent Skills Tied to Releases: Relying on the base training data of an LLM means the AI is always architecturally behind the current Salesforce release. Every major release must deliver Metadata Skill Updates. When a new Apex method drops, Salesforce should push a pre-packaged “Skill” to the ecosystem so our agents know how to use it on day one.
