Fast Code, Slow Platform
AI moves fast. Salesforce has limits that don’t care. Here’s where the gap quietly shows up.
This is part of Field Trip, where I share experiences on various topics related to Salesforce and AI. Was this newsletter forwarded to you? Sign up here.
The Tool Is Not The Problem
AI has made Salesforce development faster than ever.
Documentation drafted in minutes. Components are scaffolded before the coffee cools. Flows designed, Apex written, test classes generated. The whole stack, handled.
And somewhere in that speed, something gets skipped.
Not obviously. Not in a way that shows up immediately. The code looks right. The tests pass. The sandbox behaves. It is only later, in production, at scale, under real data and real users, that the platform reveals what was missing.
AI moves at one speed. Salesforce operates at another. That gap is where things quietly go wrong.
Salesforce is not a general-purpose codebase. It never was. It was built on a shared infrastructure in which every org is a tenant, every execution has a ceiling, and every piece of metadata carries a contract. Those rules do not care how the code was written. They only care whether it respects them.
AI does not know those rules by default. It knows patterns. It knows syntax. It knows what worked somewhere else.
That is not the same thing.
Where The Speed Becomes A Problem
There are three places where this shows up most clearly.
LWC is calling Apex without thinking about the boundary.
A component gets built. It calls an Apex method. It works. What AI does not naturally consider is whether that call should be wired or imperative, whether caching is appropriate, whether the call will fire multiple times on re-render, and what the server load looks like at 10,000 records instead of 10. The component ships. It works in testing. In production, it becomes a performance problem nobody can immediately trace back to an architectural decision made in thirty seconds.
FLS gaps that tests cannot catch.
AI generates DML operations. It writes the logic correctly. What it does not enforce, unless specifically asked, is field-level security. The code runs. The test coverage is there. Then the AppExchange security review or an internal audit finds that the solution bypasses FLS entirely. Not because the developer was careless. Because AI does not default to CRUD and FLS enforcement the way Salesforce expects it. It defaults to what works, not what the platform’s security model requires.
Flows hitting governor limits at scale.
A Flow gets designed for a use case. It handles the happy path cleanly. What AI rarely accounts for is how that Flow behaves when triggered by a bulk data load, when it sits inside a transaction that already has DML operations, or when the element count and decision depth quietly push against the platform’s automation limits. Sandbox does not show this. Production does. Usually at the worst possible time.
None of these is an AI failure in the traditional sense. The output is not wrong. It is just unaware of the layer it is operating in.
The Layer Problem
Salesforce has always asked engineers to think in layers.
Data model. Security model. Automation layer. UI layer. Integration layer. Each one has its own rules, its own limits, its own relationship with the others. Experienced developers move between these layers deliberately. They know when a decision in one layer creates a constraint in another.
AI compresses this. It produces code that exists at the surface layer, the thing you asked for, without necessarily accounting for what sits beneath it. Multi-tenancy. Governor limits. Sharing architecture. Metadata contracts. These are not features. They are the platform’s value system. Ignoring them does not break the code. It breaks the org, slowly, in ways that are hard to attribute.
The speed is not the issue. Autopilot is.
There is a difference between using AI to move faster and using AI to avoid thinking about where you are. Most people are doing the latter without realising it. Not because they are lazy. Because the tool makes it easy to skip the pause.
A Different Way To Think About It
This is not an argument against AI in Salesforce development. That ship has sailed and the pace is not slowing.
It is more of a quiet question worth sitting with.
Before the code gets written, is there a moment where the layer gets named? Where someone asks which part of the platform this touches, what limits apply, what the security model requires, what happens at 200 records instead of 2?
That moment is the work. Not the generation. The generation is easy now.
The thinking before it is what determines whether the output holds up.
There are people building tooling around exactly this. Workflows that enforce a planning phase before implementation, review agents that understand Salesforce-specific constraints, compounding loops that get smarter after each iteration. One direction worth exploring is the sf-compound-engineering-plugin, a Claude Code plugin built specifically for this kind of structured, layer-aware Salesforce development. Not a complete answer. But a considered starting point.
The platform has always rewarded engineers who respect it.
That part has not changed.
Want access to exclusive research insights and curated reading recommendations? Consider subscribing.