Salesforce VP Dan Fernandez on How Vibecoding and MCP Will Transform App Development

Hello and welcome to the latest edition of the Techstrong AI Leadership Inside Series. Today we're with Dan Fernandez, who's vice president of Product for developer Services at Salesforce. And we're talking about, well, the rise of vibe coding and model context protocols and all kinds of fun stuff.

Dan, welcome to show. Yeah, welcome. Thanks again.

Happy to be here, Mike. Yeah. For the uninitiated, what exactly is vibe coding?

'cause some folks would just say it's sun of no code slash low code with a little AI thrown in, but maybe there's more to it than that. Yeah, you know, it's kind of funny. It's, uh, depending on where you stand, you might see it as almost a derogatory term.

Like, oh, I'm just, I'm just describing this stuff. And there, there's sort of no, no care or thought within here, but I think it really is sort of thinking about, uh, the requirements of what you wanna build and making that the focus and letting AI really do a lot of the rest. And, uh, one of the key areas is obviously making it an iterative process.

How do we sort of understand the requirements, build a plan, and then iterate on those requirements to understand? And it really is faster time to value. That's the number one thing we're really trying to drive.

But that the, the downside, well, it's insecure. Like we have, there's a number of stories where we see, uh, folks releasing things and things like personal data driver's license. You don't necessarily wanna have somebody vibe code, you're a medical history, right?

So when it comes to enterprise, uh, vibe coding, uh, you really want to think about security and within the context and how do you apply sort of, uh, uh, policies and governance, uh, so that you're building safe, secure applications. And that from an enterprise perspective, you can delineate, uh, that process. And that I think is really sort of the, the difference between vibe coding, and I think the, the latest area that's really taken off is model context protocol, which is the, uh, you know, it's sort of thought of as the, the USB for being able to plug in different services, but what it's doing is, hey, if AI or, you know, an LLM let's just pick on Claude can, uh, generate, uh, application artifacts instead of just doing application artifacts, it can now take actions on your behalf.

So call that API call that website, do that specific action, run the query, visualize the results, and that's something that has really sort of taken it to the next level. Hmm. And vibe coding, is this something that I, as a, say, citizen developer are doing?

Or is it basically just something I'm instructing a bunch of AI agents to go do on my behalf? Yeah, I think that's one of the, the real areas is who is this for? Uh, and there's sort of two answers, which is, hey, how do we democratize development so that a bigger and broader audience of folks can participate in that?

So that's, uh, maybe it is more product managers, UX designers, analysts a business, uh, people that own a specific, uh, business could literally describe their application and generate that, that application. So what are, like, a classic example might be what you'd almost call personal apps, which is meaning I'm doing it to solve my problem, to answer some question, which is, I'm not planning on intending to share this publicly, but I gotta write some complicated data query and I can copy paste things into Excel and, and spend a bunch of time looking at vlookup. Or I can ask an LM to basically build that visualization for me, or look at this CSV and tell me what's interesting.

That's a great use of data. Uh, and things like Tableau Light, actually visualize that, show me that in a bar chart, show me trends over time. So there's great capabilities on almost the personal apps.

And then prototyping is sort of another killer app as well, which is, Hey, I don't really know what we want yet. We wanna just meet with customers and let them see the application, get feedback. And so instead of, you know, getting in the backlog of it, we can get feedback, get a better understanding of the requirements, get a better understanding of the user experience.

Um, as just kinda one example that we've been working on is what we call Figma to LWC, which is, hey, our UX designers, our product manager and UX designer are working in tandem. Product manager has some ideas. They, they don't necessarily have to wait for engineering to build that prototype.

They build the prototype. It's a working prototype, it's not gonna be the finished product, but it allows you to get feedback and the designer's able to work from where they want to within Figma. And then you take that Figma design and literally build the application based on top of that.

So it's sort of that great, uh, uh, how do we basically increase the feedback loop for building a better product? So we didn't spend three months building the wrong thing. So will this reduce the tension that often exists between so-called citizen developers and the professional developers out there who frequently find themselves trying to iterate some sort of application in a low code environment only to have to go back in and kinda rewrite it in at a, at a lower level language so that it can scale and run and qualify to run in the enterprise, but is the dynamic between those teams gonna change?

