Transcript: ‘Vercel’s Guillermo Rauch on What Comes After Coding’

The transcript of AI & I with Guillermo Rauch is below. Watch on X or YouTube, or listen on Spotify or Apple Podcasts.

Timestamps

1. Introduction: 00:01:33
2. How to spot trends early: 00:03:18
3. Why you should be your own customer: 00:07:34
4. How to create an ecosystem of talent and ambition: 00:14:55 
5. Why Guillermo doesn't identify as a coder: 00:17:29
6. AI is gearing us toward an allocation economy: 00:20:50
7. How Vercel’s copilot compares with other coding agents: 00:28:34
8. Guillermo’s advice on having better taste: 00:40:35
9. The future of AI agents is specialized: 00:42:46
10. How AI startups can compete with big tech: 00:47:50

Transcript

Dan Shipper (00:01:33)

Guillermo, welcome to the show.

Guillermo Rauch (00:01:35)

Thanks for having me. 

Dan Shipper (00:01:37)

So, for people who don't know, you are the cofounder and CEO of Vercel. You're also the creator of Next and Socket.io, which is very close to my heart. I told you when we met that Socket.io is the reason I could build my last company. So I appreciate all you've done for the developer ecosystem.

Guillermo Rauch (00:01:54)

Just met some folks last night that said the same. It's nice to get recognition for open-source, but I'm thankful to the people that maintain those projects.

Dan Shipper (00:02:03)

So we've a lot to talk about. I really, in general, in this conversation, I want to talk about the future of programming with AI. I want to talk about v0 and what you're doing with Vercel. But where I want to start is, before this interview, I was thinking about the kinds of things that it seems like you're interested in building, and the kind of taste that you have—and then think about how that might apply in this sort of AI era. And where I kind of came to, and I'll admit, o1 was involved a little bit in this. What I kind of came to is, it seems like you're very good at playing at the edges of what's possible technically, looking for where there's something that's new and pragmatically valuable, but still pretty messy and then coming up with a very clean opinionated zero-config solution to it. So, I would put Socket.io in that bucket, I would put Next in that bucket, I think Vercel that in that bucket. So one is, I'm curious if you feel like that's kind of—

Guillermo Rauch (00:03:12)

I mean, if o1 came up with that, it’s over. That's pretty good. I'll tell you. It's funny. I was having a conversation with one of my coworkers the other day and I was giving them the example of Socket.io as: When I started the project, WebSocket, which is the underlying technology that later became a part of web browsers— For context, maybe everyone doesn't know about Socket.io. It enables real-time chat, real-time communication. It powers websites like Perplexity. And when I created that developer tool, WebSocket was in its infancy. So, to your point, you kind of want to identify the wave when it's just a few drops of water, but you see that potential. And it's also extremely messy. So, being able to go from, I want to do something with real time, to I want to create an application, I think that's the vacuum, or the huge gap, that Socket.io filled out. And with v0, I think we saw the same thing. So models became good at writing code. Specifically, they were very good at being able to design with HTML and CSS and also writing React code. So, even when GPT-3 was out, we started thinking about, well, this could be used for revolutionizing how design and code gets emitted. How the process of bringing an idea to life could be completely disrupted, but it was really early. So to your point, there's almost a parallel between WebSocket was a draft of a specification when I started Socket.io. And when we first thought about v0, models could barely be coherent in outputting code, but there was that promise. And I think you kind of want to ride those waves when they're early.

Dan Shipper (00:04:59)

Yeah, and I think one of, one of the interesting things is, it feels like— So everything that you've done so far has been very developer-focused, and it feels like you have your finger on the vibe of what developers want.

Guillermo Rauch (00:05:12)

Well, I’ll tell you something I don't think I've shared before, which is, the company was called ZEIT, and then we renamed it to Vercel. And the reason I called it ZEIT was a few things. One, I was obsessed with this idea that if you really want to capture developers, you need to capture the zeitgeist. The zeitgeist is this idea of the collective conscience and how people are thinking about the future. And you need to really be on your toes, because things change so quickly. The vibes change so quickly, right? You see these models—one day one model is popular for developers, the next day it's another model. And another point was zeit means time in German. And I was obsessed with this idea of real time with my background in Socket.io. And what I thought is that the best way to build software would be in real time and it has two meanings. One is real time in the sense of you're just typing and you're getting feedback instantaneously from the system. I think v0 is almost like the culmination of that idea because you're literally chatting with the system and getting feedback in real time. But the other one was chatting with your customers, getting feedback from the world and adapting. I sometimes joke that for early-stage founders, their job is to chat on X with their customers and prospects, get feedback, fix things, and put a ton of quality craft and taste into their products.

Dan Shipper (00:06:38)

I want to stay with that idea of zeitgeist or paradigm or having your finger on the pulse of something. Because I think one thing that's interesting is to come up with Socket.io to come up with Next, you have to be developing stuff yourself all the time to realize that this is possible and that you want to make something but it's too hard, so you need a tool to help you do that more easily. And I'm curious how that has changed for you. I don't know how much programming you're doing right now.

Guillermo Rauch (00:07:13)

