Quality gates for AI code in the Salesforce pipeline

AI-generated Salesforce code should pass the same quality gates as code a person wrote, with three conditions: every check must be able to stop a change, it runs in a pipeline you own, and it applies to every partner alike. In practice that means five checks on every pull request, the change proposal a developer submits before code enters the main branch: code analysis with a hard threshold, a few rules for mistakes agents typically make, a test deployment into a sandbox, performance hints from ApexGuru and a merge block nobody can bypass. What a rule cannot decide stays with a human reviewer.

Worked example: the spare part that is suddenly out of stock

Assume a machine builder with SAP S/4, Service Cloud, Field Service for 150 technicians and a dealer portal. Two partners, one onshore and one nearshore, started using coding agents this year. All numbers are assumptions. Pull requests rise from about 60 to 110 a month; on the client side, one architect and one release manager still review them.

A nearshore developer asks an agent to fix a rounding error in the spare-parts availability check that technicians use in the mobile app. The agent fixes it, adds a test and, on the side, moves the code to a newer Salesforce API version. Under that version the code sees only the records the logged-in technician may see. If technicians have no access to central warehouse stock, those parts drop out of the result. The test does not run as a technician, so it passes. Code analysis is green, the test deployment is green, coverage is 91 percent.

That check is a short script, about an afternoon of work. Against it stands pipeline time: at 25 minutes per test deployment, 110 runs are about 46 hours a month, paid in CI minutes, not in anyone’s calendar. Why the version change matters is explained in API 67.0 and user mode.

The partner’s own checks are not enough

The 2025 DORA report1 found that AI adoption increases delivery throughput but still has a negative relationship with delivery stability. Its explanation: “Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.” In a Salesforce programme, the pipeline is that control system.

Salesforce’s own skills for Claude Code already check a lot on the developer’s machine. According to the Salesforce Developers Blog2, they reject database queries inside loops, run Code Analyzer and the Apex tests and ensure 75 percent coverage before they finish. The same post still tells developers to “run Salesforce Code Analyzer manually as an extra safety check”.

For you as the client, a check on a partner’s laptop is the partner’s word. You cannot see which configuration ran or which rules were switched off. The check that counts runs in a pipeline you own, with the same thresholds for every partner. Tests that prove nothing, wrong fields and business rules still need a person; that split is the topic of reviewing AI-generated Salesforce code.

Which quality gates should AI-generated code pass?

I would run five checks, in this order, so the cheap ones fail first.

The five checks on every pull request

CheckWhat it stopsBlocks the merge?Who owns it

Code analysisKnown security and performance flawsYes, from severity HighClient sets the threshold

Rules for agentsUnrequested version changes, hard-coded addressesYesClient architect

Test deploymentInvented fields, missing dependencies, failing testsYesPipeline, integration sandbox

ApexGuruSlow code under real loadNo, report onlyRelease manager per release

Merge blockMerging a red build, even by an adminYesCode owner on the client side

Code analysis. Salesforce Code Analyzer3 checks Apex, Lightning components and flows for known security and performance problems. By default it only writes a report. I would let it block from severity High on day one and report everything below. Blocking everything on an org with ten years of Apex produces hundreds of old findings, and partners start switching rules off instead of fixing them.

Rules for agents. The standard rules do not know your org. Two additions earn their place with AI-generated code: your own rules for patterns you never want, such as hard-coded addresses where your SAP interface should use a stored connection, and the version check from the example above. Do not expect the analysis to judge test quality: a test with one meaningless assertion passes it.

Test deployment. Before anything is merged, the pipeline deploys the change into an integration sandbox, a test copy of your org with the full field set, and runs all your own tests. Nothing is installed; the run only shows whether the release would work. That is where an invented field or a missing dependency fails, before a person reviews. For production, Salesforce requires 75 percent test coverage and all tests passing (Apex testing best practices4). A successful run can later be released without running the tests again, within 10 days (command reference5).

