Salesforce AI Engineer: will this role replace Salesforce admins and developers?
Last reviewed: September 28, 2026
Salesforce administrators have traditionally worked closely with business teams and met many requirements directly through configuration and automation in the org. Developers often came in when a solution went beyond what configuration could do, or when custom development, tests and a controlled deployment were needed. With AI coding agents, these areas of responsibility are now converging.
An AI agent can draft a Flow within minutes, for example. That the Flow works technically does not yet mean it fits the specific Salesforce org and the business process modelled there. For an agent to work reliably, the Salesforce team has to decide in advance which business rules apply to it, which tools it may use and how the team will recognise a correct change.
A new responsibility arises at exactly this interface. Pariveo uses the role name "Salesforce AI Engineer" for it in this article. This does not simply mean a developer who uses AI tools. It means responsibility for a workflow in which business org knowledge, administration, development and AI coding agents work together.
An AI agent does not know the org the way your team does
Take an example. When an opportunity closes, a handover task should be created automatically. The coding agent produces a Flow. At first glance, the draft looks plausible.
The agent found three fields describing handover status and chose one as the trigger. An existing integration populates a different status field, however. This dependency cannot be reliably recognised from the field metadata alone.
Whether the Flow draft fits the org remains unclear. Someone has to establish which field matters and how the new automation works together with the existing integration.
Further questions come up: What should happen if the opportunity is reopened and later closed again? Who should see the resulting task? Should an existing task be updated, or a new task created?
An AI agent cannot reliably infer such decisions from metadata. They belong to the team's business knowledge and have to be documented so that the agent can take them into account and the team can check the result later.
This shifts the decisive question: no longer "Can the agent build this Flow?", but "Under what conditions can the team trust the result?"
From Salesforce knowledge to the agent's workplace
For an AI coding agent to work reliably, it needs more than access to the source code. It needs a defined working framework that connects technical information, business decisions, tools and checks.
We call this working framework a harness.
We use harness to mean the working environment around a coding agent. It captures which context applies, which tools are available, which org and data may be accessed and which checks a change must pass.
| Area | Team decision | Required implementation |
|---|---|---|
| Context | Which conventions, examples and business rules apply? | Reviewed project instructions and reference Flows |
| Tools | Which operations may the agent perform? | A set of tools limited to the assignment |
| Access | Which org and data can it reach? | Configured and tested permissions |
| Validation | How will we judge the change? | Automated checks and business test cases |
| Traceability | How can someone review the result later? | Change diff, check results and approval |
The harness is therefore more than a technical configuration. It translates the Salesforce team's knowledge into rules and evidence an AI coding agent can work with.
1. Context: what does the agent need to know about the org?
Useful org context for AI coding agents connects the technical structure to the team's business decisions. For the handover example at the start of this article, that would include a short explanation of the relevant status field, an approved reference Flow and the circumstances in which another process already creates a task.
That is because the business intent cannot be derived from the org alone. A field name cannot show, for example, whether an integration continues to use an older status field. Nor does the org reveal which existing Flow should serve as the template.
When naming a specific Flow as the template for a new Flow, keep in mind that an agent also adopts its construction. If the template Flow contains outdated Flow patterns, the agent carries them over. If it is not yet clear that the template suits the new handover Flow, the assignment should therefore state that uncertainty explicitly.
We recommend recording these decisions in short project instructions that point to the relevant fields, Flows and test cases. For the handover process, that means, for example, the affected fields, the existing automation and the expected test results.
If it stays unclear which automations overlap or which field is actually maintained, an inventory helps. A Platform Assessment records exactly those overlaps and prioritises the next steps.
Building AI agents vs. building with AI coding agents
There are two areas of use to distinguish here. AI coding agents assist with developing a Salesforce application. An Agentforce agent, by contrast, is part of that application and can carry out a customer service process, for example.
Salesforce documents a development workflow using Agent Skills and the CLI in which a coding agent helps design, build, test and debug an Agentforce agent.
| Aspect | AI agent for a business process | AI coding agent for development |
|---|---|---|
| Example assignment | Handle a service request | Prepare a Flow for a handover |
| Context needed | Process rules and approved business data | Requirements, org metadata and project conventions |
| What the team approves | Behaviour within the business process | Changes to code and configuration |
Work with the two kinds of agent can overlap. Someone developing an Agentforce action in Apex, for example, needs business process knowledge as much as a reliable development workflow. Permissions, testing and acceptance criteria also play an important role in both areas.
Skills as part of the context
The Salesforce Skills Library supplies another part of the coding agent's working environment. Its repository includes skills for Apex, Flows, objects and fields, among other areas. It follows the open Agent Skills specification.
Salesforce also warns that the library changes frequently and that skills don't carry the same stability guarantees as generally available platform APIs.
A skill bundles instructions with optional scripts or reference material. The Agent Skills specification describes loading the full instructions when needed.
For a project, it is therefore not enough to simply install a skill. The team should decide which skills it has reviewed, what local conventions supplement them and how updates are adopted in a controlled way.
2. Tools and access: what may the agent actually do?
The tool selection determines which operations an agent can request. A team does not necessarily have to introduce an entirely new development environment for that. A coding agent works through the same tools as development, meaning Salesforce CLI, Git and the existing deployment path.
Common coding agents can be allowed or blocked per command. Their hooks run before execution and can hold or decline a command.
Retrieving metadata or validating without saving, for example, can be allowed without a prompt. A deployment to a production org, by contrast, should require explicit approval.
If the authenticated user lacks the necessary permissions, the org does not allow the deployment through the Metadata API either.
The most important access boundary, though, is not the individual tool but the user the agent authenticates as. A dedicated sandbox user without access to production data limits what every tool can do at once.
For the automation in our opening example, we would start with a clearly bounded development scope. The agent can read the necessary metadata, prepare a draft in the repository and validate it against a sandbox. This assignment does not require write access to production business data.
When the CLI is not enough
Where an agent needs more than the CLI, Salesforce Hosted MCP Servers come into consideration. They expose org data and automation to compatible AI clients, including custom tools for Apex and Flows.
The mcp_api OAuth scope grants access to those MCP servers and, according to Salesforce, serves as an alternative to the broader Platform API scope. Which operations are possible also depends on the exposed tools and user permissions.
A description within a tool is not an enforceable access control, as Salesforce explains in its MCP security guidance.
With custom Apex tools, the user boundary applies only partly, because the execution context does not automatically inherit that user's permissions. The specific implementation should therefore be tested with the intended user permissions before the team exposes it as a tool.
3. Approval: how do we recognise a fitting change?
The third part of the harness answers the decisive question from the start: how does the team recognise that the agent has not just built something, but the right change?
An approval should show what changed and which checks actually ran. For the handover Flow in the opening example, our approach covers the change diff as well as test cases for the first handover and for closing the opportunity again.
That way the implementation can be measured against the original requirement, not only checked for technical validity.
The Salesforce CLI supports deployment validation without saving the changes to the org through sf project deploy start --dry-run. Which Apex tests run depends on the chosen test level. Its documentation specifically recommends --test-level RunLocalTests for sandbox validation with tests.
The team should record the target org, scope and test results so that it stays clear later what was actually validated.
Not every criterion can be checked this way, however. Naming conventions, for example, can be checked with Salesforce Code Analyzer, extensible through PMD, ESLint or Regex.
Whether the task is created only when the opportunity finally closes, and not already at an earlier status change, is shown only by a test of the business behaviour.
For the harness, therefore: every acceptance criterion needs its matching evidence.
What this means for Salesforce admins and developers
By this point, it becomes clear why the Salesforce AI Engineer role is not simply a new variant of the developer. It combines responsibilities that were previously spread more across different roles.
Salesforce administrators and developers have so far brought different focuses to technical implementation. For agent-assisted changes, both have to connect business requirements, technical implementation and checks more closely.
Salesforce administrators bring process knowledge. Developers bring engineering practices. Both become relevant for working with AI coding agents.
The central change therefore lies less in a new job title than in combining these skills.
The route from Salesforce administration
Salesforce administration brings the knowledge the agent lacks: Why does a field exist? Which process do people actually follow? What do the business teams require?
The next step from there leans more toward software architecture and checkable requirements. What happens if the same sequence runs twice? What does this change depend on? How would the team notice that it no longer behaves as intended?
Anyone who designs processes already asks those questions in substance. Version control, test cases and review conventions additionally translate that knowledge into a form a coding agent can work with.
The route from Salesforce development
Salesforce development brings the experience of making a change demonstrable. Reviews, automated checks and a controlled deployment to the production org are part of that.
The next step here leans more toward the business side. An agent can produce code that clears every automated check and still models the wrong process. Someone who understands the business intent behind a change can recognise the difference.
The shared responsibility
Both routes lead to a shared responsibility. Whoever maintains reference Flows and business test cases works on the same harness as the person configuring automated checks and reviewing Apex changes.
Administrators learn to define requirements with testable acceptance criteria. Developers learn not only to implement the business purpose of a change technically, but also to keep it in view.
Whether that becomes a separate position, a new specialisation or an additional responsibility within existing roles depends on the volume of work and the organisation. The real change does not begin with the job title, but with responsibility for the context, tools and approval of agent-assisted changes.
How Salesforce teams can start with AI coding agents
To get started, we recommend one concrete change in a sandbox whose expected result the team can describe. The handover task from the opening example works well as a manageable model.
The first workflow can deliberately stay small:
- The team defines a fixed scope in the ticket: affected fields and automation, boundaries for changes, the target sandbox and the person who accepts the business behaviour.
- When recording the requirement, the team sets testable acceptance criteria. For the handover task in the example, these cover creating the task for the first time, what happens when the opportunity closes again and reviewing the change diff.
- The agent receives only the tools and access it needs for this task.
- After execution, the change, test results and business approval are reviewed together.
- After each task, the team records which org context, tool boundary or check was missing, and updates the project instructions, permissions and tests.
This last step is especially important: the harness should not be treated as a one-off configuration.
If that example process changes later, the project instructions and test cases need review too. Org context can become stale: the agent might use an earlier reference Flow even though the team has since introduced a different process.
The harness thus evolves together with the agent's use. An initial concept does not need to anticipate every detail. With each routine assignment, the instructions, access and checks become more precise.
So what is a Salesforce AI Engineer?
The answer to the opening question is therefore not simply "yes" or "no". The Salesforce AI Engineer role describes a new connection between previously separate responsibilities.
An AI coding agent can produce code and configuration faster. But it does not automatically know the business meaning of a field, the history of an automation or users' expectations.
Salesforce administrators bring knowledge of the org and its individual processes. Developers contribute engineering practices, reviews and tests. The Salesforce AI Engineer connects this knowledge with a controlled workflow in which AI coding agents can be used safely and traceably.
This includes in particular:
- defining the relevant org context
- translating business requirements into checkable criteria
- limiting tools and access
- providing suitable references and skills
- connecting technical and business checks
- approving changes in a traceable way
- continuously evolving the workflow based on the team's experience
The Salesforce AI Engineer therefore does not automatically replace Salesforce admins or developers. Rather, the role changes how their knowledge is used: part of that knowledge becomes the working context, the guardrails and the checks within which an AI coding agent can operate.
Next step
If you want to use AI coding agents in your Salesforce org, don't start with the agent but with a clearly bounded change. Define the org context it needs, limit access and decide up front how the result will be measured. Step by step, this builds a dependable harness for agent-assisted development and, at the same time, a way of working that continues to build on the knowledge of Salesforce admins and developers.