Apex Code Review with AI: Standards, Anti-Patterns and Automation

Salesforce ships eight code analysis engines behind a single command, and one of them silently changes depth depending on which org you point it at.

Start there, because the automation question is further along than most Apex review discussions assume, and because the defaults matter more than the tool choice. Salesforce Code Analyzer scans Apex, Visualforce, Flows and Lightning components, and Salesforce documents the engines it bundles as enabled by default. In Salesforce’s own words:

Two deserve attention before anything else. Graph Engine is described by Salesforce as performing complex analysis on Apex to identify security vulnerabilities and code issues, and it is the engine that reaches defects spanning multiple methods rather than sitting on one line. ApexGuru scans a connected org rather than a local directory, and it behaves differently from every other engine in the set.

Apex code review is the practice of checking Apex against platform constraints, security requirements and written standards before it reaches production. Automation covers the checkable part. This page is mostly about the rest.

Most published Apex review guidance describes a retired tool

Before adopting any of it, check the version, because this tooling changed underneath the internet.

Salesforce’s own documentation states it plainly: as of August 2025, Code Analyzer v4 is retired and no longer supported. Version 5 introduced a new CLI plugin, @salesforce/plugin-code-analyzer, moving commands from the old scanner topic into a code-analyzer topic.

That single change invalidates a large volume of tutorials, CI configurations and internal runbooks. Any pipeline still invoking a command in the scanner topic is invoking a retired tool, and any tutorial teaching that topic is teaching a dead interface.

The trap extends into Salesforce’s own doc set. A rules reference listing Graph Engine rules including ApexFlsViolationRule and AvoidDatabaseOperationInLoop is still live and still indexed, under a heading marked Retired inside the v4 section. The rule names are informative. The page is not current documentation, and citing it as such is the kind of error a reviewer should catch in a standards document.

There is a lesson here that applies directly to AI-assisted review. An assistant trained on the public corpus has read far more v4 material than v5 material, because v4 had years to accumulate content and v5 has had months. Ask a general model to write your Apex scanning pipeline and the odds favor a retired command.

ApexGuru runs in two modes and picks one without telling you

One engine in that table carries a behavior worth understanding before it appears in a CI pipeline.

Salesforce describes ApexGuru as an AI-driven performance and code optimization engine that works alongside PMD, ESLint and RetireJS to detect SOQL inefficiencies and scalability issues, returning line-level highlights, severity ratings and recommendations as JSON.

It then runs in one of two modes. Advanced Mode scans runtime code, and applies when your org or its parent org family has enabled the ApexGuru engine through the Setup page. Basic Mode performs standard static analysis on the connected org, and applies when neither your org nor its parent family has enabled it.

The line that matters for anyone automating this is Salesforce’s own note: scan modes are not configurable at trigger time through the CLI or configuration files, and are determined automatically from the org’s ApexGuru settings.

Read the consequence carefully. The same command, against two orgs, returns two different depths of analysis, and nothing in the invocation says which one you got. A pipeline promoting from a sandbox where ApexGuru was never enabled is running static analysis while the team believes it is running runtime analysis. Checking the Setup page is therefore part of trusting the result, not an optional configuration step.

Advanced Mode also means org Apex is retrieved for analysis, so the activation decision belongs with whoever owns the security review rather than with whoever wrote the pipeline.

Static analysis catches shape, and misses intent

Automated rules evaluate structure. That covers a real and valuable class of defects, and it covers it better than a human skimming a pull request at 5pm.

Structural problems a rules engine finds reliably: a query inside a loop, a DML statement inside a loop, a class declared without a sharing keyword, a hardcoded record ID, an empty catch block, a method whose complexity exceeds a threshold, a duplicated block, a vulnerable JavaScript dependency.

What no rules engine evaluates is whether the code does the right thing. Three failures pass every automated gate, and they are the reason review still needs a second reader.

The query targets the wrong object. SOQL against Opportunity where the requirement concerned OpportunityLineItem is syntactically perfect and semantically wrong. It returns rows, so nothing errors. Salesforce’s own research into LLM agents on CRM tasks identified exactly this confusion between related business objects as a recurring failure, and no linter has an opinion about which object a requirement meant.

The implementation satisfies a misread requirement. Salesforce puts this in its own developer guidance for agentic tooling, conceding that generated output can compile while missing what the author intended, and that a person still has to review it. Apex can be clean, fast, secure and answer the wrong question.

The test asserts the implementation rather than the requirement. When the same system writes the code and the test, a misunderstanding is encoded twice and then protected by a passing assertion. Coverage rises while correctness does not, which is why unit tests need meaningful assertions rather than coverage targets, and why the wider test strategy separates developer verification from acceptance.

Each of those is an intent problem. Automation reads shape.

Volume-dependent defects need volume-aware review

One Salesforce-specific failure deserves separate treatment because it is invisible in every environment where reviewers actually look.

Limits apply per transaction, so the defect only exists above a record count. Twenty records in a scratch org will never reach a SOQL ceiling that two thousand records reaches instantly, which means the same code is demonstrably correct in the environment where it was reviewed and reliably broken in the environment where it runs. A rules engine flags the shape, which is why bulkification sits in every Apex ruleset. A reviewer who executes the code, watches it succeed and approves it has confirmed nothing about the only condition that matters.

This has a practical consequence for how AI-generated Apex should be reviewed. The instruction files that ground coding assistants on Salesforce have to state bulkification and governor limits explicitly, which is itself evidence the platform constraint is not inherent model knowledge. A review process that assumes the generator knew is reviewing the wrong risk.

The control is environmental rather than procedural: a sandbox seeded with representative volume, and test methods that insert enough records to cross a limit if the pattern is wrong.