It really hasn't changed, surprisingly. So like I mentioned earlier, one of my goals is to enable Vercel to do a lot of what I did as an individual—come up with those ideas, and be able to bring them to life. And so one of the things that I mentioned is, kind of inspiring our employees with, well, you could build the next Socket.io if you think about these principles. So I think a lot about principles that I can set for the company at large. And one of them is that we're always customer zero. We dog-food our tools. We put product experiences before tools as well. I was just having a conversation with our tech lead for the AI SDK. 

So AI SDK is a really interesting project, it's becoming the number one framework in the JavaScript world for how you interact with AI models. So it's almost the Socket.io or Next.js of LLMs. But it didn't come out because I was excited about AI, or because I live in San Francisco and I saw a lot of billboards about AI was, hmm, we should have an AI framework. What it came out of is us building AI products. So, we're building a lot of really cool demos of how to use Next.js with AI, we're building v0, and we realized there's an opportunity to extract out the infrastructure of those AI products and then share them with the world. And so the operating principle here is, you want to always put the product first, not the framework first. A framework in isolation without having that initial sort of patient zero is never going to be a good tool. And this actually came out of my fascination with how Meta put out React. So Next.js builds on the open-source UI infrastructure that Meta open sourced. And what I noticed is that I kind of reverse engineer why I liked React and why I was impressed with it. And I remember it first started with their product. I would go to the Facebook news feed and all of the things that they were doing that were very real time like the chat thing and the notifications badge and it just felt snappy. I actually remember a specific moment when they announced that comments were going to start trickling in in real time and I was like, that's hard because I had built something. I was like, that's really hard at that scale. It's very impressive. And then I realized, okay, you ask yourself. Okay, how did they build that? And this is actually something that a lot of people do unconsciously and is really good to tap into that sort of, it's almost like a primal instinct. When you see something good, you ask yourself, how did they build that? It's like when you walk into a studio and you're like, oh, I really like the vibe here. Well, the next thing you do— I mean, maybe not everybody, but creative people we can call them. I wonder whether they got that chair and I wonder what fabric is for this curtain. And so developers do this all the time. And so start with the product. You almost don't need to promote the tool. Because people are going to ask themselves, alright, I want a product like that. And that's how I still do it. I try to use our products, but I also am always on the lookout for really good things and then reverse engineer how you, how you get there.

Dan Shipper (00:10:25)

There's so much there to talk about. I've definitely found with Every, we have the writing and then we build software products. And a lot of the writing is about building new technology, new businesses.

Guillermo Rauch (00:10:38)

It's a marketing strategy in its own right.

Dan Shipper (00:10:40)

Yeah, honestly, the best marketing for our articles has been building great products because people are like, well, I want to know how they think about it, which has been really, really cool. And the other interesting thing that I think is sort of your ethos and also, I think uniquely valuable right now is like the sort of dog-fooding ethos. We do that too, because I feel like AI sort of changes the landscape where there's now a ton of low-hanging fruit of things to build because like there's a new technology paradigm. And so you can just wave a stick around and just think about like, okay, what are all the things that I want? And probably someone has not built that in a good way yet. Whereas, I don't know, three years ago at the apex of the B2B SaaS wave, all the low-hanging fruit. 

Guillermo Rauch (00:11:20)

Yeah, there was a saturation. And that's what you see when there's a platform shift. AI is a new platform. And when a new platform emerges, it's kind of hard to even estimate how many new applications will emerge. I remember the early days of the iPhone. It wasn't clear to people that it was the new platform. In fact, it launched and there was kind of a hint that there could be apps of your own in that home screen, but it actually took quite a few years for people to be like, yeah, this is the platform. We have to, we have to claim a square in that home-screen grid—not obvious at all. And I think you can think of AI as almost like another new— It's a new home screen. And right now there's a handful of icons on that home screen: there is ChatGPT, you could have Google AI Overviews, Perplexity. And the question you should be asking yourself is like, how many more of those are there going to be in it? And my guess is probably millions. And so very exciting time for especially small teams like yours to be thinking about, what are my pains that AI can answer?

Dan Shipper (00:12:30)

I want to go back to the thing you said earlier about sort of transitioning from— Maybe in the Socket.io days, you have your finger on the pulse and you're the one who's solving your own problem, to thinking about how do I enable an entire organization of people to think that way? So you're more like thinking about the principles underneath that mode of thinking and then trying to infuse that in the culture. Tell me about how that process has been for you personally. Do you like that vs. actually coding a lot or— Tell me about that transition.

Guillermo Rauch (00:13:05)

