Agentic Development for Salesforce: Capability Is Cheap, Ground Truth Is Expensive

Something quietly inverted in Salesforce delivery over the last year, and most teams haven't repriced their work to match. An agent can now author a permission set, refactor an Apex batch class, write the test coverage, generate a data-migration script, and open a clean merge request — in minutes, without complaint, at a level of craft that would have been a mid-level developer's afternoon. The bottleneck everyone spent a decade optimizing — can we build it fast enough? — has largely dissolved.

So the interesting question is no longer whether the agent can produce the metadata. It can. The question is whether the metadata it produced matches the org it's going to land in. And that turns out to be a completely different, much more expensive problem.

We recently finished a retrospective audit of an entire Salesforce engagement — every merge request across the life of a client CRM repo, 149 in total, built in a fast, largely agent-authored stream. We weren't looking at what shipped. We were looking at something more diagnostic: where a later merge request had to fix, revert, or re-baseline what an earlier one got wrong. The number that fell out of that analysis is the thesis of this piece, and of the short series it opens.

Roughly 27% of those merge requests became rework. Not because the code was bad, but because it was built against a version of the org that wasn't real.

Capability is cheap now. Say it plainly.

It's worth sitting with how thoroughly the economics have shifted, because the reflex on most teams is still to treat generation as the hard part and buy more of it.

On Salesforce specifically, an agentic development loop can now reliably: read a metadata tree and reason about its dependencies; produce syntactically valid Apex, Lightning Web Components, and Flow XML; generate permission sets, sharing rules, and field-level security config; write and run test classes to a coverage target; draft data-migration and backfill scripts; and package all of it into a well-described, well-scoped merge request. The craft floor is high and rising. In our audit, the quality of the assets themselves was consistently strong — the team built genuinely reusable tooling and did deep analysis.

That's the trap. When the generated artifact looks this good, it's easy to assume the expensive work is done. It isn't. The artifact is a hypothesis about the org. Its correctness is entirely contingent on whether the picture of the org the agent reasoned from was accurate. And that — the fidelity of the picture — is the part nobody automated.

The expensive thing is ground truth

In Salesforce, the org is the system of record. Not the repo. Not the sandbox. Not the spreadsheet the migration was scoped from. The production org — its live metadata, its actual field-level security, its real data shapes and volumes, its deployed component inventory — is the only authoritative statement of what is true. Every other representation is a cache: useful, faster to work against, and guaranteed to drift.

Agentic development is spectacularly good at working from caches, because a cache is what fits in context. You hand the agent an sfdx mirror, a fixture dataset, a pipeline description, a pivot table — and it reasons flawlessly over the artifact you gave it. The flaw isn't in the reasoning. It's that the artifact and the org have quietly diverged, and nothing in the loop forced a check against ground truth before the work was declared done.

That single failure mode — trusting a stale or synthetic stand-in for the live org — was the root cause underneath nearly every rework episode we counted. Here's what it actually looked like on the ground.

• A branch was built against an sfdx mirror of a permission set that had 128 lines. The live org's version of that same permission set was 773 lines. The mirror had gone stale, the agent reasoned perfectly against a five-sixths-incomplete picture, and the result was a full revert and a v2 redo of the whole sequence.
• A data migration was validated against a 10-record fixture that never contained the collision classes and null-shapes the real dataset carried. The cleanup logic looked complete; it wasn't, and the gaps surfaced downstream one round-trip at a time.
• A migration scoped from a spreadsheet pivot silently truncated its source, and 218 Opportunity records went missing — discovered only after the work was called finished, in a separate remediation run.
• A field-level security gap that no local artifact revealed showed up as UAT compile failures, because "the layout has the field" is not the same statement as "the profile can see the field."

None of these are exotic. They're the ordinary consequence of a high-capability loop pointed at a low-fidelity representation of the truth. The capability was never the problem. The ground truth was expensive, and the process didn't pay for it.

Why Salesforce punishes this harder than most stacks

You could argue this is just a general truth about AI-assisted engineering — garbage baseline, garbage output. It is. But Salesforce has four structural properties that turn a fidelity gap from an annoyance into a revert.

The metadata is the program. In a conventional codebase, the source in the repo is the source of truth, and the running system is derived from it. Salesforce inverts that. The org accumulates state — through admins, managed packages, other teams, clicks-not-code changes — that your repo never saw. A permission set, a Flow, a FlexiPage in your branch is a partial claim about an object that lives and mutates in the org. Deploy a claim built from a stale snapshot and you either fail validation or, worse, silently overwrite live configuration.

The org is the system of record, and it drifts continuously. Between the moment a mirror is pulled and the moment a branch merges, the live org can change underneath you. Baseline hygiene isn't a one-time setup step; it's a per-change discipline. Pull shared metadata live before editing it, or accept that you're editing a photograph of something that has since moved.

