We solved the blank canvas problem | Tom Occhino from Vercel

0:02 Hey everybody. I'm Nancy Wang. I'm the chief technology officer at 1Password. Welcome to Zero Shot Learning, which is a podcast about the reality of developing with AI from the people actually doing the work. I host today's show and this show series alongside Dave Teare, who's a senior director and head of engineering for Google Gemini Enterprise and business. Today's episode begins with a question about platform shifts. Tom Occhino helped shape one of the biggest shifts of the team behind React at Facebook. And now as a chief product officer at Vercel, he's helping define how software is being built with AI.

0:39 The move to component-based interfaces with React really changed how developers structured software. But the shift to AI-generated software really changes something even deeper. Who gets to build, how fast they can build, and what the job of building even looks like in this age. In today's conversation with Tom, we explore what lies beneath that shift. The tooling, the latency, observability, secured guardrails, and what it takes to make those systems actually usable in production. Then we get to see it. Tom is going to show us exactly what looks like with a real demo of V0 building a real app in real time.

1:18 This is going to be a great conversation about how software is changing, but also what stays the same. Taste, judgment, ownership, and really the ability to turn an idea into something that people can actually use. So, lock in. This is Zero Shot Learning. Tom, thanks for joining us in our studio today. >> Thank you, Tom. It's great to have you here. You've been pushing the edge of front end and AI and developer productivity in general for several years. So, Tom, you know, looking back at back at sort of the Facebook vintage or Facebook era, uh specifically the shift from MVC to component-based architectures with React, does the current shift to like AI-driven interfaces feel more similar or does it feel like super disruptive?

2:15 >> This is fundamentally different. You know, it's worth it to provide some context about the shift I think that we went through from MVC to React in this like single directional data flow and this kind of component-based view architecture. Um but it was it was fairly incremental. I think basically what was happening at the time is as we were building these sophisticated apps that had data backing them, the data changes, right? So, either the user does something that changes the data or change comes from the back end. And then we had to manually do some things to like update our views so that the user could see the latest version, so that the models all stay in sync with our data.

2:59 And in this case we're talking about models from the MVC era, right? Um and it was just a manual error-prone process and I think software was kind of littered with bugs. The biggest thing that happened for us was that our software was just hard to maintain because you have lots of different things that can change the data and then you have lots of different ways of updating your views. Um and so as our teams got bigger, as our code bases got bigger, things got hard.

3:21 React comes along and says, "Hey, don't think about most of that. You know, like here's what you should think about. You've got some data, how do you render all your views, right?" And it's just a liberating experience. You're like, "Okay, I can just think about this this way." And then the system will intelligently and efficiently update my user experience. Um that's awesome. It turns out that like agents like to do things that way as well, right? So, overwhelmingly React is the sort of framework of choice for LLMs. And I think one of the reasons is because the code that you get to author doesn't have to consider a lot of these weird intermediate states and imperative manual updating of views and things like that. So, I think, you know, React is really well suited for this new world. But, the shift between, you know, me authoring all of this out for myself and then LLM's outputting that stuff is just a fundamentally different approach to software. Um I you know, there's a lot of similarities in the sense that you still have to think really clearly about requirements and outcomes that you're hoping to achieve.

4:27 You have to have opinions, and you have to have taste, and you have to be able to make decisions. Um but, in terms of the actual implementation, that ends up being dramatically easier now. I mean, the LLM can output really, really high-quality code. Um and so, you know, we'll use V0 later. We'll use it with with Max. Uh V0 Max, which uses Opus under the hood. And and you'll see like the quality of the code that it can output is really, really amazing. So, the the way that you spend your time now shifts a little bit, I think. And uh you know, certainly a lot more people can become empowered to build.

5:03 >> Well, speaking about empowered to build, right? I'm going to quote you on something you said, Tom, which is um the the prototype is a new PRD, right? And so, obviously, this brings back flashbacks because, you know, coming from AWS, right? We were taught to to write six-pagers, right? With with dependencies, which really didn't really make it six-pagers, but you get the drift. And so, when that becomes the new norm, right? How do you think teams should think about shipping product when everyone, to your point, now has the ability to prototype? Right?

5:35 >> Yeah, and maybe in many cases go beyond prototype. But, you know, I think that the the idea that you would have a a two-step process that is like this offline step where I first generate a PRD, and then I maybe collect feedback and iterate on it. And then I take that and I send that over to the engineering team. You know, this can be a much tighter loop now. I can be generating a PRD with the agent that is about to build my app. So, sometimes in V0, what I'll say is, "Hey, like let's just plan out what we want to do here. Let's put together like here's all of my thoughts, fill in some blanks, you know, and you can kind of fill in a bunch of content."