Yeah, it's awesome. So I believe that there are seasons of a startup's life and in the early days you need to be obsessed with getting a high-quality product out into the world and you live and die by product-market fit. I think at some point you start realizing that you have it and there's other things to build to operationalize that product-market fit to make it into a machine. And I would say like, that's a transition between a startup and a scale-up and think anything when you're a scale-up, whatever that term means, but I guess like a larger, more mature startup, you realize that you no longer live or die by one individual product-market fit. You're probably thinking about becoming a platform or you are a platform and you're thinking about multiple products and so you start becoming more of a machine that outputs products. You're essentially a Y Combinator in the initial like recursive sense. And when you're creating a machine, you still apply a lot of the thinking that you apply when you design products. It's only the company itself that is the product, right? And you're still worried about all the things that you worry about when you want to create excellent products. For example, onboarding: If you're going to be hiring a ton of people, what do you want to have? You want to have an excellent onboarding experience, right? Just like when you first start using a new app. When people join Vercel, they need to be equipped with everything they need to succeed. So you start thinking about other aspects of the company. I think principles are kind of the product specifications of your company. And so thinking about what are our values, what are our ethos, what is our mission, what are the right people to pursue this mission. 

In terms of a recursive product generation machine, I think a lot about what I call recursive founder mode. So there's founder mode: I believe founder mode fundamentally doesn't scale in the sense of, if your aspirations are very large, the total output and creative output of a company can not just be limited to the founder. And so, especially when you started having those ambitions of being a company that can nurture new founders within it. And so I think a lot about what is the DNA that we can incorporate into the company that is almost like the people that would start a company on their own, but they can actually kind of do that within Vercel. And so we select for specific trades. We offer very unique things. So we build a lot of cool open-source technologies. People know us for Next.js, but we also contribute to Svelte, which is a very popular web framework. We acquired it initially, but we support a tool called Turborepo that helps companies to scale huge codebases to the size of Google and Facebook. So people can come to Vercel to fulfill their dreams to reach millions of developers through open-source. And so those are kind of the things I think a lot about how I could find not just the next Socket.io, but how to create the environment that creates Socket.ios and Next.jses and the ecosystems around it.

Dan Shipper (00:16:15)

I think that's really interesting. And the reason I'm kind of keying on that journey from doing it yourself to making the machine that builds the products is it's sort of this journey of moving up layers of abstraction in an organization. And what I want to talk to you about is sort of the future of the developers in an AI world, and I think that there's something similar happening in some aspects of being a developer where, Cora, for example, we have this email product that I demoed for you. And Kieran, who built Cora, he didn't write 80 percent of that code, right? He knows how it works, but 80 to 90 percent of it was written by o1 or Claude. And I think that's a very similar up-leveling journey where the AI is actually typing the stuff and you're thinking about what are the principles and what's the architecture that you want it to write. Talk to me about that.

Guillermo Rauch (00:17:25)

Yeah, one thing that immediately comes to mind is that it does seem like people are becoming full-stack product builders. I don't think I would identify today even as a coder, even though that's what I was obsessed about for years. Since I was like 10 years old, my ego and my identity became tied up with “I code. That's my thing.” And yet I think what I was lucky to have is also that aspiration to build products. And that's what allowed for things like Socket.io to happen because it was like, I just want to make the web more real time and more interactive. It had like a product idea in mind that wasn't just only in the code. I think it's an important asset to have. And when I look at people at Vercel today, I've been noticing that they’re just more full-stack. With v0, for example, they can do design. They can bring context, data, copywriting into their creations that otherwise would have required chatting with other people and crowdsourcing ideas. So, we are going into a world where coding is a specific skill and when things are specific skills, machines tend to take them over time. If your skill when you were a kid was like, I can do math in my head really well, awesome, great asset to have, I love it. But also, there's a specific machine that can do that skill also very well, and even better than you. And so what I try to separate is, what are the meta skills that are not as easily replicated by machines that you should still nurture? And I think those tend to be more around very high-level conceptual thinking. Your engineer who automated the production of that product to an 80 percent degree, he still has a very good understanding of how all the concepts relate. He can prompt the right things to the AI. It's not that he just was like, okay, o6, please build me this thing and then you justin checked out and like went on vacation. So the concept of symbolic systems comes. to mind a lot for me because it transcends language, runtime, framework, coding, and that's extremely important to have how things work and relate to one another. Interestingly enough, it's a skill that VCs kind of nurture a lot. Because I've been in rooms with a lot of venture capitalists that play by ear and you can tell that they play by ear because they have— And by the way, this is a skill in its own right, and it's very impressive. They have extreme, what I would call, “token breath.” I'm using a token in the sense of LLM. They know 30 companies for the space of continuous testing, and they know 50 for LLM pre-training models. And that skill actually is super helpful when you're prompting, because you understand how the concepts relate to one another. You can point the agent to use a specific technology that might be the right solution, but you're not actually doing the coding. And so, I think the biggest step that's going to play out in the ecosystem.

Dan Shipper (00:20:35)

I love the idea of meta skills. And one of those being, okay, how do things fit together? How can I be a little bit more full-stack? How do I think about things from end to end? Another thing that I've been playing around with is like I have this whole idea of us moving from a knowledge economy to an allocation economy where in a knowledge economy, you're compensated based on what you know, and an allocation economy, you're compensated based on how you allocate the resources of intelligence. And that the skills in that economy that are valuable are the skills of human managers today. So, an example which, which I think is kind of interesting, because I think a lot of developers are probably thinking, okay, is it even worth it to be able to code right now? And when you think about being a manager, let's say being a technical manager you always have to— There's, there's this line between, okay, am I going to be in the details and know everything in micromanage or am I going to completely check out and just let them do whatever they want, basically. And both options are bad and you have to be able to know, okay, when is it important to be in the details and when is it important to just delegate? But in order to do that, you kind of have to know the underlying skill. It’s very hard to know that if you're not technical.

