The Stale-Baseline Trap: Why AI-Authored Salesforce Delivery Keeps Building on a Fake Org

We recently audited an entire Salesforce delivery stream — 149 merge requests across a single client engagement, start to finish — and asked one question the usual retrospective never asks. Not what shipped, but where a later change had to revert, re-cut, or re-baseline what an earlier one got wrong. About a quarter of the merge requests were rework. And when we grouped that rework by root cause, one pattern sat underneath almost all of it, surfacing in cluster after unrelated cluster.

The single most expensive, most repeated failure mode in AI-authored Salesforce delivery is this: the agent builds on a stand-in that isn't the live org.

Not a bad prompt. Not a hallucinated method. Something more mundane and far more corrosive — the ground truth the agent trusted was stale. A local mirror that had drifted. A test fixture that was too clean. A pipeline described from memory instead of confirmed. Every one of them looked authoritative. Every one of them was a cache pretending to be the source of record.

This is the first article in our Salesforce series, and it supports the larger argument we make about agentic development for Salesforce: agents are extraordinary at producing correct-looking work at speed, which is exactly why the thing that trips them is not capability but grounding. Get the baseline wrong and the agent will build competent, well-tested, thoroughly-reasoned code on top of a fiction — and it will do it fast.

The mirror looks like the org. It isn't.

Most Salesforce teams working with agents give them a local copy of the org to work against — an sfdx project retrieved from a sandbox, a metadata snapshot, a mirror. It's the sensible thing to do. You don't want an agent editing production metadata directly, so you give it a representation to reason over.

The problem is that a mirror is stale the moment it's created, and it drifts worst exactly where it hurts most: the high-fan-in files that many tickets touch. Permission sets. Profiles. Large Apex classes. Page layouts. These are the shared surfaces where two in-flight changes collide, and they're the files most likely to have moved in the live org since anyone last pulled.

In the engagement we audited, this went from theoretical to expensive. A run of changes was built against a permission set that the local mirror showed as 128 lines. The live target org's version of that same permission set was 773 lines. The agent wasn't wrong about the 128 lines it could see — it reasoned about them perfectly well. It just couldn't see the other 645. Cascading those changes forward would have stripped field permissions wholesale from the live org. The only safe move was a full revert of the built work, then a v2 redo against the actual org state. Days of clean, confident, thoroughly-reasoned work — reverted, because the ground under it was fake.

Here is why an agent walks into this without hesitation. The mirror is internally consistent. It compiles. It passes the tests written against it. Nothing in the artifact itself signals that it's out of date, because staleness isn't a property you can see by looking at the file — it's a property of the difference between the file and something the agent never checked. An agent, like a junior engineer, trusts the environment it was handed. It has no instinct that the environment is lying, because the environment gives no tell.

The fixture that was too clean to be true

The same trap wears a second costume in data work: the test fixture.

When you validate a data migration, you run it against a fixture — a small set of representative records. In the audit, one migration was validated against a synthetic fixture of about ten records. It passed. It passed because the fixture was clean: every record was a tidy, well-formed, non-colliding case. Production was not clean. Production had the messy relationship shapes that real data accumulates over years — shared child records, records related to more than one parent, the collision cases that only exist when real humans have been entering data into an org for a long time.

The cleanup logic kept missing those collision classes, and it took three separate passes to catch them all — because each pass surfaced a shape the synthetic fixture had never contained. The fixture wasn't wrong. It was just a stand-in that didn't reproduce the shape of the live data, only its rough volume. And the agent trusted it, because it passed.

This is the deeper lesson hiding inside the stale-baseline trap: volume is not shape. A fixture with the right number of rows and the wrong topology is still a fake org. So is a migration script validated against a spreadsheet pivot instead of the source object — which is how, elsewhere in the same engagement, a pivot-table intermediate silently truncated its rows and dropped 218 opportunities from a migration that reported success. And so is a "batch completed, zero errors" log: one migration run that reported all 1,047 of its batches clean had, underneath, silently failed at the per-record merge step on roughly 11% of records — 5,673 of them. The batch framework's summary was a cache of a truth it hadn't actually reconciled.

Guessed ground truth

The third costume is the most human. Sometimes the stand-in isn't a file at all — it's an assumption written down as fact.

In the audit, client pipeline mechanics — who deploys, with which tool, through which approval gate — were documented from reasonable inference rather than confirmation. The framing was corrected, then corrected again: three passes before the deploy story was actually confirmed with the client. Nobody was careless. The guess was plausible. But a plausible guess about the live process is the same category of error as a stale mirror of the live metadata — an authoritative-looking stand-in for a ground truth nobody checked.

Managed-package configuration is the version of this that bites hardest, because it's invisible by design. Tools like rollup or lookup helpers store their settings as records in the org, not as metadata in the repo. They don't appear in the mirror at all. In the audit, one sandbox had zero active rollup rules configured; the QA org had 59. An agent reasoning from the mirror would have no way to know the 59 existed. The config wasn't hidden by accident — it lives in a layer the snapshot never captures. Which means "I checked the mirror" and "I checked the org" are not the same statement, and treating them as interchangeable is the whole trap in one sentence.

The fix is a forcing function, not more talent

The instinct, watching an agent make these mistakes, is to make the agent smarter. That's the wrong lever. The engagement we audited was already high-capability — the assets were good, the analysis was deep. What it lacked was control: a near-solo, AI-authored stream has no default human reviewer standing between a confident change and the merge button. So the reverts and the redos weren't a talent problem. They were a grounding problem, and grounding problems are solved mechanically.

The single highest-leverage guardrail we recommend is a baseline-drift check, mandatory before merge. Before an agent's work can land, diff the shared metadata it touched against the live target org — not the mirror, the org — and block the merge if they've diverged. Had that one check been in place, the 128-versus-773 permission set would have failed the gate instead of failing production. It converts the invisible property — staleness — into a visible, blocking signal at the exact moment it matters.

The same discipline generalizes across all three costumes:

Metadata: build shared, high-fan-in files against the live org, and diff against it before merge. The mirror is a cache you refresh, never the source you trust.

Data: reproduce production's shape, not just its volume — seed a fixture row for every real relationship and collision class before declaring a migration validated, and reconcile per-record outcomes against an independent count, never a batch summary or a pivot.

Process and config: confirm the live pipeline and enumerate active managed-package settings per environment. Mark facts as confirmed-by-whom, and treat an unconfirmed assumption as a stand-in, because that's what it is.

Underneath all three is one principle worth pinning to the wall: production is the system of record. The mirror is a cache, not truth. A cache is a wonderful thing to work against for speed — right up until you mistake it for the thing it's caching. Agents make that mistake by default, because a cache and its source look identical from the inside. The job of the delivery process is to make the difference visible before it becomes a revert.

The takeaway

Agentic Salesforce delivery doesn't fail because the agent can't write good Apex or reason about a data model. It fails because it will pour excellent work onto a foundation it never verified was real — and do it faster than a human ever could, which means it can build further onto the fiction before anyone notices. The stale mirror, the too-clean fixture, the guessed pipeline: they're all the same failure wearing different clothes, and they all yield to the same fix. Stop trusting the stand-in. Diff against ground truth, mechanically, before every merge.

That's the first move in building a Salesforce delivery practice that can actually run at agent speed without accumulating agent-speed rework. It's also the first of several grounding disciplines we'll walk through in this series.

At Facet, this is the work — putting the forcing functions in place that let AI-authored delivery move fast and land on solid ground. If your team is scaling agentic development into a real Salesforce org and you've started to see the reverts pile up, let's talk about where your baseline actually lives.