The Standup with ThePrimeagen - Cloudflare CTO talks AI, Opensource and the Future

Episode Date: April 3, 2026

Ship with confidence. Try Sentry: https://trm.sh/sentry This week on The Standup, we sit down with the team behind Cloudflare’s “Vinext” experiment an attempt to bring the Next.js API surface onto a completely different runtime. What starts as a simple “why does this exist?” quickly turns into a deep dive on AI-driven development, open source in the age of agents, and what happens when an intern is told to “just build Next.js” . Dane Knecht, Steve Faulkner, and Dillon Mulroy walk through how the project went from a half-finished intern prototype to a full-blown AI-assisted experiment complete with bots reviewing PRs, triaging issues, and even maintaining parity with the Next.js repo itself. Along the way, we get into the realities of maintaining a “not-a-fork-but-kind-of-a-fork,” why developers keep depending on undocumented behavior anyway, and how AI both creates and fixes its own messes . Naturally, it spirals. We talk about Hyrum’s Law in practice, template-string nightmares, “slop” codebases, and the growing question of whether throwing more AI at a problem is actually a strategy. Somewhere in there, we also hit on build systems, performance tradeoffs, and what it means to keep a project “not experimental” when people are already using it in production. Chaotic, honest, and very much how developers actually talk especially when AI, open source, and reality all collide at once.

Welcome, everybody, to the stand-up. We have quite the list today, and we're going to be talking about quite the topic. It has been all over Twitter, the new NextJS clone from Cloudflare Vi Next. And with us, we have on. We have Dane from Cloudflare, CTO, correct. We have Steve, Steve, sorry, I do not know your position. And Dylan, of course, most people here know Dylan, streamer extraordinaire. If you guys could take a moment, maybe introduce yourself a little bit better.

That would probably be the best. That would be better. be good, actually. Yeah, yeah, yeah, yeah, yeah, yeah. Anyway, sorry. Yeah, thanks a lot for having me on. Dan Connect, I'm the CloudFour CTO, been in CloudFERC for a little over 14 years

and trying not to break the internet every day. Okay, that's reasonable. Yeah, because when Cloudflare goes down, so does the internet. I'm Steve Fulcner. I'm the Director of Engineering for Workers, Containers, Agents, SDK, a bunch of other stuff, about 100 people. so responsible for a bunch of our developer platform products. I've been only for two years, so Dan's got a few on me.

I guess we're going in order of seniority. Dylan, go ahead. Yes, I am the least senior by far here. I'm an engineer at Cloudflare. I've been here for four or five months now and working on one of our AI and agent teams. And as chat knows, I do a lot of streaming. So a lot of familiar.

Also one of the founders of Twitter. also one of the founders of tweet mash and the real humans. So I mean, Dillon Moskowitz. He was definitely not moonlighting, to be clear. Definitely not. There was nothing during that time beer hit was involved in. All right.

So I think there's a lot of ways we could introduce this topic. So I think it'd probably be best just for everybody kind of getting up to speed. Why don't you kind of give like a pitch of what is Vine next and what is or what was like the goal for you going into this, shall we say, experiment. I mean, the goal is pretty much everything we do. We do it for customers. It's, you know, for almost five years now, it's been one of the biggest requests is how

do you make next easier to deploy on Cloudflare? And, you know, we recognize we have a slightly different architecture. You know, we have Region Earth. Deploy once goes everywhere. That applies different constraints to how you can build things on Cloudflare. I mean, there's always going to be trade-offs. So we understand that Next was built for more traditional environments and no issue with that. And so we've always been trying to figure out ways to make it easier to deploy on Cloudflare

because that's what the customers are asking for. And actually last summer, Steve pitched the idea that let's have one of the interns just try this. He kind of had the idea that the light surface area with the next API actually could work. He thought it through a little bit. And we brought on an intern who, you know, he gave it a good shot. You know, interns only here for three months. He got a lot of the page router surface area done. And, you know, we kind of put that on the shelf because we realize it's going to be quite an investment to actually.

A lava lamp shelf or a different one? I don't know. Probably more than Steve's garage. Okay. Yeah. Yeah. And then I guess Steve, you know, a month. month and a half ago, two months ago, was, I guess, in his garage and said, hey, I have an electric screwdriver now.

I'm going to, let's see if I can give it a go and finish this project out. Tej, production's down. I don't concern myself with such matters. What do you mean production doesn't concern you? I've shipped 37, nay. 38 features today. Teach always makes the mess and I always clean it up. I'm better than that.

I don't have to be a janitor. Someone has to be the adult around here. Oh, oh. Who is that? It's me, your West L.A. Godfather. John Carmack? What? No, it's me trash. Oh.

Wait. Are you here to finally get management to understand software? What? I'm a West L.A. Godfather, not a miracle worker. Oh, then why are you here? I'm here to tell you about Sear by Century, the world's first AI debugger that actually has access to all of your logs, stack traces, code, commit history, and more.

Code breaks, but you can get the fixed Faster with Sear. Who are you talking to? What? Back to the stand-up. Build with AI? Fix with Century. Yeah, it was really, for me, it was all about AI, right? I mean, next and sort of applying it to Viet was the problem that I ended up picking, but it was more about like, how can I push out AI in all these ways and these limits?

And can I just take it further than I've taken any other project? And so it's just sort of the right problem at the moment. Can we go back to the intern for a quick second? What was the intern's reaction when you're just like, hey, make NextJS for Cloudflare, no mistakes? Like, what was the, what was that experience like? He was excited. It was one of our interns, more ambitious than most. And he really wanted something big and juicy to try.

And so I said, hey, here's a big juicy thing. You know, see how far you get. And honestly, like, we scoped it initially just to pages. I didn't think he would even get to touch App Router before, you know, three months. And he made a decent amount of product on, uh, process on pages. Like it,

it did kind of work, um, at least the basics. And so, yeah, it, it, at least showed me that there was something there,