Guillermo Rauch (00:21:55)

I love this concept, by the way. The idea that you're allocating resources and delegating to these agents is already happening. One of the things I think is really, really interesting. So, Vercel has two parts, broadly. One is our managed infrastructure. We basically host websites. We deliver them through a global CDN network. We make it so easy for developers to deploy and build, etc. And that has a usage-based model. So for example, we host UnderArmor.com and OpenAI.com. If they have more traffic, Vercel costs more for them, and if they have zero traffic, it costs nothing, which is awesome. On the other hand, we have v0, which is more like a design engineer tool in the sense almost as VS Code or Figma would be, and almost like if they had a child. And those products you typically pay by subscription, not by usage. I think AI is actually disrupting that, and it goes back to that idea of allocation. 

So I'll tell you a concrete example: You have users that are draining AI tokens and running these GPUs super hot, day in and day out. They're like AI-powered engineers. And there's users who use it in a more casual way. They're like, oh, I'm on my phone, I want to create a personal app, I'm going to use v0. And what happens is that, at the end of the day, we're seeing the first category of apps, I think, that are tools that have a consumption billing model attached to them. Because what you're doing is you're not simply using it as a system of records like Salesforce. You're actually setting machines in motion to perform tasks. And I like that metaphor—it's almost like you're doing management in capital allocation. Okay, how much computation am I going to allocate to perform this given task? And you even have to think about risk because it's true that AI is really exciting and capable, but sometimes it's not that capable, so you have to think about, am I going to burn lots of inference time compute? Am I going to set this entire like $500 billion data center on fire to try to solve this task and actually don't know if the AI will perform?

Dan Shipper (00:24:15)

Is this on the customer side or on the—

Guillermo Rauch (00:24:18)

It's on the customer side. So the user of AI will have to think almost as if they were a cloud infrastructure user. I think it's a leap that maybe the closest thing to that in today's sort of product development world would be CI/CD, where a given engineer can say, okay, I'm going to run 100 machines to test my program, but it's a lot less fluid. It's a lot less elastic than this kind of thing where you can sit down and say, okay, five agents, go at it. And in my mind, I'll give you the right result. And so you have to think like a capital allocator and you have to think like a manager of these agents.

Dan Shipper (00:24:58)

What that makes me think of is, in this world, it makes much more sense to pay for tasks to be done and for the price that you pay to reflect. The level of risk that the task will get done well.

Guillermo Rauch (00:25:15)

100 percent, which is like hiring any other human for that matter. I go to Upwork and I'm like, I don't know if this is the person, right? I don't know if this is the agent or this is the task for this agent.

Dan Shipper (00:25:25)

Exactly. And then what that makes me think of is like, well, at that point, if you have a market where different agents can bid from different companies to do any particular task, that's an actually really interesting market percentage.

Guillermo Rauch (00:25:35)

Yeah, 100 percent, because I also think that we're going to see specialization in agents that some will have better context, some will have better taste. Yeah, a lot of that deals with the post-training process. And so there is definitely a marketplace and a competition that happens in who is the right agent for this problem.

Dan Shipper (00:25:53)

Yeah, I want to go back, though, to just you saying, I don't think of myself as a coder. I think that's so interesting and also you serve developers, right? So where do you think that term goes over the next five or ten years?

Guillermo Rauch (00:26:08)

Yeah, you know what's interesting? Coder as a word used to be more popular in my community. And I think even before AI, people were starting to realize that their job was not just to introduce keystrokes into an IDE. There's a history of this. 

One example that I like to give is: Before automatic code formatting tools became popular, people used to care a lot about what their code looked like on the screen. How many columns? Are the words neatly aligned? People would have discussions about this. It was actually considered to be a productivity drain, but it was a huge subject of debate within companies. Now we look back and it's like, of course, people should not be discussing if the aesthetic arrangement of the code is right or not. And so people introduce this tool called the Formatter. I don't know the exact project that popularized the most, but I remember when Go Lang. came out of Google, it came with very simple code for automatic code formatting. And then in our community in JavaScript and TypeScript, Prettier came out. It's called Prettier because it makes your code pretty with no discussion—objectively prettier. And then that whole category of quote unquote problems disappeared. And I would say, look, how your code is formatted that felt appropriate to the word coder. It's just a person that makes their entire purpose to write code, engineer, then product design, which is a role that sort of came out of Facebook, became more important. So the trend has been away from the implementation detail, which is the code and towards the end goal, which is to deliver a great product or a great experience. And it's in that context that our company has become popular because one of the things that we came to market with is: Start focusing more on the front end. Start focusing more on the customer experience, on the site speed. We've demonstrated to companies that you make your website faster and you just sell more things, you make more money. So we started to try to divorce ourselves from the code and put the focus on the experience.

Dan Shipper (00:28:35)

