AI-Assisted Salesforce Development — Patterns & Limitations
Overview
Using an AI coding agent (Claude/Claude Code) to build Salesforce customizations is viable and dramatically cheaper than hiring a dedicated Apex developer — but the process is iterative, rarely clean on the first pass, and runs into hard platform limits that no amount of prompting can overcome. This article documents the patterns, workarounds, and failure modes observed during a working session building two Salesforce features for the Quarra client.
Reference session: [1]
How It Works
The agent connects to the Salesforce API, explores available objects and metadata, writes Apex code, and deploys it directly to the live instance. The general flow:
- Describe the desired behavior in plain language
- Agent explores the relevant object schema and checks for existing triggers
- Agent writes and attempts to deploy an Apex trigger or Quick Action
- Salesforce inspects the code before deployment (security/integrity check)
- Iterate based on actual behavior vs. expected behavior
"It's never right the first time. You kind of have to fight it." — Mark Hope
Case Study 1: Task Comment Timestamping
Goal
Automatically prepend a timestamp and user initials to each new comment added to the Task object's Comments field.
What the Agent Did
- Confirmed the Comments field is a standard long text area with no existing triggers
- Deployed an Apex
before updatetrigger that prepended[date] [user initials]:to new content - Iteratively refined the trigger after observing duplication and stacking bugs
Problems Encountered
| Problem | Root Cause | Resolution |
|---|---|---|
| Cursor lands at bottom of field on edit | Lightning's built-in text area behavior; not controllable via Apex | Accepted as limitation |
| Timestamp duplicating on every save | Trigger treated entire field value as new content each time | Fixed via prompt iteration — agent learned to diff old vs. new content |
| Leading blank lines stripped | Salesforce strips leading newlines from text area fields | Accepted as limitation |
Final Workaround
Rather than fighting the standard edit pencil (which always drops the cursor at the bottom), the agent created a new "Edit Comments" Quick Action button that opens a focused modal. Users click "Edit Comments," place cursor at top, add a blank line, type their comment, and save. Not perfect UX, but functional and trainable.
Remaining cleanup item: Remove the default pencil edit icon from the Task layout to avoid confusion between the two edit paths.
Case Study 2: New Opportunity Modal Deduplication
Goal
Fix a New Opportunity modal that was displaying the "Opportunity Information" section twice.
Root Cause
Lightning automatically pulls in every page section that contains a required field. Because required fields (Process_C, Loss_Reason, etc.) lived in a section not included in the Quick Action layout, Lightning injected the entire section — causing the duplication.
Fix Attempted
The agent added the missing required fields directly to the Quick Action layout so Lightning no longer needed to pull in the extra section. Fix was deployed but not immediately visible, likely due to browser/Salesforce caching.
Resolution: Hard refresh (Ctrl+Shift+R) required after deployment to see layout changes.
General Patterns
The Iterative Loop Is Normal
Expect 3–6 prompt cycles for any non-trivial customization. The agent will:
- Make an attempt
- Hit an error or unexpected behavior
- Try a different approach
- Sometimes correctly self-diagnose; sometimes need explicit correction
Being more explicit upfront helps but doesn't eliminate iteration — you often can't know what to specify until you see the first result.
Heavily Customized Instances Are Harder
Existing custom triggers, non-standard layouts, and prior developer work create conflicts the agent has to navigate. Fresh instances deploy faster and cleaner.
Salesforce's Four Code Layers
Understanding which layer a problem lives in helps set expectations:
| Layer | Description | Agent Access |
|---|---|---|
| UI/UX | Standard clicks, field config, layout editor | Read-only guidance |
| Flow / Process Builder | Declarative automation | Limited |
| JSForce | Salesforce-flavored JavaScript | Yes |
| Apex | Low-level compiled language; full platform access | Yes — primary tool |
Some behaviors (cursor position, leading whitespace in text areas) are controlled by Lightning's rendering layer and cannot be changed via Apex or any API. When the agent says it can't do something, believe it.
Deployment Requires Salesforce Code Inspection
Every Apex deployment goes through Salesforce's server-side validation. This adds latency and occasionally rejects code that conflicts with existing metadata. The agent handles retries automatically but it adds time.
Cost & Speed Comparison
| Approach | Estimated Cost | Turnaround |
|---|---|---|
| Hire Apex developer (e.g., Dmitri) | $500–$10,000+ | Days to weeks |
| AI agent (Claude Code) | ~$0 marginal | 30–90 minutes per feature |
The agent approach is dramatically cheaper. The tradeoff is that someone on the team needs to understand enough to direct the agent, interpret errors, and recognize when a platform limit is real vs. a prompt problem.
Practical Tips
- Paste files as paths, not drag-and-drop — right-click → "Copy as Path" then paste into the agent prompt. Drag-and-drop is unreliable.
- Ask what tools are available before invoking them — some pre-built tools will make changes, not just audit. Always confirm scope before running.
- Hard refresh after deployments —
Ctrl+Shift+Rclears Salesforce's aggressive caching. - Work in a partial data sandbox when possible — developer sandboxes have no records to test against; full sandboxes are expensive. Partial data sandboxes are the practical middle ground.
- Don't edit live records during development — the session did this out of necessity, but it's risky and would make a Salesforce rep wince.
Related
- [1]
- [2]
- [3]