⚡️ Ship AI recap: Agents, Workflows, and Python — w/ Vercel CTO Malte Ubl

All right, we are here in the remote studio. Thanks again to F.NG for lending us the space, with Malte, who is CTO of Vercel. Welcome.

Hey, how’s it going? Glad to be here.

Did I get it right? I’ve actually never pronounced it out loud until just now.

Yeah, that was completely perfect. It rhymes with Google.

Ah, okay. You worked on Search at Google, AMP, and Wiz, which I think people still don’t know enough about Wiz.

It’s no longer a secret, but yeah, you can’t use it. Unless you work at Google, in which case you probably know what it is. Otherwise, there’s no reason to really know.

Suffice it to say that you are responsible for a lot of the web as it is today, so thank you for spending some time with us. You’re also now building the next web, as we say, with Vercel. We can cover framework-defined infrastructure. I think you probably saw that I have a lot of interest in self-provisioning runtimes.

We can cover v0, but this part is recorded right after you did Ship AI, which we’re trying to recap for the broader Latent Space audience who may not be watching Vercel as closely as I do—or as you do. So, generally, what is your message to the broader AI engineering audience about what Vercel is doing with AI?

1. Vercel Builds AI in Reality

The super-high-level view is that we’re the biggest fans of the AI engineering movement. We’re also fans of not just going hard on hype and big ideas and talking about things, but being very concrete about the fact that agents are very exciting and that you can actually build them.

I think our entire conference was about both making that easier and discovering the right abstractions as we figure out what people actually want to do, which is emerging as we speak. The way Vercel always does these things is by building things ourselves. That’s both in terms of products—agents that are products you can purchase from Vercel—and things that we do in our back office to make our own operations more efficient.

This building of apps lets us ground what we do in reality and then extract the abstractions that we feel are really helpful to put on the road. Probably the most talked-about thing that we shipped at the conference was our new Workflow Development Kit, which really is just a way to make writing workflows idiomatic, so that they become first-class. It’s something you do every day. You think about it and write 15 design docs just because you want one of them. It’s something you literally do every day.

Since your audience is also generally interested in what people are talking about, I think there’s a lot of discussion about our Workflow Development Kit, but also more generally: What are workflows? What are agents? How are they related? Do you use one or the other? I would love to talk about that as well.

At our conference, we introduced what we hope is by far the easiest way to make your agents easily embeddable into complex workflows and to make those workflows durable, zoomable, streamable, and so forth.

As listeners might know, I have a long history with workflows at Temporal. I think what’s weird is that a lot of people are discovering this for the first time. You don’t really learn about this in computer science classes, boot camps, or anything like that, because it’s not really a unit of compute and storage that is taught. It’s kind of emergent from companies like Uber and Stripe and everyone else. I don’t know if there’s a version of this at Google.

There’s a version of this at every single company that has been doing anything in computing since 1950.

What’s not necessarily the case is that it has been abstracted in any way. When I run a bank transaction system in 1975, then I invent this, right? Maybe I’m in a pure batch-processing world and I kind of avoided it, but the reality is that I built this.

Either I use something very productized, which Temporal obviously innovated on by making that a thing, or I use something ad hoc. I say, “Well, I need some kind of queue that tracks the work, and I need a database to store the state at any given point. Maybe I write a cron job that makes sure the stuff on the queue doesn’t get stuck.”

What’s extremely common in essentially every transaction-processing system that has ever been created is that there either is an explicit abstraction for workflows in it, or someone made one ad hoc. Otherwise, the thing just doesn’t work.

Yeah, totally. The headline thing for people who maybe haven’t explored workflows enough is that you can wait and resume code. It’s as though the serverless function is kind of indefinitely long-running. Literally, you can run an infinite loop inside your serverless code, and that breaks a lot of people’s mental models if they don’t really understand that the code pauses and resumes.