Okay, yeah, that makes sense. Talk to me about how you see v0 fitting into that and just generally where you see v0 sitting in the whole ecosystem of, there's Replit Agent, there's Claude Artifacts. There's Cursor Composer. There's all these different tools. Talk to me about that.

Guillermo Rauch (00:28:52)

Yeah, it's exactly in the context of that idea, right? We look at v0 as code-last rather than code-first. When you come to v0, you prompt with your idea or your intention. You can import a Figma file so it can bring your designs alive. That's for companies that already kind of relate to that mode of working, v0 will make a lot of sense that way. But you can also just come with an idea. Build me this thing. We're about to introduce templates. You can already kind of start with, for example, an AI chatbot: you can use AI to like produce AI products. And so the biggest difference with those is that those start with the code. They look at themselves more like IDEs and we look at this more as a product development environment that merges what you would expect from a design tool because the things that v0 produces, we aim to make them great. It should work great. It should be accessible. It should be mobile-ready. All of the things that I've been trying to teach our customers in a less scalable way by means of customer support, I would say more, or professional services, you could call it, or enterprise agreements, where a big company will come to us and say: Look, you're the experts in building storefronts. Help me have a killer storefront for Nintendo. And a lot of that process is just manual, ultimately. Of course, we had the framework. Next, js tries to set up the right foundation. On top of that right foundation, there is a ton of business logic that needs to live. So the idea of v0 is: Could I partner you with an agent that is an expert in web development, has taste and produces things that we're legitimately proud of, which is hard to do in the AI world because AI has become a little synonymous with, well, you can get a lot of slop from different products. So we're very focused on the outputs that have to be great.

Dan Shipper (00:30:50)

I had Nabeel from Spark on the show last week, and one of the things that he said that I thought was really interesting is when he looks at these sort of agent products, every agent has to make a decision about how long the leashes between the user prompt and when the agent gives a response back. So Copilot is a very short leash, right? Devin is a very, very long leash. Cursor is sort of somewhere in the middle, maybe. How did you think about that? And how do you think about— When I put something into v0, what my experience with it is, it tries to build something immediately and like give me the result. How do you think about that vs. other ways that you can maybe check in halfway through or whatever?

Guillermo Rauch (00:31:40)

Yeah. It very much depends on the task. I believe that the future of AI will be sort of the classification of an estimation of the difficulty of the task and then taking different strategies, but also getting feedback from the real world. So a concrete one is when you give us a prompt, we have to give you feedback right away because you're almost in the taste-making part of the job. It’s like you hired an interior designer and, they're checking for your vibes of, what do you like, let's get deeper into this. But then you have very specific functional requirements. I've sometimes told v0, make this faster and it does. And sometimes actually it's taking me a few prompts. No, make it faster again. It’s amazing how good it is at optimizing React code. So I had a very intensive animation that it rendered. And it was just expensive in how much it was re-computing. So I literally just told it, make it faster. And they told it, make it faster again. And it was all vibes from my side. This is why I was telling you the coder thing is It's interesting. It's strictly less important because I didn't care how, it just made it faster. And so I would expect that for that type of task, we can give v0 a longer leash. And I think there's a precise technical distinction. It, one, feels like more in the one-shot world where you're getting knowledge plus RAG data out of the LLM and the other one is more the feedback loop of thinking that can have an arbitrary length. And that to me is one, the thing that has allowed us to increase the quality of the product. v0 actually fixes a huge amount of error that comes out of the models. He has error correction loops because it looks at feedback behind the scenes. 

Another careful balance that we need to strike is how much do we expose of that process to the end user. You kind of want to learn, but you don't want to be overwhelmed by everything that the agent is trying. As I mentioned earlier, we have a product called AI SDK, which is kind of like the infrastructure underneath v0 and it's open-source and companies can use it to build their own agents and their own products and we have a playground for it and we just added the DeepSeek-R1 model, which people are raving about right now and you can see when you use that model that, you can see every thinking token and it's actually completely overwhelming. It's so overwhelming, and the classic demo that people are doing is they count the number of Rs in a strawberry, and then you see it think through that process and it's overwhelming, it's nauseating, it's almost like peeking into the mind of a mad person. And now extrapolate and bring that into your product. You don't want to emit every thinking token into the user, but you kind of want to give them an overview of why the leash is longer and how the agent is using your time and resources.

Dan Shipper (00:34:40)

One of the things you made me think of in this, in this sort of transition from coder to something else. What word would you use?

Guillermo Rauch (00:34:52)

I like to be a product engineer, product developer. Another role that has emerged a lot is design engineer. I love design engineering because I care a lot about design. And I want to make things work in the real medium. So those are the two roles that are sort of emerging.

Dan Shipper (00:35:05)

Okay, so let's say, from coder to product engineer, design engineer. One of the things that I think that transition reflects is if you have machines that can build things really cheaply in a world where that is really expensive, you care a lot about how all of that works and you want to do that by hand because you want to optimize that really, really well. But in a world where that's really cheap, you go from caring about how it's done to how the end result feels, which is why you kind of want that rapid prototyping loop. And it sort of occurs to me that it's actually also like a really long-running process. I don't code in Assembly or like, I don't do garbage collection, you know?