like a thread to pull. And then it was sort of like, okay, now AI is here and can actually, you know, do the rest of the work. Wait, at that,

okay, so I, how do you make the decision to put something on the shelf at that point? Because you have a somewhat working version of it. You have a bunch of customers wanting to use it. And, but you have to maintain it afterwards.

Like at what point, what was the, the line that said, okay, we're willing to maintain things at this point, because obviously you did not go forward with the interns work. Yeah. Well, first off, this thing was just Pages Router, right? Which is, you know, there's a bunch of people out there that still are on Pages Router and love Pages Router and want to keep using it. So, you know, I couldn't see a world where we would have just, like, done a Pages Router only version. But again, this is where AI just kind of keeps coming back into the story. If you go look at the VNX repo, we maintain it with AI, right?

We have AI bots that are doing triaging. We have AI bots that are reviewing all the PR. We have AI bots that are doing security reviews. We have now AI bots that track the Nextjs repo and then open up issues back into our repo when we find commits that are relevant. So it's like part of why we can keep doing this is because of AI too. It's why we could do it and then it's why we can keep doing it.

I mean, in some ways, the fact that we're also doing this as open source, it's a kind of a bigger experiment on how you make open source work in the AI world. A lot of open source maintainers are really strong. struggling with all the pull requests to have to deal with the comments. And, you know, is there a more a sustainable way? And so far, this has been pretty sustainable. I think there's over 50 committers who actually, when we say they're commitors,

it means they wrote a plan for an agent to implement something. You know, they're still using all AI implemented code, but, you know, they're still committers and they're helping move the project forward. But then, you know, then you have their agents talking to the GitHub comments. And so, you know, we don't have it all figured out. But I feel like there's a model here where, you know, you're applying AI in any sustainable way to open source. And yeah, that's kind of beauty of open source.

I had a so sort of like related to that in terms of, you know, so I did a, like, lot of stuff with NeoVim and like maintaining a fork that like still cared about like we were trying to still make it so that it wasn't like completely different experience compared to using VIM still applying like patches and a bunch of other stuff. I think actually you know NeoVim is experimenting with some stuff in some of the same vein of figuring out like hey how do we not have to spend all of our time like merging over patches from VIM you know like some people that's like their thing Dylan I think you know like there's a few. people who are like, how does this person even do all

this? It's crazy. But like how, you know, deciding like, okay, we're going to have this fork and everything. Like, how do you decide what features from next make sense to go into this? How do you, you know, triage, what things are most important, etc. Like, because that part for me is the really

difficult part about like having a fork of something is not so much like hey, we have this new piece of code, but you also need to, you know, decide how it continues to be a drop interplays. is a dropleton replacement for certain aspects? Or what?

I'm interested on that, like, part of the maintainership. Well, I mean, I think that's part of how you define the mission of it, right? Yeah. The mission is it to be, it's to be a, it's not really a fork. This is a, you know, it's just the next API service, the official API surface, put over a different runtime, really, the VET of runtime. So we actually are not accepting poll requests and feature requests for things that fall out of that. We are following Nodex completely.

Versus today, we launched M-Dash, which is a, I would call that, you know, I'd probably name these different kind of forks. You know, I'd call that more of a spiritual fork of WordPress where, you know, it can import WordPress. It looks a lot like WordPress in a lot of ways. But, you know, it has a lot of unique things that go off the traditional path. And, you know, and I think its roadmap over time will diverge more, like a traditional fork.

You know, I mean, there's a long history of how different forks evolve. Like, you know, you know, WebKit came out of the, you know, a Linux ecosystem. And then Chrome obviously made it, you know, blink. And sometimes they diverge. And, I mean, honestly, if we didn't have forks, we would still be all on I.E. probably. Right. You know, or the Node's ecosystem, right? In that case, Node, you know, obviously had the fork to I.O.

And, you know, it made some points. and it actually brought the community back together in a better place when it kind of remerged back together. So in general, I think it's all healthy. I think it just, you can do it at such a different rate and cost today. That's really the biggest part of the story. What are you guys going to do if you have to kind of compete against some sort of surface area that goes against what you're doing?

Because I know you made like building was one of the big things where you made building work better because it doesn't build every single artifact if they have some sort of static thing instead it analyzes your traffic and it's like, hey, we're only going to build 10% of your assets because if we do that, we're going to cover 99% of traffic.

It's super fast in your build times, not 45 minutes. Are there things they could add that you would have to say no to? Like, is there a world where by next is actually a different fork? It no longer maintains the same surface area. Or are you like hard on same surface area always? I would say right now we're hard on same surface area. always, right? I'm not trying to create, like, drastically different things. I would say, like, never say never, though, right? Like, I mean, we're going to see where this goes. If they

introduce something that completely, you know, is, like, against what, you know, like, we want to do or against, you know, maybe like what we consider our best practice for architecture, I mean, we'll consider it, right? It's going to really depend on the thing and what is needed. I'll be honest, I've been surprised how many people have come in asking for us to fix bugs in next or things that next has said it won't do, right? Um, there's a lot. Um, actually a pretty active discussion right now, a feature from Next Nine that apparently a lot of people really liked that they deprecated. There's a bunch of people that want us. It's like eight versions ago or something like that. What is the feature? Like what is the request going on? They switched

from get initial props, which ran on the client and the server to get server side props. I think I'm hopefully getting the details right there. And a lot of people still like get initial props, right, for various reasons. So there's a vocal community that wants us to add get initial props. I don't know if we'll do that one since it's deprecated and we're, we're, we're still trying to keep true to next, at least next 16, like where next is at today. But it's the kind of example of things that are coming in that people are asking for. So there's like smaller ones, like little behavioral tweaks where somebody maybe says, oh, next should have always done it this way.

