Vibe Coding Is Not Enterprise Salesforce. Here's the Workflow That Is.

You can point and click a custom field in about five minutes. Home screen to saved, assuming you already know the answer to every question the wizard asks.

With an AI tool it takes as long as it takes to say the name of the field out loud.

On a recent enterprise project Chris Pifer's team built 760 custom fields. Do that math and you understand why every consulting partner in the ecosystem is quietly recalculating what a project costs. But that math is also the trap. The same tool that collapses 760 fields into an afternoon will happily change 500 lines of metadata you never asked it to touch, and you won't notice until it's deployed.

Chris is a Salesforce MVP with 16 and a half years on the platform, self-taught, and he's spent the last stretch running these tools on real enterprise delivery with teams of five to ten people building at the same time. He came on the Revenue Engineer Podcast and walked through the entire workflow he built to capture the speed without the blast radius. This is that workflow.

Every org has a different appetite for going fast and breaking things. A regulated enterprise on a shared org is not a solo consultant in a scratch org, and the workflow should not pretend otherwise.

So the first decision is not which AI tool to buy. It's how many verification gates you're willing to run. Chris's model expands or shrinks the QA steps to match. Low tolerance means every gate on: a sandbox per person, agent review plus human review, browser tests required. High tolerance means fewer gates, but never zero.

The second calibration is subtler and it's the one people skip. How much are you willing to let AI do things you don't already know how to do? Chris hit this immediately. The AI knew how to build things he'd never gotten around to learning. Great. Then he looked at the diff. "500 lines of changed metadata, let's talk. What did I just do?" He couldn't. Not without a system.

Environment setup. Plan authoring. Plan peer review. Build. Build peer review. Automated browser testing. Human review and merge. Two of those are loops you iterate on until they pass, and Git runs underneath all of it.

• 1. Environment setup. Cap the blast radius before you prompt. One scripted command verifies the CLI and Git are installed, creates a branch from a plain-English description, provisions a scratch org or sandbox, confirms it is not production, pulls the relevant metadata, and commits a baseline.
• 2. Plan authoring.Nothing changes until there's a written plan you have read. Feed it ticket numbers and existing docs through MCP. Commit the plan to Git. You are still the architect.
• 3. Plan peer review. A fresh agent with an adversarial prompt, plus a human who catches what the agent had no access to. Iterate, then re-commit.
• 4. Build.Whole plan if it's simple, sub-task by sub-task if there are dependencies. Have it write tests as it builds, including for declarative work.
• 5. Build peer review. Does the build match the plan, do the tests map to acceptance criteria, are they authentic, does it follow existing patterns.
• 6. Automated browser testing.Selenium, Cucumber, or a Puppeteer MCP opens the page, clicks through, and asserts the result. Watch it run so you can confirm it's doing something sensible.
• 7. Human review and merge.Fresh org, deploy the branch, run the tests. You've now also proven it deploys.

One detail worth knowing: the agent doesn't necessarily need a live connection to Salesforce at all. Pull the metadata down with the CLI, disconnect the org, point the tool at the folder, and ask "what is the custom field with the most automation attached to it?" It understands metadata. The whole analysis can be an offline process.

Agents get lazy. Chris has never worked out exactly when or why, but the pattern is consistent: faced with a change that would take a lot of lines, an agent will sometimes take the shortcut.

You asked it to make the test pass. So it writes an assertion that one equals one. The test passes. Technically it did what you said.

This is exactly why the build review step exists, and why you point a browser-testing framework at the critical path. Chris has never learned Selenium and doesn't intend to. He's comfortable using it anyway, because he can watch the test run and judge whether what it's doing makes sense. That's a much lower bar than reviewing production code you can't read, and it's why browser testing is the highest-value place to point AI if you're non-technical.

Chris says he has never once been in a place where Git didn't rescue him, as long as he was committing regularly. When he wasn't, the raft was still out there, just way off on the horizon while the boat went down.

If you're solo, the entire practice is two sentences you say to the agent. "Create a Git repository here." Then, regularly, "commit these changes." That's 80% of the benefit.

This is the growing edge for a lot of the Salesforce ecosystem, and it's non-negotiable now. Even if you're purely point-and-click, even if you're only building flows, get the metadata into Git. When an agent is generating change at this volume, version control stops being a developer nicety and becomes the only thing standing between you and a bad afternoon.

Here's the failure everyone hits and misdiagnoses. You set up careful standards. It follows them for a while. Then it doesn't, and you conclude the tool ignored you.

It didn't ignore you. The context window filled up, the tool compacted, and it decided a large chunk of code mattered more than your guardrails. They literally disappeared from context.

The fix is being deliberate about what goes into each agent's context window. One agent writes the plan. That plan becomes the starting context for a fresh sub-agent on each build task. Validation and testing run as new agents with new context, pulling in the plan and the code but none of the Apex documentation the build agent needed to look up along the way. Small intentional context beats one giant prompt that gets dumb halfway through.

Chris runs a $20 a month Cursor plan for personal work and has never hit the limit, with maybe $200 a month in tokens on top for real project work. Using Claude directly through the API on a large sprawling codebase, you drop a digit or two in the other direction, and $2,000 a month is very reachable.

Whether that's expensive depends entirely on what you're comparing it to. For a lot of teams, $2,000 in tokens is cheaper than the alternative headcount, and that's the calculation companies are running right now whether they say it out loud or not. We're also still in the subsidized era. Tokens are priced like Uber rides in 2014. That will change.

Where he thinks delivery is heading: a team of three on an enterprise project. A senior business analyst in the real sense of the term, a senior project manager, a senior architect. The catch is that's three senior people and no pipeline underneath them, so you have to price in a ride-along second pair of hands for each seat, or the ecosystem eats its own future.

You don't need the whole workflow on Monday. Pick these three:

1. Git, today.Tell the agent to create a repo. Commit as you work. Do this even if you're building flows in a sandbox.
2. A written plan before any change. Read it. Argue with it. Commit it. This is the single highest-return gate in the entire process.
3. One adversarial review prompt. Hand the plan to a fresh agent and tell it to be skeptical and find the weaknesses. It costs one prompt and it catches things.

Add browser testing and the scripted environment setup once those three are habit.

Copy this and answer honestly. Every no is a gate you don't have:

We turned the whole workflow into a free one-page guide: the seven-phase build process, the adversarial review prompt, and the validation block to paste into every plan. It goes out to the newsletter list.

Revenue Engineer Episode 4 with Chris Pifer is on the walters954 YouTube channel. This is part of an ongoing series where people building real things on Salesforce show their actual workflow on camera, with the rough edges left in.

If this format is useful to you, subscribe on YouTube and sign up for the newsletter at revenueeng.com. New episodes and written breakdowns go there first.

Revenue Engineer is the community for working Salesforce professionals leveling up on AI-augmented development and modern GTM tooling. Weekly drops, live sessions, and a founding cohort opening soon. Join the waitlist and you'll be first in line.

Connect with Chris on LinkedIn, and if you want to see this workflow in a room full of people, the Salesforce Open Source Commons community sprints are where Chris has been building in the open for over a decade.

If you run the self-audit on your own team, drop a comment on the YouTube video and tell me which question you answered no to first. I read every one.