Guillermo Rauch (00:35:50)

It’s so funny. Garbage collection is such a good example because when people naively try to do memory allocation to make things faster, sometimes they actually underperform garbage collection. It takes a lot of skill and knowledge in a domain specific task to get the right ROI out of manual memory management.

Dan Shipper (00:36:10)

Yeah, and sometimes that's useful, but more often than not, it's not. I mean, 10 years ago, if you used Python or JavaScript, people were like, that's not real programming and I think today probably something similar is happening with some of these underlying technologies like JavaScript or Python languages.

Guillermo Rauch (00:36:30)

I have a lot of thoughts on this. One is, product development AIs need to sit on top of significant infrastructure for them to be useful and productive. They need to be on top of a platform. That's why it makes sense for v0 to sit on top of Vercel and Next.js. Because think of it just from an economics point of view. The AI either, re-emits all of the code necessary to render the thing. Or it says, I'm gonna use Next.js. And I'm gonna render the thing with it. One would take you millions of lines of code of tokens to output if you need to reinvent the framework, the other one might take you 100 lines of code to produce a really good result. And so you have to think about AIs as a collaboration with infrastructure and platforms that already exist, most of which are human-made. Very much like a Waymo self-driving car needs to interoperate with the real world. We couldn't modify the streets and say we're going to build new streets for self-driving. No, we needed to put the cars on top of that infrastructure. 

And so, another thing that your comment made me think of is: It is true that there's certain skills that will yield, for example, better performance or better safety, such as using Rust instead of using JavaScript. Now my question is optimizing something in those languages something that AIs will be able to do in the future? Everything seems to indicate that would be the case because when you use these languages, you're also respecting very well defined rules, like in the case of Rust, the borrow checker, lifetimes, and I think it's going to be the case that AIs can do a lot of that optimization work for us better than a human could do. It's going to take a while to get there, but I'll give you another concrete example. There's a project out of Google called Project Zero that seeks to unveil security vulnerabilities in the entire world—not just Google's products. And it's some of the most cracked security engineers on the planet. And there's a category of bug that they always find that is in C code. There's memory corruption bugs that lead to catastrophic security vulnerabilities. Sometimes it's one line of code that you get wrong. And in our global encryption infrastructure, OpenSSL, such a line of code was found that did a very unsuspecting McPy, one line of code that basically made the entire universe vulnerable to a really, really, really bad vulnerability. 

And now the problem is we know that C is not the right language for that kind of infrastructure. It's just so easy for human beings to sneak in those vulnerabilities, either by mistake or tinfoil hat on, some dark secret agent. It just takes one line to create a massive backdoor. And so the problem that we have is how do we rewrite all of that C code in Rust, and I know that this is a meme of rewriting everything in Rust, or any other memory safe language for that matter. Will AI agents do it? My bet is yes. Will AI agents help us uncover those vulnerabilities? Because Google has maxed out on how many cracked engineers that can sort of read all of this world code and identify those specific bugs. So it's going to be exciting to see that AI will also have a very profound impact on the underlying infra, but it will be a different kind of task, I think.

Dan Shipper (00:40:00)

Another way, I think, to say what you're saying, and you tell me if you think this is right, is for any task where you can quantify whether the task is done well along one direction—

Guillermo Rauch (00:40:10)

Yes. A fitness function.

Dan Shipper (00:40:12)

One well defined fitness function, where the steps are verifiable. That is going to be very easy to automate. And then anything else that's much higher-dimensional, which we usually call taste and sort of this aesthetic thing that's like, this actually just feels good.

Guillermo Rauch (00:40:30)

Yes, and it has social effects.

Dan Shipper (00:40:32)

That's gonna be a little bit more— You just need to figure that out.

Guillermo Rauch (00:40:36)

You need to be the vibes guy above the machine.

Dan Shipper (00:40:42)

Yeah, how do you cultivate that in yourself?

Guillermo Rauch (00:40:50)

A lot of practice. I think I remember one of the best engineers I ever worked with, he was also a very good designer. That's how it kind of became infatuated with the idea of like, we can do more. Common wisdom in Silicon Valley was like, you're either knee-deep in the data center room and writing back in code or you're the designer supe- polished, mustache. You can do both. And this guy TJ kind of taught me that and I remember having a conversation with him and he was like, well, look, I just train my taste a lot. I look at a lot of things. I look at what people like, I seek a lot of feedback. So I do think that you can work on your ability to discern what people are going to like. 

There's obviously some rules underneath, and this is what we're trying to sort of uncover with v0. It does turn out that how you distribute spacing on a page does lead to more pleasant outcomes in the viewer's eyes. And we try to sort of yield those out of the box. But I do think taste can be worked on and sort of the higher dimension, like the metaphor you used of bringing in inspiration from multiple sources and multiple things. Thinking radically outside the box can be super helpful. And then the art of understanding what's possible and what you can sort of start to push the boundaries on. So it's kind of funny, but being terminally online, kind of answers for this, for these two things: one is you want to consume at the stream of consciousness of what good design looks like and what the avant garde is, but you also want to be you at the forefront of what's about to become possible that I can start cooking on now. Kind of goes back to the beginning of the conversation with Socket.io. I became aware that a real-time communication channel API was about to become possible in every single web browser on the planet, and I could start cooking on it before it was real.