ApexGuru. ApexGuru finds slow patterns such as queries without limits. Salesforce says it “is available only in Production and Full Copy Sandbox orgs” and rates findings with runtime data from there (Salesforce Developers Blog6). A pipeline against an integration sandbox may lack that data, so I treat it as a report per release.

Merge block. Checks only work if a red pipeline stops the merge. On GitHub, administrators can bypass branch protection unless a separate setting forbids it (GitHub Docs7). With partner admins on the repository, I would switch that setting on and make a person on the client side the code owner for sharing, permissions and integration code.

For developers

Commands and settings behind the five checks

• Code analysis: sf code-analyzer run --severity-threshold 2 (2 is High) or the official GitHub Action in version 2; version 1 still uses the retired Code Analyzer v4 (CI/CD integration (opens in a new tab), command reference (opens in a new tab)).
• Own rules: Regex rules in code-analyzer.yml with pattern, file extensions and severity (Regex engine (opens in a new tab)), for example WITH SYSTEM_MODE without a written reason. PMD's ApexUnitTestClassShouldHaveAsserts only checks for "at least one assertion" (PMD best practices (opens in a new tab)).
• Version check: compare apiVersion in changed -meta.xml files with the target branch and fail unless the bump was requested. From 67.0 Apex runs in user mode by default (Apex Developer Guide (opens in a new tab)); a bump needs a System.runAs() test with a restricted user.
• Test deployment: sf project deploy validate with RunLocalTests, release with sf project deploy quick and the job ID. RunRelevantTests is still beta.
• Merge block: required status checks, code owners and "Do not allow bypassing the above settings" on the protected branch.

sfdx-hardis covers most of it as open source

sfdx-hardis runs two control jobs on every pull request, according to its documentation on pull request results8. One simulates the deployment in the target org, runs the tests, checks coverage and posts the result as a comment on the pull request. The other checks code quality and comments its findings as well. In the documented configuration only the release manager may change the error threshold, and exceptions are meant “only for false positives, never to publish faster” (MegaLinter errors9).

ApexGuru and org-specific rules such as the version check are not part of the documented jobs; add them as extra steps. sfdx-hardis also lists an automatic fix by a coding agent for failed deployments, still in beta (overview10). I would accept such fixes only if they pass the same checks and a person reviews them. How the rest of the pipeline fits together is in why DevOps decides Salesforce enterprise projects.

Write the checks into every partner contract

Setting up these checks for programmes with several partners is the core of my DevOps and release management work. The order matters, because a partner can switch off any threshold as long as the pipeline belongs to them.

1. Own the pipeline. Repository, pipeline and thresholds sit with you, as described in why clients should own their DevOps tools.
2. Let code analysis block from High and publish the full report on every pull request.
3. Test-deploy every pull request into an integration sandbox with all your own tests.
4. Stop unrequested version changes and require a test as a restricted user for every requested one. Put the same rule into the AI rules file of your repository, so agents know it before the pipeline stops them.
5. Protect the main branch without an admin exception, with code owners on your side for sharing and integrations.
6. Run ApexGuru per release against an org where it has runtime data.
7. Count failed checks per partner and category every month. A rising category shows which rule is missing from the rules file or the contract.

Sources10

1. 12025 DORA report (opens in a new tab)cloud.google.com
2. 2Salesforce Developers Blog (opens in a new tab)developer.salesforce.com
3. 3Salesforce Code Analyzer (opens in a new tab)developer.salesforce.com
4. 4Apex testing best practices (opens in a new tab)developer.salesforce.com
5. 5command reference (opens in a new tab)developer.salesforce.com
6. 6Salesforce Developers Blog (opens in a new tab)developer.salesforce.com
7. 7GitHub Docs (opens in a new tab)docs.github.com
8. 8documentation on pull request results (opens in a new tab)sfdx-hardis.cloudity.com
9. 9MegaLinter errors (opens in a new tab)sfdx-hardis.cloudity.com
10. 10overview (opens in a new tab)sfdx-hardis.cloudity.com