You can wait multiple days and it doesn’t matter. It doesn’t cost anything. Actually, I don’t know if it doesn’t cost anything. Maybe I don’t know if you charge.

No, it literally does not cost anything. You can run compute for an infinite amount of time. Whenever one of these steps fails, you can also automatically retry it. Things like that make it more reliable.

It has a lot of parallels to long-running orchestration problems for agents if you want to do human-in-the-loop as well. It’s a simple task of waiting for—what’s this API that you guys have? It’s not—I want to say signals, but you have something like resolve web hook or something.

I think it’s a little bit similar to a signal, but the idea is that you basically make a webhook—an ephemeral one—which is just a URL that you can ping.

The realistic flow would be that you reach the step where you want human approval, get the webhook URL, and write it to some database. Let’s say the user logs into their computer 2 hours later and has a queue of things they need to approve from the database. They click on one and say, “Approve.”

What happens is that the system calls that webhook. From the perspective of the workflow that you originally implemented, you’re now able to await that webhook. It resolves, and you can just proceed with the program.

Yeah, it’s very elegant. I would say that it eliminates some complexity that we introduced at Temporal, and that’s probably for the better. The other thing, I think, is that, obviously, as someone who’s in this space a lot and has seen all the solutions, you made it open source, which is another above-and-beyond thing. You could have made it proprietary, but you didn’t.

The way we think about Vercel—and I don’t want to go too deep into that tangent—is that open source has essentially 3 business models. The first one is Red Hat, where you just sell support. You think it’s open source. The second one is open core, where you’re the only one that gets to monetize it, but everyone else gets to run it if they want.

Vercel may not have invented this, but we’re certainly the most successful at a model where you say, “Okay, I have this software library, and it’s truly open source. Everyone can run it. It comes with adapters for every place on the planet, and that makes it really popular. Then we get a piece of the pie.”

Our strategy is to grow the pie, while what we actually see is that our piece of the pie is relatively constant in size in proportion to the pie. We can drive the open-source project. I don’t want to say we’re in it for the business model, but I think it’s a business model that has more winners than the alternatives.

I think this is also something that people seriously evaluating production workloads care about. I ran into this at Temporal: these are going to be extremely valuable workloads that you’re going to put on workflows. You want some ownership and some auditability. In practice, who’s going to actually run it themselves? Probably not, but you want the option. You want to check the box.

100%. I actually do think people will run it themselves, and that’s great.

Awesome. So that’s workflows. By the way, I think the most disgusting thing is the use of directives: “use cache,” “use no memo,” “use memo,” or whatever. So fun. So fun. What’s your take on directives in general?

I don’t, to be honest, feel super strongly. I do find, in particular, inside the workflow definition, that the use is pretty elegant.

I could imagine—

Yeah, I could imagine other ways of doing it. We did post a blog post about all the alternatives we considered, because there are some approaches that you think about for 5 minutes, and after 2 hours of thinking about them, you realize, “Yeah, maybe this isn’t such a good way to do it.”

There could be other ways of doing it. I think we’re working with TC39 to bring decorators into more places, which would kind of make this literally the same thing.

Above the function instead of below the function.

So it’s not a big difference, but it would become, for example, something that TypeScript could be aware of without a TypeScript plugin, which we already provide. I was vibe-coding this thing on Sunday, and I said, “Okay, Claude, you have no idea what ‘use workflow’ is because it came out on Thursday, but here are the docs. By the way, put it on my site.”

It installed a TypeScript plugin for me, so I had the perfect experience, and it just worked from scratch.

So that was great.

Okay, awesome. We can come back to the workflow anytime you want, but I just wanted to keep moving through all the stuff you had announced. We should probably also touch on the AI SDK. I know you're not as closely involved with that team, but obviously it's one of the most successful open-source projects.

