What a CI quality gate catches that code review misses
Code review finds what a reviewer happens to look at. A CI gate checks every change against every rule, every time. What that difference means on a Salesforce org.
If your Salesforce partner tells you every change is peer reviewed, ask the follow-up question: reviewed against what? A reviewer reads a change with the context they have on that day and the attention they have left after the meeting before. A continuous-integration gate reads every change against every rule the team has ever written, and it does not get tired.
Both matter. They catch different things, and a delivery process that only has one of them is exposed in ways the buyer usually discovers at the deadline.
What a reviewer is good at
Judgment. Is this the right design? Does the field belong on this object? Will this Flow make sense to the admin who inherits it? Is the story actually done, or is it done enough to close the ticket? A senior architect reading a pull request catches things no rule can encode, and that review is why our delivery model keeps humans at every gate: humans orchestrate, agents accelerate, humans assure.
What a reviewer is not good at is exhaustiveness. Nobody reads every line of every change against a 200-item standards document. They read the interesting parts.
What the gate is good at
Exhaustiveness. On every push to a feature branch, before a human ever looks, the pipeline runs the same checks it ran yesterday and will run tomorrow. On a Salesforce org, the ones that earn their keep:
Deployment validation against a real org. The change is deployed to a scratch org or a sandbox in check-only mode. Metadata that references a field that does not exist, a permission set that was renamed, a Flow version that was never activated: these fail here, not in production on release night.
Apex tests, with coverage measured per change. Not “the org is above 75 percent” but “the classes this change touched are covered, and the tests pass.” A reviewer sees a green checkmark; the gate sees which lines the checkmark is standing on.
Static analysis. Rules for SOQL inside loops, hardcoded IDs, missing sharing declarations, unbounded queries, and naming conventions run on every file, every time. A reviewer might catch the SOQL-in-a-loop. The gate catches the one in the class nobody opened.
Metadata hygiene. Unused fields being added, profiles being modified when a permission set was the standard, page layouts changed without a story reference. These are the changes that accumulate into the org nobody can explain two years later.
Traceability. The branch name and the pull request carry the story ID. If they do not, the gate refuses the merge. Every change in production traces to a story, and every story traces to the discovery material it came from.
The failure mode without a gate
Undocumented orgs cannot be maintained, audited, or handed over. Every change starts with archaeology. The pain we call The Documentation Debt is usually not caused by anyone deciding not to document; it is caused by a process where documentation is a separate task that gets skipped under deadline pressure. A gate changes that. When traceability is a merge condition, the documentation is a by-product of shipping rather than a chore after it.
The same applies to The Status-Report Fog. Manual status reporting is occasional and optimistic because it is written by a person who wants the meeting to go well. A pipeline reports what it observed.
What this costs the team, and why it is worth it
A gate slows the first week. Developers who have shipped by clicking Deploy for years find the pipeline fussy. Then two things happen: the fussy failures stop, because the team stops making the mistakes the gate catches, and the seniors get their review time back for judgment instead of proofreading.
That second effect is the one that matters for an elastic team. When five specialists rotate across an engagement, the gate is the institutional memory that makes the rotation safe. The standard does not leave when a person does.
Ask us to show you a real pull request, the checks it passed, and the release note it produced.
The short version
Code review catches what a smart person notices. A CI gate catches everything a team has ever decided to check, on every change, without exception. Delivery you can audit needs both, and the gate is the one most Salesforce partners skip. Ask yours what runs before a human reads the change.
AnswersThe Status-Report FogThe Documentation Debt