AI code best practices for Salesforce programmes

For AI-generated Salesforce code, every major tool vendor recommends the same pattern in 2026: a short rules file in the repository, a plan before the code, and checks that do not depend on the model’s goodwill. Salesforce adds typical defects that a machine can mostly find: queries in loops, missing field and object permissions, tests without real asserts, invented field names. And API 67.0 changes the permission defaults per class. As the client you do not need to read code. You should own the rules file, the pipeline and org access, and no agent touches production.

What does the evidence say about AI-generated code?

The studies measure very different things, and none of them measures Apex. Four findings are enough for a decision:

Study	Setting	Result
Veracode, July 2026 (opens in a new tab)	raw models without tooling or review, 11 models in this year’s comparison	56 % security pass rate, “virtually unchanged”; Python 63 %, Java last at 30 %
METR, July 2025 (opens in a new tab)	16 experienced developers, real issues in their own large repositories	19 % slower with AI, while believing they were 20 % faster
METR, February 2026 (opens in a new tab)	follow-up	a speed-up is now “likely”, but the data is “only very weak evidence” for its size
DORA, September 2025 (opens in a new tab)	nearly 5,000 respondents	AI raises throughput but still hurts stability; “it amplifies what’s already there”

I draw two conclusions. A mature client org with years of triggers, flows and SAP integrations looks more like the METR setting than a greenfield task, so measure productivity gains there instead of assuming them; chapter 9 covers how. And Veracode’s Java figure is a warning sign for Apex to me, because the two languages are close relatives. That is not proven; there simply is no Apex data.

Which defects does AI typically put into Salesforce code?

Salesforce documents the weak spots itself. The review checklist for Agentforce Vibes (opens in a new tab) asks about queries in loops, the 100 SOQL query limit in bulk operations, and asserts that check more than System.assertNotEquals(null, result). Its key sentence: “Permission modes protect your filesystem. Code review protects your application.”

Area	Typical defect	How to catch it
Governor limits	SOQL or DML in loops, unbounded queries	Code Analyzer, ApexGuru
Bulk processing	trigger handles one record instead of a list	bulk test; the Apex testing guide (opens in a new tab) asks for at least 20 records
Permissions	no sharing declaration, no WITH USER_MODE	Code Analyzer, runAs test
Tests	coverage without assertions, test data taken from the org	review, assert rule
Field names	invented API names that do not exist in the org	validation deployment
Metadata	new field missing from the permission set	validation deployment, review
Configuration	agent changes sharing, profiles, layouts	rule: a human does this in Setup

The last row is Salesforce’s own advice: according to the Vibes workflow patterns (opens in a new tab), permission sets, profiles, page layouts and sharing rules should be set up by hand in Setup, and code for encryption, authentication and permission logic deserves a line-by-line review. At a manufacturer, those are exactly the places that make sure dealers see only their own orders and warranty cases.

On coverage: Salesforce requires 75 percent for a deployment, but its testing guide explicitly says not to focus on the percentage. An agent optimises for whatever check you give it. Give it only the 75 percent and you get tests that run through lines and prove nothing. How to have such code reviewed as the client is covered in reviewing AI-generated Salesforce code, and why every pull request needs a review in why pull request reviews are a must.

The API 67.0 trap

With Summer ’26, Salesforce changed Apex’s default behaviour. According to the Apex Developer Guide (opens in a new tab), code saved at API 67.0 runs in user context, classes without a sharing declaration run with the current user’s sharing, and WITH SECURITY_ENFORCED is no longer allowed in SOQL. The Summer ’26 architect blog (opens in a new tab) adds two points: triggers always run in system mode, but the handler classes they call are affected if they lack a declaration. And classes still using the old clause will not compile on 67.0.

Think of the batch job that writes order status from SAP into Salesforce every night, or the class that calculates warranty periods across all of a dealer’s installed assets. Both have quietly seen everything until now.

For AI code this matters twice over, in my view. Models have mostly seen older Apex, so they suggest patterns that no longer compile on 67.0 or behave differently. And agents like to raise API versions in passing when they touch a file anyway. The rules file should therefore fix three things: the target version for new classes, an explicit sharing declaration, and no raising of existing classes without a task and without a test as a restricted user. Where system mode is intended, the code says WITH SYSTEM_MODE on purpose, as the LWC guide on secure Apex (opens in a new tab) describes. Details are in API 67.0: why Apex sees fewer records, and the pipeline impact in Winter ’27: what changes for your pipeline.

Rules the agent reads, and rules it cannot get around

Every coding agent reads a project file with standing instructions, but the name differs per tool.

For developers

Which file does which agent read?

Claude Code reads CLAUDE.md, Codex AGENTS.md, Agentforce Vibes .vibes/rules/. According to GitHub's docs (opens in a new tab), Copilot reads .github/copilot-instructions.md, AGENTS.md or a single CLAUDE.md in the root.

Whether Vibes reads AGENTS.md is not covered in the Vibes rules docs (opens in a new tab); for mixed teams I would keep one canonical AGENTS.md plus a short Vibes rule that points to it.

The vendors agree on length. Anthropic’s Claude Code best practices (opens in a new tab) recommend staying under 200 lines and keeping only what the agent cannot work out from the code: test and check commands, misleading places in the code, decisions that are written down nowhere, and “anything you’ve had to correct twice already”. OpenAI’s Codex best practices (opens in a new tab) say: “A short, accurate AGENTS.md is more useful than a long file full of vague rules.” An excerpt for a Salesforce repository:

