🚀 The Model Context Protocol (MCP) Explained — Why It’s the "USB-C for AI" ========================================================================== by kirupa | Interviews with Creative People: https://www.kirupa.com/podcast/index.htm Den Delimarsky (https://registry.modelcontextprotocol.io) breaks MCP down into plain English, explaining why AI assistants need a common way to reach tools, files, and live data. The conversation moves from protocol basics to harder questions about trust, neutrality, and security, then widens into a thoughtful look at taste, authorship, and why strong engineering judgment still matters even when code gets easier to generate. Watch the interview: https://www.youtube.com/watch?v=gI8ybMqORck A conversation with Den Delimarsky | 1h 25m ABOUT THIS CONVERSATION This episode works as a clear, practical introduction to the Model Context Protocol. Den Delimarsky explains MCP as the layer that helps AI systems connect to the outside world in a consistent way, whether that means pulling data from a database, reading from a design tool, or taking action through another service. The big idea is simple: models are more useful when they can work with real context instead of guessing. Framed that way, MCP feels less like abstract infrastructure and more like a necessary piece of everyday AI work. The middle of the conversation focuses on the questions that decide whether a standard actually sticks. Den walks through the difference between local and hosted servers, why a registry helps discovery, and why a registry is not the same thing as trust. That distinction matters. A healthy ecosystem needs easy setup, but it also needs sane security habits, clear ownership, and enough neutrality that teams are not forced into one vendor's stack. The discussion stays grounded in those tradeoffs, which gives the episode a useful engineering perspective instead of treating adoption as automatic. What makes the interview especially strong is that it does not stop at protocol details. It opens into a broader conversation about agentic tools, the flood of low-effort output, and the role of human taste when software becomes easier to produce. Den is optimistic about what AI can unlock, but he is careful not to confuse fast generation with finished engineering. The result is a smart, balanced conversation about the plumbing behind modern AI, and about the human judgment that still determines whether any of that plumbing leads to something worth using. WHAT YOU'LL HEAR ABOUT - MCP matters because it gives models a standard way to reach real tools and data. - The protocol complements existing APIs instead of replacing them. - Discovery is easier with a registry, but trust still depends on security review and governance. - Vendor neutrality is a major reason standards gain real adoption. - AI can speed up building, but taste, judgment, and security work do not disappear. JUMP TO A TOPIC - 0:00 - Setting the Stage: Kirupa introduces Den Delimarsky and frames MCP as a way for AI assistants to work with real tools and data. (https://www.youtube.com/watch?v=gI8ybMqORck&t=0s) - 2:20 - What MCP Actually Is: Den explains the protocol in practical terms and shows how it gives models access to useful context. (https://www.youtube.com/watch?v=gI8ybMqORck&t=140s) - 7:00 - Local and Hosted Servers: The conversation breaks down the difference between local stdio servers and hosted HTTP-based setups. (https://www.youtube.com/watch?v=gI8ybMqORck&t=420s) - 9:00 - Finding Servers: They look at registry-driven discovery and why a central index helps developers and end users alike. (https://www.youtube.com/watch?v=gI8ybMqORck&t=540s) - 11:30 - Trust and Security: Den explains why discovery, package hygiene, and supply-chain trust are related but very different problems. (https://www.youtube.com/watch?v=gI8ybMqORck&t=690s) - 19:30 - Why Neutrality Matters: The discussion turns to open standards, interoperability, and why MCP gains strength by staying vendor-agnostic. (https://www.youtube.com/watch?v=gI8ybMqORck&t=1170s) - 33:00 - Agents and Interfaces: Kirupa and Den widen the lens to agentic workflows and the kinds of user experiences MCP can support. (https://www.youtube.com/watch?v=gI8ybMqORck&t=1980s) - 52:00 - Empowerment, Taste, and AI: They talk about using AI to empower people while keeping human judgment and originality in the loop. (https://www.youtube.com/watch?v=gI8ybMqORck&t=3120s) - 1:15:00 - Guardrails for Real Software: The conversation returns to engineering discipline, from context shaping to the risks of shipping loosely generated code. (https://www.youtube.com/watch?v=gI8ybMqORck&t=4500s) - 1:25:30 - Plumbing Behind the Magic: They close by tying MCP back to the invisible infrastructure that can make AI tools feel seamless when done well. (https://www.youtube.com/watch?v=gI8ybMqORck&t=5130s) TO LEARN MORE - Den's MCP Registry: https://registry.modelcontextprotocol.io - Den's MCP Website: https://modelcontextprotocol.io - Den's LinkedIn: https://www.linkedin.com/in/dendeli/ - Den's Blog: https://den.dev/ TRANSCRIPT The automatically generated captions have been organized by speaker, lightly edited for clarity, and broken into paragraphs for readability. Names and wording may still contain errors. 0:00 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=0s) Hi everybody. I'm back to talk with Den Delimarsky about the future of AI and, more specifically, Model Context Protocol, or MCP for short. Now, don't worry if you don't know what MCP means. We'll cover all of it in detail during our conversation. But the TL; DR is that, when you're using an AI assistant, you want the data and the responses you get from it to be more tailored to what you're doing currently and also integrate across other tools and services, where some of your data and some of the actions you might want to take will live. MCP is the standard that helps power the communication between all of those moving pieces. Den is a core contributor to the MCP standard itself, so there's no one better to walk through it with us right now. In classic fashion, we're also going to go off-road quite a bit. We're going to talk about GenAI authenticity and where all of this is headed, so it's going to be a fun conversation. Well, hi everybody. I'm back with Den. He's going to be a serious regular at this point with all the great knowledge he shares with all of us. Today we're going to be talking more about AI, and MCP in particular, something Den has a great deal of expertise in. So, Den, what is your role in MCP? How did you get involved in becoming, at least in my LinkedIn feed, the go-to person for anything that has to do with MCP? 1:23 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=83s) The go-to person in the LinkedIn feed is not the flex I would want to put behind me, honestly. But yeah, I'm Den Delimarsky, and I'm one of the core maintainers for MCP. I'm very explicitly saying one of, because there are many very talented people, people much smarter than me, who are running the show. Basically, I'm helping collaborate with the broader MCP community and helping shape the protocol. I got involved in this project, man, was it May, April, March? It feels like a while ago, but it's really been less than a year. Earlier this year, my journey with MCP started because the authorization spec wasn't in the shape that was ideal for the average developer. So I jumped in, worked with the community, and helped rewrite it. We did, and since then I kind of thought, hey, this sounds like a fun project. Let's help build it more. And here I am. 2:24 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=144s) So let's take a step back and explain to us all what MCP is. 2:29 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=149s) What is MCP? Yeah. If you use the typical outline Anthropic gives people, it's USB-C for LLMs. And when I say that, it can sound pretty abstract. What does that actually mean? Well, here's the deal. When you're using any existing LLM and you want to apply it to a real scenario, maybe you want to build an application from a design in Figma, maybe you want to access code in some other repository, or maybe you're building something that needs to analyze your company's data. Say you want to predict sales numbers based on data in a database. How do you do that? If you just throw an agent at it and say, hey, give me the sales numbers for the past quarter, where is it going to get those numbers? It doesn't know anything, and those numbers are not in the training material, so it's probably going to hallucinate something. The MCP protocol, and it stands for Model Context Protocol, can also be explained as the protocol for providing context to models. You just flip the acronym, and that's kind of it. The gist is that it unlocks all the scenarios I just mentioned, where you can now give models access to a lot of these capabilities. Your MCP server is responsible for exposing things like data sources, actions, or design assets. There's a Figma MCP server, by the way. Then your LLM is capable of invoking specific primitives from that MCP server, like tools and resources, and acting on those primitives. So if I point to an MCP server and say this MCP server exposes sales numbers, now my LLM can go and get the sales numbers before it makes a decision or helps you analyze them. It gets the real sales numbers and then works off that information. So it unlocks all these scenarios where the model has context dynamically injected into it with the help of different MCP primitives. When you describe it really seems like a client, a server, and a host, kind of a model. 4:44 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=284s) It seems like we've had, for decades, many ways of handling communication between someone who has the data and someone who needs to consume that data. What was the need for a new solution here, as opposed to repurposing an existing one? 4:59 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=299s) Well, the problem with the existing ones is that none of them are universally scalable to LLMs. And for the record, I have this conversation basically every week, where somebody says, well, can't I use a REST API for this? We have APIs, right? But here's the thing. How is the LLM going to know about those APIs? How are you going to tell it which API to use and how? It also has no built-in way to invoke those APIs properly. Are you going to run curl for every REST call? What about authentication? How do you handle all of that? How do you do things like streaming data back from those APIs? There are a lot of nuances here. So yeah, the solutions kind of exist. If you superglue a lot of these things together, you can kind of get to what MCP is. But think about it this way. If you go to Claude, you have one implementation. Then you go to OpenAI or Google and they have a different implementation. None of those things work together. MCP is trying to be that bridge that says, look, behind the scenes you still use those REST APIs. Going back to the sales numbers example, behind the scenes you might still be talking to some database through a REST API to get your document DB data, but the layer between that API and what the client is actually asking the LLM is the same universally, and that's the superpower. The underlying thing can be anything. It can be a REST API, an XML API, SOAP, and if you're using SOAP, my condolences. But you get the idea. It becomes that translation layer between the LLM and whatever is downstream, which can be an API, a container set of apps, really anything. So it's almost like the road is the same. It's still TCP/IP or whatever classic communication method is underneath, but what you're using it for has been augmented with extra details that make talking to an LLM possible. Otherwise, you have to reinvent so many common primitives to send data back to the LLM, or even have LLMs talking to other LLMs in some cases, because communication can be one-way, two-way, three-way, with multiple hops. That's where MCP comes in. And it's also worth calling out that MCP servers themselves can be of two types. They can be hosted, which means they get a URL and you throw them somewhere in the cloud, Cloudflare, AWS, Azure, whatever. And there are servers that run locally on the box. That's where you'll hear the distinction between streamable HTTP servers and stdio, where stdio stands for standard input and output. 7:45 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=465s) Like classic C++ terminology, or maybe even older, when you had stdio and little brackets to get something like the console or terminal or whatever. You're essentially piping things through the standard pipes. Wow, that's very cool. The reason I'm excited by MCP is that my day job involves working on an AI-powered dev tool, and a large part of that is interoperability with other AI services and solutions. Like you mentioned earlier, Figma as an MCP server. If you're a developer or someone building an application, you might want to interact with that Figma capability. They're using MCP, and we use MCP as a part of it, so that's where my world of MCP got really interesting. That's also how I ran into your content. The way we do it today, in some ways, is through a hardcoded file called mcp. Json, and I think a lot of tools call it mcp. Json as well. It basically contains a lot of JSON blobs with various commands, endpoints, and things like that. The challenge, of course, is that the day I create it's up to date and everything is fine. Then a week later it may not be up to date anymore. There are probably more tools and more entries. So is there a centralized solution for discovery of all these MCP things? Is there something being done, kind of like what OpenVSX did, or what marketplaces did for Chrome extensions and so on? Is there a solution for making MCP management easier? 9:16 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=556s) Yeah. Well, first of all, there is now a global index. It's called the MCP registry. Legit, there is now an MCP registry you can go to. I don't want to misspell the URL, but I believe it's registry. Modelcontextprotocol. Io. This is essentially the global index of MCP servers that are out there. Caveat: as a developer of an MCP server, you still have to list it there. It doesn't magically discover it, but it exists. Now we have a global index where you can go and say, okay, let me find all these servers. Organizations, IDEs, editors, console apps, anybody can use this registry. By the way, it's an unprotected endpoint. Anybody can query it and get the list of servers. If you look at the JSON response from the registry, you'll see that it allows for remote servers, local servers, all the stuff we just talked about. Discoverability is managed through the registry. What this also unlocks is that a lot of organizations might have policies where they want to make sure employees only use a specific set of MCP servers. The registry allows you to do that, because you can ingest that data source and then filter it depending on your needs. VS Code is using a registry-like experience, right? You can now install MCP servers. GitHub just launched the MCP registry as well, and that is also using the initial registry as one of the sources. So you have a lot of these capabilities emerging, but the MCP team is working very hard on centralizing this and having one source of truth. That's your discoverability engine. 10:59 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=659s) No, I think that's exciting. I just did a Google search for MCP registry and landed on the GitHub repository for the MCP registry, which seems about right. 11:08 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=668s) Oh yeah, and it's all open source. I should mention that this is the beauty of the MCP community too. All of the work you see is done in the open. Go to the GitHub repo. If you're curious what folks are planning on the registry, go to the GitHub repo. If you want to know what they're talking about in terms of changing things, go to the Discord. We're not hiding any of this stuff. It's out there. 11:31 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=691s) No, I think it's actually really exciting, because discovery is always the hard part. For many of these things, the people using a lot of the capabilities are not going to be the most technical users. They're going to be saying, I need to set my calendar entry, or I need to get an image file, and they don't know all the details behind it. So there's an abstraction that goes along with this that the LLM understands and, I guess, the implementer of the capabilities understands as well, because MCP itself is just data in and data out. How it's surfaced in the right UI and all of those things is probably a big part of it. 12:09 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=729s) Yeah, and that's precisely kind of the benefit of the registry. All these applications being built, whether it's Claude Desktop or whatever the OpenAI version of Claude Desktop is, don't have to worry about teaching people to do an npx install. Do your non-technical users, or your grandma, know what npx is? No. But they might understand if you say, oh, here's the thing that connects you to Expedia to book your travel. That's the abstraction here. Once you have the registry, that abstraction becomes immensely powerful, because now I don't need to find random repositories or copy some random mcp. Json into my config. The registry gives you the information. Your client developer, whatever that client might be, maybe a developer app like VS Code or maybe a client app your average person is using, can just plug in, use that data, and allow you to install the MCP server. That's it. It's easy, and we're inching toward that kind of ease of use. By the way, folks don't realize how young MCP is. It's less than a year old. We're going to hit a year in November. Just look at the adoption. Look at the community that got built around it in less than a year. It's insane. 13:33 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=813s) Yeah, and I think the URL is modelcontextprotocol. Io. It took me a little digging around. For some reason, it wasn't the first result in Google at all. I had to go through the GitHub documentation, read the blog post, and then the blog had the blog subdomain in front of it, so I had to clear that part out before I got to the website. It's a beautiful website, by the way. We have some SEO work to do, that's for sure, but it's a great-looking site, very detailed and really cool. Now, the thing about registries is this: how do you prevent bad actors from coming in and adding their own stuff, where on day one it looks legit, but on day two it's basically stealing my credentials? 14:14 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=854s) So transparently, we're in the very early days of a lot of this stuff in terms of the registry and all the security constraints, mainly because the registry right now is just an index. That's all it is. The registry doesn't do security scanning or vulnerability scanning or anything like that. So if you come into the registry and say, I have a server that requires you to run npx, and here's my package name, that's what it will list. The registry itself is not proactively doing that kind of security scanning right now. In a way, a lot of these things are delegated to the downstream repositories of the content you're installing. So if you're installing an npm-based MCP server, the assumption is that npm downstream is the one managing the security of the package, or at least alerting you when things are wrong. Now, fair point, if you saw the news last week, or really the last two weeks, about npm being in hot water with packages being compromised left and right, that's a real concern. Think of the threat vector here. I'm an MCP server developer. A new package gets released for one of my dependencies. I go into my code and think, oh yeah, sure, let me just update the package versions. That's all I did. I just upgraded the package versions and shipped the MCP server. Now anybody who got that MCP server is compromised, and I as a developer might not even know I did that. I didn't embed any custom code. I just updated the versions. But because there isn't enough practice around securing the supply chain, you end up in that kind of situation. So the danger is definitely there. Every cool thing we do starts with good things and bad things mixed together. One thing I run into in my own MCP implementation in Firebase Studio is that, in many cases, you have many MCP solutions, or at least tools that, if you squint a bit, are basically identical to each other. Using the payment example... 16:31 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=991s) Using the payment example, you have PayPal, Stripe, Google, and all these things. There might be a world where your registry is pretty comprehensive and now there are many, many, many solutions for basically the same thing. You have Expedia, Google Travel, and I don't know, Expedia owns so many sub-brands it's hard to know, Trivago is part of Expedia probably, all these things. How do we get to a point where the right solution gets recommended for an end user? And if they don't have a preference, is there some kind of mechanism the registry is going to provide? Is it going to be based on advertising? Is it going to be AdSense-style, where whoever bids the most gets recommended first and everyone else gets recommended later? What is the mechanism there? And look, I know you can't speak for the future, and caveat, you're not working on the registry. 17:30 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=1050s) Okay, so I'm not making any statements like, here's how the registry is going to work in the future, because I don't know. I would be shocked if there's going to be any kind of sponsorship or ad model. The registry itself is just an index, and especially the MCP registry is basically a vendor- and company-agnostic index. It's an index of everything. If some company takes that data and launches another registry, like a visualizer with a web UI on top of it, and then says, oh, we're going to promote the people who pay us the most, nothing stops them from doing that. Of course they can do that. But I would be shocked if that ever made it into the actual MCP registry, the official one. And the reality here is, if you think about it from a customer-solution perspective, how do you install apps today on your Android or iOS device? You go to the App Store, and the App Store is your index. Imagine that, in this case, the App Store is powered by an underlying meta-index that has no opinion about who is who. It's basically saying, here's all the things that I know, here's all the servers that I know. Then somebody can build a front end for it and say, oh, we're going to have some fancy styling for these specific things. Sure, they can do that, but that's not the registry itself. 18:53 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=1133s) I think that helps greatly because you're providing the raw data in an unfiltered, unopened form, and then it's up to whoever the consumer is. Some consumers can go to the raw data directly, and some might go to an intermediary that takes the data and processes it in a way that's optimized for whatever their purpose might be. 19:14 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=1154s) Yeah, and for the record, the terms of usage may change in the future. Right now, we're looking at the current state of things and how people are using it. But again, I see MCP as a protocol, and the infrastructure around it, as very much vendor- and company-neutral. Anybody can use it, and we see all sorts of companies adopting it. The reason they're adopting it is because it is vendor-neutral. It doesn't lock you in. Me using MCP doesn't mean I can only deploy my MCP servers to Azure. It's like HTTP web servers. There are a billion of them, all optimized for whatever runtime or capability you need, but the underlying protocol between them is standardized and common. No one really cares how it's built as long as the data in and out works the way everyone understands. And it's not just HTTP either. Even local MCP servers can run on Linux, macOS, or Windows. There's no requirement that you have to be on a specific environment to use them. And to your earlier USB-C analogy, yes, MCP is an evolving standard. Like USB itself, where you had USB 2.0, USB 1, micro USB, mini USB, and all the rest, this stuff evolves. Authentication is much easier now than it was six or seven months ago, when everybody was wondering, okay, do I handle my own OAuth thing? Am I inventing my own solution? Does this other system have its own solution? How do we figure this out? As long as the protocol is implemented to spec, the form does not matter. That brings us back to the USB-C analogy: USB went through several forms while retaining common ideas. Kudos to you and the team for improving that. Looking ahead, which challenges need a standardized solution rather than separate interim implementations? Even around OAuth, I don't think it's a solved problem. There is a solution we have right now, but it's not necessarily universally applicable to everyone. There are still questions like, how do I build server-to-server OAuth, or how do I build OAuth with things like SPIFFE or other standards? One of the things the team is working on is what we call profiles and extensions. These are layers on top of the protocol that let you customize MCP servers or clients for whatever environment you have. So if you're somebody in government and you need a high-security MCP server profile, you can imagine snapping to that and having those conventions applied without modifying the core spec itself. That's the point. You want to keep the core MCP specification as lightweight as possible. A specialized requirement should live in the appropriate profile instead of forcing every implementer to absorb it. That separation lets a government deployment enforce its conventions without turning them into requirements for an unrelated local server. You don't want to cram everything into it, like HIPAA standards for data flows and every other special requirement, because nobody's going to read all of that and nobody's going to implement all of it. You don't want to take the Bluetooth path. Historically, Bluetooth is one of the most complicated things to implement because the spec is massive, and living up to that spec requires a lot. That's why, even today, using Bluetooth on some devices is hit or miss. Very few people can go through the hassle of implementing every single thing in the spec. The practical problem with a massive specification is not just reading it. Implementers skip pieces, devices satisfy different subsets, and users are left with behavior that is technically related but still unreliable in practice. So you don't want the MCP spec to become bloated and extremely hard to implement, or even hard to understand. The spec establishes the baseline, the least common denominator, and then on top of that you can build a lot of other things. The mistake people make is thinking the spec is the end of it all. They think, oh, if it's not in the spec, I can't do this. You can, but you'll be constrained to environments that support what you built. People talk about things like client credentials. You can use them, but if you plug that into an existing MCP client that doesn't support them because they're not in the spec, it's just not going to work. If you're building your own custom client that does support them, problem solved. You built the capability and it's there. So to your question about the big things coming next, extensibility is going to be massive, just the ability to extend the protocol in a way that unlocks a lot of enterprise scenarios. That's a big one, because as the protocol matures and we get to the first year, we're seeing a lot of very large companies adopt it. They come in with requirements specific to their environment, whether that's security, data management, exfiltration control, and so on. Statelessness is one topic being assessed. Richer UI capabilities and their extension points are another. The repository shows both the large proposals and smaller discussions, so it remains the source of truth as plans change. Those enterprise answers still need to be documented and presented to the community so people can integrate them consistently. Because MCP is interoperable, people are also building complementary offerings and extending it in their own ways. Work spans both smaller changes and larger architectural questions. Some proposals may become shared protocol features; others may remain profiles or extensions for the environments that need them. Community discussion determines where that boundary belongs. 25:06 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=1506s) Do you foresee a world where MCP will encompass all the various flavors of implementations and forks you might see in the future? So maybe MCP 2.0 includes bits of other protocols that are extending it, or do you see a world where the diversity is fine and MCP stays core to a handful of capabilities while others extend it for their own purposes and build on top of that? 25:31 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=1531s) I think the beauty of MCP is its universality. I can take an MCP server, plug it into Claude Code, and it's going to work. I can plug it into GitHub Copilot, and it's going to work just as well. It would be a sad world if that became more balkanized, where there's an MCP server but it only works if you plug it into one specific agent and nothing else. That's not a world I want to live in. I don't want MCP servers to become something where I have to make a decision about whether they'll work with the platform I'm on. So I like to think the way the community is managing this, and the way Anthropic is managing this, is very much in the direction of making it universal. It has to be the least common denominator, with a set of extensions folks can apply to it, but those extensions need to be non-breaking. These are extensions that should not make a server suddenly stop working just because I plug it in somewhere else. 26:38 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=1598s) Yeah, the reason I ask is that I'm dealing with this challenge right now, because we support MCP and, since I'm on a developer tool, there are a lot of things in that world that have their own flavor of it. You have A2A, agent-to-agent protocol, and when I squint at it, I think, okay, it does a lot of things MCP does, but there are a few things it doesn't. Then you have Zed, which is another up-and-coming code editor that's pretty popular with a subset of people, and they have their own agent client protocol. They all love these three-letter acronyms, by the way. ACP, A2A, all of it. 27:10 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=1630s) I think IBM has their own one too. I think it's the Agent Communication Protocol. I should send you the link. Lori Voss, Lori is phenomenal, shout out Lori, gave a talk at the MCP Developer Summit earlier this year about the sprawl of protocols, because everybody and their mother wants to have their own protocol and now we have so many of them. Here's the thing, and yes, I'm speaking as a totally non-biased MCP core contributor. Realistically, we see huge community adoption behind MCP. The community is behind it. It's not fake. It's not something somebody invented purely for their own problem. There's real support and integration around it. Downstream, I think a lot of this stuff is going to converge. Lori kind of set the stage for that theory, and I subscribe to it. You can fairly ask which protocol an MCP core contributor is going to advocate for, but the adoption is visible across products, companies, integrations, and the broader community. A lot of those pieces where somebody says, oh, this protocol does this one thing better than MCP, can get folded in over time if the community support is there. Those capabilities are going to slowly emerge and converge into the MCP world, and then you'll have whatever future version of MCP includes them. That's basically Lori's theory on it, and I think she's right. The important qualifier is community support. A capability does not converge merely because it exists elsewhere; enough users and implementers have to want it, carry it over, and maintain it in the shared protocol. And honestly, that makes the most sense to me. Right now, if you're building an MCP client, it can feel like Blu-ray, HD DVD, and VHS all at once. You have to support all of these things because people are implementing them in different ways, and the burden is high. I never fully understood why so many big companies want to back their own version of this, but maybe I'm still a little naive there. Part of it is probably that Anthropic originated MCP even though it has become a community thing, so everybody wants their own angle on the same basic problem. Some people are even holding on to the VHS version and saying they will never change. As someone building an MCP client, I still have to account for what people actually implement, not just the standard I would prefer them to choose. A lot of big companies are getting behind their own version of it, and you naturally ask, why? What's the end game here? Because to me it is still a communications protocol. Let's keep it simple and figure it out. MCP is further ahead right now because it has a registry and more of these details figured out. The others may have their own answers, but they implement them differently, and then you have to support that too. As a consumer of it, that is painful. And look, when we're predicting the future, we're either going to be right or wrong. Technology changes. But right now there is a lot of inertia behind MCP, and that inertia is powerful. Once you get critical mass from the community and from company adoption, support snowballs. XML dominated for a long time before JSON arrived, and protobufs later emerged for particular jobs. None of these technologies is guaranteed to last forever. When implementations differ, the client cannot treat them as interchangeable; each variation needs its own compatibility work and testing. The current advantage is that MCP already has the capabilities developers and consumers are clearly asking for. If somebody comes along and says, hey, your product has been running great for years, but what if you swap this authentication or authorization library just to get slightly better caching, how likely are you to do that? Probably not very. Ripping all of that out comes at a cost. That's not platform lock-in. It's just the reality that universality matters. Because MCP is adopted by a large swath of the community, products, and different companies, improvements accelerate too. Imagine that the existing product is a complex web app and API with authentication and authorization already wired throughout it. Replacing that library is not a one-line change. You would have to remove working integration, rebuild it, test it, and accept migration risk merely to gain a little better caching. You start seeing changes like, okay, now we need this capability because one client needs it, and now all these clients can do that thing because MCP does it. That inertia is good. It helps evolve the project faster, but it also means you need very, very good reasons for something else to supersede the protocol. 32:25 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=1945s) Yeah, I think that makes a lot of sense to me in terms of how I think about it. Now, let's go one step beyond it. When we look at how all these things are done, one of the big things with MCP is connecting some request from a user or some other system to some LLM that is going to process it and return data. The thing is, and we touched upon this briefly the last time you and I chatted, the last 30 or 40 years of everything we've been doing has really been optimized for a mouse and a keyboard. What we've seen with AI, of course, is that the idea of “I have a problem; I need a solution” is still there. I still have that problem, and I still need a solution. For example, I need to set up an invite. We were chatting, and I had a calendar entry and so on. The way I did it today was to go to my calendaring app, type in your name, find the time, and hit the button. There's a world in the future where I'm just going to say, “Book my entry. I need to meet with Den at 100 on Thursday, September the 18th. Take care of it for me.” It knows how to do all of that. We're still solving the same problems, but how we solve them is no longer going to be the same. One of the big things that's going to make it happen, of course, is MCP, where intelligent agents will orchestrate all these various activities. Depending on the task, they will discover, using a registry directly or in another way, “Oh, you use Google Calendar, so we're going to choose the Google Calendar approach.” It will use the context. For example, you're at Microsoft, so you probably use Teams and Outlook. It will be like, “Oh, in your case, it's going to use Outlook and Teams.” That level of smarts is going to be hugely valuable in the future, when people are no longer worrying about what tool to use, where to click, or what time zone something is in. It's all going to be taken care of automatically. When we think about all the things we need at the protocol layer, the agent layer, the discoverability layer, the security layer, and the pricing layer, what will all these things cost? Is it going to be free? There are a lot of things that need to be invented. When you look at MCP overall, where do you see the boundaries of what MCP is going to solve ending, and where do you see something that enhances it needing to be done more universally to enable this new world? When you look at all the keynotes from Apple with Apple Intelligence, Microsoft with its agent OS, and some of these concepts across the various Build keynotes, everyone is converging on this world. It's not quite like the movie Her yet, where you just have a device, perhaps what Jony Ive is working on right now, and you talk to it, explain what you want, and things magically happen. You don't really know how it happens. It could be booking a trip, and it could be using Expedia. You don't know that anymore either; it just gets done. That's going to require a whole lot of fundamental constructs to be invented, adapted, and evolved. I'm curious to hear your take. It's sometimes MCP-specific, but at this point we're leveling it up a bit because you like technology and we've talked about this before. I figured I'd pick your brain while I have you right now. 35:34 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=2134s) Yeah, for sure. I'll plug MCP here as a start and say that one of the reasons MCP is very well suited for this world is that it bakes in a set of primitives that agents can use. We use the term agent to mean an autonomous entity that goes and does something on your behalf, right? You might have an agent that says, “Go find me the cheapest price for a phone charger cord, order it, and make sure you ship it to some PO box somewhere.” You might have several agents in the loop. One might say, “I'm going to be the deep-research pricing agent.” Another might compare the wattage of the chargers or whatever. This is a dumb example, but nonetheless, MCP has the primitives for us. We have the tools and resources that an agent can use to say, “Let me use the tool that queries an e-store.” It goes and queries the store. Then it says, “Now I need to go to this other agent to convert currency. Let me convert this to your local currency and see which ones are cheap. Now look at the reviews,” and so on. The primitives are there, and I think we are headed into a world where a lot of these things will become automated. The paradigm shift is going to be fairly significant because we are going from having a UI in front of us, where we click buttons and select things, to using natural language to ask for things and then having things magically happen. What was the saying? The greatest technology is indistinguishable from magic, right? The underlying piece is plumbing. How often do you think about plumbing when you're buying a house? How often do you think about plumbing when you are going to an office building? Not often, as long as it gets the job done. A lot of these things are plumbing. A lot of these things are infrastructure that will support it. Having the right primitives, securing them, making them interact, and chaining them properly so they can go one after another and trigger the right actions are implementation details for different clients. I think we're speed-running in that direction. There's no stopping that train because the convenience is there. No one ever wakes up and says, “I want to do something that takes 20 clicks,” as opposed to hitting an icon that says to use my microphone, talking to it, and having it get the job done 5 seconds later. I'm no longer thinking about how much work the poor computer had to do. I'm thinking, “I got the job done.” There's an important caveat here that I want to call out. How do you build this technology in a way that is actually user-oriented and not oriented toward whoever is providing that technology? The reason is very simple: if we don't do that, it's going to get abused. Imagine we're talking about the shopping assistant. For the shopping agent, I might say, “Go and find me the best-quality, best-priced phone charger.” I can go to Amazon or eBay myself, sort by the vendor, look at the reviews, and apply some heuristic by which I can do this. If I send it off to an agent and that agent is provided to me by corporation X—not X as in Twitter, but some anonymous corporation or unnamed entity, perhaps Belkin or Anker—how do I make sure that it is actually unbiased and providing me the best choice? How do I make sure it isn't saying, “Every time you ask me for a phone charger, I'll always recommend whoever paid me the most for ads”? That's the tension. How do you design this technology in a way that is actually solving my problems and not nudging me in a direction these companies want me to go? At the end of the day, I love technology and its ability to empower people, but I also want to make sure that it's serving the interests of the user. 39:56 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=2396s) And that's going to be the hard problem, because for a lot of these things right now, if you think about sponsored results and all that, how do you sort through it and make sure it gives you the best choice and not just the highest-bidder choice? 40:10 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=2410s) It's such a hassle even today. When I go to Google, for example, if I'm paying close attention, the first 10 links can literally just be sponsored links. 40:20 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=2420s) Yeah, same with Amazon. I'm kind of in the same place there. 40:22 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=2422s) Or any store, really. You can go to Amazon, and the thing that annoys me sometimes is that reviews used to be the best marker. Now they're bot-filled and ChatGPT filler, 10000 reviews deep, and they're useless. 40:41 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=2441s) How do I sift through that as a consumer and tell whether any of it is real? 40:47 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=2447s) Yeah, it used to be, “Use Fakespot. Com, paste the URL in, and see what happens.” But now the AI has gotten so good. Whatever AI Fakespot uses to detect whether a review is real or not, the AI generating the review is using that to nullify the detection. It's a cycle. Honestly, with all the advances in AI, this kind of worries me a little bit. Technology has the power to do a lot of good, but it also has the power to do a bunch of dumb stuff. I am tired of AI slop, man. When I post videos on YouTube, sometimes I want to generate a thumbnail. Sometimes I want a thumbnail of Ron Swanson from Parks and Recreation because it's kind of funny. I put in, “Oh, it's a reaction from Ron,” then go to DuckDuckGo and search for “Ron Swanson PNG,” and I get a list of AI-generated slop. Clearly, none of it is real. I'm like, “What is this?” You go to Etsy and think, “Okay, I'm going to find an artist who can help draw a card for my wife's birthday, because I'm not artistic. I'm learning, but I'm not there yet. I'll find somebody I can commission to make some very good art.” Then the whole page is filled with people doing AI-slop stuff, and I'm like, “Come on, man.” When we go into the world of agents, that's what worries me. How do you make sure that you build something that's actually serving me and not whoever is providing that agent? How do we solve that? You need someone incentivized with the sole purpose of serving the user and not some entity. If you took the earlier example of Apple and Microsoft, it's almost as if the operating system vendor itself has to be incentivized to provide that neutral territory, and that's also risky in its own way. Let's say you're Apple and somebody asks for great spreadsheet software. Are you going to recommend Google Sheets, or are you going to send people to your own version? I already forgot its name. There's Keynote. I know Keynote, but I don't know the other apps. That's embarrassing. They also have Excel and all of that. Numbers—Numbers is the name. That's an easy name. I could be wrong, but my knowledge of built-in apps on an OS is at least 10 years old because I haven't used a built-in app inside an operating system in ages. I always go to my app store and install the things I need. I don't know what the built-in ones are. Even in that world, it's complicated. What would you do in that case? What do you recommend people use? Do you say, “Excel is probably the best, most comprehensive tool, so we're going to send you there,” or, “Google Sheets is more free and collaborative, so we'll send you there”? It's messy. I don't know of a solution because every historical example I can think of started off good but then got kind of odd. Even with Wikipedia, you see so many complaints that a topic wasn't discussed because it didn't get enough of whatever A, B, and C. That's complicated. It's part of this thing about technology democratization and a lot of this stuff becoming accessible. Right now, running models is becoming super cheap. You don't even need ChatGPT; you can run them locally. A lot of these capabilities are becoming super cheap and accessible, which means the barrier to entry for a lot of folks becomes lower. That has a huge number of positives. This is not about gatekeeping. This is not about saying we should only distribute these models to people on an approved list. Absolutely not. That is not the solution here. At the same time, there is the proliferation of AI slop. I've been triaging issues in a GitHub repo for the past week, and I get AI-slop PRs where people say, “I rewrote this script to be more efficient.” You look at what it is, and clearly they fed it into Claude Code with a basic prompt. It makes no sense. I don't even know why this is happening, but they're doing it. How do you stop them? You can't. It's like saying, “Let's take away the IDEs from people.” That's kind of silly. You're not going to do that. The cat's out of the bag, right? The technology is out there, and now we have to deal with the consequences. We always used to index on human creativity and the unique value that humans provided as a differentiator between what could be spam or crap and what was actually good. But as we're seeing, in some cases AI does a really good job mimicking human things. There are times when I'm like, “That answer AI generated is far better than what I would have given for this situation, so I'm going to adopt that answer.” It does have good capabilities. I use AI to write code myself. 46:00 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=2760s) Yeah. If you've seen some of the projects I've launched in the past year, a lot of them involve me using AI to proactively help me prototype, code, and review things. There are a lot of positives. To be very clear, I'm not one of those people who thinks AI is all bad. It's not. It has a lot of positives and a lot of really good uses. But at the same time, to your point about creativity, if I buy a painting to hang in my room, I'm not going to buy an AI-generated image. I'm just not. I want a real artist. I want somebody who actually drew it, not somebody who spent an hour prompting things. I want somebody who drew it. For that reason, I love art books, because I get to see the artist's process, from sketch to finished art, and I can learn from how they got there. It can seem like a dichotomy, because at the same time I'm using AI over here, and over there I'm saying I don't like AI art. But yeah, people contain multitudes. It's the story behind the art that I'm interested in. The art is one part of it, but how the art got there is also what you're paying for. So it's not just the output. It's the whole picture. 47:21 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=2841s) 100%. Right. And- and this is kind of the creativity to me- using AI to boost your creativity to like, okay, let me ideulate, let me, let me brainstorm some ideas of what this image may look like. Let me- and then you sitting down and drawing it is different than me prompting it and then replacing my creativity with it and saying like, oh, here's what the computer gave me, here's art. Like that's not art, this just it's. You know, some like statistical model put it together like it's not. I don't know, you know, but you know, I feel like people with your point of view will increasingly be more in the minority than not. And the reason I explain is, like you know, Fiverr came out like you know, like I don't know- 10 years ago, or something like that, where you know you could pay a designer- you know X amount to like get something done, or you can pay a very small amount and the output you know, more or less exactly the same. You said this massive shift where a lot of companies and a lot of individuals went from, like you know, working with, like you know, traditional contracted, educated, like you know, traditional design companies and individuals to go to like whatever gives them the result very quickly and I feel like with AI, what we're seeing is a very similar shift. Like you know, if you look at like advertising budgets for companies and like so many things, I see often time like that commercial was shot using AI, which means it no longer uses the traditional model of like, and those are the worst commercials, man like. Have you seen them. They're terrible. They're terrible today, but I do think that it's a moment in time problem because, just like, you know, the Will Smith spaghetti thing from like couple years ago, that was terrible then, but now you're, like, you know what, that looks actually more realistic than not. Yeah. Like we talked about. Yeah. Like the cat's out of the bag. The technology is out there. Technology is going to get better. And I'm not for. I'm not saying there's no use for it. I just like myself my own preference, right? It's like I want, in my space, to be surrounded by art created by humans that has a story to it. And, at the same time, I don't mind using AI to go and write, code and prototype things and build things because it allows me to move faster. And like I'm sure people have like diverging opinions on that. That's, that's fine. Like it's not. What if somebody claims that they painted this by hand, but they actually just did it entirely using AI? But because the output is indistinguishable, would you care at that point? You know, it's like on it also depends. Like you, kind of I'll say, like you have a degree of trust in the artist or whoever is doing this right, cuz, like, the same way as today, like if somebody goes and like produces a bunch of code with AI and then says, like I wrote this, like, yeah, sure, you can claim that that's fine, but you have to have a degree of trust into somebody that like are they saying what is true? And also like to your, to your question, I guess it's like, does it matter? Like it matters to me on a personal level, on on the art piece, right, and I like to think that, like, I have an eye to distinguish some of these things versus like what? What's? What's AI generated, what's not. Like I think I can spot it, but you're right, like in the future, maybe I don't, and then, like it's going to be impossible to tell. And then it's like: what are you going to do about it? It's like I don't know. I don't know. There's no, there's no answers here. Like we are in very much uncharted territory. 50:47 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=3047s) And the thing is, it's not truly uncharted either. I was listening to this educational podcast my daughter likes, and one of the stories about Michelangelo was that, when he was pretty young, he created a forgery of another sculpture, made it look aged, sold it, and was pretty successful with it for a while before getting caught. If you're the person who bought that sculpture, and it's a Michelangelo and everything works out fine, but it never gets exposed, that thing probably ends up in a museum and becomes worth hundreds of millions of dollars. So I also wonder how many things around us that we think are authentic, done by that person, with that story, actually are not at all what we think they are. 51:37 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=3097s) Yeah, and I say it is kind of uncharted mainly because, in a lot of the things you just described, an artist still had to make the effort to forge something. If you're going to copy Michelangelo, man, kudos to you, because I could not copy Michelangelo. That still takes real talent. At the same time, I'm looking at the AI space through the lens of how I can help make it empower others. We started this conversation with MCP, and to me MCP is one of those components. It helps people do more with AI than they could today. A lot of the other things we talked about, like art, come down to preference. I'm not saying shut the technology down or ban it. No. People are going to have different preferences, as with anything in technology, and that's fair. 52:44 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=3164s) No, that's very fair, you know. And the thing that always surprises me about some of this AI work is that, before the world of AI, every new technology seemed to create an explosion of outcomes, apps, companies, and all these new things people never thought about before. The internet created a billion new things. What I'm seeing with AI, though, and this goes back to the example from earlier, is a world where we interact with our operating systems and devices and they just take care of things for us. 53:18 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=3198s) There are a lot of companies, and even whole people-sized workflows, whose entire existence is based on the mechanics of going from idea to app. If I need to book a trip, I open a browser, probably go to Google or DuckDuckGo or Bing, and from there I jump to travel sites. Maybe I have tabs open for Trivago, Vrbo, Expedia, and so on. In a world where AI takes care of all of that for me, the relevance of many of those front-end surfaces starts to disappear. What's going to happen is that, instead of having 20 things to do and 20 tasks to knock out, 20 separate little jobs across the day, and going to 100 different places to do them, I might just do all of it in one surface. That could be the Copilot UI, ChatGPT, Gemini, Claude, whatever. The technology is compelling, but it also creates consolidation. Instead of an explosion of options, I may get a much narrower set of surfaces, and that part is a little scary. That said, I think the important question is always: what problem does this actually solve? You and I are PMs. We've gone through the training. Anything you build or shift in technology has to answer that question. That's why when somebody says, oh, you can't vibe-code this app, my answer is, yes, I absolutely can if it solves my problem. If I can solve something in an hour instead of spending 17 days learning whatever the latest Next. Js framework introduces and how the React hooks work, and all I need is a dashboard to present my SQLite data, then yes, why not? That's where a lot of the AI empowerment comes in. There are problems it solves really well. And there are problems it solves really badly. Do I want AI deciding my health care plan and how my doctor should treat a specific condition? Absolutely not. I want the doctor with expert training to make that decision. Do I want to use AI to build some prototypes and look at a bunch of numbers and project how I should reshuffle a portfolio because there is actual math behind it? Then yes, I do want to use it. So there is a real discrepancy there, but it still comes back to what problem it solves and what it actually makes better. Developers sometimes get very attached to code. They say, no, you have to write the code. And sure, there is a process, there is enjoyment in writing code, and that's fine. The same applies to art. But if what I need is a result, maybe a prototype or a generated image for something, then AI may solve that problem. Whether that's good or bad is in the eye of the beholder. I think that's where it gets tricky, the value we place on the process of creating the art versus the art itself. 56:58 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=3418s) There was a blind taste test. One version was basically something from a can, microwaved and put on a plate. The other was made by a well-known, well-respected chef. Let's say ravioli, because that's a good example. You can do canned ravioli, microwaveable ravioli, or the hand-rolled everything-from-scratch version. Most people in the test couldn't tell the difference between what was created by hand with artisanal ingredients and chef-level process, and what was opened from a can and microwaved for two minutes. Then you take a step back and think, my body probably wouldn't notice that much either. So why do we do a lot of the things we do when the output itself doesn't necessarily reveal how it got there? There's a ceremony to it. For a lot of these things, there is value in saying I appreciate human-drawn art instead of AI art because I appreciate the artist, the talent, and the skill they put into it. But for me, having art in my house is not a problem I urgently need to solve. It's something I care about for its own reasons. When it comes to code, it's different. I have a problem I want to automate. Do I care whether I spend 15 hours writing that code by hand or one hour vibe-coding it? 58:30 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=3510s) Nah, doesn't matter, Right. And like it's a Seinfeld skit that you just talked about. Like I said, when Kramer's like why? Like you know why? Why eat at a restaurant where you can just like put some food in the microwave? Why go to the movie theater when you can just like pop a DVD in your VHS, in your player and watch it at home? It's like, yes, it's the experience, is the process. There's value in that. But also, don't forget about the fact that a lot of this is in service of what problem does it solve? And a lot of people have problems that are solved really well by it. Yeah. And you know, the example I always remembered is like a bit unrelated, is like when I was very young, he used to read Garfield comics and there's a great sequence where Garfield, he loves lasagna- of course, spoiler alert if you didn't read Garfield- and you're like surprised. Yeah, he, he loves, he hates Mondays and loves lasagna. Yeah. Exactly right. And there's one thing, like a nightmare scenario, where he gets like lasagna in pill form. I think it's like some kind of a future facing thing. He takes it in pill form. He's like: I, I feel full. This is great, but I miss the taste of lasagna. I miss, like how it feels and so on. So that's an example where Garfield would be willing to pay extra for the hassle and all of that of like, you know, doing lasagna in the more traditional way as opposed to the more easily convenient form of just like popping a version of it in freeze-dried pill form, and yet it feels the same way afterwards. And maybe that's actually a very good kind of description here. Like when we talk about like the difference between like art and code, because that that's the topic that I apparently like send us down the rabbit hole of. But like art, there's an emotional connection to it, right? Like there's like there's somebody that painted something that is like wow, they had a very specific feel to it. I don't know about you, but I don't have an emotional reaction to software. Like to me it's like soft. Like software solves a problem. Like if today I'm using, like we're using, Riverside to record this podcast. If tomorrow a software like a SAS startup comes along is like here's a better version to record your podcast that has better experience. Dude, I'm switching. I'm like I have zero emotional attachment to software. Like I'm of the opinion that nobody should ever be like emotionally attached to a software product because, like, do use what solves your problem. Are you on Windows? Are you on Linux? Are you on Mac OS? Use whatever solves your problem. Exactly. Same way I treat code that I produce with like vibe coding or using like spectriven development or any of that stuff. It's like I solve a problem and if there's a better solution to solve that problem, I will use that solution. Yep. But I will say though, a younger version of me, many decades ago, I was like a militant Windows fan. Like I would go out of my way on like Neo Win wind drivers wherever like there's a community forum and talk about Windows. You know, anywhere like people talk about like Mac OS, I'd be like no, Windows is where it's at, you know. And I remember, even in college I was like vocal about how Windows is great, which you know it's not the popular opinion to hold in colleges. You know Windows is the thing you want to go for. But. 1:01:22 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=3682s) Yeah, it is funny, though, like there's so many phases in, like where people's preferences are. Because I build- you know, I work on a team that you know built a vibe coding tool. I get a lot of people who email me and are upset that I am allowing people to build software whose output is the same. That's like the lasagna pro thing. It's almost the same as what it would be built if someone were to actually, you know, do this manually. I mean definitely not 100%. You know that you were limited by the models and so on, but from an enduser point of view, it solves my problem. For me. No, ex, precisely. It's precisely that. Because for me, if I like, code is an artifact. Code is my map to get from point A to point B. I use code to get there. And to me it's like right, like when we ship products, we like we both work at a big companies- like we know that once products ship, like how many of your customers actually care like well, let me, let me take a look at the code. Let me see how you named your variables and like, how, how, what was the? Did you use tabs or spaces? How did you like you, how kind of? What kind of comments did you use? Right? Like none of the stuff matters because they're. They're getting a product that solves a problem. That's the beauty of it. That's code. C, code, just right. Like our assembly programmers angry at us that we're using like higher, like higher level languages, like oh, it should be all like assembly, or like zeros and ones. That's the only real programmers that do that. Like no, of course not. You're not going to do that. Yeah. This generation. Yeah. And it's always been hard for me to figure out like where's the line? What is the? You know what? Where exactly? Like where's the line, really? Because I'm sure you'll follow like the. You know there's a famous Twitterx account. You know it's like die work. Where you know it's like the same. 1:03:02 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=3782s) Oh yeah, Derek Guy. Yeah, Derek Guy, right, you know, like I have zero interest or knowledge of fashion. Like I just basically have an infinite collection of, like solid colored t-shirts and that's it, you know. And yet his, his, you know, his- content is fascinating. Because I'm like, okay, what is this? Like handwoven, all the? I'm like it's the amount of intricacies and craft that goes into it is fantastic, but I'm like, I'm like, no, I'll just buy whatever is like there. And I know it like violates every single thing he talks about, like how finely craft it should be, or what should a collar be made out of. I'm like, yeah, I don't do any of that, you know, in terms of it. And that that's where we get to with the idea of personal preferences, right? It's like if you have a fine taste for clothing, art, like it's great. At the same time, there's going to be people that will wear Unilo or Gap or whatever else is like the cheaply made that you can, man, I can just throw in. I wear Uniqlo, by the way. I wear Uniqlo, too. Like, I don't care. Unilo sponsor this podcast. You know, both of us are on it. So, yeah, go for it. Yeah. Yeah. We're not sponsored by Uniqlo, for the record. We're not. But like it's one of those things. Like it's look, man, like it gets the job done and it's good enough for what I'm trying to what I'm. But that doesn't mean that there's no room for specific tastes here and actually I think we, on a subject of taste, like, we're going to prolong this podcast, but that's that's way we like to. You know that's a little about podcast. You know how you can go longer. I think that's going to be actually the differentiating factor between like when people talk about me, like. I had a few conversations the last few weeks where people like: well, if AI comes along and replaces old programmers and replaces like all the developers, like what's to set somebody apart in this kind of career hellscape where I can't find a job because of like you know what taste? You still need skills. Because to me it's like. If we look at like programming, like whether it's vibe coding or anything like that, you still need to have taste. Like. If you look at the iPhone, the iPhone is a like- I'm talking about the original iPhone- like the Steve Jobs iPhone. Steve had a very at the risk again of bringing up Steve Jobs, and this is the most cliche Silicon Valley thing possible. You're also wearing a black t-shirt, by the way, so you know. Yeah, exactly. I'm not trying to emulate Steve Jobs, but like he had taste. He had a very specific I want the phone to be this and this way for a very particular reason. And I think once we get into the world where anybody can write software, anybody can create a website, anybody can create a SAS app, taste is going to matter a lot, because then it's like, can you make it actually good? Because like, yeah, anybody can create a, like a wizzywig, whatever form, throw stuff together, but like, the taste is going to be the differentiating factor. And I still think that there's going to be a lot of value in deep expertise, because people assume that like, oh, just because I can vibe code a web app, that means I can just sling it over the fence and it's now deployed and I'm done. And the reality is not quite that. Because it's like: okay, how many of the how? How many of them are going to be properly secured? How many of them are going to have some? Like critical security vulnerability is going to excfiltrate all the customer data because somebody vibe coded their o code, right, like there, a lot of these qu like you. Still, you need taste and deep expertise, like I. I don't think those things are going away anytime soon. Do you feel like AI can mimic the taste aspect of things though? No, I think, and that that is because, like AI, inherently a lot of the models they're trained on past data. All it can do is basically regurgitate past the past. But I guess that's where the whole AGI and super intelligence and that part of the conversation is going in which is like, can we go beyond that? But I don't think the LLM are path to AGI. Yeah. Right. Like the LM are not not the unlock here. There's the LLM unlock, a lot of things, but I don't think it's AGI. Personal opinion- again, asterisk, this is this is what Dan says. Like I don't speak for any company or anything else, but like, in my view, the path to AGI, like I don't, like, I don't even know what AGI is representing honestly at this point. Like what, what is AGI? A long time ago in college- you know, you know I was taking this class. You know I read the book society of mind, I think, by Marvin Minsky and he was taking this- you took an approach was kind of like you know, instead of like trying to make you know computers more like human. What do you try to make humans more like computers to understand? A more fundamental level on, how can we expand, like what we normally do, in a way a computer can understand it? And in one of the ideas, you know, presented there is that creativity, you know, the way a human does. It is not really that magical. It is systematic in some ways. You know, you're kind of like drawing, you know, you have some plots on a line and then you're just extrapolating, based on what those paths are, to a point in the future. That can be done. It, you know, it could be a bit of randomization or some kind of like experimentation where you try things out, but that could be an essence of what creativity is. And if we look at a lot of what we're talking about right now, where taste and creativity probably intersect, could there be a world where a lot of what we're doing could be some AB experiments where, you know, random things are thrown at the wall and then one of those things you're like, okay, that seems interesting. You know, let me use like contemporary evaluation measures of like: is this good or bad style, for example, and then come up with the answer. 1:08:27 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=4107s) Right, but that sounds to me like that Italian chef clip where somebody says, what if you added this to your pasta, and he says, well, if my grandma had wheels, she'd be a bicycle. It's like, yeah, if you just figure out this one small thing of how creativity can be systematized. 1:08:48 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=4128s) I actually like look, we don't even understand our own brain. Like sure, if you look at the atomic level, it's all just electrical signals to neurons, right, it's like if you can replicate that, you can replicate creativity, right. Like we haven't even figured out our own brain. Like, how are we going to like encode this into an actual systematic way? Like I don't know, I'm skeptical, I'm I never want to say never, say never, because you, technology changes at an like astronomical pace, like you talked about, like the wills spaghetti thing. It's like, look in, like in two years, that become became a non-issue, right? Like you can now look at videos that are generated like VO. You look at the nano banana stuff that's being created and you're like that's pretty freaking, like realistic, right? So for a lot of these things, like never, say never, but, like I'm skeptical of trying to overly simplify it and say like, oh, if only we crack this super complex thing, then things are going to be really off the rails. Like let's, let's, let's get there first. Like I think we're, like I don't see signs yet of us being anywhere near it, right? Because I think it goes with the classic, like you know, 8020, kind of a rule thing where, like you know, 80% of the people in the world they would not know or care that this was generated by AI- taste or not, and so on, kind of kind of like us, like you know, with, like the, you know- unique clothing that we're- yeah, you know, we chose it because it's convenient, you know not because it has any kind of a specific you know thing to it. But there's 20% of the world who do care about some of these things and I think, with AI, what's happening is like that 80% is more easily satisfied by whatever needs to be provided. Excited because I, I used Nana, a banana, like a couple of weeks, a, you know, I mean, that's part of my job. But also, like you know, out of curiosity, and you know, I have an orange cat, has a very poofy tail and all of that, and I had it animating, like you know, as it was like just like turning the pages on a book and it a did a really good job. Like getting the- you know the poofiness of the fur and I'm like, I'm like wow, how was that even possible? Even like, I just couldn't even like imagine that point. Like how much training data. I went in behind the scenes get the physics somewhat right, and if I squinted at it and I was like, walking by, like you know, I saw a billboard with that as the thing. I'm like, wow, that's a, that's a. How does the cat do that? It wouldn't even come across my mind was until I generated. And that's today, a year from now, who knows where it's going to be? And I might not just follow the 80%, but if I'm at 20%, like actually cares about high quality animation and videos and so on, I might actually be like you know what that actually meets my bar. The story is not there. The, you know the tastefulness of it may not be exactly what I'd want, but as purely looking at the output, objectively it does a job. Yeah. And I mean that's again. A lot of this is going to come down to personal preferences, right? And this is where, again, people contain multitudes. People will have a spectrum of what they enjoy, what they. There's always going to be people that will like: I absolutely hate AI art. And there's people that, like I have just AI art and nothing else. There's going to be people that will say, I absolutely hate AI coding and I'm writing my code in Notepad, zeros and ones as is. And that's fine. And there's going to be other people that are going to be vibe code stuff and just ship. And that doesn't matter. Like, at the end of the day, it's all personal preference. It's all what you enjoy, what it empowers you to do, what problems does it solve for you, and how you're solving them, right? And if you have preferences, one or the other like that, that's fine. It's totally fair to do that. People contain multitudes. 1:12:08 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=4328s) But I think, in this case, the market will eventually speak and make the decision for you. Using coding as the example, I do see a world where AI-generated code gets decent, or even great, to the point where there isn't much market value in somebody manually writing all of it. 1:12:28 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=4348s) That is until the code breaks, and then somebody needs to come in and say, “We have no idea what's happening.” I think we saw this in a paper that was circulating: writing code becomes trivial, but reviewing code becomes even more important. In aggregate, you save time by using AI, but you don't go from 10 hours to zero hours. You go from 10 hours to maybe 8 or 7 hours because now you're spending time writing the code, reviewing it, and deeply understanding it. Even then, there is some debate about that. It's not all black and white. As with everything involving AI, no matter how you look at this, in the grand scheme of things we're still in the very early stages of the technological advances here. We've only been doing this since 2019, so it's six years-ish. That's a lot of time, but not nearly enough to say, “Wow, we've been doing this for the past two decades.” The capabilities will improve, of course. But even reviewing code has a nonzero cost, and it relies on some degree of determinism in the AI models producing the code you want. Yesterday, when I was experimenting with scripting, the AI produced a completely wrong script from a seemingly correct prompt. I had to say, “Okay, no, rewrite this part. Now rewrite this part. Now rewrite this part.” Sometimes, for certain things—not everything—you wonder, “Would it be faster if I just wrote it myself? Why am I prompting this to rewrite? I could just write this, man. I should have spent the hour doing this.” It depends. I like to think technology will improve. It will get better, more robust, more systematized, and more structured. My team and I are working on that. That's the stuff that I've been shipping recently with Spec Kit and a lot of the broader spec-driven work. It's an effort to put in these guardrails, grounded in a lot of experiences where things can get unpredictable. We want to make sure the operationalization of a lot of these processes is there so you get the superpower of writing a lot of code while steering it in the right direction. Yeah, I've been playing with Spec Kit because I thought, “We should add this to our vibe-coding tool.” I love it, and knowing that you had a hand in making it is even cooler. It's an experiment. To be clear, a lot of the things we're looking at are experiments to see what works. The only way for us to see what works with AI and what doesn't is to ship it, get it in front of people, and try to use it for real scenarios. This uncovers a lot of the rough edges with AI tools: “It didn't quite follow this instruction, it didn't quite follow that one, and then it missed this context. What can we do to optimize the context?” There are a lot of nuances that I think will get figured out. Technology is definitely not staying in place. No matter how you look at this, it is incorrect to take conclusions based on LLMs today and project those conclusions five years into the future. 1:15:31 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=4531s) Yeah, completely agree. What made Spec Kit interesting to me is that, in my product, when you have a prompt, as vague as it may be, we generate what we call a blueprint, which is basically a spec for you. You can then edit it and make modifications, and people do an okay job with that, but for the most part they just want to click the button and get the app. So when I saw Spec Kit, I thought, this is actually pretty cool, because there is a part of the audience that really cares about making sure the spec is detailed, and whatever we autogenerate is usually not specific enough. It misses details, because there is always a balance between being specific and overwhelming the person. We use things like MD AI rules files and other constraints, and it's never been perfect. Spec Kit feels like a really good solution here because it brings a bit more determinism. The way I explain it to my team is that we're all standing in the middle of this huge three-dimensional pool of water trying to wrangle it. You build a barrier here, another barrier there, maybe cap one on top, and you're trying to keep the whole thing contained. With AI, nobody has figured out a perfectly clean way to build those barriers without leaks or weird spillover. So the answer might be something like Spec Kit plus AI rules plus the right tools in your mcp. Json file, tuned exactly for what you're doing, because if you have 80 tools that all do similar things, the LLM gets confused. It doesn't know what to do. Then your MCP file gets really large and things get even more confusing. So I'm always thinking about how to constrain this very open-ended, vague, hard problem and clamp the range of outputs to the one thing that's actually being specified. If Spec Kit ends up being the right top-level constraint for that, great. And if not, maybe something better comes along. We're still in the early days of applying this to serious software engineering. People mistake software engineering for writing code, but it's not just writing code. Writing code is the easy part. You can throw hundreds or thousands of lines of code at a problem, but maintaining it, evolving it, making sure it's extensible, and making sure it can easily be perceived, or understood, by whoever is actually consuming it, that's the hard part. 1:18:02 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=4682s) And like, like you said, like the reviewing part is a hard part. Like, how do you look at the code that the AI generated you, a code that does like off or encryption or something? How do you make sure that it's correct? Yeah, like a shopping cart, basically. Or a shopping cart. Like how do you make sure that it does not leak the credit card numbers when somebody clicks on purchase, right? Like a lot of these things. Like how do you make sure that things like cross-- sight, like request for forgery, is handled properly, like un and here's- and this is where I was saying that expertise will still be needed, because somebody needs to know that I need to know what to look for, right? Because AI will produce you the code. It'll give you the code. It'll give you a lot of code, a lot of code that looks good, but the danger is in the things that you do not know, that you don't know. You know, it's like this comes up all the time, right? I know we're like way past time here, but it's fine. It's a good conversation for me. Yeah. The thing is like, you know, back at Microsoft, right? You know, one of the things I always enjoyed doing was like I don't know if they still have this tool or not, but I always enjoyed. 1:19:00 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=4740s) Like what's in the release process. Back in the day we had things like SWRAT and SDL Track and all these internal sites where fuzz testing was a big part of it. Is there a world where AI creates whatever it creates, but then the output gets tested with enough rigor to catch a lot of these issues? So even if the app was created in a poor way, maybe it's some ridiculous one-million-line switch statement that brute-forces every edge case that could cause a stack overflow or some other mistake, could that still be acceptable if the duct tape is so comprehensive that it seals all the holes and lets you land safely? 1:19:43 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=4783s) I mean, possibly. If we look at HackerOne—sorry, not HackerRank; HackerOne is the security bug-bounty site—what is the top contributor today? I don't actually know. The last time I checked, it was a project called XBow. I don't know if you've heard about it. XBow is essentially AI, and it claims all these bounties for security vulnerabilities because they use AI to detect them. It's entirely possible that in the future you might have a set of agents inspecting your code. One might say, “I'm going to look for vulnerabilities in this.” Another might look for gaps in code sensibility. A lot of this is trainable, and a lot of it can be systematized. As we talked about before, if only we can solve this very hard problem, then we're going to have all these things happening. It's not an easy problem to solve, but it is solvable. There are a lot of aspirations going in that direction. Microsoft launched the SRE agent, which can look at the logs and determine, “Oh, you have a memory leak in this code. Maybe let me open a GitHub issue.” Then you assign the GitHub issue to Copilot, and Copilot fixes the memory leak and deploys it. This chaining of things in the software development process is going to be super powerful, and it's going to get better and better. There's a lot of value to it. If I don't have to be on call because this SRE agent can solve the problem, fix it, and deploy it, then I can come in the morning and say, “Oh, it looks like a memory leak got fixed last night while I was asleep.” That's kind of neat. It solved a real problem for me and saved me a bunch of time. Of course, the caveat is that it hinges on the actual accuracy of the agent: whether it solved the problem the right way and did not introduce 10 other bugs that I now have to scramble to solve. But I'm optimistic about the direction of technology and the direction in which we're building these agentic workflows. I think that's probably the most exciting part of all these things. To your point from earlier, this is not old technology. We're still figuring it out and learning what works. We're making mistakes along the way and making new mistakes. Eventually, though, the path is narrowing and converging on certain best practices and best solutions. We will get there. Right now, the bouncy ball is bouncing all over the place. Eventually, it's going to reach a point where you can pick and choose exactly what you want and the output will be reasonably high-quality and predictable. You can sleep peacefully at night knowing that a bug was fixed, deployed to production, and seen by people without anyone seeing a bad result from it. We're far away from that today, but I think we will get there. 1:22:38 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=4958s) Yeah, and I think the hard part here is cutting through the noise, because it still is the early days. And I know six years doesn't sound like early days to everybody. When was ChatGPT released, 2019? Before 2019? I think it was 2019, though it somehow feels way more recent than that. 1:23:00 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=4980s) Somebody's going to comment on this video and say, like Den is absolutely wrong. Chad got released. Like, yeah, whatever. Chad got released. But anyway, well, this the snarky person will be like, "Well, we had called IRC". And my friend would reply back with the answer. Yeah. Yeah. Oh, sure. So like, Yeah. So, like we're, we're in the early days. So, like the technology will change, technology will get better, it will get cheaper. And there's a lot of, I think, nuances to it. Where there is, it's important to be able to also critically look at what's happening and understand what is noise and what is signal, because I think, honestly, that's the hardest part right now in the AI space is there's just so much noise, so much noise and when you go like, cutting through that noise and cutting through the hype and actually narrowing it down to very real scenarios, real things and the reality of the capabilities of the system is very, very important. So I had like For for the listeners listening to this, I encourage you to take a critical eye and figure out how to cut through the hype and find realistic scenarios that work, that don't work, and how this is going to work in the future. I think that's that's a hard problem. 1:24:04 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=5044s) Yeah, and with the universe constantly expanding in AI, we never get to the point where the dust can settle, or the water can settle, and we can clearly see where the cracks are and where the pools need to be leveled off. That just is not happening yet. It may settle eventually, like the internet did. We said this even a couple of years ago. But even right now, things are changing so quickly that by the time a best practice gets discovered, it's already a little out of date because somebody found flaws in it or the ground shifted again. 1:24:32 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=5072s) Yeah, absolutely. It's an ever-moving target right now, but it eventually will settle. That's just technology-cycle 101. Think about the internet during the dot-com boom. Everything had to be on the internet. Put your microwave on the internet. Put everything on the internet. And then eventually it just became the internet. Now if you mention it, people shrug because it's normal. So maybe one day somebody jokes about the microwave context protocol, or the micro context protocol, and we end up right back where we started. 1:25:05 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=5105s) Full circle. You and I could talk forever about some of this stuff, and maybe we should do a follow-up again in the near future. It was great chatting with you. We started talking about MCP, but the thing is that everything we're talking about here really connects back to it. 1:25:18 - Den Delimarsky (https://www.youtube.com/watch?v=gI8ybMqORck&t=5118s) Fundamentally, there needs to be something like MCP that enables all of this. And if we do our jobs right, in my case helping design the protocol with the team, and in your world implementing solutions on top of it that use MCP, then it becomes what you mentioned earlier: something that, when done really well, is indistinguishable from magic. All the things we talked about need those fundamental pieces underneath them. So yes, we've brought it properly back to a conclusion. It's an exciting time. I'll put it that way. It's an exciting time. 1:25:48 - Kirupa (https://www.youtube.com/watch?v=gI8ybMqORck&t=5148s) Yep. All right then. Thanks again, and we'll catch up again later. We'll catch up soon. Browse all Interviews with Creative People: https://www.kirupa.com/podcast/index.htm