I mean, obviously, Vercel is very good at frameworks, but I think it was not a given that AI SDK would be a winner because of LangChain, because of Mastra, and because of everyone else trying to get that spot—except that you guys have the perfect package name. I think that helps a lot. I'm not sure how much that helps, but it's great. There's a fun background from what people thought AI was 10 years ago.

2. AI SDK Stays Low Level

Yeah, I think we announced version 6 beta, and I think the big thing—it's not really news, because these things are open source and you can follow them very closely—is that it introduces a stable feature that was already kind of experimental in AI SDK 5: a direct agent abstraction. So far, that wasn't there. People would build agents with an SDK, but they would have to do it in a bit more bare-bones fashion.

One thing I do want to mention, because you mentioned it's very successful, which is true, is that I think the reason why it's successful is because we could restrain ourselves and be humble about what we know our users might want to do. The example I like to give is that when you build a new web framework in 2025, you know exactly what people are going to do. It's such a well-explored space that the person doing it has probably done it 3, 4, or 5 times in their life, failed, learned from that, and tried the other things.

It's so mature. It was the most mature thing even 10 years ago. That's why Next.js is so good: when Guillermo started building it, he knew exactly what to do. We know exactly what the app will be. Almost nothing has changed. So the AI app space is the absolute opposite. [laughter] We know absolutely nothing, and we still know absolutely nothing. Things are emerging, but we're so early.

If you put a very thick abstraction on top, it's probably going to be the wrong abstraction. You have to be humble and say, “Okay, I need to stay low-level so that this can be used flexibly as trends emerge.” That's why we didn't have to rewrite AI SDK when everyone went from writing chatbots to writing agents: we stayed at a level where that almost looked the same. The stuff people built on top changed, and I think that's why it's successful.

We didn't say, “Okay, we know what the apps are going to look like, and we're going to do this”—the Hollywood principle: “Don't call us; we'll call you.” You just have to fill in the blanks. It's super structured; you'll be happy. We didn't do that, even though that was so much in our DNA. We really did have to restrain ourselves, but that's why it's successful: it's so low-level. On the other hand, that's why we don't have an agent abstraction yet. Every other competing library leads with that.

Yeah, OpenAI's SDK did that on day 1.

Exactly. Mastra, et cetera. I'm not saying it's bad, and obviously that's more accessible right now. You have to understand that an agent is a tool with a loop. What do I do? I use the streamText function and give it tools.

We added all kinds of control already in AI SDK version 5. You can prepare the step, you can select the tools on every loop, and you can do all these things in a pretty advanced fashion. Half of those other frameworks are built on top of AI SDK anyway, right? So it forms the basis.

What we're doing now is bringing what is emerging as the patterns that people have built over and over again into an abstraction in the library, as these usages are solidifying.

I've interviewed enough agent-framework builders and model people at big labs that I actually find I can push back on you. You're basically saying we will be at the jQuery era, where we're building all these tools to make the smallest possible things easier, and then they compose up. We're just starting to emerge with agents.

I would say that the big-lab people are obviously the opposite, but they're coming at it not from a DX point of view. They're very big-model people. They want everything to go through the model. The reason they want the Hollywood principle of “We'll call you” is because they want the model to control the tool calls, the reasoning, what have you.

Obviously, you can have frameworks that do both, but I feel like there's a mentality in the big labs—if you work at big labs—that you always want to give the wheel to the model. For you guys, as framework developers and people who are software builders, it's more comfortable to build the smallest possible thing instead of the sort of AGI thing, if that makes sense.

Yeah. Yeah. I actually don't think about it in those dimensions. I 100% agree that people have to be willing to let go and let the model take control to get emerging behavior. Certainly, on coding agents, that works incredibly well, and I'm totally on point with that.

AI SDK does this very well today. All the agents I've personally built work like this. That's not to say it's the only thing, but the other thing is: how do I now embed this into an application? The model apps couldn't care less because they're not really building applications.

That's something that a company like Vercel thinks about a lot. Again, what does the developer actually want to express, and how do we let them do it? I think one of the key things that people wanted and still want is streaming, because these models are slow.

