Vibe coding in Salesforce: prototype or production?

Vibe coding in Salesforce pays off where the code is meant to be thrown away: a clickable dealer-portal mock-up for a requirements workshop, a service cockpit LWC that shows the head of service what the screen could look like, a script that fills a test org with spare parts. Build it in a Developer Edition or scratch org with dummy data. For anything that reaches an org with dealer, warranty or service data, switch to agentic engineering: an approved plan, human review, tests and pipeline gates. The prototype becomes the specification, and the production build starts again from your repository.

What does vibe coding mean, and where does it end?

Andrej Karpathy coined the term in February 2025: you “fully give in to the vibes” and “forget that the code even exists”. Simon Willison narrowed it down1 to “generating code with AI without caring about the code that is produced” and stressed that this differs from using AI tools to build production code responsibly. In May 2026 Martin Fowler gave the responsible version its own name. In his bliki entry2, programmers who let an LLM write the code but still review it “aren’t forgetting the code exists”, and he calls that agentic engineering.

So the line runs along one question: does anyone read the code? The Agentforce Vibes session can be vibe coding in a Developer Edition and agentic engineering in a scratch org built from your repository. The terms and the four layers of AI in a Salesforce programme are covered in chapter 1 of the AI masterclass; here the question is what the line means for your projects.

Where does vibe coding help a manufacturer?

Fowler names disposable software and prototypes as fitting uses: “Experienced programmers may also find it handy for rapid development of disposable software or prototypes.” In a manufacturing programme I would consider four candidates:

• Dealer-portal mock-ups. A page where a dealer orders spare parts for a machine by serial number, shown to a few dealers in a workshop before anyone writes a user story. What the real portal involves is in the Manufacturing Cloud customer portal.
• A service cockpit LWC. One screen with open cases, installed base, next maintenance date and the assigned field technician, so the head of service can point at what is missing. Agentforce Vibes 2.0 offers live previews for Lightning Web Components3, which makes this quick.
• Test data scripts. Spare parts, assets and service contracts in plausible quantities for a demo.
• Throwaway analyses. A one-off script that counts which asset fields are actually filled.

The value lies in the conversation: business teams correct a working screen faster than a specification document.

The environments cost little. Salesforce’s April 2026 announcement4 put Agentforce Vibes, a browser-based VS Code and hosted MCP servers into every Developer Edition at no cost. The Vibes FAQ5 limits that per org, for one month after first use, without refresh. Teams with a Dev Hub can use scratch orgs instead: according to the Salesforce DX guide6 they are “source-driven and disposable” and start without data.

110

Agentforce Vibes requests per Developer Edition, or 1.5 million tokens

7 days

Default lifetime of a scratch org

30 days

Maximum lifetime of a scratch org

Rules for the prototype org

How harmless a prototype is depends on the org it runs in. Fowler calls security perhaps the most serious risk: vibe-coded applications “can often expose sensitive information or worse, credentials”. For a Salesforce prototype I set five rules:

1. No real data. No dealer names, no customer machines, no prices from the price list. Generated dummy data is enough for a mock-up.
2. No connections. No Named Credential to SAP or proALPHA, no integration user, no copy of production secrets. The SAP response is a static JSON file.
3. No coding agent in production. Salesforce lets admins disable Agentforce Vibes per org7 in Setup under Agentforce Vibes Extensions. I would do that in production on day one. Salesforce says Agentforce Vibes is not available in the Hyperforce EU Operating Zone (Vibes FAQ5), so for an org there the question does not arise; chapter 2 of the AI masterclass covers the alternatives.
4. An owner and an end date. Scratch orgs expire by design. A Developer Edition stays as long as someone logs in, so somebody has to retire it or at least record what is in it.
5. A visible label. “Prototype, not for production” in the component title, so a screenshot in a steering committee deck does not become a commitment.

These rules belong in the contract with your partner as well, as described in rules for partners who code with AI.

Why should a vibe-coded prototype not go to production?

A prototype shows that a screen makes sense, not whether the code holds up under your data, your users and your sharing model. Veracode’s 2026 GenAI Code Security Report8 found that raw models write compilable code at a rate of about 100 percent, while only 56 percent passed the security tests. Co-founder Chris Wysopal puts it this way: “scan it, fix it, and never ship it blind.” Code that runs is the easy part.