6:12 And then you have this like intermediate PRD, but no one really needs to see it because what people really want to see is the actual product. And so, if you can kind of then build that, it becomes a much more effective way to communicate. And certainly you still want to document edge cases, how to handle this situation and that, and you want all of that to be codified. Um but one of the things we found is that V0 has actually become a communication tool as much as anything else because you can now communicate your ideas much, much more clearly um because people can play with the thing that you want to build or or inspect it or try things out. Um so, you know, I think it's going to change the way that people think about building things. You no you no longer need to have really fundamentally separate functions that do the clear thinking and writing and then separate team that goes and does the building. You can have kind of one team or one person that can do the whole thing end to end. So, I think that's going to be really, really powerful, but um I also think that like, you know, there's a question about ownership and like who's responsible now, who's accountable for things.

7:16 I think in this new world ownership is going to be as important as ever. You have to have somebody who has permission to make the changes and and knows uh you know, has has taste, has um customer context and feedback and they know what they want to change. And so, you know, not just anybody can go in and make that app that was created by somebody else better. Sure, you can fix bugs and things, but to know strategically how you want it to behave, I think somebody can think much more deeply and um, you know, execute on anything, the creation of of new capabilities, um, much more quickly. So, you know, I think I I love that Vercel is building lots of the tools that you need in order to embrace this future.

7:56 >> Are you already seeing that shift happen in the industry for real, Tom? In the sense that like, I once in a while will get a fully running app from a product counterpart I work with. And it it's, you know, a lot of it is mocked up, but that kind of makes sense. You interact with it, you give some feedback. Essentially, the user journey is now super interactive. And I don't have to like really spend time visualizing and documenting out CUJs. Now, it's it's there for you to see and, you know, your products obviously helping that. So.

8:30 >> Yeah, we're we're absolutely seeing it play out. I I like to talk about the kind of evolution a little bit of V0 itself because we didn't get to that state right away, right? We we've been building up to it. And actually, the name V0 comes from this idea that we assumed this would be a tool that that helped with the blank canvas problem, right? Or it's just like, you know what, just give me my initial thing and then I'll take it from here.

8:53 And so, initially, what you would build with V0 is like, it's just a skeleton. It's just a UI and then I'll go do the real software engineering. And then with the next version of V0, that became much more conversational, it's like, oh my gosh, like this is starting to build real kind of like front-end apps. And still, I a bunch of engineering work to do behind the scenes. Um, but like, it's it's a real app. And then now, we're moving in the world of like, this is building like full-stack production.

9:19 Like, I deployed something over the weekend that I'm using now every day. It's a real app with a real database and real auth and a real blob storage and and like, all of this stuff was just configured and managed for me from V0. So, so we've had this kind of evolution. It didn't start with the ability to do what you said, which is like capture multiple customer user journeys or critical user journeys and all these things, but now it it really does.

9:44 So, the thing that has been fascinating as we've watched this evolution of the tool and it's gotten more and more capable is that the profile of people who can use it and get value out of it is just widening. It's it's becoming incredible. Like it used to be a tool for developers that saved me time. And then it was a tool for developers to save me time, but some other people could build some simple stuff and they didn't necessarily have to be as technical. And it's moving in the direction of like, wow, like many, many more people can get real value out of this. So, I can give you some examples of places where we see software crop up that we used to maybe see a presentation or a spreadsheet or a or a what have you, right? Um I I love that some of our account executives at Vercel will use V0 to present to customers instead of a spreadsheet that talks about total cost of ownership or your economic impact of using Vercel.

10:35 They'll be like, "Hey, I created an app for you. A one-of-a-kind app just for this meeting that will probably never get used again, but I created an app that allows us to interactively explore things." Like when was the last time an account executive had an engineer on hand to build an app that helps with a meeting? Like there's just no way. Your engineering resources are far too critical. >> But yeah, that makes a lot of sense.

10:57 Uh switching gears a little bit into more of let's call it the the technical deep dive section here, Tom. >> Okay, sure. >> So, um specifically I want to double click a little bit into latency and and then like get to what the edge is really. Uh so, coming from like Anthropic and Gemini world TTFT is the make make or break, right? Time to first token is really the make or break metric in terms of your experience with an LLM in addition to obviously uh hallucinations and such. So, how did your how did you design the SDK to optimize for TTFT across different models and different run times that you're already compatible with and more and more coming both in the in the closed source code unquote and the open source.