Yeah, I, uh, I think so as well. Uh, just to sort of take a step back, when you think about, uh, enterprise ai, it's how do we think about having a great application line of cycle management, right? So like, hey, we're building these applications.

It's not like, um, that citizen developer can just take it and go with it. How do we define, uh, what that governance is going to look like for those applications, which is, hey, this is like the bar. And we, uh, for example, recently launched a product in DevOps center testing that allows you to define quality gates.

And, uh, the example I kinda use is federal, state, and local. Meaning like an enterprise may wanna set all applications, must follow these specific rules, and maybe there are security rules. We're gonna have code analysis tools.

We, uh, have a code analyzer tool that basically will go through and find, you know, things like security issues, best practices, scale issues, uh, uh, SoCal injection, things like that, that you wanna make sure that you're protecting yourself from. So everybody must follow those sort of federal rules, if you will. The state rules might be, uh, um, uh, within an enterprise, HR or finance wants to set different rules for what their applications are.

Maybe it's auditing and compliance rules that they must follow so they can set the governance. And that includes everything from, uh, data governance, uh, role-based access control to even AI rules, which is we built a bunch of, uh, ip, we don't want our citizen developers to basically go and reinvent that. We want you to reuse that ip, which is, we have a set of services, we have a tax calculator, don't rebuild the tax calculator.

We have a formula for, uh, finding out discounts, and this is how we said discounts, reuse the existing IP we have, and maybe that's built by proco developers. Uh, and so the, the barrier to entry becomes that much easier for reuse across your enterprise. And that's one of the challenges with the public vibe coding tools.

They have no context of your enterprise. They don't know that you already built a ca tax calculator, shipping calculator, or you have these backend services, or you already have a representation of a customer, a formula. Uh, that's one of the key differentiators with both, uh, uh, enterprise context and MCP that allows you to reuse those services and get as much of your existing IP that you already have.

So really the, the citizen developer becomes more like, I am creating glue. I'm making sure that it passes, uh, all, uh, the requirements for enterprise, and then I'm going through an application lifecycle management to make sure that any updates that application are following what constraints we have for development testing. And again, so that we have, uh, high quality and, and, uh, observability for when the application goes out as well.

Mm-hmm. You mentioned MCP earlier, it seems to me that that's a big part of the glue we're talking about that makes the data accessible to the vibe coding tools, but, um, that can be both a good and a bad thing. So do we need to apply some sort of governance around how all this stuff gets used?

Yeah, that's exactly right. So, uh, for example, we launched the Salesforce DX MCP, uh, it's available, you know, it's getting like 10,000, uh, downloads a week on, on NPM. And it allows you to basically do natural language questions for anything.

How many administrators does this specific org have? Show me this particular data in this particular way, all using natural language, it converts it into a query and, uh, and obviously you can build applications with it as well. So, uh, incredibly powerful, but it does all based on the foundation of, uh, the role-based access control that we have within our tools, which is setting things like permission sets.

So it's, it's not like you can just access data, it's using the context of the currently logged in user using, you know, not to get too technical, but the, the JWT, the jaw token. So, uh, Dan can access certain amount of data, but uh, I can't access all, like, say, HR records or, or healthcare records, right? It's using the context that I've specifically been given in, uh, uh, so we're not having that issue of those security issues, that's all because we're building on that deeply unified platform that Salesforce has, right?

So it makes it that much easier. You don't have to worry about the scale or the uptime and everything else, or worry about your business logic. We'll actually help you do tools to build, plan, build and make it have quality by default with our code analysis tools and our testing tools.

I think the other great one, uh, that we have is, um, a tool called Data Masking that's available within our sandboxes. And you can think of this as, Hey, how do I test this MCP? How do I make sure that things are safe?

Uh, you run your application tests in a pre-production environment. Uh, we have one called the full Sandbox, which is all of your data except it's been anonymized with data mask, right? So it's not actually my phone number, it's not my personal identifiable information, but I can then run and make sure the application works when, not just when I have a hundred rows, but when I have, you know, a billion and really thinking about the end-to-end application lifecycle management, uh, tool for that.