Well, you just do it that way instead. But so far, we've been really holding the line of like, let's just do it the way next does because we wanted to just, you know, match one for one. So there's a, there's a kind of a funny law that in programming, we have a lot of laws in programming, right one of them's hiram's law which is effectively that the internals there will eventually be features that aren't documented that you rely on that people rely on how have you ran into any hiram's law that's like a non-documented feature but just the way that it was programmed that people are like hey this doesn't work like vrcel i can launch this on vrcel but i can't do it on cloudflare because

of some funny internal if statement that you just don't have captured i'd say some of that's coming from the community packages right so think that are people have plugged into the next internals, right? Like other vendors, other people supplying, like, you know, things that plug into your next JS app automatically and hook things in. That's where we've probably hit the most friction is that they either were knowingly plugging into undocumented next internals or they didn't know they were. And now they're finding out, right, when they try to come use you next.

Like when someone imports like, do not import this or you will be fired or something like that? And they're like, well, bro, but you guys aren't supporting. Do not import this or you will be fired. That's literally the key to my workflow. You'll see if somebody imports from next disk, right? Like that's like next X, you know, internal distribution. Oh, nice. That's where they usually end up into trouble.

Do you guys support importing from Vinex slash dist? Or is that just something that you're like, no, we will not do internal? Right now, no, we have not done it yet. But again, never say never. The end of the beginning, like, we're doing what customers want. This whole thing is about like how, how come? can we give people a better experience running NextJS, like everywhere and on Cloudflare. And so if there's enough demand for something, we'll at least think about it.

The spike on new users that day was, you know, one of the biggest one-day spikes ever. I mean, you can see that there's pent-up demand. And, you know, that's why we do things here. What's the, like, you know, obviously right now it can't do literally everything. what's the path or like what would make you guys feel like it moves out of like an experiment into something that's like not experimental or you would say is like oh word we feel good about this we're working through that now so probably the big one you already mentioned is as proper pre-rendering for everything i mean some people still want that right they don't want the

percentage pre-rendering and so uh we've got some stuff going on right now for that um there's some ways just some like a lot of little like things that next does a little differently and we're trying to figure out, like, do we want to do it a little differently? You know, some of these things don't map cleanly between VET and TurboPack, right? So there's stuff where we're trying to still work out some details. It's all small stuff where, like, like a hard navigation might happen in our case, but it wouldn't happen in Next because, you know, they do some sort of like soft navigation, you know, hijack into what the browser is going on.

So there's a few examples of that. But it really mostly works, right? Like, if you look at like the bulk of what people are, you know, doing with Next and not sort of the long tail of new API features, but routing and hydration, server-side rendering, all works. I'm interested a little bit in sort of just like, you know, you said a lot of it is, you know, people with their AI agents. Like, I'm interested in knowing, like,

how do you guys manage that from like a, hey, it's a fast-moving thing? We're experimenting. People are running this in production. How do we make sure we don't just, like, in Slopify our entire, like, app? or release like, I mean, I know that it's all the rage these days to add 37K lines of code a day. And you're like, if you're not doing that, you're getting left behind. But I'm wondering how you guys, you know, prevent like that situation happening from some of the stuff you said at the beginning.

Yeah. So I'll give a couple examples. I mean, number one, that we rely on the tests, right? You know, we ported a bunch of the next J.S tests, not all of them because they didn't all make sense to port, but we ported a huge suite of tests. And we're still porting more. So it's just having that confidence that these tests are doing what they think. they do, so we're not breaking users. We have end-to-end test, unit tests, and then we kind of have a

whole suite now of, like, smoke tests that we run against production deployments. The other thing, too, is there's been a couple times where I've had to say sort of go in and unslapify things with AI. So probably the best example is that there was a part that was about a 2000-line template string in there that was like a lot of logic got like, you know, like clobbered into this thing. I'm not going to lie, it was pretty bad. And I just sat down one day and I was like we cannot have this in here this is unmaintainable for humans and AI so I spent I spent the weekend kicking off a bunch of PRs just bit by bit got stuff out of there split it out in its own modules and so like just going through and finding where the slot happens

and then sort of saying no no I'm going to spend time deslopifying that part I've actually seen that exact thing many many times even using cloud flare like hono just saying like hey AI agent let's go build out this thing it's just like gotcha dog it's just one it loves giant HTML strings or a JavaScript strings and then it becomes impossible to start debugging because then it's just this crazy cycle of how do you actually know it's it's tough it's a tough world it's no linty no type checking it's just like the wild west yeah so yeah just interpolating strings yeah I'm like that's my favorite way to do this this is this is why I write full stack JavaScript is so I can throw away JSX and I can use template strings

Steve, I actually have a good question for you because like you probably Hey Dylan you're you're a guest to you you're not an interviewer what the head I'm just kidding this is my good I'll allow it we'll allow it we've talked about we talked about this a little bit early when you started the project but I wanted to follow up and ask the question again now that you've like had you probably have more experience than most people in driving a large code base with exclusively AI and like finding slop this template string literal that you were just talking about like have you found good strategies for

like building tooling for either the repo cicd or like harnesses to like prevent the same mistakes over and over again or like what what are like your tips for like there's a whole conversation to be had about how to properly do like agent take development like i'm very much in the camp and like i want to keep my work small i want to keep it isolated and i want to review every single line of code that goes in but like vinax being like a good experimental repo and like how can we like really maximize this? Like what have you found to work on putting good guardrails on the AI and getting good results? I mentioned already tests, Lintene stuff around well formatting matters a little less but I think it still helps right so

some of the diffs aren't you know ridiculous. So we put a lot of effort into that. I honestly like I would say once a week I just go ask AI like hey what's the sloppiest part of this code base and how can we fix it, right? I think that's an important part. We also, I do have a scheduled process that updates agents.m.D. every few days. So it goes and looks through PRs, looks through the comments on those PRs where we had AI, you know, finding stuff and saying, okay, how can we make sure we don't, you know,