11:39 >> One of the things that I I think we we've optimized for for a very long time is you know delivery to you end users and we know that the closer you can be to the user with the majority of what you need to send them the faster it will get there. But then there's this really interesting thing that happens where like if you get to the user really quickly but then you need to go to the origin to get data or to get you know tokens or to get whatever you need to get. You've just moved the latency. It used to be directly from the user to the origin now it's from the user to the edge is real fast but then the edge needs to go to the origin so um what we've done is we've tried to architect a system that um prioritizes getting as many things to the edge as as it can but then you know creating this very fast link between the edge and the origin and and making sure that that's a very you know uh uh very wide highway uh for communication and things like that.

12:33 >> So I have to ask right as you know we are a security company I have to say that your AI SDK makes it just ridiculously easy for agents to call tools and so you know putting on a kind of my security hat and for the CISO's listening to this right how do you make sure that you know these agents don't get exploited right or what guardrails are you all thinking about kind of putting in place or out of the box?

12:57 >> Yeah I mean like you know under no circumstances are we like encouraging uh code execution on the client. Um of course it happens during development you're doing some of this stuff but you know the reason we created for sale sandboxes because we need that untrusted uh code execution environment that does not have access to production secrets that does not have access to production configuration etc. Um but there's a there's a really rich question of the security of agents here and and we're doing a bunch of things.

13:24 Um you know one thing recently hardening of markdown rendering to prevent uh data exfiltration. We had a an actually a blog post about this called building secure AI agents, which I encourage you to take a look at. So, ton of work going on there. And then the other thing is like, you know, we created the sandbox environment, which is great cuz you can run untrusted code without worrying about it accessing production secrets, etc. But there's outgoing requests that come from that sandbox. And so, we need to have this you know, we need to be thinking about the way that agents do things from the sandbox. Who are they allowed to talk to and what capacity, etc. So, open area of like research and development for us, but obviously something that that I think all of us need to take very, very seriously because especially as you open up access to these tools to so many more people who don't have the security fundamentals from their prior career or from the first, you know, 15, 20 years of their career, we need to be creating systems that are sort of like secure by default and safe by default.

14:22 >> Awesome. Well, it's almost like you read my mind because one thing, you know, I've been also promoting internally is you got to make the paved path the easy path, right? Because if security gets really hard, then that's where it risks becoming an afterthought. >> Exactly right. >> Um just thinking through it, is the goal for the SDK to become the OS for the for the agentic world? >> So, we started building V 0 and it's a front-end cloud app, but we we needed more stuff. We're like, okay, this is necessary but insufficient set of things. What else do we need?

14:53 We needed the AI SDK because we were constantly swapping out the models in our app because new ones are released all the time and we needed to stop changing our product code. We needed the AI gateway because as more and more teams are using AI, they're all managing their own keys. We have no visibility into what spend is going where. It was crazy. We needed things like sandboxes like we I mentioned earlier for untrusted code execution. We needed a primitive called workflows because agents do this very you you workflow-like, this very uh kind of wait for something and then do something and then So, we needed to build all this new stuff.

15:27 And so, the AI SDK became one more piece of this puzzle for us. We call the collection of these things the AI cloud and and that's why I say like sure, Vercel could be the operating system of agents because it's composed of everything that the agent needs in order to deploy the the software of the future. Develop and deploy and secure and observe the software of the future. >> Makes a lot of sense and and thank you for the framing, Tom. I think it ties together a lot of the building blocks in place.

15:56 >> Yeah, for sure. So, this goes back to I think Tom, you know, when we talked about, you know, generative uh UI, right? Uh cuz I think you're maybe on the fence about the word probabilistic, right? So, putting on my engineering hat for a moment, um you know, how do you think about sort of this world of generative UI, right? Where the output's not always the same based on what your input is, right? And so, from an long-termness, um how do we avoid sort of the trap of creating tech debt, right? Especially when, you know, core UI components are now being generated with AI and to your point, right? More and more um front ends will be created that way.

16:39 >> When we coined this term GenUI, where um an agent's uh >> Oh, I like that. GenUI. >> GenUI. Um a model is going to be outputting UI for you, right? And that UI, you know, in in theory, you've you could have never seen anything like it. The first versions of this, and I think even before AI, the way to think about this is that based on something from the user, I need to generate a user interface that I didn't necessarily anticipate exactly that one.

