Malte Ubl on Rebuilding Vercel's Agents and Running a Company While the Ground Shifts
The Pragmatic Engineer
At The Pragmatic Summit, Vercel CTO Malte Ubl talked about what it means to build products while the models underneath them keep changing. The interviewer framed the moment as different from earlier waves of coding hype: builders are trying to figure out how to work while the ground is moving under them. Ubl drew on two Vercel products to explain how the company has adapted. One is d0, an internal data agent. The other is v0, the public app builder. He also covered reliability at an infrastructure company, how Vercel's organization is changing, and whether cheap software will mean more engineers or fewer.
His recurring position is that agent builders have to be humble. What counted as best practice a few months ago may no longer hold, and being willing to throw work away is part of the job.
d0: a text-to-SQL agent in Slack
Ubl started with Vercel's habit of building on its own technology. One of the company's theses, he said, is that building agents is "actually extremely easy," so there is no need to buy them. d0 is the result. It is a text-to-SQL engine: an employee asks a question in Slack, and the agent replies with the answer. It can reach Vercel's entire Snowflake data warehouse, subject to the access rules of whoever is asking.
To show what it can do, he shared a query he called the funniest one. Early in the year, a salesperson asked which S&P 500 CTOs and VPs of engineering have private Vercel accounts and deployed over Christmas. Ubl guessed those people then got an email or a call. Answering the question takes some outside research, such as checking LinkedIn, and the agent does that too. The hard part, he said, is eventually working out the right Snowflake query.
Deleting the first version
The first version of d0 used what Ubl called a traditional architecture: "tools in a loop," with many different tools for many different jobs. He said it didn't work badly, but it wasn't "as magical" as they wanted.
So the team deleted everything and rebuilt d0 to look much like a coding agent. It is still custom code. It does not use the Claude Code harness, because in Ubl's view building such a harness is easy. The new design depends on up-front work on the data. The team went through the whole Snowflake warehouse and wrote, in prose, the business meaning of every single column. Those descriptions are exported to YAML files. The agent is then told, roughly, that it was post-trained to use grep, tail, and the other tools of coding, and it should use them freely on these YAML files to learn the business semantics before writing a SQL query.
The agent has exactly two tools: a bash tool and a tool that executes SQL. Ubl said the whole agent is about 50 lines of code and that it has been "completely transformational for the business."
The interviewer mentioned a Vercel blog post arguing that all you need is the file system and bash. Ubl explained the reasoning. You should ask what the model was trained and optimized on. Right now that is largely coding tasks, though he expects this to change. If you can make a problem look like a coding task even when it isn't one, he said, you get proportionally good results.
Why throw it all away
Asked how the team brought itself to discard working code, Ubl returned to humility. He said something that was best practice in summer 2025 "means quite little today." Websites have been built for about 30 years and people broadly know how to do it. Agents, by his estimate, are "in their maybe third year for real if at all." Teams have to be open to the idea that a better approach exists.
He tied this to model capability. As models get more intelligent, he argued, it becomes more practical to build agents that rely almost entirely on emergent behavior. Those agents can be simpler, because they need less prompting and fewer hard-coded rules.
A CTO coding "24/7"
The interviewer asked how many Fortune 500 CEOs and CTOs use Vercel on personal accounts. Ubl didn't have an exact number but called it "pretty substantial" and agreed it was dozens. He counts himself among the executives who code. He said he is "deep in 12 hours a day coding." In practice that means he can still attend meetings, because every so often he checks in, adjusts prompts, and does code review. He said he has long swung between coding a lot and coding little, and now he is back to coding constantly.
Vercel does not require any particular tool. The company wants people to have broad experience so they feel what users feel. Ubl's own setup, which he said may change, was Claude 4.6 in fast mode for coding and Codex 5.3 for code review. The interviewer compared the experience to a slot machine's dopamine hit. Ubl mentioned that the Wall Street Journal had quoted him saying something similar, his first quote in a major newspaper. He added that maybe he isn't addicted, but he does love it.
v0: built for front-end engineers, adopted by back-end engineers
Turning to v0, launched in 2023, Ubl said the team first believed it was building a tool for front-end engineers, which fit what Vercel does and meant building for themselves. They then found that back-end engineers were the real audience. In the GPT-3.5 and GPT-4 era, the tool helped but was unreliable. Back-end engineers could fix the cases where it failed. A non-engineer could not have used it back then. That was v0's main product-market fit for a while.
He rejected the word "pivot" for what came next. A pivot, to him, means realizing you misread your own data. The situation was different when, for example, Anthropic shipped Sonnet 3.5 and essentially the same prompt could suddenly build full-stack apps that weren't possible before. You can't keep the product the same, he said, "because the world is different." That model release let v0 build end-to-end applications, with success rates approaching the point where non-engineers could succeed.
The Tailwind moment
The interviewer said Ubl had described about five moments when a model leap or a shift in usage forced a rethink. Ubl chose the first one, from summer 2023. ChatGPT had launched, and it seemed like LLMs should be able to make web pages. When people tried, the pages came out subpar and not good enough to package as a product.
He recalled a colleague, originally from China and based in Berlin, working in the San Francisco office. At one point the colleague raised his hand and said he'd found something. He had changed the prompt to say "use Tailwind." Ubl called it a moment of serendipity. Tailwind, a way of writing CSS, was old enough to be in GPT-3.5's training data. It wasn't very popular yet, but there was enough data. Ubl's explanation was that models then were "too dumb" to write a CSS file and later write matching HTML. When told to put everything in one place, they did a real job. That, he said, is how they found a viable product at the time.
From tech-adjacent users to shadow IT
As more products appeared in this space, some moved into consumer markets. Vercel found an enterprise use case aimed at users Ubl calls "tech adjacent": PMs, designers, product owners, and interested business people. That group gave strong product-market fit. The latest use case is a business person inside a company building an internal app for themselves. Ubl called the resulting surge of shadow IT something Vercel is very interested in, both for v0 and for Vercel's deployment business.
Where Vercel fits as models improve
Ubl described Vercel's core business simply: you throw your code over the fence and Vercel runs it. With more software being produced than ever, whether through Claude Code, Cursor, or anything else, that software eventually needs a place to run. Vercel connects to a Git repository and ships a new production version on every push. v0 also puts Vercel on the creation side, but Ubl said he spends most of his time on how to run apps that are now made in new ways, in a way that suits this new kind of application.
Asked how worried he is about obsolescence on a scale of 1 to 10, he didn't give a number. He said there are things he worries about, but he doesn't see a major disruption to the business of operating software. Someone could argue that agents write Terraform well and can create infrastructure themselves. Ubl said that isn't how it works. Professional devops depends on people understanding what is going on, and "you can't really vibe code that." In his view, running software always needs some form of platform, and Vercel competes there successfully.
On whether limited observability is a temporary or fundamental problem for long-running agents, Ubl expects a coming revolution of agents taking part in devops and in running applications. Vercel has started calling this "self-driving" infrastructure, meaning something that understands in an agentic way what is happening. He added that this still depends on some uniformity in how things run, as opposed to just letting the AI loose.
Starting v0 today: one person, not a team
If he restarted v0 now, Ubl said, the main difference is that "today you actually don't need a team." Teams make things slower. A single person, or perhaps two or three but not seven, can get far enough to support a judgment call about whether an idea deserves investment. His instruction would be: figure out the product, show me a demo, and if the demo is good, you get a team.
He said Vercel hasn't fundamentally changed how its engineering teams work. Letting individuals ship end to end without depending on the whole organization was always a good idea. What has changed is that the old friction hurts more. When agentic coding speeds up the inner loop and the outer loop of shipping stays the same, the gap is more painful.
Optimistic locking instead of approvals
Ubl gave an example from his 12 years at Google, where he led part of the search team. He described it as a very slow operation where his job was essentially approving things by email and going to meetings. He didn't want to recreate that at Vercel.
Vercel instead uses what he called, "in the nerdiest way," optimistic locking. No approvals are required and anyone can ship anything. They do have to tell the organization what they plan to ship, and the organization can veto it. He admitted "veto" sounds scary but said it is empowering. Most of the time legal says something like "this sounds totally reasonable." Sometimes they say you can't ship this to children in North Korea. If legal has to approve everything, you wait on round trips, vacations, and so on. If legal can object at any time, they have to be active participants. Ubl said this both empowers those teams and gives them responsibility.
Moving fast without global outages
The interviewer asked how an infrastructure company balances customers' uptime against moving fast. Ubl rejected the framing that these are opposites. Vercel's business is helping customers move fast, and Vercel is its own first customer. Everything he does is about speeding up the inner loop of development and the outer loop of shipping.
He acknowledged trade-offs. Vercel ships its serving systems only once a day, while the control plane ships on every push to main. He'd like to release consumer serving features 15 times a day, but the company chose not to.
The interviewer brought up a deep dive into Cloudflare outages, which were twice caused by bad data in a globally distributed configuration store built for speed. Ubl answered from his time at Google. Large Google outages, which he said happen maybe every five years, are almost always a bad config change or a problem with the secrets management service everything relies on. The interviewer added that the most recent big one was a config change to the secrets management service.
Vercel runs 20 core regions. For the serving stack, the company deliberately made those regions autonomous, with no mechanism to change them all at once. Ubl said Vercel "thankfully cannot" make the kind of config change that breaks everything simultaneously and has to roll changes out in waves. Fast feedback on something like a feature flag doesn't require a global rollout. Deploying to one region is enough, and if that region fails it can be pulled from rotation. His general principle is to look at the risk profile of each change and find a way to keep the same speed without risking something like a global outage affecting 20% of the internet.
Unlimited tokens
Vercel gives engineers unlimited tokens and says so in its job descriptions. Ubl couldn't see why he wouldn't want that. When people overspend, he said, it's usually a bug. One engineer was spending 10 times as much as the next highest. Ubl said he was impressed at first. Then they found that the engineer's custom coding harness kept changing the prompt prefix, so requests missed the cache, which is much more expensive. His conclusion was to keep an eye on spending but otherwise "the more the merrier."
On executives shipping code: Vercel's CEO still deploys an app to Vercel almost daily but rarely makes production code changes. Ubl makes production changes about two or three times a week, nothing large. He described this as the typical profile of many people in the room, doing real work but not the most important work.
Engineering looks more like management
Ubl said engineering work already looks more like management than individual contribution, which changes the profile of the people who do it well. At Vercel, he sees the most senior ICs benefiting most, because they already did similar work and now "just have more minions." The most junior engineers also benefit a lot, for the same reason they're better at making TikTok videos than he is: they grew up with the technology. The group he finds most interesting is in the middle. They have to learn what amounts to a new role and need to be willing to engage with the technology. He said Vercel is very impressed with its internship program and has a sizable cohort of junior engineers.
A headcount cap of 1,024
Asked what the organization will look like in one or two years, Ubl said he doesn't know. He shared a "quasi joke" with his CEO: Vercel has about 750 people, and they "decided" to cap headcount at 1,024. He noted that this isn't below the company's hiring plans for this year, so they'll see what happens. He can picture an asymptote where revenue keeps growing but headcount doesn't need to.
He described automation already in place. Vercel automated sales lead qualification with an agent, which it also open-sourced, and has automated 87% of support intake. The company did not lay off support staff. It is growing fast enough that it wouldn't be necessary, and in his view support agents now have a better job because they only handle the hard problems, which he thinks they enjoy more. Factors like these at least slow headcount growth, so he expects some change there.
How elastic is the software market?
Ubl's bigger question is how elastic demand for software is. Making software cheaper clearly produces more software, and he said Vercel sees this in its own numbers. Where things settle is "completely unclear" to him. The new equilibrium could have more software engineers than today or fewer, and he said both are very possible. One reason for his uncertainty is that all this new software carries a large maintenance burden, and it's worth paying people to manage only the software that proves valuable enough to the business.
The interviewer offered a YouTube analogy. TV and film production used to be very expensive, and then anyone could make video. It turned out the world had been "video light" around 2005 or 2006. If we are "software light" now, the interviewer said, that would be great. Ubl agreed and noted that far more people work in professional video production today than 20 years ago. He added that this doesn't mean nothing changes. He cited Ben Thompson's comparison that this shift may resemble the 1960s arrival of mainframes, when buildings full of human "computers" lost their jobs, more than the arrival of the internet. That transition was very painful for some people, Ubl said, but society overall is far richer now, so over the long term it went well. He sees a possibility of a similar transition.
Software is free like a puppy
Asked for a hot take he hadn't shared, Ubl said that was hard because he tweets everything right away. His current view is that software is now "free" in the way a free puppy is: it still has to be maintained. He is excited about agents doing software maintenance and is exploring it, including whether things can be maintained automatically in production.
He ended with a problem he hasn't solved. An engineer now comes to him and says they built a new file system. Before, that wouldn't have happened, or it would have been a six-month plan. Ubl said he really wants to figure out what to do with it: can he ship it now, or is it "actually not real"?
Malte, thanks for having the conversation with us today. This time it feels different when it comes to coding agents. I think there have been times in the past where, you know, it felt like it was a little revolutionary, but I think this time we're all trying to figure out how we are supposed to build while the ground underneath us is shifting. And so super happy to be speaking with you today.
I think that with your products, d0, your internal data agent, and then Vercel v0 as well, your public-facing thing, you've been able to roll with the punches and be able to build and create products as the world has changed around us. Let's start with d0, your internal data agent. What was your first approach there, and why did it turn out to be so flawed?
Yeah, to give folks a little bit of context, like the thing that makes Vercel strong is that we always built things with our own technology. And like one of our theses is that building agents is actually extremely easy, and you don't need to buy them, you can just build them yourself. And so we built one ourselves.
And so the agent that we call d0 internally is a text-to-SQL engine. So you give it any question in Slack, and it will reply with the answer. And it has access to our entire Snowflake, kind of subject to the access rules of the user, right?
And so I'll share one query, which I think is the funniest one. It's a salesperson, you'll hate it all. So early this year, this person asked the following question: which S&P 500 CTOs and VPs of engineering have private Vercel accounts and have deployed over Christmas.
So, presumably they got an email or a call. I don't know. But I think actually finding that, I mean, obviously you have to do a little bit of research. You have to go to LinkedIn, etc. The agent does it as well. But then eventually you kind of figure out the right Snowflake query. It's very, very difficult, right?
And so the initial version of this agent was kind of this traditional infrastructure architecture where you have, you know, the agent as a tools-in-a-loop type of thing and all kinds of different tools to do all kinds of different things. And it wasn't like it was working badly, but it was, you know, maybe not as magical.
And then we deleted everything and switched to an agent that looks very similar to a coding agent. Now, it's still kind of custom coded. Like it doesn't use, for example, Claude Code's harness, because again, building such a harness is actually really easy and you can just do it. But otherwise it kind of looks the same way.
So, the general architecture is that we did the work of going through our entire Snowflake and, for every single column, in prose, explaining the business value. Right? And that gets exported to a YAML file, and the agent essentially gets told, you know, you got post-trained on using grep and tail and all these things, right, that you need for coding, and go to town on these YAML files to figure out the business semantics of everything, and then you make a SQL query. For that it has a completely different custom tool.
And that's it. So, there's just two tools. There's the bash tool and there is the execute SQL tool, and that's the entire agent. So, it has like 50 lines of code, and it's completely transformational for the business.
What led you to understand that you needed to throw everything away? Because I feel like you go and you build all of this code and it's just so hard to light it on fire and then start from scratch again.
Yeah, I think in the world of agents, you have to be humble in the sense that we're just discovering how to build them. And so just because something was best practice in the summer of 2025 means quite little today. And that's different from, I don't know, if you build a website, you know, it's been 30 years and we kind of know how to do it. But agents are in their maybe third year for real, if at all, right? And so you have to be willing to entertain the notion that yeah, maybe there's actually a better way to do it. And it's kind of proportional to the models getting more intelligent, so it's more viable now to have agents that are essentially fully relying on the emergent behavior and, respectively, are more simple because you don't have to prompt them so much. You don't have to hardcode so many rules.
On the Vercel blog you had a post. It was titled, I think, all you need is the file system and bash. Is it something like that? And so you just took a complete step backwards and described what the data was in plain English, and sort of you just stepped back and let it cook and moved to a much more declarative model with everything.
Right. Yeah, the intuition is that you have to think about what the model was trained on. What is it optimized on? And for now there's lots of coding tasks, right? And it'll change in the future. And so if you can make things look like they're coding tasks even though they're not, then you get these proportionally good results.
How many CEOs and CTOs in the Fortune 500 are using Vercel on their personal accounts? I don't have the precise number, but it's pretty substantial. Okay. Yeah. Dozens of them.
Well, it's quite amazing now to see all of these CEOs and CTOs come out of the woodwork and start coding and doing all these agents. Are you one of those CTOs that are close to the ground and shipping stuff?
I was already before, but I'm deep in, 12 hours a day coding. And by coding I mean, I can do meetings, right? Because I can, you know, just every so often go in, check the prompts, do code review. Yeah, I'm super back. I've been for the longest time kind of oscillating between coding a lot and not coding so much, and I'm back on, I'm like 24/7.
What's your drug of choice? Your agent of choice?
So for Vercel, we try for folks to get a broad experience across the company, to feel what our users feel. So we don't mandate anything. My current stack, but it's subject to change, is Claude with 4.6 fast, and then I'm using Codex 5.3 for code reviews.
Yeah, it's quite amazing. It's just this dopamine hit where you're hitting the slot machine hoping that you get something awesome out of it.
Right? By the way, there was an article in the Wall Street Journal of me basically saying that, and so that was my first ever quote in a major newspaper. Here you go. Oh, okay. Oh, wow. We both came to that. Close. To be addicted. But yeah, maybe I'm not addicted, but I do love it. It's such a good experience.
Well, let's shift to Vercel v0, which I think you launched back in 2023. Is that correct? Yeah. So, the original pitch was anybody should be able to make an application, even non-engineers, and you could do some prototyping and stuff like that, which was, I think, pretty revolutionary at the time. What did you think v0 was going to be, and how quickly did it start diverging from the plan?
Yeah, I think initially we thought we were building a tool for front-end engineers, because that's what we're doing in general, right? And so we were thinking we were making a tool for ourselves. And we then realized we actually built a tool for back-end engineers, because it was empowering them, but it also sucked in the sense that it doesn't work all the time. You know, this is 2023, GPT-3.5, GPT-4 days. And so, it didn't work all the time, but the back-end engineers were good enough to fix it in the cases where it didn't work, but you couldn't have given it to a non-engineer at the time, right? Because it was just not reliable enough. And so, that was kind of the main product-market fit for a while.
And then, but again, in the AI space you have to be humble, right? You have to be willing to entertain that the world is changing around you. So, sometimes people call it a pivot, but it's not really the right word, because usually that's used for the cases where you realize that you kind of made a mistake on your internal data, and you have to do something else. Whereas, let's say Anthropic ships Sonnet 3.5, and suddenly essentially the same prompt can be used to build full-stack apps, which previously just wasn't possible. You cannot now keep your product the same, because the world is different, right? And so, that was a major milestone where we realized, "Okay, we have to…" And I mean, obviously this is amazing, right? We can now adapt our product to be able to build end-to-end applications, and also with a success rate that kind of approaches the case where a non-engineer can be successful.
So, you told me there were about five "oh" moments when it came to v0 over the years where the models took a really big step forward or, you know, usage patterns shifted and you needed to rethink things. Can you take us through one or two of those moments and how you were thinking about things?
Yeah, I mean definitely the first one was in the summer of 2023 when, to take us all back, right, ChatGPT had launched and LLMs were still kind of new in broad adoption. And these things were making text. And so, I think us and everyone was thinking it must be possible to make web pages with these things. And back in the day when you tried, you would realize that it wouldn't do a good job. It would kind of do it, but it wouldn't look good. It'd kind of be subpar, not something you would package as a product.
And I still remember to this day, we had someone actually who is from China and lives in Berlin, but he was in our office in San Francisco and he was hacking away, and then at some point he was raising his hand like, "Guys, guys, guys, guys, I found something." And so, he had just changed the prompt to say use Tailwind. And this was such a serendipity moment because Tailwind, which is a way to write CSS, at the time was old enough that it was in the ChatGPT 3.5 training cutoff. At that time it wasn't super popular yet, but it was enough training data. And so, the model is so much better at doing inline reasoning rather than saying you have to write a CSS file and then later write the HTML. The models at the time were too dumb to do that. So they couldn't, right? But if you told them basically just put everything in the same place, then they did a real job. And so, that's kind of how we figured out how to build a product that actually was viable back in the day, right?
So that was kind of the first milestone to actually make it work. Eventually, I already mentioned the second really big pivot was that. I think the final step, you know, obviously there was this whole ecosystem now of products in the space, and some of them went very much into the consumer space. And we definitely discovered, okay, there's this enterprise use case. So for Vercel, the users we're aiming for I would call tech-adjacent, right? So it's the PM, it's the designer, it's the product owner, the business person who's kind of interested. That found a lot of product-market fit.
And then the final use case, and I'd love to talk a little bit more about that, but it's essentially, I'm a business person in the company, I'm going to make an internal app for myself, right? And then the new crazy onslaught of shadow IT is definitely something that we're very interested in, both from the Vercel point of view, but also from the Vercel deployment point of view.
How do you think about the fact that the models are so fully capable right now? And where does Vercel sit as a product, you know, as these models get better and better?
Yeah, so we're a multi-product company, but our core business, for folks who don't know, is you throw it over the fence, and we're going to run it for you. And the beauty of that is that there's no more being made right now. Sorry if we're cursing on TV, but here we go. So we love it if you use Claude Code, if you use Cursor, you know, at some point you're going to have to have a place to run it, and, you know, we can connect Vercel to your Git repository and every time you push, we'll make you a new version of it and have it in production. So that's how I see my primary position in that marketplace, right? And then, you know, with v0, for example, obviously you're also playing kind of on the creation side, but I certainly spend most of my time actually on the question of how do I run these apps that are made in different ways in production in a way that's appropriate for this new type of application.
So, on a scale of 1 to 10, as the CTO of a tech company in 2026, how worried are you that the stuff that you've built will become obsolete as these models get better and better?
There's things I'm worried about, but I don't really see, like, again, you know, since we're in the business of operating software, I don't see a major disruption there. You could argue, you know, the agents are also great at writing Terraform. They can just make the infrastructure for you. But that's actually not how that works, right? The whole idea of any form of professional DevOps is that they have somewhat an idea of what's going on. And so you can't really vibe code that. There always has to be some form of platformization of how I run something. And so, essentially, we're playing in that space relatively successfully. So from that point of view, I'm actually not particularly worried.
Well, do you think that the lack of observability is a temporary limitation or a fundamental limitation of long-running agents?
You know, I think there's a whole revolution ahead of us of agents participating further in kind of the DevOps space and running applications. We started calling it kind of self-driving infrastructure, where, you know, you have essentially something that in an agentic way kind of understands what's going on. But yeah, I think that still kind of relies on the fact that there is a certain uniformity in how things are running, versus essentially, you know, letting the AI kind of loose.
If you were to start the v0 team today from zero, how would you do it differently than when you started it in '23?
Oh, that's a really good question. I think, obviously, if you already know what the product-market fit is, you can jump over all these steps, right? I think the big difference is that today you actually don't need a team. So if you start, why would you have a team? Teams just, I don't know, make things go slower, right? You can always go to the step where you have enough that you can make a judgment call as to whether that's worth investing in with a single person. And maybe there's two of them, maybe there's three of them, right? But it's not like seven people, right? And so I would tell someone, go figure out what the product is and give me a demo, and if the demo is good, I'm going to give you a team.
So you just have one dude. Just go and do it after you've found the market fit. Or gal, but yeah. Yeah, yeah, yeah.
That's amazing. So, how are you thinking about your dev teams within Vercel then? Are they much more about like one person and one
sphere of ownership and then they go and they do everything? Or are you trying to retrofit maybe like a broader team dynamic?
I definitely don't think we have in a major way changed how we operate. I think it was always a good idea to have individuals be able to ship something end-to-end and to not really always rely on the entire operation to make progress. And I think many of these things continue to be true, but they're probably more painful now if you increase the speed of the inner loop through agentic coding, but your outer loop of shipping is different.
I'll give you one example, which I think is relevant for this group. So, I was at Google before for 12 years. I led part of the search team. You can imagine it essentially being a very slow operation, right? My job was essentially to approve things via email and go to meetings. And so, I didn't want to build that organization. And so, the pattern that we use at Vercel is what in the nerdiest way you could describe as optimistic locking.
So, there are no approvals. Anyone can ship anything. But they have to tell the organization that they're going to do it. And the organization can veto things. And so, veto actually kind of sounds scary and weird, but it's really empowering, right? Like if the legal team says... Most of the time they say, "Yeah, I mean this sounds totally reasonable. I don't need to spend any time on it." Right? But sometimes they'll say, "Oh my god, you cannot ship this to children in North Korea." Like, sometimes that's true, right? But if you have a process where legal has to say yes, then you have to wait for them and there's round trips and they're on vacation and whatever, right? It's complicated. If you say, "Well, no, you can always say this is not okay," but you now have to be an active actor in this process, it's both empowering for those teams, but also puts the responsibility on them.
That's interesting. And so ultimately you're an infrastructure and DevOps corporation. How do you see the role of reliability and maybe moving a little bit slowly and more conservatively for the uptime of all of your customers versus wanting to move really quickly in this age of agentic coding?
Yeah, I think it's just not right to take those things to be in opposition. Everything we do in our business... we have this maybe great situation where it's our business to make our customers move fast and we're taking advantage of it ourselves, right? We're our own first customers. And so everything I do is I think about how can I make my teams move faster. How can I improve the speed of the inner loops? How can I improve the speed of the outer loops of shipping?
And so that doesn't mean I never make a trade-off, right? For example, we only ship our serving systems once a day. Right? Whereas we ship our control plane every time someone pushes to main. And so would I love to be able to make a new feature in our consumer serving stack like 15 times a day? Yes, but we did make some trade-offs there. So obviously you make some decisions, but it doesn't mean that you cannot move fast and not break things, right? It's possible.
Well, I did a deep dive into Cloudflare's outage and it turns out that it was some bad data in the control plane, twice. And the whole reason they had the dynamic configuration was that they could move really quickly and make changes and customers would see that reflected really quickly. But this globalized key-value pair store that is storing these configurations has the potential to take out 20% of the internet. And so do you make a distinction between the ops and the DevOps side of the corporation and then the software and the engineering and the architecture? Are those the same thing?
It's a really good question. Also from my experience at Google, every time Google goes down, which at a large scale only happens maybe every 5 years, right? Every single time it's one of two things. It's either a bad config change or it is something around the secrets management service that everything depends on, right? Or it's a config change of the secrets management service. Which I think was the last big one. Right? So it's always going to be that.
In Vercel's architecture, we operate 20 regions, 20 core regions. And so on the serving stack, again, we have deliberately decided that we want these regions to be autonomous and we don't have a mechanism to change them all at once. And so we thankfully cannot do these types of config changes that break everything at once, and so we change them in waves.
And so yeah, there's another deliberate decision to say, okay, if I want to move fast, I want to be able to get relatively quick feedback on my config changes. Let's say feature flags, for example. But to get that feedback, you actually don't have to ship it globally. It's completely sufficient to say maybe I only put it into one region and see what happens. And then obviously when that region goes down, we can easily just take it out of rotation. And so I think every time you do something, it's obviously important to think about what's the risk profile, and can I find a way to make progress at essentially the same velocity but without taking the risk of, for example, global outages of 20% of the internet.
Are you one of these shops that give unlimited tokens to your devs?
Absolutely. We even put it into our job description. I could not see why I could possibly not want that. I mean, obviously there's always going to be people who abuse some policy, but I mean, how much could it be?
I don't know, you're the CTO. Don't you know about your costs?
No, we had a class... basically, mostly it's bugs, right? I had an engineer who was 10x the second one. First of all, I was impressed. Second of all, we found out that his custom-made coding harness was changing the prefix of the prompt so that it wasn't hitting the caching system. Which is drastically more expensive, right? So obviously that happens, but yeah, I think it's worth having an eye on it, but otherwise I think the more the merrier.
And are your code changes going into production? CEO's code changes, are they going into production?
So my CEO, I think, still deploys an app to Vercel every day, but he very, very rarely does production code changes. And I do, I mean, regularly. About maybe two, three times a week. Nothing super big. I think it's a really common profile people in the room will have, where you say I do things, but not the ones that actually are important.
What do you think the future of your tech organization is going to look like as these agentic tools just get more and more powerful?
I think what's already happening is that the job just looks much more like management than it looks like IC work. And I think that's changed a lot about the profile of the people. And so, what we see is that the most senior ICs are in a way the ones that benefit the most, because they already did a very similar job, but now they just have more minions. And then the other folks who benefit the most are the most junior engineers. Because, for the same reason that they're better at making TikTok videos than me, right? They're growing up with that stuff. I think what's most interesting is what happens in the middle, where people have to still learn to be in, in a way, a new role and also need to be just willing to engage with the technology.
So, are you one of these companies that's really leaning heavily into interns and junior engineers?
Yeah, we are very, very impressed with the internship program. And yeah, we also have a very, very decent cohort of junior engineers.
So, in terms of your organization, what does it look like in a year? What does it look like in 2 years?
Obviously, I don't know. My CEO and I have this quasi joke that... So, right now we're like 750 people and we just quote unquote decided that we cap employee count at 1,024. Nice round number. Which is not really below our hiring plans for this year. So, we'll see what actually happens. But I could see, right, that there's essentially this asymptote, where you grow the company, but at some point the growth... hopefully our growth on the revenue side keeps growing up, but maybe you actually don't need more people.
Is it realistic?
I mean, we see agentic transformation, obviously, according to everyone here does. We automated, for example, our sales lead qualification with an agent that we also open-sourced. We automated 87% by now of our support intake. And that's actually a good example. Did we let support agents go? No. A, first of all, the company's growing fast enough that that would never be necessary, and B, they have a much better job now because they only have to solve the hard problems, which I think as a support agent you enjoy more. So, I think there are some factors that are, you know, at least reducing growth. And so, I do think there is going to be a transformation on that line.
Otherwise, the real journey that I think we're all on is that we're figuring out how elastic the software market is. Right? Because we are making it cheaper to make software, and what's definitely true, and I think we're very much seeing this also in our own numbers, is that it leads to more software. And so, the question is, obviously that's going to balance out at some point in some equilibrium, and it's completely unclear to me right now if that equilibrium has more software engineers than today or fewer. It's very possible that it's more. And it's also very possible it's fewer, right? I couldn't tell, because the maintenance burden that is associated with all that free software is very substantial.
And but also, as long as it gains the corporate activity of wins, it's not worth investing in it, having people who manage it and so forth. Yeah, I can see how you're positioned to support all of this new software that's going to be created. So, I'm pretty bullish on that. But yeah, I just think the big question is whether we're software light or software heavy in this new world where software is free.
I think of it sometimes like YouTube. Right? Before, it was very, very expensive to create a TV show or a movie. Now, anybody can do it. And so, it turns out we were actually video light in 2005 or 2006 when YouTube came out. And I do think, you know, nobody knows the future, but if we are software light, it's going to be pretty great.
I love that analogy, right? It's exactly my point, right? There's going to be more software. And now the number of people that are engaged in professional video production is drastically higher than it was 20 years ago. And again, that doesn't mean there's no changes, right? To quote Ben Thompson, who I think is making this really good analogy, the transformation is probably closer to the one in the '60s, when the mainframes were introduced and the buildings full of quote unquote computers no longer had a job, than it is to the transformation of the introduction of the internet. And so, if you look back at the transformation in the '60s, that was very painful for some folks, right? But overall, from a societal perspective, obviously everyone's drastically richer now. So, in the long term it goes well. And so, I think there's a possibility of a transformation that's very similar.
Last question for me. What's your prediction about the future that's a hot take you haven't shared with anybody else yet?
It's difficult because I tweet everything out immediately. Okay. Well, your spiciest tweet then.
I think what I like in my recent world... Certainly the point is that software, you already mentioned it's free, I mentioned it's free. I think we all realize it's free like getting a free puppy. Right? It has to be maintained. And so, I'm very excited about the role of agents in software maintenance. I'm exploring that. And we touched on how does stuff happen in production? Can I automatically maintain something?
And yeah, but otherwise I'm just in the same position as everyone. I now get an engineer saying, "I built a new file system." And they wouldn't have done that before, right? It would have been just too much work, or it would have been on the plan that took them 6 months. But yeah, I know it's not a spicy take, but I really want to figure out what do I do with that file system? Can I ship it now? Or am I now in a... or is it actually not real?
Article published