AI review changes the economics of the second reader

The argument for adding AI to code review is not that it reads better than a senior engineer. It is that it reads everything, immediately, without becoming the bottleneck.

Human review has a known failure curve. Attention drops as diff size grows, reviewers approve rather than block when they are the constraint on a release, and standards get applied inconsistently depending on who is rostered. None of that improves when generation speeds up. A team producing four engineers’ worth of Apex with one engineer’s worth of review capacity has moved the bottleneck into the least visible place in the pipeline.

AI review helps on three specific axes, and it is worth being precise because the category is oversold.

It applies a written standard uniformly, which removes the variance between reviewers rather than removing reviewers.

It reads the whole change rather than the parts a tired human samples, which matters most on large generated diffs.

It explains findings in prose, which converts a rule violation into something a junior developer learns from rather than a code someone looks up.

What it does not do is carry accountability. The approval that matters is still a person’s, and the platform vendor’s own position on human review being non-optional applies to review tooling as much as to generation tooling. The distinction between an assistant that flags and a person who decides is the one that keeps this defensible.

The wider question of where coding tools stop and delivery agents begin is covered in AI coding tools against delivery agents. Here the scope is narrower: what happens after the code exists and before it ships.

Standards become automatable only once they are executable

An AI reviewer inherits whatever standard it is given. Feed it preferences and it produces opinions at scale.

Use one test to sort them. Hand the rule to two engineers who hold opposite opinions about it and see whether they flag the same lines. Rules that survive that are mechanical and belong in automation. Rules that need the author present to adjudicate are guidance, and labeling them as guidance stops a preference being enforced as a violation.

Four groups of Apex standards meet the executable test:

Structural. Naming conventions, layer separation between service, domain and selector classes, maximum method complexity, no business logic in triggers.

Data access. Every query and DML operation runs under an explicit access mode, sharing is declared on every class, and no CRUD or field-level security check is skipped on the assumption the caller handled it.

Resilience. No queries or DML in loops, no hardcoded IDs, no empty catch blocks, no assumptions about record counts.

Test quality. Assertions present and meaningful, no dependence on org data, volume cases included for anything that touches a collection.

Those belong in a written standard that both the automated gate and the AI reviewer read from the same file. Where that standard lives and who approves changes to it is a governance question, and a review process without one degrades into whoever reviewed last week.

A four-gate pipeline puts each check where it costs least

Sequence matters more than tool selection, because a check running in the wrong place either blocks work or arrives too late to be cheap.

The fourth gate is the one teams skip and the one the ApexGuru Engine exists to serve, since scanning a connected org reaches code as deployed rather than code as committed. Divergence between those two is common in orgs where anyone has ever made a change in production, which over a long enough period is most orgs. Quantifying that divergence is part of an org assessment, and closing it is how technical debt stops accumulating silently.

Security findings deserve their own escalation path rather than a severity threshold, because a field-level security violation is not a lower-priority version of a complexity warning. The security review sets what those rules check against.

Review belongs inside delivery, not beside it

Code review fails most often as a scheduling problem rather than a quality problem. A review queue staffed by whoever is free becomes a queue, and a queue becomes an approval.

GetGenerative.ai addresses that by keeping test and support agents inside the lane that produced the work, so review is a stage someone owns rather than a favor asked of a colleague between meetings. For change after go-live, its Support Agent runs the request through to a documented fix in one pass, which matters for review specifically because the reasoning behind a change stays attached to it. A reviewer inheriting a fix three weeks later otherwise reconstructs intent from a diff, which is the least reliable source available.

Teams wanting to test that against their own backlog can start the 7-day free trial and run it on a real pull request rather than a sample repository.

Recap. Salesforce bundles eight analysis engines behind one command, including a Graph Engine doing path-based analysis and an ApexGuru Engine scanning connected orgs. Code Analyzer v4 retired in August 2025, so a large share of published guidance teaches a dead command. Automated rules catch structure. Wrong-object queries, misread requirements and self-confirming tests survive every gate, which is what AI review and a human approver are for.

Key facts

FAQ

What does Salesforce Code Analyzer check in Apex?

Code Analyzer scans Apex, Visualforce, Flows and Lightning components using eight bundled engines enabled by default. PMD handles static analysis of Apex and Visualforce, Graph Engine performs path-based analysis for security and code issues, and the ApexGuru Engine scans connected orgs directly through the CLI.

Is the Salesforce scanner command still valid?

No. Salesforce documents Code Analyzer v4 as retired since August 2025 and no longer supported. Version 5 ships a new plugin, @salesforce/plugin-code-analyzer, with commands under the code-analyzer topic rather than the older scanner topic that most published tutorials still teach.

What can AI code review catch that static analysis cannot?

Static analysis evaluates structure. AI review can compare code against a written standard expressed in prose, read an entire large diff rather than sampling it, and explain findings. Neither catches a query against the wrong object or an implementation of a misread requirement without a human checking intent.

Why does AI-generated Apex pass review and fail in production?

Governor limits apply per transaction. A query or DML statement inside a loop executes correctly against small sandbox datasets and breaches limits at production volume. The pattern is not a syntax error and passes any unit test written against a handful of records.

What Apex standards can be automated?

Standards that a reviewer who disagrees with them could still apply identically. That covers naming and layer separation, explicit access mode on every query and DML operation, declared sharing, no queries or DML in loops, no hardcoded IDs, and tests carrying meaningful assertions plus volume cases.

Where should Apex code review run in a pipeline?

Four gates work: editor-time for syntax and obvious patterns, pre-commit for rules against the local change, pull request for a full Code Analyzer run plus AI review against the standard, and pre-deploy for an org-connected scan with volume-aware tests before promotion.