17:09 If you think about Google Search or you think about Facebook News Feed, there's just an infinite number of blocks that can show up in that top box. It seems infinite. It's actually not. It's just a lot of them. There's thousands of them. There's a thousand different types of of newsfeed stories. And so, what we did was we made it so that you could dynamically import code based on what the user asked for. So, I need to show a video story, so I'll download the code for a video, and then I can display this video story.

17:41 And for Google search, I'd I'd search for some calculation, and it would show me a calculator. It's amazing. It didn't download all of the code for all of the different types of things you could generate up front. It downloaded them as needed. So, the first version of GenUI with V0, I think what we were assuming was going to happen here is, well, when I have a chatbot interface, now instead of just asking for text, I can show you rich UI.

18:08 And that UI had to be developed, right? So, it was like, oh, this is like a date picker. This is a map. This is a something. But, the the LLM could invoke that and render this gener- GenUI thing. But, then you know what happened next. It was like, well, it's not just these deterministic list of stuff, this deterministic list of components. It's kind of anything. And now we can generate whole UIs on the fly that have never been seen before. Um and they're made of primitives, and those are things that are composed together. Those components are composed together, usually with React. Um and and what happens now is is you can output uh UIs that are truly bespoke.

18:48 And so, in that world, you know, is this going to be mean that like every time I open an app, um I get a different UI? I think that would be like a pretty frustrating user experience. So, there's a lot of people that say, um what do you think it's going to be like when blah blah blah? And like, you know, I've had a bunch of mentors that have said, don't try to predict the future, just build it. So, here's what I think.

19:11 I think it should be fairly probabilistic while you're in development, while you're trying to learn is this the right approach or is that the right Should I Should I put this here and this on the right or should I flip them? Should I I think during creation of something, while I'm building, while I'm developing, I actually want lots of options. I want to refine and iterate and I think it's really good that the LLMs don't output the same thing every time because it would stifle creativity.

19:37 So during development, while I'm building, that's great. Then when we get to the actual final user experience, I think you want the like perception of this kind of like really highly dynamic UI that can really mold to the user need, but you don't want the user to have to learn how to use the app every time they open it. So you you do want familiarity and you want common patterns and you want all these other things that, you know, kind of constrain the solution space.

20:06 And now I'll go sort of towards the like where we headed. I don't know, once LLMs are outputting 50,000 tokens a second and UIs can be generated so much more quickly, will it be like novel to want to see like a personalized version of the UI? In that world, I actually don't think it's probabilistic anymore. I think it's much more deterministic, but it's much more personalized. Right? So so I I I kind of, you know, move past probabilistic and I I and I move towards like either personalized or I think it can still be just highly dynamic, but um I think we want to know what the LLMs are outputting and I think if we have users and and customers, we want kind of a predictable experience for them. Um can you imagine the support tickets that come through and you've just never seen the UI before, right?

20:56 >> To limit free in this space is going to be huge. Well, I think it's something that you you all are working on in UA, but with every dynamically rendered UI, you're going to have quirks, you're going to have a lot of personalization, every single rendering even cuz, you know, a P context or personalized context evolves over time. And then, it's going to be insane to reproduce any moment. Uh which means like you probably are going to ship like native screen capture tools, native recording tools, which usually come with most Chromium-based browsers, let's say. In any case, uh but how do you stream that back and how do you interpret it?

21:35 To sort of reproduce this, it's going to be fun. So, as we move towards the the demo section of this podcast, I'm curious, do you see like uh the role of the front-end engineer evolving more into a system architect or like a general enterprise architect who's orchestrating your V0 uh or simply writing the prompts instead of like, you know, configuring the CSS or putting the fine fine-tuning touches on things? >> Yeah, I think a really interesting thing happened. In the early days of computer science, every software engineer did it all, right? Like you just you're building the thing, and so I got to build the how am I doing data storage and then my algorithms and how am I fetching and retrieving and then what's my UI look like? I'll sprinkle a little that in there.

