AI Coding Tools vs Salesforce Delivery Agents: Cursor, Copilot and Beyond

The strongest published evidence that AI coding tools work on Salesforce comes from Cursor, and it is worth reading closely rather than quoting.

In a customer story dated 21 January 2026, Cursor reports that over 75 percent of developers at Salesforce now use the editor, with a 30 percent or greater increase in pull request velocity and 85 percent less time spent on legacy test coverage. Shan Appajodu, an SVP of Engineering at Salesforce, is quoted describing the change as transforming how developers use tools to improve product quality.

Those numbers appear real and the named executive attribution makes them checkable. Now read the subject of the sentence. The case study describes Salesforce as a software company maintaining a codebase built over more than 25 years, with thousands of engineers shipping products on top of it. Cursor’s own framing notes that junior engineers were the first adopters, many of whom started their careers remotely and used the tool to learn an unfamiliar codebase.

That is Salesforce’s product engineering organization building the Salesforce platform. It is not a customer configuring Sales Cloud, and the two activities share a brand rather than a workload.

The distinction governs this entire comparison. AI coding tools operate on a repository of source files. Salesforce delivery agents operate on an org, a project and a set of deliverables. Whether the first category is sufficient depends on how much of your work is actually source code.

A Salesforce org stores configuration, and a repository stores files

An IDE assistant assumes a filesystem. It indexes files, reasons over their contents, and edits them. That assumption holds completely for the codebase Cursor’s case study describes, and holds partially for a Salesforce project.

What lives in a Salesforce org that has no file representation until someone retrieves it: object and field definitions, validation rules, record types, page layouts, Lightning record pages, flows, permission sets and permission set groups, sharing rules, queues, approval processes, custom metadata records, and the data itself.

Some of that can be pulled into source form through the Salesforce CLI, and disciplined teams do exactly that. Two problems survive the retrieval.

Retrieved metadata is not readable in the way source code is readable. A flow arrives as XML describing nodes and connectors. A validation rule arrives as an errorConditionFormula inside the object’s metadata file rather than beside the field it constrains, so the rule and the field it protects sit in different places in the retrieved tree. An assistant reading those files can parse them. Working out what the automation does to a business process is a different operation.

And retrieval is a snapshot. The org keeps changing underneath it, through admins working in production, through managed package updates, and through three Salesforce releases a year. A repository is authoritative for a codebase. For an org it is a photograph.

This is the concrete version of a point made more generally in the comparison of general chat assistants against purpose-built agents. Here the constraint is narrower and more technical: the tool is excellent at files, and a meaningful share of the work is not files.

Coding tools read the repository; connected agents read the org

The gap above has a partial remedy, and Salesforce built it.

Salesforce publishes official setup instructions for connecting Cursor to its hosted MCP servers, describing Cursor as an AI-driven code editor that supports MCP. Configuration runs through a local mcp.json file, an external client app consumer key, and separate endpoints for production against sandbox or scratch orgs. Salesforce’s tested-client table lists Cursor with native OAuth support and no additional software required, alongside Claude, ChatGPT, Postman and Agentforce Vibes.

Connected that way, a coding tool gains real org awareness. It can retrieve the shape of your objects, so generated code references API names that exist instead of names that sound plausible. For a developer working in an unfamiliar org, that single capability removes a large class of wasted iterations.

What the standard tool set does not reach is the logic layer: the Apex already deployed, the branching inside your flows, the formulas behind your validation rules, the contents of your permission sets. The reasons and the exact tool inventory are covered in the general assistant comparison; the consequence for a developer is short. A connected editor learns the shape of your org without learning its behavior.

That gap produces one recurring failure. A developer asks for code that updates a field. The tool writes correct code against a correct field name. At runtime a validation rule neither of them could see rejects the update, or a flow nobody mentioned overwrites it seconds later.

Salesforce publishes its own skills library and makes it tool-agnostic

The most informative signal about where the platform vendor thinks this is going sits in a public repository rather than in a product announcement.