# Orgs
- Work only against scratch orgs and the alias dev-sandbox; never uat or prod

# Apex
- New classes: API 67.0, explicit sharing declaration, WITH USER_MODE
- Do not raise the API version of existing classes unless the task says so
- No SOQL/DML in loops; triggers must be bulk-safe for 200 records
- SAP calls only via Named Credential SAP_S4, never direct endpoints

# Done means
- Positive, negative and bulk tests with real asserts, plus a runAs test
- Report the test command and its output before saying done

The most important part is not in that file, though. Anthropic puts it this way: “If something has to happen every time, make it a hook, a deny rule, or a managed setting.” The model may decide that a guideline in CLAUDE.md does not apply. Deny rules, on the other hand, hold in every permission mode, and a Stop hook sends the agent back to work while tests or Code Analyzer are red. For Salesforce that means: no reading of sf CLI credentials, no commands against production aliases, tests as a hook.

The rules file belongs in your repository, not your partner’s. Who maintains it and how it grows is covered in the AI rules file in your Salesforce repository; why repository and tools should sit with the client in why clients should own their DevOps tools.

Which quality gates belong in the pipeline?

What is in the rules file may go unchecked. What is in the pipeline is checked on every run. I would require the same gates for AI code as for code written by people, just without exceptions:

Gate	What it finds	Note
Salesforce Code Analyzer (opens in a new tab)	security and performance rules via PMD, ESLint, RetireJS, Regex, Flow Scanner	available as CLI and GitHub Action
ApexGuru scan (opens in a new tab)	SOQL in loops, unbounded queries, over-fetched fields	runtime-based severity only with production or a Full Copy sandbox
Validation deployment (opens in a new tab)	missing references, invented fields, failing tests	sf project deploy validate, default RunLocalTests, at least 75 % Apex coverage
Human review	logic, sharing model, architecture	pull request that flags the AI-generated parts

The open Salesforce Skills (opens in a new tab) already include part of this: they reject queries in loops, enforce sharing declarations and run Code Analyzer before reporting success. Salesforce still recommends checking field names against the schema and running Code Analyzer manually as well. A gate in the developer’s tool does not replace the gate in your pipeline. If you do not want a commercial DevOps product, sfdx-hardis is an open-source option. The gates in detail are in quality gates for AI code in your Salesforce pipeline.

Before the gate, the way of working decides how much fails. Three habits work, in my view:

Habit	What it means
Plan before code	In Vibes Plan Mode, according to Salesforce, nothing changes “until you click Approve Plan”. That pays off for an extension spanning several metadata types. For a bug fix, a test that reproduces the bug is enough. Birgitta Böckeler watched a tool turn a small bug into four user stories with 16 acceptance criteria (opens in a new tab).
Evidence instead of claims	The agent delivers the test command and its output, not “all tests pass”.
Small changes	DORA lists working in small batches (opens in a new tab) among the capabilities that carry the benefit of AI. A pull request with 40 changed files does not get reviewed; it gets waved through.

Why does no agent get access to production?

Simon Willison describes the “lethal trifecta” (opens in a new tab): access to private data, exposure to untrusted content and a way to communicate externally. A coding agent signed in through the sf CLI to an org with real dealer and customer data, reading tickets and web pages, with network access, has all three. In its guide to secure deployment (opens in a new tab), Anthropic itself gives the example of a README with unusual instructions that the agent might follow.

My minimum rules for every programme:

1. Agents work only against scratch orgs and developer sandboxes without real customer data.
2. Agentforce Vibes is disabled (opens in a new tab) for production orgs in Setup under “Agentforce Vibes Extensions”.
3. Permissions start at “Ask every time” and open up step by step, as the Vibes docs recommend.
4. Deny rules block credentials and production aliases; credentials live outside the agent’s environment, and Anthropic describes a proxy for this.
5. Production deployments run only through the pipeline, with approval by a person.

These rules belong in the contract with your partner, not only in their working instructions. They are part of my work in DevOps and release management.

Walk-through: spare-part availability in the dealer portal

Assume a machine builder with an Experience Cloud dealer portal, Service Cloud and SAP S/4. All figures are assumptions. The partner is to build, with four developers and Claude Code, a component that shows dealers the availability of spare parts for their machines.

In the requirements workshop, a clickable draft comes together in two hours in a Developer Edition org. That is vibe coding at its best, and the draft is thrown away afterwards; where the line runs is covered in vibe coding in Salesforce: prototype or production. For the real build:

1. 01

   Rules file

   The rules file lives in the manufacturer's repository and names the SAP Named Credential, target version 67.0 and the scratch org commands.

2. 02

   Plan

   The agent writes a plan first, and a developer approves it.

3. 03

   Test

   The plan includes raising an existing selector class from 62.0 to 67.0, so the rules file requires a runAs test. The test as a restricted dealer user shows that other dealers' assets disappear, which is intended, but so does the parts master data, which is not. Caught in the validation deployment instead of in the portal.

4. 04

   Code Analyzer

   Code Analyzer reports a query inside a loop over 200 order lines, and the pull request goes back.

5. 05

   Review

   The reviewer checks the sharing model, not the formatting.

None of these steps is new. What is new is that without them, far more unreviewed code is produced in the same time. The cost of the AI tools themselves is covered in chapter 7, and all chapters are on the overview page.