Security is layered and invisible from the code. Field-level security, permission sets, profiles, and sharing interact in ways you cannot fully infer from the metadata in front of you. A field can exist, sit on the layout, be referenced in Apex — and still be invisible to the user because the profile lacks FLS. Agents reason from what's in the artifact; FLS lives in the org.

Deployment is sequenced and dependency-bound. Components deploy in dependency order, against governor limits, with validation that either passes against the real target or doesn't. A migration that runs clean against 10 records can blow a query-locator or trigger governor at 50,000. The behavior that matters only exists at the real data shape and volume.

Put those together and you get the core lesson: on Salesforce, correctness is a property of the org, not of the diff. An agent optimizing for a clean, well-tested diff is optimizing for the wrong artifact.

Seven shapes of the same mistake

When we clustered the rework, it fell into seven recognizable patterns — the stale-baseline revert-and-redo, the wrong-base branch that ballooned an unrelated diff, the cleanup filter that kept missing collision classes the sandbox never held, the reactive scan-fix loop with no local view of the client's gate, the post-deploy remediation for records that slipped, and a couple more. They look like seven different problems. They are one problem wearing seven costumes: work was declared done before it was checked against the thing that would judge it. We break those seven shapes down, with the merge-request forensics behind each, in a companion post on the stale-baseline trap — the single most expensive and most repeated pattern in the set.

The throughline is what matters here. Every one of those episodes was preventable not by making the agent smarter but by making a ground-truth check unavoidable before merge.

The fix is not more capability. It's a governance spine.

Here's the counterintuitive recommendation, and it's the reason this engagement is worth writing about. Faced with a 27% rework rate, the instinctive move is to add capability — better prompts, a stronger model, more sophisticated tooling. That would be a mistake. This was a high-capability, low-control operation. Adding capability to a control problem just produces more high-quality work built on unverified assumptions, faster.

What was missing was mechanical. In a fast, largely agent-authored stream, there was no default human reviewer standing between "the agent thinks it's done" and "it merges." The check that a traditional team gets for free — someone who knows the org saying wait, that permission set is way bigger than that in prod — simply wasn't in the loop. So the fix is to reconstitute that reviewer as policy-as-code in CI: a thin governance spine that makes ground-truth-checking impossible to skip.

Concretely, that spine is a small set of gates that run on every merge request and refuse to pass on assumption alone:

• sf deploy validate against the real target org — green, or it doesn't merge. This is the check that would have caught the 128-vs-773 permission set immediately.
• A baseline-drift check — does the metadata you edited still match the live org you're deploying to? Evidence is a diff against the org, not a promise.
• Per-record migration reconciliation — counts in equal counts out, with the delta accounted for. No "0 errors" sign-off standing in for "every record landed." This is what turns 218 silently-dropped Opportunities into a hard failure instead of a next-week surprise.
• A scanner-actually-ran assertion, plus branch-name and file-count-vs-scope lints — cheap mechanical checks that convert an absent reviewer's judgment into a gate.

The point of the spine isn't ceremony. It's that each gate forces a check against ground truth at the exact moment the work would otherwise be trusted on faith. It converts the expensive, easy-to-skip discipline — go look at the real org — into something the pipeline does mechanically, every time, whether or not anyone remembered to.

On a practice-maturity ladder, an operation like this sits at "standardized" — reusable assets exist, some CI is present, but the gaps still get caught reactively, after a revert. The leap to "governed" is precisely the addition of that enforced spine. We lay out the full maturity model, and the phase-gated lifecycle that sits on top of it, in a third companion post. The short version: capability got you to standardized; only control gets you to governed.

The takeaway

Agentic development changed the price list for Salesforce work, and the line items moved in opposite directions. Generation got cheap. An agent will produce the permission set, the migration, the test class, the tidy merge request, all day, at real quality. Verification against the live org got relatively more expensive — not because it's hard, but because it's the one thing the loop won't do for you, and the one thing Salesforce's org-as-system-of-record architecture punishes you for skipping.

So stop investing in the cheap half. The differentiated, defensible work in agentic Salesforce delivery is no longer writing the metadata — it's building the forcing functions that guarantee the metadata is true before it lands. A thin governance spine of policy-as-code gates does more for your rework rate, your margin, and your client's trust than any amount of additional generation capability. Capability is table stakes now. Ground truth is the moat.

This is the pillar of a short series on agentic development for Salesforce. The supporting posts go deeper on the three ideas above: the stale-baseline trap and how a cache silently diverges from the org; the seven shapes of rework and the merge-request forensics behind each; and the maturity model and governance spine that moves a delivery practice from standardized to governed.

If you're running — or planning — agent-assisted delivery on Salesforce and you don't yet have a mechanical answer to "what proves this matches the live org before it merges?", that's the conversation worth having. It's the one we help teams stand up. Let's talk about building your governance spine.