22:21 And over time, what happened is we had to develop specializations because it was much more effective to push the state of the art forward. So, we became very, very good at one discipline or the other. And the most crude sort of like uh most coarse-grained breakdown, you could say we had front end and back end. In reality, we have dramatically more than that. Design engineering, CSS-only front end, you know, you have these these folks that are very, very specialized. You have back-end engineers that specialize in APIs or really efficient algorithmic data access or then you have even lower-level systems-level engineers, etc. But, we had all of this specialization that happened because human beings can only have so much context in their head about how things need to be implemented, how they need to be built. So, you started out in a world where everybody is kind of a generalist but the software is pretty low quality and pretty rudimentary.

23:11 You accelerate towards a world where you have dramatic specialization, extreme diversity of skill set. And now I think we're moving into a world where basically everybody is about to be a generalist again. In a world where the models can output best-in-class backends and best-in-class frontends, I think it's going to be really about where you want to spend your energy, where you want to think and focus and iterate. But the default that you used to get, the default UI you used to get from a backend engineer used to be pretty bad.

23:43 The default UI you're going to get from a backend engineer going forward is going to be really good. And you can certainly go forward, you can go further than that if you have a passion for the frontend. But I think everybody is going to need to be able to communicate extremely clearly, which requires thinking extremely clearly, which probably requires writing cuz writing is thinking. Um and they're going to need to be able to to to deeply understand the how the system is is um or how the product is supposed to behave, like what they want out of the the product. So, I think that you're going to take frontend folks and make them more full stack.

24:20 You're going to take backend folks and going to make them more full stack. And everybody who has agency and passion is going to be able to create really high quality stuff. So, it'll be a really interesting shift to watch. The thing that happened with this frontend cloud thing was we we kind of almost inadvertently created what I would describe as self-driving infrastructure because the frontend engineers didn't really want to think as much about efficient infrastructure architecture and deployment. That was kind of taken care of for us by the system. But now, the infrastructure can kind of improve itself, that's why we call it self-driving infrastructure. I think the same thing can now happen on the frontend It's like, I used to specialize in how to do the exact CSS needed uh for that exact layout of that button and the behavior and the the And now I don't need to spend as much time like I can I can I can spend I can spend my time where I choose to rather than feeling like I have to go and and refine this and that. So, I think we're going to have this you know, the the the evolution for self-driving infrastructure could be like self-driving front-end development where I can just tell it where to go and what I need and it's actually quite high quality.

25:28 >> Right. >> We don't have a term for that yet, but I think that's we're moving in the direction of everybody being able to become much more full stack. >> Makes a lot of sense. Maybe I'll give you a term that I'm thinking of which is the front-end Pareto. Where you reach the 95th percentile of what you want in terms of like your end-to-end experience really, really fast. You decouple the infrastructure pieces and make them self-improving and like not a concern of the front-end engineers anymore. And then for the last 5% you give awesome tools uh via your SDKs and such. So, that that way like you hit the the front-end Pareto in like, I don't know, a tenth of the time that you would normally.

26:07 >> I like it. I'm looking forward to reading the blog post. >> That's a beauty. >> Yeah, it's really, really >> All right, do we want to jump to the speed of thought demo? I think it's going to be exciting. >> Yeah, I'm like I'm I'm ready to jump in and build some stuff. This this is V0, everyone. This is my uh personal V0 account. Um and I'll use that cuz you know, whatever we generate here, I I hope that it will need a a database, but um I recently was talking to somebody who worked in finance and they were used to using a Bloomberg terminal and they're like, "Man, I wish we could just like I wish I could just have my version of this that had only the things that I care about and kind of got rid of some of this UI and all this other stuff."

26:47 And I was like, "Well, let's like just start iterating on a finance terminal." Um I created a prompt here. if you don't mind me using a a pre-canned prompt that we're going to read through. Um, we'll read through it while it starts cooking. But, one of the things I want to make clear is um a database for storing all the um stocks and values. I really want to connect to an integration here. Um, okay, so let me let me just walk you through what we're going to build. This is a This is a high-end portfolio tracking web app for a professional financial analyst. Um, we want it to feel like a real internal tool. So, this was the analyst telling me they're like, "Yeah, like it needs to be professional."

27:33 Um, and you know some some features here we need and and some other things. Um, the first thing it realizes like I asked it I I wanted to use a database cuz I think this is going to be a real production app. It's asking me if I want to install Superbase here. Um, I've got some options, but I'm going to install and it's going to take me this is I I just love going through this flow because um right inside of the Vercel marketplace, um this is all ready to go. Uh, I click one button.

