[object Object]

The Stack

Salesforce DX for project structure and deployment. sf CLI for automation. VS Code + Salesforce extensions as primary IDE. Vibes 2.0 for AI-assisted development. LWC browser preview for UI iteration. Salesforce DX MCP Server for natural-language dev tasks. A representative sfdx-project.json for a 2026 project:

{
  "packageDirectories": [
    { "path": "force-app", "default": true }
  ],
  "namespace": "",
  "sourceApiVersion": "62.0",
  "sourceBehaviorOptions": ["decomposeCustomLabelsBeta2", "decomposePermissionSetBeta"]
}

The decomposePermissionSetBeta flag splits permission sets into per-object files, which finally makes Git diffs on permission changes legible. Combined with sf project deploy preview --target-org production, the deploy diff before a release is now reviewable in a regular pull request.

2026 Inflection Points

LWC browser preview closes the UI iteration gap. Multi-framework React support broadens the developer pool. MCP-based dev workflows let developers use natural language through Claude Desktop or Cursor. The aggregate effect: a new hire productive in the org goes from roughly 6 weeks to roughly 2 weeks. Three measurable shifts:

  1. Inner loop: 60-second push-to-scratch cycle drops to 2-second hot reload via sf lightning preview component
  2. Test feedback: Apex test runs emit structured JSON for IDE-native results panels instead of console-scraped tables
  3. Code generation: Vibes 2.0 schema-aware completion eliminates 70% of “what’s the API name for this field” lookups

What Still Frustrates

Slow tests on medium orgs. Deployment package complexity. Metadata API quirks. These persist. Ecosystem tools (sfdx-hardis, Illuminated Cloud) fill gaps Salesforce hasn’t addressed. Specific gotchas from production teams:

  • Apex test runs of 500+ classes still take 25–40 minutes even on Hyperforce; parallel test execution helps but profile-context test data setup is still serial
  • Metadata API still returns inconsistent error messages on dependent metadata failures (deploy a Flow that references a missing field and the error blames the Flow XML rather than the missing field)
  • sf CLI authentication with multiple production orgs requires careful org alias hygiene; sf org list --all still hides expired auth tokens behind warnings rather than removing them

Trajectory

Developer experience improvements accelerate under new leadership. Expect steady improvement release over release. DX in 2028 will likely look materially different from 2026. The roadmap signals worth watching: TypeScript-first LWC authoring out of pilot in Winter ‘26, native Jest debugger in VS Code by Spring ‘27, and a unified Apex/LWC/Flow source format that lets you deploy a feature as a single artifact rather than coordinating across metadata types.

For a new project starting today, the consensus configuration:

  • IDE: VS Code with Salesforce Extensions Pack v62.0+
  • Source control: Git with conventional commit format and branch-per-feature workflow
  • CI/CD: GitHub Actions or GitLab CI invoking sf CLI; sfdx-hardis for delta deployments
  • Testing: Apex tests in CI, Jest for LWC, Selenium or Playwright for end-to-end where critical
  • AI assistance: Vibes 2.0 inside VS Code; Cursor with the Salesforce DX MCP Server for cross-cutting refactors
  • Org strategy: Scratch orgs for feature work, two long-lived sandboxes (integration, UAT), one production

Common Failure Modes

Mixing source-tracked and metadata-deployed orgs without intent. Source tracking on a sandbox that also receives manual deploys produces baffling conflict states. Pick one paradigm per org and document it. Second: skipping sf project deploy preview on production deploys because “we’re in a hurry.” That’s how you accidentally drop a custom field’s required flag. Third: failing to pin sourceApiVersion — drift between developers’ local CLI versions and the project setting causes silent metadata corruption.

What to do this week

Pin sourceApiVersion: "62.0" in your sfdx-project.json, install the Salesforce DX MCP Server in one developer’s environment, and run sf project deploy preview against your production org. Review the diff with your team. If anything surprises you, that’s exactly the unaccounted drift the preview tool exists to surface.

[object Object]
Share