make these same mistakes again? This stuff is pretty wild. Like, every time I think I'm like, oh, I'm kind of hitting the limit, this is like, it can't figure itself out. The answer just kind of seems to be throw more AI. it and it sort of like rescues itself right from the brink. I don't know. So this is sort of like a lab for us for, you know, how we do things internally.

I mean, internally, you know, we are still very much in the, you know, engineers write the code with AI, they commit it and, you know, much more traditional still, you know, pull request process via human. But with AI assisted, of course, and, you know, we have strict rules like no vibe coding. You have to read every line of your code and you basically test to it when you do it. But we obviously see that things in this project where we want to apply internally and try to think about how you do the guardrails not on a, you know, a project that is one main maintainer and versus like, you know, a 2000 person engineering org. And the things that we found work well there is, you know, there's linting, but there's also, you know, how you build. And so, like, we've been working internally a lot on what we call like the engineering codex, which is a set of RFCs that,

get kind of rolled up into a kind of like 10 commandments of a lot more than 10 on how you build everything. And then, you know, an AI review internally, does it just do a security review, doesn't just do a, you know, performance review? It actually goes over the codex and says, you know, is this how you build things at Cloudflare and kind of reviews those? And some of those things are things like, you know, kind of, you know, no long HTML strings, you know, obviously that's the thing that it would catch and hopefully kind of put these. the AI back to the PR reviewer back at it to review it. But you can see that those things can kind of get applied to more purgentic workflow in the future

as well to those kind of guard rails. But I mean, you have to treat the AI like as if it was another engineer. I mean, AI is kind of just making us all clean up a lot of the tech debt that we had where our readmees weren't up to date. Our comments weren't good. Our code wasn't structured great. you know, AI wants the same things as, you know, any human developer wants when they come into a project, really. Realistically, you're obviously approaching Vynx much different than you're approaching everything you do internally, right?

I forget the name of the big edge you had a name for it. It was in Lua for version one. It's now in Rust for version two. I read so many of your blocks at this point. I know there's a name for it. But could you ever, would you be okay with people trying to take the same approach that you see? and Vine Next into that area? I think, I mean, today, probably not quite just because, I mean,

but I think you'd have to do a whole different set of test suites that, that, that just the level of detail of writing something that is so specific to our hardware so that we get, you know, every CPU cycle is, you know, perfectly time. So we can, I mean, it's the only way we can run at our scale and offer so many free things is if everything is kind of perfectly aligned there. that takes a lot of innovation that, you know, that, you know, I think the AI is still good at how you copy existing patterns and you replace it. I still haven't seen AI, you know, invent a new algorithm or invent a new way where, like, you know, building FL, we also have patches that go all the way into the kernel that change how IVV6 hash flip, IBM4 hash looks happen, right? like AI wouldn't know that in order to build this, we also need to do a kernel patch to change how we, you know, do these socket lookups, right?

So, I mean, the level of complexity is a little different in those cases. Do you think any of it also is different, like for this one, a lot of it is there's already a well-defined, like, shape and stuff that you're trying to match against versus like, hey, we're starting. a brand new greenfield project. Like, I've seen it go off the rails a lot more often when I'm like, hey, like, let's just write this. And I say, like, okay, go. And it spins for a little bit. And it comes back.

I'm like, this is so bad. I can't believe that this generated this as opposed. So I'm wondering, like, your thoughts on, is this like a particular kind of repo where it's special that this kind of strategy would work compared to like regular? I'm driving my own product, I'm driving my own thing, we don't have this set of constraints like an API. I think today that it's still very much, that is a different process, right?

I mean, in some ways there already is a spec for this out there that AI knows how to kind of follow and go through. I mean, you know, I can think of a few internal projects that have existing shapes that we largely can do that with, but, you know, so many things that we do are just, They don't have comparables out there, right? I'll like middle ground this one, which is I do think having the next test suite was a really good starting point. But now that we're into the territory of having to really make decisions about sort of more architectural things where maybe the surface area is the same, but like underneath the hood, what are we doing?

Are we doing things that make sense for VET and not things that make sense for TurboPack? like it's almost like we've had to bring the human back in a little bit more in the loop, right? Where now we're actually having more discussions about like, okay, is this the right way to do it or not? And not just letting AI go wild at the test suite. So definitely, if there's anything I've learned from this, it's that humans, in my opinion, aren't going anywhere in software development. But our role is going to change. I mean, I still think there's going to be over the long term, more engineers, not less. You know, we see people wanting to add engineers in our legal department, in our finance department.

You know, the number of places that you need engineers to do, you know, the thinking of architecture. I met with a bunch of interns this morning, and I said, you know, we talked about how, like, how what they do versus what someone came in five years ago is going to be different, right? You know, I encourage them to work on their communication skills, their writing skills. their problem-solving skills, as opposed to just, you know, expecting to be in front of a computer and taking a Jira ticket and, you know, solving it. Like, you know, you have to be ready to do higher-level things. But I think there's definitely going to be a role in a need for that. Yeah, I mean, very little of my career has felt like I had a clearly scoped piece of work

that I could just take a J-R-ticket off and, like, do it anyways. That always seemed like, I guess there were. were people doing that, but I always felt like that's weird. I've never had that experience, like, at work where it was just like, yeah, you just, here's the well-defined task that's obvious what it's going to do and how long it's going to taste. Like, just go spend your time on that and come back to us later. Like, that didn't, I don't know. For me, that was like not really part of any of my jobs after like year one of working. It felt like. I've had, I've had that happen once. And, uh, I realize now, like, looking back on that, that's also the same thing that I did, uh,

TDD with is because it was so well defined that we had to sit down for so long to come up with it. There's like, oh, TDD also works in this situation, which probably highly aligns with this type of approach. It's like, oh, we already can build out all the constraints and the interface and everything. Therefore, everything just works. And now it's neat. Like, if I had AI back, then I could just say, go now. All right. So I guess I kind of want to switch gears a little bit in the more interesting side of this discussion,