In Salesforce, a workshop prototype typically carries the same gaps:

• It was built and clicked through as a system administrator, so it never met the sharing model that keeps one dealer away from another dealer’s orders.
• It reads records one at a time, because the demo had twelve.
• Stock levels and delivery dates are hard-coded where the production version must call SAP.
• It has no tests, or tests written only to reach coverage.
• Its metadata lives in a Developer Edition, outside your repository and outside any review.

Fowler adds maintainability: unreviewed code grows into code that is hard to change, for people and for LLMs alike. In my judgement, closing these gaps one by one inside the prototype takes longer than building the feature properly. Which defects to look for in AI code is the topic of reviewing AI-generated Salesforce code.

The path from prototype to production

I treat the prototype as a specification. What survives the workshop are screens, decisions and acceptance criteria. The production build then follows agentic engineering:

1. 01

   Freeze the result

   Screenshots or a short recording, the field list, the open questions and acceptance criteria written with the business, for example "a dealer sees only orders for machines sold through that dealer".

2. 02

   Start in your repository

   The developer works in a scratch org or developer sandbox created from the client's repository, with a rules file that names your Named Credentials, API version and test rules. Why that file belongs to you is explained in the AI rules file of your repository.

3. 03

   Plan before code

   Agentforce Vibes' Plan Mode (opens in a new tab) produces goals, non-goals, an approach and numbered tasks, and "No files change until you click Approve Plan." The developer checks the plan against the acceptance criteria, sharing and permissions first.

4. 04

   Configure security by hand

   The same Salesforce guide recommends building permission sets, profiles, sharing rules and org-wide defaults manually in Setup and reviewing every generated security change before accepting it.

5. 05

   Review and gates

   Pull request, human review, Code Analyzer, validation deploy with Apex tests. The gates are described in quality gates for AI code.

One exception I accept: the HTML template and CSS of a mock-up LWC can be carried over if they pass the same review. Apex and data access are always rebuilt.

Worked example: two-day workshop at a machine builder

Assume a machine builder with Service Cloud, SAP S/4 and 400 dealers, planning a dealer portal and a new service cockpit. All numbers are assumptions. In a two-day requirements workshop, one developer builds both mock-ups with Agentforce Vibes in a fresh Developer Edition. The portal page takes about three hours, the cockpit about two, together roughly 40 of the 110 requests. Dealers and the head of service correct the screens live: the cockpit gets a column for the warranty end date, the portal loses a filter nobody used.

After the workshop the architect reads the prototype code once, as a reference. The order query ignores the dealer relationship, because the developer was logged in as administrator. Delivery dates come from a hard-coded list. The cockpit runs one query per case.

The production build therefore starts from the repository: three user stories, each with an approved plan, a runAs test as a dealer user and an SAP call through the existing MuleSoft API. Assume that takes two sprints for a partner team of three. Without the workshop, my estimate is that the first sprint would have gone into finding out what the screens should show. The prototype paid for itself in requirements and contributed no line of Apex. What the AI tools for such a team cost is covered in AI coding costs in a Salesforce project.

Allow vibe coding explicitly in Developer Editions

1. Allow vibe coding explicitly, in Developer Editions and scratch orgs with dummy data, so nobody does it quietly in a shared sandbox.
2. Disable Agentforce Vibes in production and keep production deployments in the pipeline.
3. Define the hand-over: screens, acceptance criteria and open questions leave the workshop; prototype Apex does not.
4. Make plans visible. Ask your partner to attach the approved plan to the pull request.
5. Own the pipeline. Setting it up for programmes with several partners is the core of my DevOps and release management work.

Sources8

1. 1narrowed it down (opens in a new tab)simonwillison.net
2. 2bliki entry (opens in a new tab)martinfowler.com
3. 3live previews for Lightning Web Components (opens in a new tab)developer.salesforce.com
4. 4April 2026 announcement (opens in a new tab)developer.salesforce.com
5. 5Vibes FAQ (opens in a new tab)developer.salesforce.com
6. 6Salesforce DX guide (opens in a new tab)developer.salesforce.com
7. 7disable Agentforce Vibes per org (opens in a new tab)developer.salesforce.com
8. 82026 GenAI Code Security Report (opens in a new tab)veracode.com