28:03 I'm going to give it a name. I'll use the default. And then I'm going to be back in the V0 and and and building. And so, what's really cool here is like a database is being provisioned on the back end. Not a Vercel database, a Superbase database in this case. Um, and it's I didn't have to like go and create an account or do anything. It did it for me. And now I'm back in V0. I didn't even close the tab. And I can tell it to continue building and it's got what it needs to keep going.

28:32 Um it definitely like, you know, this it's got a design brief. It's setting up a code base. Um, and it's going to create a a sort of like list of all the things it needs to do. But, just this like seamless integration I think is really powerful cuz there's just tons of things that you need when you're building an app that, you know, you you kind of take for granted. Um but yeah, I told it it's connected. It's going to keep going.

28:55 It's creating some SQL tables. And what's looking at our project plan? >> It is super awesome, Tom, cuz uh it takes me back to one of your earlier observations, which is integration need to be seamless, and you let the database experts deal with their stuff. Uh you just want to give a control plane um to to interface with that very, very natively. I think that that's an amazing >> Yeah, the thing that I love about using tools like Vercel is like, you know, we talk about self-driving infrastructure for after I deploy my app, but this is kind of self-driving front-end development. Where I And look, I was pretty detailed. Like I actually expressed exactly what I wanted. This is, you know, it's not a full PRD, but there's a lot of requirements here, and it's got some um some details. And And I need it to be pretty specific about it because there's a lot There's a lot to do here. There's a lot to build.

29:44 >> So, seeing like the you know, Vercel come up with like the the baseline so quickly was was amazing. Um going back to I think the observability comment, right, that you made and and potentially hinting at, you know, future product features. Um like for engineering teams like debugging this, right, in real time. Like uh I guess what tools should they use? Like how should they do that as, you know, Vercel's generating um these new baselines? >> Yeah, I mean, you know, certainly like once you're in production, I think there's just a bunch of best-in-class like observability tools that allow you to um you know, sort of see what's happening in production. I think I you know, I'm using Vercel here to observe what what Vercel is doing, but um yeah, you know, Vercel has a has a great observability suite if you're deploying to Vercel, but um I think the beauty of this is like you can tell the agents what observability tools you want to use, and they can build those integrations for you. And so, you know, if you're familiar with one if you're not familiar with any, you can have it recommend one. It's like this one seems really popular based on XYZ. You can ask the agents to teach you how to use it.

30:52 Um, so, you know, I think observability and to our points earlier about telemetry, I think those things are going to be increasingly important over time. Um, but yeah, you can kind of like cook up whatever whatever you need. You can ask questions and and explore it. >> Wow, it's amazing. The other thing I really love, and this is probably cutting over into Nancy's role, is uh human in the loop feedback. Cuz now you can interject, you can guide it however you want to do. It waits for like some, you know, is this the right thing I've done once in a while. I I really like it cuz it's the only realistic path to abuse mitigation at this point. Otherwise, you could have like bots just going and keep doing their thing without any human oversight whatsoever. So, it's like it's just the right amount of human in in the loop feedback.

31:44 >> Yeah, and I think we'll want human in the loop for a long time. I mean, there are certain things that I'll be developing where I'm just like, you know, no, this is like in my own thing. It's a personal thing. It's small. It's Um, but I think, you know, for any production system, I think it can be really, really critical that, you know, everything has not as an afterthought, but like really part of the core flow.

32:05 Like, where do I decide? And and the best thing that the agents can do is provide us with as much context as possible to be able to make the right decisions. I've got some some scripts to run here to generate our database. So, I'm going to just run that and let it keep going. Um, I can't believe we're done already. We used uh we used max here. So, this was a this is a big one, but let's uh let's you guys are okay with taking a look at our app?

32:29 >> Let's do it. Yeah. Cool. >> So, this is our financial portfolio tracker. Um, I I don't know what features we have, but let's let's look. Okay, we have a watch list. Um I can add something to the watch list. Do I already have Apple? Uh okay. Okay, company name. It should just probably fetch that. I would add that in hindsight. Oh, it added it. >> Perfect. >> And critically, this is all stored in a database.

32:57 Um and so we're going to take a look at that in a second here. We're doing we're doing a very live demo. But I want to kind of show you how this is a real production app that can be deployed. So, I'm going to go click manage on our database. Um I'm going to click configure. And then it'll take me into the Vercel dashboard. Um but what's really cool is like let's say that I'm building an internal app. We're talking about doing this as an internal tool earlier. Um when I build this, the biggest thing that needs to happen is I'm building for my personal account, but visibility and access to the this thing is really really important. So, if I'm building an internal tool and I was building it for my company team, um I need to make sure that only my employees at my company, only my colleagues can see it. And so this kind of locks it down by default.

