~/revenueeng/blog/revenue-engineer-ep5
8 min read
// revenue engineer podcast · ep. 5

Setup with Agentforce vs the CLI: Which One Should Build Your Org?

>Salesforce now gives you two AIs to change your org. We put them on screen side by side, live, on the same prompt. Here's how to pick.

//byWarren Walters··watch on YouTube

Salesforce now hands you two different AIs to do the exact same job on your org.

One lives right in your setup menu. The other runs in a terminal. Both will create a field, build a permission set, and assign it for you. Pick the wrong one and you either lose the speed, or you ship a change you can't even see.

That's the whole conversation on episode 5 of the Revenue Engineer Podcast. My guest is Vuk Stajić, founder of Mavrik and creator of the Salesforce Solopreneur Blueprint. He runs real implementations with a full dev team, he isn't a developer himself, and he came in wanting Salesforce's native tool to win.

So we did something we'd never done on the show. We shared both screens at once and gave the same prompt to both tools live. His in Setup with Agentforce, mine in the CLI. Dueling pianos, Salesforce edition.

Here's what actually happened, and how to decide which tool fits the task in front of you.

## 01_naming_trap.md

First, the naming trap

Before anything works, get the names right. This tripped up the native tool during the recording, and it will trip you up too.

  • Setup with Agentforce is the new AI built into Setup. This is the one you want.
  • Agentforce Setup is an older, different thing. Not this.
  • The permission that grants access is called "Use Setup with Agentforce."
  • Under the hood you'll still see it reference Einstein Copilot, a name Salesforce has otherwise moved on from.

If you don't know these apart, you'll ask the tool a simple question, get a confidently wrong answer, and conclude the whole thing is broken. It isn't broken. The names are just a mess right now.

## 02_live_test.md

The live test: same prompt, both tools

We gave both tools the same job: create a permission set that grants "Use Setup with Agentforce," and assign it to me.

Setup with Agentforcedrafted the change first. It showed the permission set name, the API name, the granted permission, and asked for confirmation before doing anything. That draft-and-confirm step is genuinely good. It's the thing the CLI didn't do out of the box. It created the set, then assigned it, and we opened the org and confirmed it was really there.

The CLI (Claude Code driving the Salesforce CLI against a scratch org) took a slightly different path. It pulled down metadata, worked out what I was asking, created the permission set, deployed it, and assigned it. No hand-holding on the name, but everything landed in Git, diffable and reversible, and it opened the org in the browser I asked for.

Both worked. But the interesting part wasn't the win. It was watching where each one is strong and where each one is still shaky.

## 03_which_tool.md

Where each tool actually fits

Reach for Setup with Agentforce when:

  • You're not a developer and don't want to open a terminal.
  • The change is simple and native: a field, a permission set, an assignment.
  • It's a one-off you'll verify on the spot.
  • You want the tool to draft the change and confirm before it runs.

It's included, there's no setup, and anyone can jump in. That last point is what makes Vuk bullish on it. He's watched people with zero technical background, a chef, a plumber, a lawyer, become strong admins because the platform was open to them. A native AI tool extends that. When it's good, it's the thing he'll point client admins to so they don't have to pay a consultant to move a field.

The catch: today it still misses your org's context, and it will sometimes tell you it did something it never did. That's why Vuk isn't putting it in front of clients yet. He wants it to get there. He's just not betting a client's org on it this month.

Reach for the CLI when:

  • The task is multi-step, spans objects, or you'll run it again.
  • You want the change in Git, diffable and reversible.
  • You need it to read across all your metadata to answer a question, like "why can this user do X and that one can't."
  • You're comfortable steering a general tool and reviewing the commands it runs.

The CLI is more powerful and, once it's steered, faster. The cost is the steering. It's a general tool, not a Salesforce tool, so you have to teach it your org and your rules. Purpose-built tools like DX Zero exist to prefill that steering for people who don't code, which is exactly the gap Vuk's non-developer consultants use it to cross.

## 04_the_line.md

The line that reframes all of it

Vuk said something that's bigger than either tool:

The quicker it is to spin up a validation rule or a permission set, the more of your time should go into deciding what to build in the first place. His way of putting it: the business analyst of 2026 is the Salesforce admin of 2016. The nuts and bolts get automated. The judgment about what the business actually needs does not.

## 05_guardrails.md

The guardrails that don't change

Whichever tool you reach for, these four don't move.

  1. Trust, but verify. Both tools will tell you they did something they never did. Open the org and check with your own eyes. Every time.
  2. Work in a safe org. Scratch org or sandbox, never production. The AI has your permissions, which means it has your blast radius.
  3. Steer it, don't just prompt it.Context is the whole game. Bake your rules in once so you never repeat "use the Salesforce CLI" or "ask me questions first."
  4. Learn the fundamentals first.You have to be able to read what these tools create. Clicking approve on changes you don't understand isn't saving time, it's stacking risk.

There's a version of this where you're just a beta tester. Vuk's word for it was guinea pig. These tools ship fast and half-tested, and when you run them, you're the QA. That's the price of being early. It's worth paying, as long as you know that's the deal.

## 06_self_audit.sh

Run this on yourself

Copy this and answer honestly:

1. Do you know, right now, which of the two Agentforce setup
   names is the current one?

2. Is the org you'd point either tool at production, or something
   you can throw away?

3. When a tool tells you it made a change, do you open the org and
   look, or do you take the word?

4. Are you retyping the same instructions every session instead of
   putting them in the tool's config?

5. Could you read and explain the last change one of these tools
   made for you?

If question 5 is a no, that's the one to fix first. Everything else is downstream of it.

We turned the whole side-by-side into a free one-page guide: how to pick the tool for a given task, the naming cheat sheet, and copy-paste steering prompts you can drop into either tool. It goes out to the newsletter list.

## 07_video.md

Watch the full episode

Revenue Engineer Episode 5 with Vuk Stajić 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.

## last_call.sh

Building at the intersection of Salesforce and AI?

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 Vuk on LinkedIn, and if you're working independently with your Salesforce skills, his Salesforce Solopreneur Blueprint has a free book inside.

If you run this test on your own org, drop a comment on the YouTube video and tell me which tool you reached for. I read every one.

> join the waitlist

// one email, no spam, first in line.

← back to ~/revenueengsigned: Warren Walters