So, uh, that makes you basically be able to have trust that you can verify, uh, the MCP tools aren't doing things that they shouldn't be able to do. Mm-hmm. Um, to your point about the types of applications that we're gonna build, uh, you hear people say, we're gonna build more apps in the next few years than we built in the last decade, but a lot of those apps are gonna be, as you described it, personal apps, right?

Correct. How do I kind of distinguish between what should remain personal? 'cause a lot of the end users, they say, oh, I have this cool tool, and they start passing it around, and the next thing you know, it's an enterprise app, Uh, that is exactly it.

And it sort of is, uh, uh, I don't know, uh, it, to use the, the scientific way to think about it, but it's almost like evolution, which is, hey, if that app really becomes and solves a problem, this salesperson did this one thing and it visualizes, uh, their top prospects and what are the great things they have? It uses transcription services, audio transcription for meetings and, and automates a bunch of the work they have, they show it to one other person and it becomes sort of viral. The, if you started with that enterprise policy and governance, you can assure you like, Hey, whatever that application built, we can make sure that it was always, uh, uh, building on that foundation of security, right?

That the sort of federal rules, if you will, if you just say like, Hey, everybody can do everything else, then that's the problem where it comes in and Wow, this just became, now I have to spend a bunch of time making sure that it does follow the, the minimum requirements and everything else. So it really is a good idea for us to think about that policy and governance upfront and what are, uh, what are the, the things and the dials that we will and won't allow, uh, uh, our citizen developers to do. And, um, that is one of the key areas that we're seeing.

It's when people don't have that policy or don't start thinking that forward looking is the application and oh geez, we're gonna have to re-platform this. This is using a different data. It's actually, you know, uh, doesn't have SOC two compliance, you know, you should have used our official data source and all that fun stuff.

That's really where we, we get into the problem. So if you start thinking about that governance and policy upfront, uh, it makes things that much easier. Mm-hmm.

Most of the professional developer organizations I know have a significant amount of application backlog work that they're supposed to do. Exactly. And then look through that and maybe kick some of those things back to the citizen developers and say, you know, go use vibe coating to build this thing because it doesn't really rise to the level of effort required for professional developers.

Yeah, that's exactly right. I mean, think of many departmental apps, like, I just need this one thing and it's always gonna be the priority 15 for the organization. So how do we enable folks?

It's like great marketing person. You basically wanna have some way to collaborate and just share, uh, assets or artifacts, logos across different marketing teams inside an or a large organization. You can absolutely, uh, uh, build your application and empower those folks set up sort of that fundamental, uh, policy and governance and set up their dev environments and test environments so you can make sure before anything gets to production, Hey, you have passed.

You must be this tall, if you will. These are the quality gates we're making sure that you run with our automated code analysis tools and, and things like that. And that really is the key, but it is a great chance for us to really lessen the load and also to have that conversation, what really is important for it to only do, or that we can empower and democratize, uh, the right, uh, folks across our organization.

And that will, uh, uh, lead to like good conversation. I'm like, actually, no, this is critical. We definitely want it to do it.

Or Hey, uh, let's empower that marketer to do it. And there's certain parts of the application that we wanna make sure anything within data act, we're gonna build an API, we'll expose that as MCP and, uh, you know, it enables the B2B website and all that other fun stuff. So really thinking about what are the intersections of where we want those things to do, sort of the, the plumbing and piping that we want, uh, uh, different folks to be able to do and setting those across it in different departments.

So is there a smart way to introduce this, or do I just kind of give everybody the tools and we all experiment on each other until we get to something that works? Yeah, I, it's a great question, which is like, Hey, how do you do it? And this is always different with different, uh, uh, organizations in terms of like, Hey, how do we set, how do we start thinking, uh, about this as just kinda one example, A number of folks just start with the pilot.

Hey, we have one team. Let's just take one of those applications off the IT backlog. Let's see what would happen, and let's figure out what those guardrails are.