33:41 Um but yeah, I don't know. What should we look at in our app that we made? >> Maybe we try adding like a widget or two to to this. Uh yeah, let's say we do like a a trend line of analyst forecast to stock price for the last 6 months. >> Actually, that reminds me, Dave. You used to work at Robinhood. >> I did work at Robinhood, and I worked at Bloomberg. Well, this this gives me a lot of memories on using Bloomberg.

34:12 Where I it was a skill, you know, like 2010s or 2010 precisely, it was a skill to operate the short keys on a Bloomberg terminal to basically build a view like this. And now I'm like I can give a handful of prompts and and just render it. Um thank god I went deeper into software engineering. Uh >> Um, but let's let me see if I can get this right. So, do you want to say it again? I'll actually use uh >> Hey, so let's do a a widget that plots the the trend line of analyst consensus stock prices versus actuals for the last 6 months.

35:02 From whatever list you have of stocks. >> Let's see. Let's see, yeah. >> I think it's going to work. I think I think you have all the information for this in your database. >> Yeah, I'm I'm surprised it's live updating in real time. I don't think I asked for that. Uh, I don't need my console here anymore. But yeah, it's working. We can kind of still play with it. Um, one of the things I I also want to show is like this design mode is is really cool where you can go in and make changes to the design of the the whole thing in a very visual way.

35:35 >> I love the interactive um, sort of, you know, the thinking mode, but it's it's not overly verbose. Cuz the moment you start thinking all the thoughts the model has back to the user, it's way too much. >> Yes, it's doing a ton behind the scenes. I you know, I think we could introduce like a verbose mode for anybody who's really curious about what's happening, but there's a lot happening behind the scenes that we just see as analyst consensus chart.

36:01 >> I mean, a technique I've seen is instead of the steps you see there, which is read a base structure, read market data, read types, etc. You click through that and then you enter the verbose mode. >> Yeah, yeah, absolutely. And you know, I think when it's doing these like reads and it's telling you what it's reading, that's not as interesting as what's happening behind the scenes here. Uh, but okay, we've got >> Yay. I mean, this is an incredible.

36:29 >> Quite a good UI, too. So, this is all over the place. This is just >> Just like pick the holding and then you got it. Those are either missed opportunities or dodged bullets, however you >> Yes. >> depending on the direction. >> Yeah, this is actually a really cool chart. And it seems like it understood the assignment, too, because um this is what this analysis looks like, right? >> Mhm. Yeah, exactly. Yeah, yeah. You if you're growing with the the trend, you want the two lines to be somewhat similar.

37:00 >> Amazing. >> Wow. This is super cool. I mean, I I guess it put puts uh, you know, more emphasis on uh, live demos, right? Um and going back to the verbose mode, I I think like it could be helpful for a developer to understand like why a certain UI path was taken. >> Yeah. Oh, yeah. That's That's for sure. >> Yeah, absolutely. I mean, one of my favorite things to do here is to ask questions about why it did something a certain way.

37:26 Um and actually like, I you know, I have this example of a a kind of I I'll stop sharing screen right now if that's if that's all right. Um I was building this like very, very simple uh, and it's just for counting things. So, you'd type in a thing and it would create a button and then every time you hit the button it would count up. I needed this to count light switches, but I have since used it when people are giving presentations to when they have repetitive words, I'll type the word and then I'll say you said it this many times. So, anyway, very simple app. I I'm the only one who uses it. Um but what was really interesting about this app is on mobile at the time, on mobile web, you can't do haptic feedback, but I needed some way to know that the click registered without me looking at at it.

38:10 So, I wanted to add sound. So, I asked V Zero to add sound every time a button was clicked. And like, I could have looked this up. Like, I could I I know I've done this before. I've added sound when a button is clicked. But it was so cool because it did it in a way that taught me how to synthesize sounds in the browser by creating a synthesizer. So I'm like reading through the code that it that it wrote. And I was like, "Oh my gosh, this is so great." So I like copy-pasted that code into another existing app that I had because I just wanted it to make sounds when the buttons were clicked.

38:41 And so like I learned how to do this whole thing. So So asking it how it did something, why it chose some to do something a certain way, I think this is like a really powerful new way of doing things. >> You know, we could certainly go for for much, much longer, but uh I did want to um kind of you know, end this episode on a uh prediction question, of course. And And Dev has a a fun question for you. So given just the speed of iteration, right? What part of the AI stack do you think is going to become obsolete in the next, let's call it 18 months?