which is the receiving of this, you know, library slash, what? what do we call framework? I'm not really sure. I never know when to call. I don't want to, you know, use the F word when people get really offended about it. I know. It's a, or meta framework.

It's an MF. It's an MF. We do not say that on this podcast. Not of this podcast. So with that, with that in mind, how, how was the receiving of it all?

Because it's hard to kind of suss out what people actually feel when you just go on Twitter. And so I'm actually curious what that was like for you guys. I can go. Honestly, like I,

honestly, I saw a lot of the Twitter. stuff, but I tried not to pay too much attention to it. I think when we launched this, I actually just turned off my phone and went on a walk with my kids or something like that. I'm not going to pay attention to that the rest of the day. I want to build something that people like. That's it.

At the end of the day, I want to build software that's useful for people. So I've been very focused on the people that are actually getting value out of this, right? I mean, Dane said, you know, 50 plus contributors, I think at this point, we've merged like 400 plus PRs in a month. I mean, this is like an active project. And so the reception in my mind has been really good because I'd see people using it and getting value out of it, right? And people outside of Cloudflow, to be clear, right?

I mean, from day one, this has worked anywhere. It's just a VIT plugin. So you can VET start and run it on any server in the world, and it just works. So I think I've been very focused on that aspect of, like, if I can make software that people enjoy using, and I'm going to keep doing that. I mean, as you said, it does go back to the customers for us. I mean, obviously, I mentioned that it was, you know, the number of new users and new customers came that day was just a huge spike. So, which, you know, that's gratifying, you know, that people are using it and, you know, the there's all the different metrics on, you know, what could be success there, you know, a number

of active developers for us is really important. So, you know, that was a success from that. You know, all the Twitter, you know, it is what it is. It's like, you know, it can be a little fun, you know, but, you know, it's, you know, it's short-lived and you move on and get back to work, really. I think the interesting thing here for me, too, about, like, the reception has been around, like, VET, right? I mean, basically all the frameworks, except for Next have standardized on VET. I mean, I think that's just how it works now.

And so you, you know, Next has sort of been telling everybody for years, like, well, we use turbo attack because we have to because it's, you know, whatever, better or faster or all these things. And I think there's just been, like, this pent-up sort of latent sense of, like, well, what if you had just used VET? and this answers that question. So when I built this, I definitely did not spend any time on performance

or sort of like making build times fast. That was not what I was trying to do. I was trying to get the breadth of coverage with the API. So it's a testament to VET that just literally the first version of this was six times faster, right? Like that is like that that's how powerful VIT is and how good it is as a bundler. I mean, yeah.

I mean, what I haven't built, just the, you know, how many people have been able to build, great things off of it. I mean, including, you know, Astro, right? This is really more of a story about how great Vita is, right? Like, none of this would be possible without that. I mean, you know, maybe it would have just, you know, been a lot more tokens. But, you know, I think the fact that a design like that has been able to kind of get you

the ubiquity and still remain performant and it's pretty amazing. We've got, I would say, like a wide range. of devs that watch the pod, can you explain to people who are not in the web dev world? Why is there a thing called VET? And then why is, and also why don't people use VET

and they use other things? Oh, I thought for sure you're going to say, and why isn't it pronounced by it? I was, I was, right? I saw, I threw that up for you, probably, because I knew that was your one, and then you didn't even go for it. That's a little week, it's clearly right. Okay, keep on going. All right. It's funny you ask

this question for people who don't understand web dev, and then I'm, like, do I, we have an hour for me to spend talking about, like, the history of bundling on the web? Because you must start with grunt. And then I want to... Okay. You got back to grunt, browser thigh, Gulp. I would love to start with grunt.

Listen, I will die on the hill. Gulp was one of the greatest build tools of all time, and I will die on that hill. I agree with Dylan. Dylan is correct about this. I don't understand. I don't understand. We can't just use make for all this, to be quite honest. I love...

And there's a group of people that agree with that. I still use that. I do have a hot take about Make. I think Make is overutilized in developer ecosystems outside of WebDab, outside of web dev and severely underutilized in web dev. That's my Make hot take. All right. So for those that have no idea what fight is.

You didn't want to follow up on the hot take project? No, we're not because we are so far off. We did. Okay. People are still like three quarters of a. audience, they're going to be like, okay, so what is Vite and why do they keep talking about Gulp when I asked him about Vite? It's a very confusing one. That's what I'm saying. People actually don't know. I will do my best to do this. Okay, so when you build a web application,

you need, you have things that need to all get bundled together and deployed, right? So you have your HTML, your CSS, and your JavaScript, right? Paper it over like 10 other things, but like, let's just say most of it is that. Now, you need something that understands all of these things and the relationships between them and that is capable of basically admitting something that is just, here's your deployable site and you can deploy it to the internet on anywhere and it'll just work, right? So over the years, there have been many takes on this and for, and many iterations and things come and replace the thing before it.

And the last big thing was Webpack, right? So Webpack for a long time was sort of the king and everybody was like, okay, you use Webpack to take your raw source files and turn it into something that is optimized to be an actual a website, right? If we deployed raw source files to the web, we would have all kinds of problems, right? Which there's people that think you should just do that, but we're going to like ignore those people for a second. Let's go DHA. All right, keep going. Sorry. Sorry. So then Webpack has got, you know, again, I'm saying like offending people left or right. There are people that think Webpack got slow and, you know, it was hard to configure and had all these problems, right? And so there was a

next generation of things that kind of decided to try to replace Webpack. There's things like Parcel, RSPAC, various things. VET is one of those things, and VET, and again, I'm going to just sort of like blanket statement this, kind of just one, right? So VET is the underpinning bundler for most frameworks today. I would actually say any popular framework besides NextJS uses VET. Now, what Next did was build their own thing in Rust called TurboPack that they saw as like a spiritual successor to Webpack.