Salesforce maintains `forcedotcom/sf-skills`, an Apache-2.0 licensed collection it describes as a curated set of Salesforce agent skills for building applications, covering Agentforce agents, Lightning apps, Flow, Apex, SOQL, Lightning Web Components, UI bundles, objects and fields, permission sets and related areas. The repository states that skills are contributed by Salesforce and the broader community.

The sentence that matters commercially: the library is optimized for Agentforce Vibes and can be used with any AI tool that supports skills.

Read that as a strategy statement. Salesforce is not attempting to make you abandon Cursor or Copilot. It is publishing the platform knowledge those tools lack, in a portable format, and letting you attach it to whichever editor you already use. The repository also carries an explicit warning that it is evolving rapidly and that skills may be renamed or restructured, which is an honest caveat and a maintenance commitment for anyone depending on it.

The practical conclusion for a delivery lead: the difference between a coding tool that is dangerous on Salesforce and one that is useful is mostly the skills, rules and connections wrapped around it. That wrapper is work, it has an owner, and it needs updating three times a year.

Every tool solves Salesforce competence the same way, through an instruction layer

Compare how the three main options acquire platform knowledge and the pattern is identical.

Agentforce Vibes ships with Salesforce skills attached. Cursor takes project rules plus MCP connections. GitHub Copilot takes repository instruction files, and GitHub’s own Awesome Copilot collection publishes an Apex instruction set describing guidelines and best practices for Apex development on the Salesforce Platform.

Read what that Apex instruction file actually has to say, because it is the most direct evidence available about what these models do not know. It instructs the assistant to focus on bulkification and write code that handles collections of records rather than single records. It instructs the assistant to be mindful of governor limits and design solutions that scale efficiently. It prescribes separation of concerns through service, domain and selector layers, and it sets naming conventions.

Bulkification is the first thing any Salesforce developer learns, and governor limits are the defining constraint of the platform. An instruction file exists to tell the model both. That is not a criticism of the tools. It is a precise measurement of where the Salesforce knowledge lives: in a text file somebody wrote and somebody has to maintain, not inside the model.

Which produces the real selection criterion for a delivery lead. The editor is close to interchangeable. What differs is who authors your instruction layer, how current it is against three releases a year, and whether it is attached to every prompt or only to the ones a careful developer remembers to ground.

Generated Apex compiles at desk volume and fails at production volume

Salesforce-specific code failure has a signature that general code quality research does not capture, and it is worth naming precisely because reviewers miss it.

The platform enforces execution limits per transaction. Code that queries inside a loop works against the handful of records in a developer sandbox and breaches limits against production data volumes. Code that performs a DML operation per iteration does the same. Neither pattern is a syntax error, neither fails a compile, and neither necessarily fails a unit test written against a small dataset.

Salesforce concedes the general risk in its own developer documentation, warning that agentic development stops short of autonomy, that generated output can invent method names or assume the wrong things about an org, and that review by a person remains mandatory rather than advisable.

Three consequences follow for anyone running coding tools on Salesforce.

Test data volume becomes a review control rather than a testing detail, which is why test strategy and Apex unit testing practice need explicit limit-aware cases rather than coverage targets.

Review has to check patterns as well as correctness, and pattern checking against a published rule set is what AI-assisted code review is suited to.

And the environment matters: generated code needs a sandbox with representative volume before anyone can claim it works.

Coding tools accelerate a minority of Salesforce delivery

Even granting perfect code generation, the question remains what proportion of a project that addresses.

A Salesforce implementation includes discovery and requirements, solution design, declarative configuration, data migration and reconciliation, integration, unit testing, system and acceptance testing, deployment, training and adoption. Apex and Lightning Web Components appear in one of those ten activities, and many implementations of standard functionality write very little custom code at all by design, since Salesforce guidance has long favored configuration where configuration suffices.

No credible public dataset gives a reliable split between declarative configuration and custom code across Salesforce orgs, and this page is not going to invent one. The absence is itself informative: anyone quoting a precise percentage for how much of Salesforce work is coding is estimating.