Dan Shipper (00:42:45)

Tell me about that now. What's buzzing in your ear right now that's about to become real?

Guillermo Rauch (00:42:55)

Yeah, we kind of touched on it a few times. This idea of domain-specific agents that are infused with taste and tools and knowledge for even tasks that you would think, okay, maybe I could solve that with ChatGPT, but it's a ton of work and maybe the result is not that great. And again, I can infuse a lot of quality into that vertical. This idea of agents that have the long-horizon work, but also can give you rapid feedback when necessary. I think there's a big opportunity there. 

Broadly, I continue to think of AI as this iPhone home screen on top of which we can deliver lots and lots of applications and. I think the idea of ChatGPT for X continues to surprise me. I just heard from a cardiac surgeon that said, I basically spend a lot of time during my professional life using not ChatGPT, but this so-called OpenEvidence, which is infused with all healthcare data used by 250,000 medical professionals in the U.S. And it kind of makes you think. If you're a medical professional, are you going to go to the general purpose A.I. that is sort of like the lowest common denominator for everything? Or are you going to go to the thing that is constantly improving for your domain and field? So encourage entrepreneurs to think about it that way, and also find the opportunities to bring creativity into tools that are otherwise pretty plain. Of course, Copilot could autocomplete code in your IDE. But v0 took that way further, as you mentioned earlier. It’s not just about the little bit of auto-completion, but bringing a lot more ambition and creativity into what the AI agent can do.

Dan Shipper (00:44:35)

Yeah, I think there's all this talk right now, or, it's probably a little bit less so now, but especially like a year ago, where everyone was like, well, incumbents are just gonna win if you have access to AGI distribution is all that matters, and blah, blah, blah, blah. And I don't think that has panned out and I don't think that will continue to pan out because part of what you're saying is, for example, the doctor issue is like, it's not just that maybe o1 or ChatGPT is not tailored for doctors. Iit has to be a general-purpose tool. So it has to say like, I'm not a medical professional, right? And it has to have guards against what it says.

Guillermo Rauch (00:45:15)

It was a principle that every refusal of ChatGPT can be turned into a tool that doesn't have to refuse because it's actually going the extra mile, whether it's with better data, with maybe even human in the loop, whatever it is, every refusal is my opportunity.

Dan Shipper (00:45:35)

Exactly. I love that. And I think another way to say that is startups get to take risks and the intelligence that is available is not necessarily a technical limitation anymore. It's often a risk calculus by a particular kind of company serving a particular kind of user. And big companies have to serve everyone and so they have to take lower risks.

Guillermo Rauch (00:46:00)

And in terms of disruption, there is a very concrete one that I think a lot about. The history of SaaS has been, I start out creating a product that's really good in its category and then I expand its feature set to beat out my competitors in enterprise bakeoffs. And so you become a competition of checklists and there is a precise correlation between product maturity, enterprise maturity, and amount of UI. You can actually quantify the number of buttons, the number of dropdowns, the number of nested dropdowns. And so all of that UI can vanish without a trade-off in functionality, if you're thinking from first AI principles. And that gives the startup a very concrete wedge to attack the incumbent. I'm going to underdo you. I'm going to underwork you. I'm going to under-UI you. And I actually will beat you on functionality. Because if you're solving problems with classical engineering alone, and if-else branches, this is— I love the Karpathy software 1.0 to software 2.0. Software 1.0 is if-else, invert binary tree, and algorithms and data structures. And AI is like, well, maybe that competition ends up happening. But we don't know why. And so we have that agility that comes.

Dan Shipper (00:47:30)

We're searching through the space of possible programs to solve the problem instead of having a recipe.

Guillermo Rauch (00:47:35)

And that's a concrete way of underdoing the competition. Because you're just having the AI produce better or equal outcomes with a lot less manual code.

Dan Shipper (00:47:45)

Yeah. And I think it's also an important thing that I think startups sometimes get wrong in this era, which is trying to do, let's say an email product or any classic productivity software, maybe PowerPoint or something like that. What some products end up doing is doing the classic version plus AI like plus a chatbot or whatever which is exactly what incumbents do too, where I think what you actually want to do is figure out, okay, what's the totally new norm factor, and how do I be worse on all of the checkbox dimensions but so good on the thing that matters that—

Guillermo Rauch (00:48:25)

100 percent. Actually, I would say there are two models that I think a lot about. One is actually you can be better at eventually every checkbox, but in the meantime, you're overwhelmingly better and simpler. I think eventually you do need to do more because companies just want to sit— Another thing I've learned with Vercel and when you go to enterprises and larger companies, they want to buy only a handful of software platforms. This is why Microsoft and Amazon and others are so prolific as they provide broad solution spaces. So eventually you need to get there, but I like your idea of, in the meantime you're just a killer at a specific dimension, you're way simpler, and perhaps you'll never have to have the UI complexity of those incumbents.

Dan Shipper (00:49:10)