I think one of the original Webpack maintainers is very involved in TurboPack. And so they sort of had their own take on what this has looked like, but nobody else ended up using it besides Next. And so that is where VET comes into the picture. And so there's been this like sort of very simple fork in the ecosystem of whether you use Next in TurboPack or whether you use some other framework and use VET. Or you just use VE. VE is actually very capable on its own. You don't need a framework you can just like use VIT. It has very good sort of primitives and APIs.

You can just deploy a React app on VET and it works really well. Does that make it a meta framework? I mean Dane we only have one rule Dane and you broke it We don't say that word here Okay To put it maybe help color some people's perspective If you have a language that was invented beyond 2008

You typically the language itself also provided all the tooling So Go has its own tooling Rust has its own tooling Zigg has its own tooling and all that Some of the older languages you don't get all the tooling kind of also thrown into it so it gets really complicated Everyone knows about you know Java Java was very very difficult back in the day C is very, very difficult as you get huge build systems devoted to it.

And JavaScript is the exact same thing. There is no, you know, committee that owns the web, HTML, CSS, and JavaScript. These are all individually, you know, developed items all falling under the W3 consortium and some NTC39. Multiple, you know, multiple things are all doing it. And so they get a lot of stuff done fast. Yeah. So that means tools, there's not like a department of tools.

So everyone kind of makes up their own tool and then some of them got popular. There, in fact, was even Snowpack at one time, which I think got renamed to Parcel potentially. I can't remember. But there's been a lot of, a lot of bundling in the web world. If we just make a new one, do you think everyone will use ours then? Yeah. There's a small chance, TJ. I fully support it.

Just one more, just one more framework, bro. Just one more framework. If you do that, I will fork V-next, and then I will rewrite V-next and the new thing. V-even-nexter. Nice. Well, the way, or we have to change the prefix, right? because the VI for it is for V, I'm assuming, right?

Yes. It'd be X and X. We X-Aid. I'd XNAID. There we go. All right, so, how about some of the sentiment? Like, did you have any uphill battles in the sentiment change?

Or did, was there enough social pressure that you had to, did you feel any of it? Like, not just like, hey, we put our heads down. We moved on. We had a great customer day. Was there any fires you had to put out or things you had to take a little bit more time on, kind of explaining your positioning? So, I mean, we have a ton of respect for the next JS team. We're working with them closely.

A blog recently came out about Next Adapters that we helped work with the team on. I mean, they built a great product. I mean, the testament to just the number of developers that use it. You know, obviously, by tweet with a little tug-in-cheek, you know, it was not meant to offend anyone. Because, I mean, we do have that in huge respect. So we did spend a lot of time with the team and making sure that they knew we were committed to the next adapters

and that we are still committed to that because we've been working with them on that. And we're still very excited for that to come. I mean, and Steve and his team and Fred from the Astro team all spent a lot of time with them on that. And we think they're doing great, work with adapters and, you know, and, you know,

a lot of this, this is how open source works like, you know, and when adapters gets there, obviously, then, you know, maybe we won't, we'll just support V-TenX and Pure Next, as opposed to also, there's a whole other thing we haven't been talking about Open Next. But, you know, I think the pressures and forking is how you kind of push back innovation when there's not, you know, complete community support for the direction that you want to take something in.

All right. And then I did want to talk a little bit more. I know, TJ, you kind of alluded to it earlier, kind of about this whole, like, using AI on a purely on the project. Has there been any downsides besides for some sloppification, has there been any downsides or things that you're finding frustrating in this more purely AI approach to building something that is largely customer facing? Yeah, I mentioned sloppification.

I'll say sometimes I just feel like I'm a little babysitting everything too much, right? I've got like maybe 10 different workspaces going and they're all kind of going along in the background and then I'm losing track of what's doing what and then I go check in on it and I'm like, oh, like, what did you do here? You know, you just went down some weird path. And so it definitely feels like right now I'm sort of this glorified AI babysitter. And I want to believe that like as these agents get better, the agents can do more of their babysitting for themselves, but right now it feels very much like I still have to be, like, sitting there,

like, minding them every day. I think that's sort of... I describe managing your own team, Steve. It's sort of interesting because, like, I gave a talk at an event in SF about this and sort of contrasting the difference between managing humans and managing AI. I mean, AI is better at taking feedback than humans are, right? I mean, you can just tell an AI it did a bad job and it won't get mad at you, right? But also, like, so it's, somebody asked me, they were like, oh, you know, is your management skills

translate? And I said, not really, right? Like, I mean, humans, humans are like squishier, right? And we need, like, sort of more like thoughtful feedback. And AI, you can just kind of say, like, oh, this, this sucks. Just do it again, right? You know, and it'll just do it again. So it's been interesting. There's a less overlap there than I thought there would be. We're just laughing about this recently, Prime. I were working on something. And he, like, told, like, hey, move this thing to the left and then it did it. And he's like, no, put it back on top. And I'm like, I'm just imagining if it was a person on the other end and you're like

yelling at some junior dev. And it's like, move the couch over an inch to the left, know your other left kind of situation. But AI doesn't care. It doesn't care. It doesn't care at all. It'll just, okay, I'll put it back on top. No problem. It's interesting to see the range of outcomes, right?

Like if somebody writes a document for me and then, you know, I say, okay, this isn't very good. You need to make it better. You know, maybe it'll get a little better, right? But somebody's not going to like rewire their brain overnight. But AI really kind of can. You know, you can literally say like, no, this is entirely wrong. Start over. And it can do something entirely different, which humans are, it's hard for them to make that level of adjustment in relative to feedback.

I'm a little bit rambly, but like there's, like, I don't have a takeaway. other than I'm still trying to figure it out too. There's this kind of process where, you know, they say that writing, like how you write is how you kind of express your opinions or how you think through stuff. Like it's kind of like one of the big signs of intelligence is your ability to write out your thoughts because you have to organize and actually go through stuff without the actual activeness of programming and then a lot of more and more feedback about, say, the interfaces and all that of how you interface with stuff kind of just also just being vived out where people

