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

Dan, it's great to meet you and interview here at uh Dreamforce. I mean, the the scale of this event is I never seen this kind of event before. So, it's pretty amazing. — Yes. Uh I love Dreamforce. You're able to connect with customers 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. and just 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 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 build my application. — Got it. Okay. It's really lowering that barrier to entry just from a tools perspective. Get — started. Yeah. How about like um I mean I still feel like um it's kind of the fact that you know 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 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 point isn't that this is going to be the production grade application. And I'll give kind of one example and 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 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 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 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 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 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 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 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 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 anybody loves when they're building applications. Hey, just make this one change. Oh, you know what? Revert back 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 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 showing so much excitement and promise for development. — That's awesome. Um yeah because I wish um there's more tools in the middle ground where like 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 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 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 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. 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 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. — 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. 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 codified rules 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 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 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 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 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. 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 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 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. 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 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 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 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 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 go away and watch Netflix or something 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 have self-healing systems versus like 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 just like they'll take the boring stuff and then all the humans can work on the fun stuff again. Yes, exactly. — The whole point of AI should be to optimize the best use of your engineering time. — 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, 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, at home and start getting 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.