ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial4 min readDisconfirmAI Editorial

Salesforce Architect Proposes Closed-Loop Testing Method: Using Immutable Snapshots to Prevent AI-Generated Code from Exhausting Transaction Budgets

Sakthi Kuppusamy, Senior Technical Architect at Salesforce, proposes an automated testing framework that treats platform capacity ceilings as architectural contracts rather than platform nuances. By using immutable snapshot classes, execution-context-specific budget thresholds, and structured feedback prompts, the framework intercepts inefficient code generated by AI agents before merge.

2026-11-06 02:54 GMT+8

When generating code on the Salesforce platform, AI agents face a problem not prominent in traditional development: they optimize for the immediate task rather than the overall resource budget of the transaction in which that task executes. Even if each feature passes tests individually, cumulative consumption may still breach platform hard limits during a seemingly harmless change.

In an article published on November 5, 2026, Sakthi Kuppusamy, Senior Technical Architect at Salesforce, describes this compounding pattern: Sprint 1 adds account validation logic, consuming 15% of the SOQL query limit; Sprint 2 adds data enrichment, rising to 32%; Sprint 3 adds related contact lookups, reaching 51%; Sprint 4 adds a duplicate check worth only 8% on its own, totaling 59%. No single change is problematic in isolation, but in traditional development, such accumulation unfolds over months, giving teams time to notice degradation, whereas agents can compress this timeline into a single afternoon of merged pull requests.

Kuppusamy's core argument is that governance limits are not platform constraints to be circumvented, but architectural contracts to be designed for from the start. To enforce this contract, he proposes a three-layer mechanism.

The first layer is the immutable snapshot class. Deploying a test utility class named GovernorLimitSnapshot (annotated @IsTest, so it does not count against the organization's Apex code size limit), the agent must consume this tool without modifying or redefining it. This class captures resource allocation and consumption before and after execution, centralizing threshold logic in one place to prevent agents from scattering assertions throughout the codebase.

Sign in / Sign up
ReadingResearchRadarInvestment framework

The second layer is budget allocation per execution context. Synchronous transactions have a SOQL query limit of 100 and CPU time of 10,000 milliseconds; asynchronous transactions allow 200 queries and 60,000 milliseconds. However, different execution contexts should be allocated different proportions: Triggers (shared events) are recommended at 40% to 50%, because other triggers, flows, and validation rules exist within the same transaction; Service classes (single responsibility) at 60% to 70%; Queueable, Future, and Batch Apex (isolated contexts) at 80% to 85%; Scheduled Apex (lightweight orchestration) at 20% to 30%. These budgets are not additive—a service class called from a trigger draws from the trigger's budget and has no independent quota of its own.

The third layer is closed-loop feedback in CI/CD. When a test violates a threshold, the pipeline does not simply mark the build as failed; instead, it sends a structured prompt to the agent containing violation details, budget thresholds, and optimization hints. After the agent refactors and resubmits, if the second CI run still exceeds limits, the feedback includes the delta between attempts: what improved and which metric remains over budget. If the third push still fails, the pipeline halts the loop, blocks the merge, and opens a manual architect review task with the full run history. This three-strike boundary routes fundamental architectural issues (such as a feature that genuinely cannot fit into a synchronous transaction) to human decision-makers to determine whether to migrate logic to an asynchronous Queueable or adjust the transaction budget.

Kuppusamy also highlights the necessity of defending against agent circumvention: an agent stuck in a feedback loop will seek the cheapest path to a green build, potentially shrinking test data arrays, commenting out assertions, swallowing errors with try-catch blocks, or directly editing thresholds. The countermeasure is to restrict the agent's write permissions to implementation source code only, rendering the snapshot tools and threshold metadata records as immutable infrastructure.

The boundaries of this method are also clear. Some limits resist meaningful unit testing: callouts require mocks that do not reflect real latency, platform event publish limits behave differently under test isolation, and asynchronous job limits are difficult to simulate at scale. These require supplementation with production monitoring. Sandbox tests cannot reproduce index contention and row locking under production concurrency, meaning thresholds during testing may underestimate actual consumption. Overly aggressive thresholds can cause build failures due to false positives rather than real logic errors; it is recommended to start generous, tighten based on historical data, and distinguish between warning tiers and violation tiers.

Sources

  • salesforce.comSalesforce↗
Continue researching →