Suddenly, this almost obscure subgenre of programming where people are like, “It's 500 milliseconds; I'm just not going to ship it,” becomes “It's 30 seconds,” and it becomes absolutely important. So we gave people the tools to build streaming applications in a way that feels intuitive. I think that unlocked a lot of value there because that was genuinely hard, and we made it easy.

Those are the kinds of things we're looking for that are not obvious when you're mostly concerned about the AI part.

Fair enough. I think the design space has more dimensions than what I tried to simplify it down to. Just one more thing on the AI SDK, and then we can move on to the other agent stuff. Obviously, you guys announce so much that it's hard to cover.

Vercel is a house of frameworks, right? You have so many framework authors, all of them legends in their own right. What's one philosophy that you're also applying from all your years and all the people who work on frameworks that's informing you?

I have one, and feel free to counterpropose, which is what Sebastian Markbåge, who's obviously the tech leader of React, used to say: have a small API surface area. I feel like that has maybe been less important, or there are other overwhelming priorities, but I just want to get a sense of what governing principles really resonate with you.

3. Dogfooding Shapes Frameworks

Yeah, Sebastian and I are talking about this a lot, right? But I think I'm often representing the enterprise side, where it's like, “No, but I actually want to just control this.”

One API for this—just one more, bro.

I want to be in control, and I want to be able to configure it, and I want to define the defaults the way I see it. But it's good to have tension around these things.

I think the thing coming down from Guillermo is just the absolute founding principle of Vercel: we never give you an abstraction that we haven't used ourselves. Dogfooding is ultimately the thing. AI SDK was extracted from v0, and then we built it, and we kind of diverged a little bit. Then we took on the substantial work to bring v0 back, actually fully hosted on AI SDK, and we learned from that. We made sure that the migration isn't too hard, which the users have appreciated as well, and so forth.

There's this constant feedback loop where, if you don't have that—which sounds so obvious, right?—the reality is that framework builders are usually not application builders.

Yeah.

They build ivory towers that, when they're hyper-geniuses or they get lucky, happen to be good. But if you want to do this in a reproducible fashion with a high hit rate, then the only thing you can do is try that stuff out yourself, and that's what we do every day.

I really like that principle. Obviously, it's a good idea; it's just very hard to practice in real life, because when you're a maintainer of a framework, a lot of bugs come to you, they pile up, and you have to spend some time working on framework-level issues.

I'm happy to move on to the Vercel Agent and maybe the Agent on Every Desk program, which I think you're also championing. Let's talk about the use cases: you guys use internal agents within Vercel, and what emerged from that.

4. Vercel’s Agent Strategy

Yeah, let's structure this in 2 ways, because I do think there's a difference between the agents that we're building internally versus the stuff that we're selling as a product, right?

Yeah.

And which you can use today.

I thought they were the same thing. [laughter]

No, they're not the same thing. That's actually quite important. We also distinguish between an agent as a service, right? The Vercel Agent is ultimately an agent-as-a-service product, similar to Codex in the cloud or the Cursor agent—not as in they're the same product, but as in these are things where you go somewhere and say, “I would like to use this agent,” and then maybe you give them a credit card and it works.

That's different from the stuff that we run internally. But let's talk about the Vercel Agent for a second. We've basically been chipping away at our overall strategy of having an agent that helps you build applications on Vercel.

There is some overlap with coding agents, but I think the thing that's unique about the Vercel situation is that we have your runtime data. We have your error logs. We know where the deployments are, and we know how to start the development server. We already have the secrets, so there can be a quite integrated solution for something that otherwise can be quite hard.

If you've ever onboarded, for example—I mean, you've onboarded Devin a few times—but you've probably been in that situation where it feels like onboarding a junior employee, right? Some of these things become much simpler if you're within the Vercel ecosystem.