How does that sit with you? Because you're just stylistically a minimalist simplicity guy and Vercel kind of has to be a little— If you want to be enterprising, you have to have all the checkboxes or something like that. How are you thinking about that?

Guillermo Rauch (00:49:25)

Yeah. You can think of v0 as almost like the AI-native interface into the Vercel world. And I expect the next billion developers to sort of come in through that door. And then there is the eject button into Vercel. Very much like Vercel did that to AWS— And people still need AWS and we have great integrations and many more coming where we create a bridge to the lower level. I like your concept of you're basically raising the abstraction bar. Very much like we did with manual memory management and Garbage collection. Look, at the very, very bottom, there is the rock solid foundation. There's a bedrock, literally, of hyperscaler clouds like AWS. And then you have the developer infrastructure on top. I believe most of the world would want to interact with developer infrastructure. Because you don't want to go to the raw materials and do alchemy there. 

And the success of ourselves speaks to that, but now there's another level and it's almost like a self-disruption that we're doing with v0, which is like, look, most people are going to want to interact through these agents. They're going to make it more accessible, more design oriented, less infrastructure oriented. And what's nice for us is that you still have the two sorts of levers to pull some more mature organizations, like, look, we're not ready for AI. I've talked to folks in super regulated markets where we're running a lot of their web projects and they were like, please don't say the AI word in my office, literally like during an onsite. And then there are the people that are like, don't say the code. 

Actually, fascinating one of our enterprise customers for v0. It's a company that, without giving away too many details, has been in the cloud space since the cloud was born, literally in the room where the cloud was invented. And they told me our new organization is just a v0 organization. We have it as a rule that we don't do code. They showed me their Slack conversations, it's just them sending v0s back and forth. There's no GitHub. There's no infra, there's no anything, there's just building products going back and forth and having shared channels with their clients, where they also send them v0s. And so they're trying to even innovate in how the company all together works. And so there's people that are going to live in that level of abstraction. Just like there's so many companies that only use Vercel. There's companies that combine both. A lot of enterprises use Vercel. It can connect into AWS through a product called Secure Compute. And they kind of live in two worlds. Most startups live only in the Vercel world. And so it's going to be interesting to see— And perhaps, is there another level of abstraction coming where the result comes to you in a much more sort of objective way, and you're giving less feedback? Yet to be seen.

Dan Shipper (00:52:25)

That's interesting. Yeah, one of the things that sparks for me is I watched, I watched a talk by Eugene Wei that he did at— We ran a conference called Thesis, and he spoke at it, and it was an amazing talk. And he was talking about the different kinds of company cultures and how that affects the kinds of products you can build. And he made a distinction between a written culture and a prototype or demo culture. And in a written culture, which he would say, Amazon is a written culture. I think Stripe is written culture. You're like you're building products that can be expressed cleanly in writing. And what that lends itself to is, if you look at AWS, for example, it has all the specs, all of the logic and rigor is there. But the Amazon phone just feels like shit because it has the specs, but it doesn't feel good, right?

Guillermo Rauch (00:53:20)

I think people don't even appreciate the extent that they're so good at writing correct, highly available, secure infrastructure and what goes into making that sausage.

Dan Shipper (00:53:30)

Exactly. And that's an output of like, being able to have everything written down vs. he makes the example of Apple, where the early iPhone— Apple is a prototype culture. Every time you do something, you go and give a demo to Steve and Steve rips you and then you make it better. And I think v0 and this company, you just, you just mentioned, like it allows us—

Guillermo Rauch (00:53:55)

To live in that Apple world. 100 percent. It's so interesting. I think to each their own. For each role that you play in the ecosystem, you need to lean more towards one or the other. So for example, AWS, not only do they have a written culture, they have an automatic reasoning team that writes TLA+ proofs of correctness of all their cryptography and durability. I can trust them with my clinical records. I can trust them with anything. And I know that those people have written mathematical proofs of the certainty of that code and the distributed system that supports it. And then on the other hand, you need tasks that are so creative that you imagine writing a mathematical proof before you sit down to cook on a product. 

And so what I like about Vercel is that I think we've blended both. We have so much respect for that work that— Sometimes a lot of people ask me like, do you want to build your own data center? I said do you even realize what it goes into getting to that level of quality? My job is to procure the best possible components, just like the iPhone bundles a lot of incredible hardware that you don't know about, but you know that it's the best at doing that task. And then I want to enable you to live in that world of vibes almost, right? Prototyping, creativity, velocity, performance, etc.

Dan Shipper (00:55:15)

Yeah, that's great. I think that's a good place to leave it. This is an incredible conversation. Thanks so much for doing it. I would love to have you back. 

Guillermo Rauch (00:55:20)

Thank you. That was fun. Will do.

Thanks to Scott Nover for editorial support.

Dan Shipper is the cofounder and CEO of Every, where he writes the Chain of Thought column and hosts the podcast AI & I. You can follow him on X at @danshipper and on LinkedIn, and Every on X at @every and on LinkedIn.

We also build AI tools for readers like you. Automate repeat writing with Spiral. Organize files automatically with Sparkle. Write something great with Lex.