What can be stated without a statistic is directional and sufficient for a buying decision. A tool that accelerates code generation compresses one activity. If that activity is a quarter of your effort and the tool makes it twice as fast, the project gets an eighth shorter, and only if nothing downstream becomes the new constraint. Requirements that were ambiguous before remain ambiguous. Solution design and user stories with acceptance criteria are still produced by people, and they still gate everything after them.

Delivery agents produce reviewable artifacts, not edited files

The category difference becomes clear when you look at what each tool returns.

A coding assistant returns a diff. The unit of output is a changed file, reviewed in an editor, by a developer, in the context of a repository. That is the right unit for engineering work and the wrong unit for a requirements workshop, a configuration specification or a test plan, none of which are files in a repo.

A delivery agent returns a deliverable. GetGenerative.ai assigns named agents across six delivery stages, of which only the build and test stages overlap the territory a coding assistant occupies. The stage that matters most for this comparison is the one that inspects the org before design starts, because that inspection decides whether the requested thing should exist in the requested form. A coding tool joins the project after that question has been settled, or after it has been skipped.

Pricing follows the unit of output. Coding assistants bill per developer per month, which is coherent when the thing produced is code and the producer is a developer. Credit-based delivery platforms bill per artifact generated, which is coherent when the thing produced is a document that a project consumes once and revises many times.

Those two meters are not comparable on price per seat, and a procurement exercise that treats them as substitutes will pick the cheaper one and then discover the missing deliverables in month two. Teams can weigh GetGenerative.ai plans and credits against one real deliverable, which settles the question faster than any feature grid.

Choose by artifact type, not by tool preference

Sort the work by what it produces, and the answer stops being a matter of preference.

The rows split cleanly. Where the deliverable is a file, a coding tool wins and the only question is how well it is grounded. Where the deliverable is a document, a decision or a reconciliation, a coding tool has no unit of output to produce, and that is not a quality problem to be solved with a better model.

Teams surveying the wider market can work from the AI platform roundup once the artifact question above has been answered.

Recap. Cursor’s published 75 percent adoption and 30 percent velocity gain at Salesforce measure a 25-year product codebase and thousands of platform engineers, not Salesforce implementation work. Coding tools operate on files; much of an org has no file representation until retrieved, and retrieval is a snapshot. Connected through MCP they gain schema awareness but still cannot see Apex source, flow logic, validation rules or permission sets. Salesforce publishes a tool-agnostic skills library rather than competing for the editor. Choose per task by whether the deliverable is a file.

Key facts

FAQ

Can Cursor or GitHub Copilot be used for Salesforce development?

Yes, and Salesforce publishes official instructions for connecting Cursor to its hosted MCP servers, listing it as a tested client with native OAuth support. Connected that way, a coding tool can read object and field schema so generated code references real API names rather than plausible guesses.

Does the Cursor Salesforce case study apply to Salesforce implementations?

Not directly. Cursor reports over 75 percent adoption and a 30 percent pull request velocity gain at Salesforce, but the case study describes Salesforce’s own product codebase built over more than 25 years by thousands of engineers. Configuring Sales Cloud is a different workload.

What can AI coding tools not see in a Salesforce org?

A connected editor can retrieve the shape of an org, meaning its objects and how they relate. It cannot read the behavior layer: Apex already deployed, branching inside flows, validation formulas, or what a permission set actually grants. It learns structure without learning runtime behavior.

Why does AI-generated Apex fail in production but pass locally?

Salesforce enforces execution limits per transaction. Queries or DML inside loops work against small sandbox datasets and breach limits at production volume. The pattern is not a syntax error and does not fail a compile or a unit test written against limited data.

Does Salesforce provide anything to make coding tools better at Salesforce?

Yes. Salesforce maintains an Apache-2.0 skills library at forcedotcom/sf-skills covering Agentforce agents, Flow, Apex, SOQL, Lightning Web Components, objects and fields and permission sets. It is optimized for Agentforce Vibes and documented as usable with any AI tool that supports skills.

When should a delivery agent be used instead of a coding tool?

When the deliverable is a document, a decision or a reconciliation rather than a file. Requirements, solution design, configuration specifications and test plans have no unit of output a coding assistant produces, which is a category limit rather than a model quality problem.