We've been chipping away at different things. A while ago, we shipped a code review agent, which I think is really good and well integrated. The thing that we announced last week is our broader DevOps Agent, which is tied to our anomaly-detection system.

Whenever we detect an anomaly on your production side, it kicks off the agent, and the agent investigates what's going on. From a technical point of view, this agent has several tools. It can make any observability query against your project, so it acts as a query builder and can execute the queries. It also has a way to read logs, obviously with other queries as well.

What's really magical is that it's just very good at this. By the time you click on the anomaly, it will almost all the time tell you very precisely what happened. It shows you all the graphs it looked at. It's just so much easier than doing it yourself. It takes away minutes of work, certainly.

But what I'm actually very excited about—and I think this is an overall pattern that we see with agents—is that, in many situations, there's what we call in search a precision-recall problem. That also happens with anomaly detection. You have to tune it, right? You either tune it to be very aggressive, in which case it fires and, in the worst case, pages you in the middle of the night when nothing was wrong. Maybe a team in Asia sent a newsletter and the traffic went up.

Or you tune it to not be aggressive enough, and then you miss events. With an agent, you can say, “Okay, I'm going to have this tuned very aggressively, and I'm not waking anyone up. I'm telling the agent.”

The agent can take 2 minutes to run, and I'm fine with that because no one would have reacted in that amount of time in a very reliable fashion. Now it can look at a time series, see what happened, look at the IP addresses making the requests, and look at the types of error messages. It can make a call about whether to escalate to the on-call engineer and wake someone up, or say, “This is completely fine for someone to take a look at the next day.”

I think that's the perfect decision for agents to make. You have this co-worker that has no sleeping problems in the loop, and they get woken up instead of you.

Yeah. I think the dream of AI SRE has been a long time coming. I'm actually on the record: at the start of this year, I made a podcast saying, “I don't think anyone's going to do AI SRE.” So I'm very excited.

I haven't tried it out personally. I've seen you tweet about it, and I think, yes, obviously that is the goal. That is the dream. We should make Bryan Johnson happy and have good sleep, but we're not exactly there yet.

I think the question is really twofold. Time-series analysis isn't exactly within the distribution for language models. There have been a lot of people doing time-series models, and there's a deep field of anomaly detection, which is basically what you're doing. There's a question of whether this is a solved problem and how much we can trust it.

The other one is aligning human preferences, right? Sometimes I don't know until I've seen a few examples: “Oh yeah, this one you should wake me up; the other one you should not.” Then, pretty much, when I solve the problem, it goes away. So the next problem is that you're always fighting the last war in AI SRE. I give you a bunch of things; you can take whatever you want.

No, I think you have to try out the product. It works really well. We don't do the anomaly detection in the LLM. The anomaly detection is a completely separate part of Vercel. It's a pipeline that works on our time-series database and launched independently of this.

Once you have that, our experience is that if you give the agent a tool that does queries, it's really good at digging into individual parts of the time series. The other thing it has access to is logs, and logs are just text.

If you see from the time series what happened, you can somehow try to figure out what it is, and then head over to the logs and do a deeper dive. Now you're more in the world where the model is comfortable.

One thing that we don't do today but will do in the future is give that particular agent access to your source code. It can first of all figure out what the error message means, and every so often it could actually make a pull request to fix it. That will be possible in the future.

Which is why I think companies like Datadog and Sentry are trying to do that, obviously, because they're observability platforms. But they never own the code, so they're always limited in what they can do.

100%. But I want to qualify how happy I am with how well it works. It's just a small part of the overall problem, right? We're actually not here to build the AI SRE that replaces that job function.

That's another part of what I feel pretty passionate about: at this moment, agents are both extraordinarily effective and still very ineffective. You have to find the right problems. When you find the right problems, they're super magical, and if you wander beyond them, they don't work. That's kind of the magic.

What we see is that getting triggered by a greatly increased error rate works well, and certainly making the decision about what to change in the firewall works well. I would not let the agent do that yet, because it's just too dangerous.

