What Is Enterprise Vibe Coding? (And How It's Different) | Dan Fernandez (Salesforce)

Dan, it's it's great to meet meet you

and interview here at uh Dreamforce. I

mean, the the the scale of this event is

I I never seen this kind of event

before. So, it's pretty pretty amazing.

>> Yes. Uh I love Dreamforce. You're able

to connect with customers and and

there's a certain just energy that you

get from here and it's uh arguably one

of the best tech conferences in the

world.

>> Definitely the biggest, right? I think.

>> Yeah. Yeah. and just the the attention

to detail and uh as we were talking

about the uh the fake grass in the city

and just the beautiful nature and

nativity and even just a couple minutes

ago hearing Jewel play live just outside

was was a pretty incredible thing in

between your sessions.

>> Yeah, that's pretty amazing. Yeah.

>> Yeah. So, you have like a 20 plus year

career uh first working at Microsoft and

now at Salesforce uh with agent force

vibes basically trying to lower the

barrier to help people code and build

apps. Right.

>> Right. And do you think we're at a point

now where like or like when do you think

we can get to a point where anyone can

vibe code like really amazing production

apps?

>> There's a couple things which is are you

vibe coding a production app like or are

you just trying to like either solve a

specific problem or everything else and

sort of one of the key things is one if

you're vioding a Salesforce app

Salesforce actually does a lot of the

infrastructure for you. Yeah. So if I'm

building an app manually on a cloud, I

need to set up the virtual machines. I

need to make sure that the hard drives

are set up, the NAT router, all the

details that go into application

development. That's all taken care of

for me. So now I have a higher level

abstraction for building applications.

That's really where agent forest vibes

can shine, which is a lot of that stuff

is taken care of for me. So I really

just need to work uh focus on defining

what is the app I want to build.

>> Got it. what are the features? And it's

that much easier because I don't have to

build everything from scratch. I'm

starting at a much higher abstraction

level.

>> I see. Yeah, cuz uh you know, I've been

using all the vibe coding, the AI coding

tools and um yeah, it's just a huge pain

to do like do all the mpn installs and

then the model doesn't recognize the

library, the version, right? It's like

out of date and you just like before you

can even build anything, you have to

spend like 20 minutes just setting

everything up.

>> Yeah. And one of the key things we

wanted to do is we have an Asian forest

vibes IDE. Okay. So directly in uh every

Salesforce or you press a button and you

instantly get a browserbased version of

Visual Studio that already includes

everything set up. So I don't need to

install the manual VS code extensions. I

don't need to relearn how to set up the

MCP.json

file for everything else. I don't need

to install the CLI. Everything's just

there with me basically ready to to

build my application.

>> Got it. Okay. It's really lowering that

barrier to entry just from a tools

perspective. Get

>> started. Yeah. How about how about like

um I mean I I still feel like um it's

kind of the fact that you know I I think

I'm pretty good at vi coding stuff but I

can't build anything nearly as good as

my professional engineer friends. Right.

Right.

>> And just kind of taking a step back you

know five years ago or 10 years ago if

we learn how to code you learn about

loops and all this kind of stuff. Right.

And how how can someone become more

technical and become better at this

stuff now? you know, is it?

>> Yeah. So, I think one of the things is

really comparing contrasting vibe coding

versus enterprise vibe coding. One of

the things we're trying to do is say,

hey, it's okay to vibe code, but call it

a prototype. If you give it a label and

realize what it's for, like the the

point isn't that this is going to be the

production grade application. And I'll

give kind of one example and I I love

lovable, but one of the things it does

it is designing to do fast prototypes of

applications. That's the goal. that's

it, you know, uh where it really shines.

>> Yeah.

>> But it that doesn't necessarily

translate into production grade

applications. It really is. Uh so one,

you want to reuse all of the code you

possibly can. So the difference there's

a a key set of difference between the

vibe coding and enterprise vibe coding.

Reuse what you already have versus

building everything from scratch. As

kind of one example, instead of being

prompt based, be requirements or

specification based. really spend a lot

of time building out what those

requirements are and AI can help you

build those but that way you have a

clear understanding of what the app can

do uh uh leverage your infrastructure

and your governance and

>> um uh and make sure that you're thinking

about quality by default. So what do I

mean by that? This is like uh unit test.

We have tools for code analysis that

really help you uh this will run over

500 rules within your code. And whether

that's human built or AI built, it's

just going to increase the code quality.

So the closer you can get to real code

and without this otherwise you're in

vibe coding and basically it's going if

you have 10 developers working on this

stuff, they're going to build 10

inventory systems, 10 C tax calculators.

>> You really don't want that. you want to

reuse as much as possible versus just

assuming everything is green field or

new apps.

>> Okay. So I guess one of the

differentiators understand the context

of everything in your company like your

existing codebase everything that's

there already right

>> that's exactly right which is like hey

what do I reuse and I can even ask you

hey which you know I see that there's an

inventory management system do you want

me to use that specific API to manage

orders it's like yes yes I do and so

having that knowledge is one of the key

things we're announced which was the

Salesforce unified catalog to understand

all of the things within your org and

this is your your catalog of reuse. Now,

one of the challenges a lot of times I

don't want just a catalog. I want to

know what it does and having the

semantic understanding of what it does.

So, don't just tell me I have like uh a

web component one, web component 2, web

component 3.

>> Yeah,

>> web component one that's the header. Web

component two that's a mapping

application. You know, web component uh

three is a navigation control. Uh so

what we can use is use AI instead of

developers having to write that the AI

is doing semant walks up to the code and

says what do you do? Oh you're you are a

mapping component. So therefore when we

go to reuse we're not just seeing the

name we have a semantic understanding

and can do much better suggestions on

what uh uh code to reuse.

>> Got it. I mean I do think um looking at

the ecosystem of I mean there's like a

lot of AI coding tools right and looking

at the ecosystem I feel like there's

kind of two different use cases. One is

like the cursor and the clock code and

the codecs. They're trying to help

professional engineers basically move

faster, right? It's kind of like Yes.

And the other one is Yeah. like like you

said, lovable boat. They're more for

like 0 to1 prototyping. Like I'm

probably not going to use any of the

code that they actually throw out. I'm

just going to show some users and like

throw throw it away.

>> Correct.

>> You know, and I feel like um so do you

think Asian force vibes is somewhere in

the middle or do you think it's more

like professional or

>> Yeah. So uh we really started from the

professional developers and then I think

we're moving towards how do we make it

more uh addressable and really sort of

lower the barrier to entries. you're

going to see us do so much more between

you know over time as just kind of one

example in the keynote Benoff's keynote

you saw Patrick so walk up and build an

application that had a set of

requirements

>> and instead of waiting and where you see

it vibe coding and it's spitting out

code you had a visual representation of

that so a literal live view of the

application it's just kind of one

example of that's what makes it much

more approachable where I can see not

just the the underlying code. What I

want to see is the outcome of that code,

the actual AP app running there. And

that's why a lot of people are like,

"Wow, this is great. That's really what

I want to see because as I'm working

with it, I can see whether it's doing

the right thing or the wrong thing." And

then that fast feedback loop is what

what anybody loves when they're building

applications. Hey, just make this one

change. Oh, you know what? Revert back

and and make sure that you have uh tools

to be able to do that. The foundational

part of this is actually built on open

source. So this is using uh Klein's open

source tools as the foundation uh uh of

that and that happens to be one of the

most used open source tools in uh the

Visual Studio ecosystem. Yeah. And uh it

really shows uh with a Salesforce

context and those developer tools but

tailored for Salesforce development is

uh uh showing so much excitement and

promise for development.

>> That's awesome. Um yeah because I I wish

um there's more tools in the middle

ground where like the the PMs and

designers and you know the sales folks

like they can actually build production

stuff production features right because

like even as me someone who knows how to

use curs and all these other tools a lot

right

>> like my engineers don't trust me to like

start committing code into the

production code code base

>> right

>> you know so

>> and so one of the things that will get

them that and is one how do you have

better agentic rules so that it follows

as one example uh uh in one of my talks

I'm showing

Look, what we want to do is give AI some

guidance. It could build code,

JavaScript code in any way, shape, or

form, and it's going to default to

something. I don't want it to default to

something. I wanted to default to how

our engineering team did it.

>> So, you actually ask AI, I want you to

build the AI rules. You may have seen

people like where they're sharing a set

of rules that they built.

>> No, no, no. Have the AI walk up to every

file. Yeah. summarize that into a rules

file and then you use that. So next now

you're using it's the the AI you now

saying hey build me a JavaScript uh file

that builds a FAQ that does expand or

collapse just to give us sort of like a

basic example.

>> Yeah. Yeah.

>> The JavaScript output of that is

following every rule that your

engineering team is doing.

>> Got it.

>> And then second is how do you have the

code quality tools that your engineering

team is like okay cool. I know at least

it's going to be performant. it's going

to be secure, it's going to follow best

practices. So, it's the more you can do

to sort of optimize that pipeline from

uh to validate code while it's being

written and have that quality by

default.

>> Okay, so it's kind of like

>> it may actually make them be like, okay,

this PR looks like, you know, if you

change the label, you know, you do those

blank tests,

>> is this GitHub request from a product

manager or from an engineer?

>> It's going to look much more like from

an engineer. Why? because you're you

gave AI the tools to follow the the the

the codified rules uh uh implicit or

explicit from your engineering team

>> and these rules and these like

requirements come from reading the

codebase or like understanding the non-

knowledge base or

>> that's exactly right. So I say, "Hey, go

read the codebase and build a set of AI

rules so that when you generate code, it

follows those rules." And it's just one

example of a prompt that then makes

every other request feel much more

natural and native to how the apps are

built.

>> Got it. Okay.

>> So, oh, we uh we don't use any testing

framework. We use this testing

framework. We don't use Mocha. We use

Jest. You know, like those sort of even

down to the library level where I can

understand that.

>> Got it. Yeah. Because each company is

like weird and has own rules like you

gota

>> Yes.

>> Yeah. You you can't build something

generic. You have something clear for

each customer.

>> Yeah. So and one example that we do use

for Salesforce because uh Salesforce or

we actually have sort of like the

federal, state, and local. Okay.

>> You may have a set of federal rules, all

code uh must pass these set of rules,

right? Make sure that we're doing this.

Make sure we're doing this. Make sure

we're doing this for error handling. All

error handling must go here. Then you're

going to have more like the state model

which is like hey the HR app is going to

have this set of rules. Finance needs to

follow Sarbain Oxley right uh the

departmental app is not going to have

those rules. So like you get to to set

the governance of the rules for each of

those applications and even within one

company you still have the federal that

everybody must comply with but now

you're able to have much more sort of

flexible and granular controls for each

app.

>> Got it. So that that's kind of I guess

that's kind of where the differentiator

come in for for uh agent force vibes

right because uh you know some people

may be wondering like why is Salesforce

launching a vibe coding tool and but the

differentiator is really like embedded

in enterprise like understanding

enterprise context.

>> That's exactly right when I'm telling it

hey I don't want to just build uh a REST

API for uh case management. What I want

you to do is build it based on my org.

Got it. And so it walks up is like, "Oh,

great. I need this uh I need to build a

REST API and it needs to work for open

and closing cases." And it's able to do

that because it looked at your internal

context.

>> Awesome. Awesome. Okay. All right, man.

Well, let's kind of switch gears a

little bit. I want to talk about the

future because this whole conference is

about the agent work workspace, right?

>> Yes. This is where it gets really

exciting.

>> Yeah. So, like what what do you what do

you think like a product team will look

like in the future? like isn't a bunch

of humans and a bunch of agents working

together using Slack or what do you

think is that?

>> I think you hit the nail on the head and

it's one of the demos I'm going to be

showing. So, here's where we have been.

We uh the developers are spoiled in a

good way, right? They have the luxury of

having uh the uh coding assistance for

everything. But here's how it works.

They're inside an IDE. They are an

individual is typing in a a prompt. Hey,

go fix this. Go build that app.

This is the big trend that's going to

happen. It's going to go from

individuals to teams. It's going to go

from user initiated to event driven and

it's going to go from shortunning to

longunning. And so let me break down a

couple of those different examples. So

uh uh in one example it's uh user

initiated versus event driven.

>> There's another agent that has

discovered a performance issue in your

application. The app just deployed. that

agent is going to talk to your dev agent

and say, "Hey, go analyze what happened

in this specific release or with this

feature flag or whatever and what are

the issues going on there? Can you

actually fix it?" So these the sort of

event driven areas uh the individuals to

team like normally like developers get

all this productivity but there's a

number of software is a team sport. So

as product managers we could ask why did

the abandoned shopping carts uh uh lower

in this area? We have a Slack channel

that represents our app. We have the

requirements in a canvas and we can

actually have the agent build the app or

adopt the uh fix the app there. Hey, I

need a new demo of the new features. Uh

there natural language. What's it doing?

It's spinning up an environment for you.

It's running CLI tools, everything else.

You now get a demo app that you can demo

for somebody else. So all the people

that participate in whether it's DevOps

uh uh data science, everybody now has

the cool tools that are only in the ID,

they have them available directly in

Slack and then short run to long

running. This is one where there might

be something you want to do for an

entire repo.

>> Yeah.

>> Meaning like, hey, I need you to fix all

accessibility bugs. Real world example

that happens us, you'll get a thousand

accessibility bugs.

>> Yeah. You could certainly have one

person within there and click, you know,

yes, continue in a chat box in an

individual or we spin up 10 dev agents

>> and each one instead of a thousand each

one is going to do a hundred, right? So

we are parallelizing things and many of

the things that we talk about for uh

processes where we're parallelizing or

having a supervisor agent and sort of

the map reduceuced protocols or things

like that are going to be able to happen

to agents. So it really becomes I can

think of it not just as a short run but

this thing is going to take maybe 50

hours to go through all these pages and

uh all the dev test life cycle and I'm

going to come back and see okay here it

is and now it's ready to merge and we

know uh we've tested the quality. So

those are the three big things and we

are showing the demos of this uh in the

slack agent in our sessions here.

>> Okay. Yeah. I I do think the world is

moving very fast from like you know vibe

cooning where I'm just sitting on a

computer be like hey watch watching the

code generate to just like more agent

where like I assign a bunch of tickets

to people to agents and I I go away and

watch Netflix or something and and then

I come back and hopefully the work is

done and I can review the work.

>> Yes. Exactly. And look, that may not be

the best thing for every single

scenario, but there's a number of

scenarios where you can. And it really

is what we're really trying to do is

prioritize where do we want humans to be

in the most place. And that is like the

nirvana. You're spending your time on

the you're optimizing human time more

than anything else. those accessibility

bugs, we can find ways to even validate

them themselves and and have

self-healing systems versus like the the

core part where do we want to spend

those engineers is really what we're

going to be optimizing for.

>> Yeah. Because engineers don't want to

spend time like man doing manual, you

know, all this manual stuff that's like

just like brain dead, you know?

>> Yes. Exactly. Oh, I need to copy paste

and build 25 of these things. Oh, it's

going to be terrible.

>> Right. So, anything we can do to sort of

optimize that. The other key one is

personal apps. Okay.

>> So, so both you and I are vibe coding

applications. A lot of times before we

would build an Excel spreadsheet to just

play around with stuff or answer uh

simple questions. Now, we're going to be

able to build much more bigger apps that

are just for our personal use. And maybe

it's to understand a problem, experiment

with, throw something in Jupyter

notebooks, visualize something that we

couldn't do before, or just ask sort of

uh questions that uh it's just another

category of applications that we haven't

seen because it's democratized uh to

that level.

>> Awesome. Yeah, I think this is a good

thing to close on. I think um there's a

lot maybe there's like some concern out

there about like AI agents taking our

jobs, but hopefully the optimistic view

is is just like they'll take the boring

stuff and then all the humans can work

on the fun stuff again. Yes, exactly.

>> The the whole point of AI should be to

optimize the best use of your

engineering time.

>> That's right. That's right.

>> Exactly.

>> So, just last question then. So, um

where can people uh reach you and where

can people try agent force vibes?

>> Uh great question. So, uh, go to, uh, do

a Google search if people are still

doing that or you could ask, uh, uh, go

to salesforce.com and ask our help

agent, and that'll take you to our agent

force vibes page and our blog post. And

we have hands-on projects, so you can

play with this uh, uh, at home and start

getting uh, uh, your hands-on vibes.

>> Awesome. Yeah.

>> And it's totally free.

>> Awesome. Very excited. I'm going to go

home and try it now. Yeah. Yep.

>> Awesome. Dam, thanks so much for the

conversations.

>> Yeah, a pleasure. Thanks.