It turns out our IT team already has a bunch of unit tests and they can already use our automated code analysis tools, no additional cost, and we already have pre-production environments set up for them. Great, let's go do that. Focus on the app and see what we learned, what worked, what didn't work, uh, where do we sort of separate, uh, the boundaries between, uh, uh, the citizen developer and the PRO code, uh, IT organization and think about what, uh, that is.

And that's probably the best place to start. It's like, okay, based on that, here's how we think we could roll this out within an an enterprise. We wanna get, you know, uh, a hundred teams inside, uh, we're gonna do, you know, recorded training and really think about putting AI in the hands of folks.

And it really is like the, uh, it's almost like fight Club. Like, Hey, we're gonna show up for a meeting and we're, you are gonna build your first app, and here's what you're gonna do. Because, you know, our, our default project is set up with that enterprise governance.

You can have this sort of confidence within there, but describe what you wanna build for your first app, get on guardrails and really set up a way for them to feel empowered, but also, uh, uh, that you have the, the knowledge and secure, uh, uh, the safety and security, uh, boundaries that you've set up within your system. Hmm. When we put all that together too, at some point, all these apps are gonna get interconnected in some ways, and we see people talking about, um, you know, things like the agent to agent protocol, but do we need more infrastructure beyond the MCP to kind of make this whole vision turn to reality?

Um, it's a, it's certainly a good question. Like, uh, we have some examples that are incredibly powerful today, right? Like the 1-800-ACCOUNTANT, uh, which is a service, you're an SMB, you don't really wanna be an accounting expert, right?

You're focused on, you know, your floral shop. The floral shop goes from one shop to 15 shops. You don't wanna do the accounting of it.

And so, uh, they, they were able to set up, uh, 70% of their inquiries were actually solved by, uh, an agent that they set up and literally pointed it to their existing knowledge base, right? So fast turnaround, uh, and is able to take actions based on their behalf, answer basic tax questions or even simple, simple things like, Hey, when do I get, uh, password or resets? What's my return status?

And so on and so forth. What's sort of like the next level of that is really interesting as well, which is, hey, we are starting to see it's not just sort of knowledge base agent, but actually action agents. And maybe it's more like, Hey, let me walk you through and really think about sort of that personalized experience.

And maybe that agent is talking to something else, which is, Hey, we are connected up into a bank, US Bank, Wells Fargo, and it's actually doing some stuff based on your data. I'm that you were able to interconnect with me. I'm able to suggest better options for you.

Hey, you bought this thing. If this was a qualifying purchase, you could actually take a tax write off on it, for example. That's an example of like, Hey, how could we actually get better knowledge, uh, within MCP?

The other area is even MCP is evolving to support things like elicitation, which is a fancy way for structured input, which is like, Hey, anytime I'm gonna ask you, uh, for certain things, tax codes, I need to understand like where your city, state, and your county to be able to understand that, uh, developers are now able to build those elicitation to always make sure to have those. And I think you're gonna see that that's for input. You're gonna see that for output as well, which is, Hey, do you want me to visualize this data so you can see your tax returns the last three years as well?

And then it gets a little wild when you start talking about those agents to agents. So maybe, uh, uh, you start thinking about, Hey, I'm going to have a set of folks, this is my, uh, uh, accounting agent is talking to my inventory agent, which is talking to another agent within their, my storefront agents, and they're all collaborating and actually suggesting path forward. I think the key though is there's always humans in the loop.

Uh, like how do we make sure that we're thinking about, uh, it's not just a agents kind of going off, it's really what is the problem that we're trying to have them solve? And being able to have that federated control of information as well. That'll be another area where it's like, Hey, I don't want my agent to leak information to another agent.

I wanna explicitly set, uh, uh, the controls for how I'm exchanging information across those agents. All right, folks, you heard it here. Usually the best way we learn is we play.

And once we start playing around with stuff, then suddenly vibe coding doesn't seem so weird and different. It's just the way we're gonna work. Hey Dan, thanks for being on the show.

Yeah, This is great. Thanks again. All Right.

And thank you all for watching the latest episode of the Techstrong AI Leadership series. You can find this episode, others on our website. We invite you to check those all out.

Until then, we'll see you next.