Or do DNS migrations. [laughter]

Exactly. That's—

That's AGI. Yeah, it's interesting, all that stuff. I think there's this growing consensus about where agents are doing well and where agents are not.

For me, meeting notes are solved. Simple UI changes are solved. What else, in that list of things that are solved and reliable every day, do you put in that bucket?

I had a section in my keynote about this, and it boils down to the question: where do you go around your company and ask people, “What do you hate most about your job?”

I really think that finds the sweet spot, because it finds problems that are boring—they're tedious and repetitive—but they would have already been automated if they were automatable without an agent in many cases. They often require some kind of text-based mini-judgment.

People do these things, and that question yields a sweet spot where the problems are probably easy enough for a current-generation agent to handle. They're also often very high business-impact problems, because this is a substantial part of people's jobs. That's why they hate it: it takes so long.

And so we ended up at our conference talking about 3 agents that we built internally, 2 of which we open-sourced. Again, we did that so people have a starting point, because these are custom agents. They're not software as a service that you just install. The first one handles processing our incoming contact sales requests—lead qualification.

Yeah.

There are obviously a lot of startups in that space, right? I think that's very much in the soft case, where you give it a tool for LinkedIn, a more generic tool for Google, and an objective: disqualify. What do you care about? You give it a way to analyze, “Oh, this is really a support request.” Okay, hand it over to the support team.

There are a few cases like that. It's not so complicated, so that one is perfect, and we open-sourced it so people can make their own. The other one that falls into a similar category is abuse analysis.

We get abuse reports, and in this case, it's really the agent essentially doing the pre-work. We still have a human look at the pre-work and make the decision about what happens in the end. What were they going to do? They were going to go to the reported website, look at the account, figure out how old the account is, see if they paid their bills, and so on. There is a list of things they would do.

You can make it so that when they eventually look at the ticket, it already has all this information. If the page looked like a Facebook login page, then a current-day LLM is also able to make the judgment call. You quickly check if it's okay, and you move forward.

Yeah, amazing. I think there's one more: a data analyst agent.

Yeah, exactly. This is also something we wanted for ourselves.

We have one too, internally. Yeah.

I think that one is also open source. The idea is that you want to ask questions against your data warehouse, and we were very unsatisfied with the current solutions because they ultimately didn't have access to enough information about the data model.

We're not promising that we have the magical tool where you give it your prompt and it spits out SQL just by accessing your schema. But we essentially developed a structured way to document the semantics of your data so that the agent is good enough. We've been using that internally quite successfully.

Amazing. For those who don't know, Vercel also has an Agent on Every Desk program, where you can reach out. Is it a forward-deployed engineering situation, where you have a SWAT team that comes in and helps people?

Yes, but it's also not appropriate for every company, right? My take is that if I'm a large company, I have a lot of efficiencies to gain, but it's also quite daunting to ship my first agent. Something like forward-deployed engineers, which we are indeed doing, helps quite a bit in that scenario.

As a startup, I don't want a forward-deployed engineer in my office. I just want to see the open-source project, feed it to Claude Code, and give it my own problem: “Build me something like that, but here's what I want to do differently.” That should also be successful.

We're really going for unblocking people who feel that they just don't know what to do. They hear the hype, but they don't know how to pick the right project. We talked about this: how do you actually find the project that's going to be both successful and high impact? Then, once I have the project identified, how do I do it?

I think forward deployment is effective. It's something that I, as a framework engineer, have thought about all my life: you need to have someone guide you the first time you do something, and then the second time, maybe you build an agent yourself.

We don't want to stay there. We essentially sign contracts with companies saying, “You have to commit to building 3 agents.” If you do, we're going to help you. We're going to build the first one for you, and for the second one, we're going to be there essentially by your side—maybe not literally, but on an on-call rotation.

