Dreamforce 2026 Dev Keynote: As a Future Salesforce Developer, I…

Unlike many of my Aquiva colleagues, I was not at Dreamforce in person. I watched from home on Salesforce+. I still have not absorbed half of what was announced.

The main keynote left me bored. The Developer Keynote genuinely excited me. For Dreamforce, it was remarkably honest and hype-free about what worked, what needed correction and what is still unfinished.

More importantly, Salesforce answered a question it had left unanswered for years: what does a Salesforce developer do when AI writes the code? And it finally showed tooling that matched the ambition. One coherent example ran from requirement to specification, implementation, review and orchestration. The answer was not another coding assistant, another pile of disconnected skills or another homegrown harness.

…Define Outcomes Instead of Pair-Coding With AI

The keynote called this "the shift from assistance to delegation." Until now, developers mostly used AI to write a class, explain existing code or produce a test: small tasks that take seconds. Delegation starts one level higher. The developer defines the outcome and gives the agent a specification. The agent plans, writes code, tests and opens a pull request over hours rather than seconds.

That gives the developer less typing and more responsibility. The expensive decisions move into the specification, the architecture and the review. If those decisions are wrong, the agent does not merely write wrong code. It writes much more of it before anybody stops it.

The demo started in Claude Code, not the infamous Agentforce Vibes. Vibes still exists, and Salesforce brought back its free tier later in the keynote. But Salesforce seems to have accepted that the coding harnesses from the AI labs are far ahead. Instead of asking developers to leave Claude Code, it brought Salesforce into it through the generally available Salesforce Development plugin. Its skills and MCP servers gave the coding agent Salesforce-specific tools and access to the real org.

At the center was a spec-driven workflow. The demo used a bounded write-spec skill to inspect the org and produce an implementation specification. The Platform AppDev roadmap also showed SFSpec-Kit, Salesforce's adaptation of GitHub Spec Kit. The specification becomes the contract for planning, implementation and review.

I am skeptical of the size and ambition of the skill library around it. At Aquiva, we use skills too, but keep them narrow: one skill for one concrete problem, such as Agentforce testing, with only the tools and instructions it needs. We found many earlier Salesforce skills bloated and overspecified. Current Claude and Codex models already understand much of what those prompts explain. Repeating it burns context and can pull the model away from the conventions in the repository. I do not see how huge prompt libraries remain stable, testable or maintainable.

The same concern shaped Speccy, the open-source spec-to-implementation plugin Aidan Harding built at Aquiva. It does not try to teach the model every Salesforce best practice. It interviews the developer, forces decisions, independently critiques the specification and plan, and only then starts building. In Putting Learning in the Loop, Aidan explains why: the developer has to understand what is being specified instead of approving polished AI output.

…Make the Final Call After Agents Challenge Each Other

The implementation agent had quality gates and enforced test coverage, but this does not tell the developer whether the feature delivers the intended outcome or whether the architecture will survive real conditions.

Salesforce therefore sent a second, adversarial agent after the implementation. It challenged the pull request against the specification instead of inheriting the builder's job to defend its own work. The developer could then focus on the architectural risks and disagreements that required judgment.

This is also how our ticket-to-pull-request pipeline works. The builder never reviews its own work. A separate reviewer starts with fresh context and no write access. But one agent reading another agent's text is not enough. For UI work, our reviewer also inspects the Playwright video: it extracts keyframes and checks that the requested surface, interactions and outcome are actually visible. The video does not replace the adversarial reviewer. It gives the reviewer runtime evidence instead of another claim.

In our Aquiva AI Pods, the orchestrator works more like an architect. Their job is to use AI wherever it is reliable and bring people in where it is not. The point is not to hand execution to agents wholesale. It is to design the right boundary between agents and human expertise.

Like almost every AI demo today, Salesforce prepared the result in advance and fast-forwarded it like a cooking show. It had to: agents run for hours, and the outcome is not equally good in every run. I also doubt that the specification and Salesforce skills alone produced the polished result on stage. The team itself said that it had steered and corrected the agent the night before. That human work is part of the system.

…Orchestrate Agent Teams in Lifecycle Center

When an agent spends an hour on a feature, why not move to the next backlog item? Salesforce's answer is refreshingly old-fashioned: put the agent work on a Kanban board and let the developer orchestrate and unblock it.

I genuinely like that Salesforce gave this a real UI. Moving a card into the build column started the agent, opened a pull request and moved the work towards review and CI.

At Aquiva, we use GitHub issues and pull requests for the same job. They are good records, but not a good board across many agents. Lifecycle Center showed what was waiting, running, under review or blocked.

The Workbench opened the agent history, changed files, review, cost and model choice behind each card. The developer became the project manager of an agent team: add context, reject a bad plan, inspect the evidence and unblock the next step.

…Decide Where Agentforce Reasons and Where Rules Take Over

Until recently, Agentforce still felt immature: clunky to build, spread across XML files and configuration, and difficult to deploy or package reliably.

The Builder itself is not new. Salesforce introduced it at Dreamforce 2025 and made it generally available earlier this year. What the 2026 keynote showed is that this is no longer an isolated preview: Salesforce now says everything behind Agentforce is Agent Script, and new agents are created in this model.

Agent Script makes this more explicit. Natural-language instructions, variables, transitions and actions now live in a source file that developers can edit in VS Code and keep in a Salesforce DX project. The comparison is not exact, but if you have worked with LangGraph or state machines, the idea feels familiar: probabilistic reasoning becomes part of a deterministic flow instead of the whole application disappearing inside a prompt.

The new Builder presents the same agent through Chat, Canvas and Agent Script. A low-code builder can change it visually, while a pro-code developer works on the source with autocomplete, validation and version control.

The developer decides which parts need interpretation and which must be deterministic. A model can understand what a customer is asking, while access to a capability, a state transition or a safety rule remains explicit and testable.

The Dreamforce demo also showed the development loop around it. Agentforce DX ran the same case ten times and produced a test report, while the trace exposed every subagent, action and variable assignment. Those sessions feed Agent Analytics in Data 360. This gives developers something concrete to repeat, inspect and debug instead of judging an agent from a few good conversations.

…Design Smaller, Contextual Interfaces Beyond Chat With HXL

For a while, the industry behaved as if every AI interface would be a chat window. HXL, the Headless Experience Layer, is the first Salesforce concept that makes a different future tangible: AI still needs UI.

That UI will probably be smaller and more contextual than the applications we build today. It appears when the conversation needs structure: a choice, a form, a status, a chart or a confirmation. The developer's task is no longer to build a complete screen for every step, but to decide when a conversation should become an interface and what the user needs to see or do.

HXL also separates the interface definition from the platform. The same declarative widget can render natively in Slack, Agentforce or Claude, using the target's styling and components. Developers define the interaction and connect it to Salesforce data, permissions and actions; HXL adapts the rendering.

For UI designers and developers, that shifts the work. Less time goes into platform-specific layouts and repeated tweaking for every surface. More time goes into combining language and interface: which part should remain conversational, where structure is necessary, and how much UI the user needs in that moment.

A Credible Reason for Optimism

Thousands of companies have invested deeply in Salesforce, and that installed base will not disappear. The platform is full of proprietary details, and the ecosystem is full of people who understand them. Their platform knowledge will increasingly be used to direct agent teams and stay accountable for the quality of what ships.

Coding agents give those people far more leverage, and Salesforce now seems to be building its platform around that reality. I find this genuinely reassuring. After years of changing names and disconnected tools, I am excited about Salesforce development again.