can't really actively know what the interfaces are, maybe you're not as familiar with them because a lot of it is vibed out. How do you kind of come up with better ways to work when these layers are becoming more and more fuzzy because you don't look at them every day. You kind of look at them, well, we can all agree we look at them less than we ever would, say, five years ago.

So how do you know that you're even building the right direction at this point without like that constant daily, everyday, thinking about it like in the trenches, not just from a high-level view? That's where like experience probably comes in, right? Like I'm almost at a bit of an advantage there where I've been in this space and working on these problems for so long that I have a lot of strong opinions about what should be done and how it should be done. Even if I'm not writing code every day, right? Like it hasn't been my job for a while, but I still have opinions about the JavaScript ecosystem and how things should be working, right? And so there has been times with AI.

They will happily go off and build something that is wrong if you just let it. And then we've had that happen on this project. And then I have to step in and say, like, no, no, no, no. I am 100% sure that we should do it this way because I have, you know, 15 years of experience that tells me that's the way we should do it. All right. And that's where, honestly, some of the other people who've been involved in the project, I think, have, you know, like, we have some fantastic contributors. But I think there's been a couple cases where they've just went and built a thing because somebody asked for it or AI just said, oh, I just do it this way. And they don't have that, like, depth of experience to say, like, no, no, no, no, this is wrong.

We're not going to do it this way. How do you think people are going to get that experience in the future? I think about this a lot and I don't know the answer, right? Like I have thought of this. So I have a more mid-level junior dev on my team. Oh, sorry, we're out of time. No, because I'm just kidding. You guys, we have a mid-level junior dev on our team.

And like, I mean, Prime and I talked about this when we're in San Francisco. for probably 30, 45 minutes. Like it, I think it's a real fear because like, how do you learn this stuff without like just struggling through it and making mistakes over and over and over again? But like the process I've been finding working. One is like we've been doing like, we'll have like, I mean, the whole team is like basically leaned into like agentic programming, right?

But like what we'll do is we'll push a plan or a spec PR up first. Like literally just the markdown document. that somebody on the team iterated on and, you know, they know the feature they need to want. And then we'll review that markdown document, like NPR, humans doing normal co-review. And this has been like, I think this has been a really good way for knowledge transfer because, like, with experience, you can see one, like, you can just know, especially like when you've done enough, like, agentic programming, like you know where the clanker is going to go off the rails. You know where GPT-5-4 is going to go write some stupid is record or normalized function.

Bro, it loves his record. Dude, normalize is crazy, too. I literally have wind rules blocking it. I'm pretty sure Sammy pre-trained it with that to get a few extra tokens on every request. That's my opinion. I don't put my keyboard on and agree. Yeah, that's what I'm saying. But, like, in that case, like, you can also start picking apart the architecture better.

and using that to refine it. So like when more junior devs go to implement features, that they're going to have a higher degree of success because you've looked over it architecturally. And like I also like don't know if I agree with the stance that we should be thinking about and looking at our like interfaces and APIs less. Like if anything, that's where I'm spending way more of my time.

Like I try to break work down really, really tiny and I start at like the interface. level and I actually think like shout out O'Camel like thinking in terms of like modular programming and shout out like one module per file operating over a primary type get the interface is really really good and strong and then leave the implementation up to the client critical go build like that seems to work really really well for me yeah I've I've done a lot recently with just saying like you will never suggest a change to me that doesn't show like the interface. I don't care if you put like dot, dot, dot, dot in the middle of the function. And you're saying like, this part's fine. You can do whatever

you want in the middle. But like if we can constrain it well, like on the outside with the types, we can get very far. And usually like it's much more apparent to me like from the get go, what's going to go wrong. It still seems difficult for me to figure out how someone would get some of those skills, though only through prompting. I've actually been toying with the idea of just like doing, whether it's like in the same project or a different project, just

like all the way, no tab completion, nothing, like for a set amount of hours every week. Like that's what I would definitely recommend for someone who hasn't written a lot of hours of code already, is thinking about like, hey, for some amount of time every week, you should just go write some

code by hand and like figure it out and find out what's painful and what does and doesn't, doesn't work, even if it's part of a bigger project. I do it actually every morning for an hour and a half. I do it every morning. Yeah. There's all this. I did this, some of the pun on Twitter a couple weeks ago.

It's like, I think it's called Blumery and it's like this blog post. I think it's called from Orda Iron. And they have like this skill, like an agent skill. And the skill, once you load it, walks you through handwriting like an actual agent from scratch. Like step. step and like I think there's like a really good use case here where like you could have more principal engineers or devrels or somebody constructing like maybe like you're working on a team that's

working on a giant astro project or a giant next j s project and like teaching the skills through that way might be useful um yeah i like it i i also agree to you guys like i don't i don't know how you pick up these skills and intuitions without having like handwritten and screwed up and caused incidents and outages and or seeing things go right over the years. So like it almost feels like it's more like a more than ever like a trade thing where like stuff has to be passed down more like intentionally than we have before. So my early programming days where Ruby, like the heyday of like peer programming, doing like katas, like TDD. I had a like a mentor who basically sat me down one day and was like,

we're only going to write test today and you're just going to have to deal with this and you're going to like sit there and learn. And like, now I don't TDD anymore, right? Like not how I like to program. But I learned the value of what it was and when to apply it and when it made sense to do it. And I was like forced to do that by somebody. And I sort of wonder if we're going to have to do that same thing with some juniors, right? Do you think the world can even handle that at this point?

Because it seems like based on Twitter, everyone's produced in 10,000 lines of code. Like can they actually satiate this? I don't think it's like a, a, when you program you have this experience where you actually feel like you're doing things. Like it's very entertained. There's like problem solving. There's putting together stuff where it's prompting. I do at least personally, I get significantly less of that. But it's a lot easier.