39:12 >> What part of the AI stack? >> And And get replaced with Vercel, really, is a subtext. Is going to get replaced with Vercel. >> I think there's a ton of things that people don't genuinely enjoy about their jobs. And I hope that Vercel replaces all of the things that people hate about their jobs. I mean, I used to hate diagnosing an incident. Right? Trying to figure out root cause an incident. Something happens, there's a spike in errors, there's there's something.

39:43 And so well, what did we build? We built agentic investigations of anomalies. So what is an anomaly? Anytime a chart spikes uh in either direction and something looks off, it triggers an alert and we tell you about that alert. So you can right in Slack, I get an alert that says, "Hey, this looks there's a rise in 404 errors here." Or um there's a there's a ton of blocked requests coming over here. And so you there's a spike.

40:10 And immediately, an agent goes and investigates it and tells me exactly what happened. Like like way better than I could have done. Um our CTO used to really enjoy doing these investigations, but he just didn't have time. I used to hate doing these investigations. And so I love that. Um anything that is the worst part of your job, I think we we want software to replace that so we get to focus on the fun part, the better part. I like creating things and building things. I don't want to necessarily go um spelunking. Uh you know, I think code reviews another one where um I I don't mind doing code review. I'm not that good at it, you know? So this is another place where anything you have where humans aren't as good as agents can be.

40:56 That's another area that's ripe for us to sort of move aside and say like I'm going to go focus on the things I'm good at that I enjoy doing rather than these other things. But I'm curious about your predictions. Like what do you think uh is going to be replaced? >> Wow, well let's see. Replaced by Vercel. I mean, just seeing like the uh example that you pulled up with Vercel. I mean, prototyping tools out there I I'd be I'd be concerned, right? And look, if you build in, you know, from engineering hat like a rich enough ecosystem of, let's say, telemetry, observability, debugging, right? You already have the sandbox. Like that gets pretty pretty flushed out. So that's that's what I think.

41:38 What about you, Dave? >> Yeah, I think I have I have a maybe like a slightly spicy take on this. Um I have the inversion of like what Tom said, which is I think the the way developers will access agents will be through interfaces and not through agents themselves. So the imperative style of programming that we're using today to build agents will actually flip and the interfaces would be something like a Vercel where I'm building the application directly and not bothering what agent to build.

42:10 That piece will just be done by a combination of like the SDKs we have today and the models getting more and more sort of intelligent over time. So, my my my spicy take on that or like my hot take there is an inversion in in the in the model that that we have with the Agent DK I today. All right, so one last question, Tom. You're builder, you know, you've always had this itch that, you know, it's probably a itch that you haven't scratched yet, right? So, if you weren't in your current role and you had a free month, what would you build just for fun?

42:47 >> You know, I actually started building it. Um I my wife and I use uh used to use a like a text document to track like all of our favorite things, like all of the best things we have. Um and it started out with the best foods because one time I I think I had like a dessert that was like really good. I had to write it down. Um and so I I started building an app.

43:09 Actually, I did this over the holidays. It was me plus V0 plus my buddy Claude for uh Opus 4.5. Um and I it was just awesome. Like I could turn this into a whole thing. It's completely over-engineered now. Like it's got the most sophisticated auth on the planet for something that only two people will ever log into. Um it's got like a really nice database schema that doesn't matter. But I like building software that I use. I don't necessarily care about distribution. I'm not trying to build something that works for everyone. I really love building software that becomes a part of how we operate and and how I live my life. Um and I've built a few apps like that where it's like I personal software I think is great. So, this app called the best, I think that's the one that if I spent a month on this, I mean it would end up being like the most amazing app of all time. Uh but even in just like a couple of hours a day for a few days, like I built a whole a whole app and and I'm using it. Um so yeah, the like personal software.

44:09 >> Sort of like moving from personalized apps to personal apps. >> That's right. I That's right. That's an interesting journey. >> Well, Tom, again, I I wish we had many, many more hours because I do actually want to dig into what AuthMe this you built, but um, yeah, so thanks so much for for coming in our studio and spending time with uh myself and Dave. Big fan of uh what you do, what Vercel does for for builders, and you know, aspiring builders everywhere. So, thank you.

44:37 >> Thank you so much for having me.