For the third one, the assumption is that you don't need any help anymore. You can still reach out, obviously, but if everything went well, this is now a company that's empowered to build its own custom agents.

Yeah, you're going to be helping your biggest customers, and obviously that's going to lead to a lot of good product ideas, right? It's kind of dogfooding at scale with the people in the Vercel ecosystem, and not just Vercel alone.

100%. You just discover things that probably the 500-person startup would not have discovered.

I think one last thing, just to leave off the whole topic—and we can add in anything on the AI SDK side, actually. Is there anything else on the AI SDK that you really want to cover and get a soapbox about? I don't know if we covered everything.

5. Vercel Embraces Python

One point that we haven't talked about is that Vercel, as a company, has been investing in Python for quite a while. The audience of this podcast might also be excited about this. The AI SDK is currently a pure-play TypeScript system, but we do find Python really interesting.

What we've done over the last few weeks is ship zero-config support on Vercel for all the popular Python frameworks, like Flask and FastAPI. Zero config means that you get the Vercel experience: you throw your stuff over the fence, and we're going to run it for you, no questions asked.

We've also shipped a Python SDK for our API to show that we're engaging with that ecosystem. It's obviously something that's new for Vercel, but we've been making hires and infrastructure investments to make Python really well supported on Vercel.

It's also on the Fluid Compute program, which gets you active CPU pricing. You can run Python in production and only pay when you have compute; otherwise, it's free, which is very nice if your backend takes 30 seconds to respond because it's an AI model.

I was also going to make the observation that workflows are very nicely meshed. It's almost as if there's this fate you're driving toward: workflows needed Fluid Compute in order to do all these fancy things, or at least make them easy to ship.

Right. I think there's some overlap. With workflows, literally nothing's running between steps, so it's literally free. That's also why it's free: there's literally just nothing happening.

Fluid Compute has the same property, except it's more agile. Usually, in a workflow, I know you're doing the FFmpeg thing, then you're doing the AI model. You're not talking about millisecond latency. There's some overhead on each step, versus Fluid Compute, where the VM is literally on, which operates on a different kind of level.

Excellent. On the Python thing, what happened to “always bet on JavaScript”? Isn't that the Brendan Eich line? I guess the broader, non-cheeky question is: are we 50/50 Python and JavaScript now? Is that the future, where no particular language will win? Or do we not have an opinion?

I don't think I have an opinion. I saw today that TypeScript is now, as of today, the biggest language on GitHub. Last year, you still had to cope with the fact that TypeScript and JavaScript were drastically bigger than Python.

Honestly, I don't really care. Both communities are very relevant and very large, and we're investing in supporting them. The way Vercel's infrastructure works is that we essentially just run VMs, so it's not actually hard for us to support Python.

We'll eventually do PHP and Ruby, but we also care a lot about the details. The reason we haven't done it yet is that we invest a substantial amount of time in making the developer experience actually good and feel native to the ecosystem.

Technically, it's easy, but in practice, it's very difficult for us to support these things. We're taking it carefully, but there's no technical restriction in our system that prevents us from supporting all these different ways of running code.

Yeah, totally. That's a very fair response. The fact is that when you're a serious AI cloud, you have to support Python. There's no way around it.

Okay, I wanted to zoom out. One other thing that we care about in AI engineering is AI leadership, which is leadership of AI engineers. Obviously, your role as CTO has changed a lot since you joined. What are some leadership principles that you've had to create from first principles?

When you're obviously in a very unusual type of CTO role, where you're in an infrastructure company with frameworks and apps, what comes to mind when I say, “How has the CTO role changed for you?”

6. AI Transforms the CTO Role

Yeah, so I joined Vercel a little bit less than 4 years ago, and that was definitely before ChatGPT. I came directly from Google, and I think I had some insights there into what was happening, but Vercel certainly wasn't living in this world. That was kind of the tail end of the last really big crypto wave and everything else, right?