And so can people even slow themselves down enough to practice the base. skill at this point? Or is it too hard to convince someone like, no, you got to stop being productive in your version of it and actually just go out there and hand cut down a tree for a little bit? I mean, I think we're in the early days. I mean, the euphoria, the dopamine hit that you're getting right now, just like early COVID days, the productivity gains, you know, everyone was getting, you know, it won't be sustainable. I think, I think, you know, people will have to kind of, it'll go back to a kind of more of a midpoint at some point where there, there is a better balance.

It does feel good. It's like playing slots right now sometimes. You know what I mean? Like I don't gamble in my real life, but I'm willing to do a little bit of gambling on some coding. You know what I mean? You pull the slot. Did it come out with something sick?

Did it update the page right? Ooh, it did it hit. It's good. It's coming up sevens. So I think there is something actually like very, like under explored about that aspect of like how people feel when they're doing like agentic stuff. It like it turns out like loot box.

are really fun. That's why every game has them. So, like, then they're making a lot of money off the loot box spin and a sparkle coming out. So it's like, I don't know what, I think, actually this is, I think developers think that we're super rational beings who only pick stuff based on rational reasons, but then if you know any software developers, like, oh, they're not actually that rational. A lot of stuff's based off vibes and, like, how they feel, and like, they met someone that they liked, two said this so then they like this thing too which is fine that's me you know like i i just

recognize like a lot of what i do is off of vibes medical someone cool told me oh camel's cool and i was like sick i love o camel um and but so i think you know sometimes we're like oh i would never get tricked by loot boxes and then you're like bro you're loot boxing so hard right now with your agents there is something about that i i have to say that because i've forcefully put in my um my life a 100% vibe-coated thing just to like feel the slot machine to understand how far I can take things to really try to quote unquote hone these skill issues that I always have and the part of that I realize that when I see the reds and greens fly real fast like when composer two is going fast like there's part of me that gets like oh yeah dude that's exciting like look at this gel this is going

a good change here we go good change and then sometimes it's not a good change it's frustrating it's very interesting but when it hits man when it's like Disney World the whole day at Disney World isn't good. We have the highest highs, right? You know, that's what I'm saying. Disney World sets it up that way, too. They don't care that most of the day sucks and you wait it in line. It's just about five magical moments with your kids.

And that's how they make a trillion dollars a year. I don't know how much Disney World makes. Don't quote me on that guys. They make a lot. Turkey leg and adult whip, I'm just like, I'm good to go. I'm happy camper for the rest of the day. Exactly. It's a small world comes on and you're like, well, that's not leaving my head for six weeks.

All right, well, we're about the run out of time with you guys. I know you guys are on tight schedule. So is there any last takes that you could give us on, say, how you rolled this out, any takeaways, things you would have changed? Any blockers? Any blockers? Any ways you do, any things forward? How are a direction you want to take them? I'll say, like, the best thing you can do is go try it and use AI, right?

Like, when we've been very upfront about that, the read me, the first thing of the read me is like, quick start, migrate to V-next, put it into your clanker, right? Like, that's what we want you to do, right? It's, again, AI everywhere, AI end-to-end. And then if you hit problems, tell your AI to go file GitHub issues about those problems and explain that. Like, some of the best feedback we've gotten so far has been exactly with that dynamic. I kind of tell people, like, if you're a human and just want to try this out as a human, like, you might just not have the best time because it's not really designed for you, right? It's designed for this new world.

So please try it out. Please use your AI to do it and tell us the problems. Can we have a 1-0 by July 4th? Oh, 1-0-July 4th? Dane just asked me like, when are we doing one-oh? And I was like, I'm like a month or two. I get him on the spot now. Let's commit on the podcast right now.

This is the stand-up right now. We need to know what, when is the release date? I'm blocked. July 4th, 1.0. Dang, I want an America day. That sounds awesome. 250 years of America, baby. Can you turn off Cloudfire support to the UK on that day also?

Like, really celebrate America? Oh, I love it. It's available. everywhere except for the UK is hilarious that's good right that's good the marketing strategy you know really good really get people excited oh that's good i like that we need to do we do we do have to do maintenance on physical machines every once in a while maybe that day just you know yeah some of our UK pops what a weird coincidence what a weird coincidence Dylan any blockers uh i am currently blocked on all my work by trash dev i'm a little disappointed

he wasn't here to work that out. You're waiting on the receipts app or what? Yeah, I just like, I can't. He's got to get his stuff together. My advice to everyone is slow down, make tiny changes with your agents, review everything. Don't just throw mountains of code at your coworkers and try a pie agent. As a quick post-mortem, is that what you did after you deleted all of the code

while we were on stream in San Francisco. I don't remember that ever happening. I just remember 80,000 lots. Josh, get the click. Josh, we have it on video. You're in trouble. Mr. Slowdown over here. Oh, yes.

And also righto camel. For sure. Oh, base. Nice, nice. Dane, anything you got to say? I mean, step away from the agents. Have fun. Have fun with your team.

I mean, we still live in a world fitful of humans. and you know the best part of my job is actually getting to work with people like Dylan and Steve so you know don't don't forget don't forget the humans prime any blockers uh just image loading in obs I got to figure that out oh yeah I actually believe it or not I tried to open your slop fork or just your slop repo and it didn't run at all in my machine and it had three it had a Postgres composer up but it said it was running sequel light so we'll we'll follow up with that offline we'll parking lot that parking lot that I don't have any blockers I'm just ready to for this episode to end.

All right. Thank you guys. That is the stand-up. Thank you, T.J. For that lovely ending. Thank you, Dillon. Thank you, Steve. Thank you, Dave for joining us.

I hope everybody appreciated this. This was very interesting. Because this is, like, really the first major project that is out there for a lot of people to use. That is going to be purely AI-driven. So, all right. Bye, everybody. Moot up the day.

Vibecoating errors on my screen. Terminal Coffee And here