Then suddenly the AI revolution happened, and the thing that I definitely had to work through was, “How do I transform the company into something quite different?” I think the solution that we've come to feels really good, and I think there's a lesson there to be learned for companies that haven't done the transition yet: You have to do something that feels native to your company.

The 2 big bets that we made early on were v0 and AI SDK. I think they felt native to Vercel in the sense that v0 was originally designed as a tool for making web pages; the full-stack stuff came later with the models. Originally, it was very much a web development tool, and the SDK was a framework for building AI apps. Because we're a framework company, it felt really native.

I think you have to be honest with yourself about what product, even if you do have to change to building something else, extends naturally from what you're doing. It shouldn't be something entirely different where no one believes that you would be the right place to buy that from.

That, I think, is just generally timeless advice. Have manager-to-IC ratios gone up? You know what I mean?

Oh, that's a really good question. I don't track that very closely.

I think it's a thesis. I would be supportive of it going up.

It's a big question, like the role of the engineering manager. I have 2 reports.

Nice. Nice.

Right. So that's the way we're organized. I'm privileged as the CTO in that I don't—you know, VPs are usually the people managers. But that's actually not the point. The point is that the really one thing that Google got right is that it has very strong ICs. It has IC levels all the way up. There's Sanjay at 11, and so we're doing the same thing. We had to have someone as an IC at the top level.

I think this is another thing that you have to be willing, as a company, to live with: You don't make your strongest engineers choose between not making more money and becoming a potentially very bad manager. There's little correlation between being the best engineer and being the right manager. Sometimes you have these moments of, “Oh my God, I'm glad we made this change,” but it's essentially a crapshoot whether that happens.

Yeah, that's the other thing that I find. Obviously, the Peter Principle applies, which is the principle of promoting people to the level of incompetence. I think the other interesting thing that people are finding is that PMs and designers are now starting to contribute more to code because they feel they can just vibe-code something. Maybe that's good; maybe that's bad.

I don't know if there are standards around this that have been established inside Vercel. There used to be clear code owners, and now, because we feel that with coding agents we can do a lot more, maybe that causes some politics somewhere. [Laughter]

100%. We want to be at the vanguard of doing this. As makers of v0, we highly encourage all our employees to contribute code.

I think one thing we haven't talked about, and we might have time to go into, is that we're very deeply working on a way to build apps that follows the threat model that assumes the developer doesn't know what they're doing, and that they're also using AI that doesn't know what it's doing. I want to be able to build an app that is secure even if the developer is incompetent, right? But today, that's not the case. Today, I assume a developer is competent.

Full trust.

Right. And that's actually the point. We have made very strong progress there, and we're working with lots of large companies that have data, for example, where you have the idea that auth cannot be part of the app because they're not going to get that right. Auth has to be extracted from the app, in fact. Which data you can see also cannot be in the control of the app, because again, you're going to get it wrong.

We're building these systems that try to have a minimum amount of security fully independent of the quality of the app, and I think that is part of the future of how people will build stuff.

Okay.

Probably a good idea anyway.

This is Vercel-level, not so much v0 or Next.js-level?

Yeah, in a way, in an integrated fashion, right? Because I'm going to build the app in v0, and now I want to deploy it to my fellow coworkers. Only the right people should be able to access it, and when they access it, they should only see the right data.

Yeah, I think this is very exciting. I think the closest people have come to this is WorkOS, basically. There should be more agent-native, if we can call it that, infrastructure that lets people build and vibe-code safely. We all want to enable them; they just cannot be trusted.

This is very insightful, actually. I'm very excited to see that. Pay me when it comes out. But otherwise, thank you for spending the time to recap all of our Vercel stuff. I cannot imagine a better person to talk to. You're so generous, friendly, and engaged. I definitely don't feel like all CTOs are as engaged with regular developers as you are.

I'm trying my best, and I'm spending too much time on X. But yeah, this is super fun. Thank you so, so much for having me.