TMiR 2026-05: Who even is on the Core team anymore, TanStack got pwn'd bad

Transcript from Friday May 29th, 2026

Interview

Carl Vitullo: Thank you for joining us. We're coming to you live from Reactiflux, the place for professional developers using React. And I am Karl. I'm a staff level product developer and freelance community leader/entrepreneur/I don't know what I am anymore, here at Reactiflux, where I do community programs like this and build some tools to help keep the community operating. [00:00:00]

Mark Erikson: And I'm Mark. My day job is at Replay, where we've built a time traveling debugger for web apps, and that can be used by both humans and agents. And in the last couple months, I've gone between building MCP tools, doing product manager work, being a dev rel, going on vacation, and now I'm trying to figure out what I'm doing now that I'm sort of back, except that I'm going on more conference travel shortly. So it's kinda crazy right now. [00:00:19]

I do Redux stuff and I collect links. [00:00:41]

Carl Vitullo: Man, we're all doing too much stuff. It's just too many things. [00:00:43]

Mark Erikson: Indeed. My... I, I needed that vacation. Two weeks of golf in Scotland. It was fantastic. [00:00:46]

Carl Vitullo: Yeah, that's pretty good. Scotland's great. I love Scotland. [00:00:52]

Some podcast meta

Carl Vitullo: Okay, let's get into it. Before we go into, like, new releases and whatever, some, like, meta discussion whatever, historically we were co-hosted by Mo, who brought us some lovely React Native and agency perspective here. He's had to step back a bit because of just, like, personal things and work busyness, and he just hasn't had the time and energy to really go up here. And I guess I, I also wanna mention, I am feeling somewhat similarly. I've been doing this for, like, three years now. I'm no longer reading React and web news at the level of intensity that I historically have been. [00:00:55]

So, um, yeah. Mark and I are talking about how to continue this. This is a valuable service. I think this podcast is good. I want to keep it going. I think a once a month news check-in about the ecosystem is really valuable, so I wanna keep offering it. But, uh, that's where we're at. So just FYI, stuff is gonna change. [00:01:25]

Stuff has changed. Stuff will continue to change. Just like life. [00:01:40]

Mark Erikson: Yeah, that sounds all too real. [00:01:44]

Carl Vitullo: We're gonna try and keep doing this, but it'll be a little different than we have. [00:01:46]

New Releases

Carl Vitullo: But yeah, okay, into some new releases. [00:01:49]

TS v7 beta

Carl Vitullo: First off, we have the TypeScript v7 beta, which is, if I recall correctly, this was gonna be the one where it's all rewritten. [00:01:51]

Mark Erikson: This is the TS Go release, and you might also notice this is pretty hot on the heels of TS 6.0. So TS 6.0 is supposed to be the last actual release of the current written in TypeScript compiler, and 6 is the one where they changed a bunch of defaults to be more strict and better match the way JavaScript's used today. [00:02:00]

7 is same settings, but completely different compiler implementation. One interesting bit here is I believe that 7.0 is not going to have a lot of the programmatic API stuff that exists right now. Uh, I think they said they hope to get that out in a 7.1. That does mean that there is definitely going to be some amount of, like, fluctuation and churn as you go upwards. [00:02:22]

But in terms of just using the compiler to type check, go ahead and start using 7. Like- Cool ... right now. It's there. Okay. It's faster. It's the same logic. Use it right now. [00:02:49]

Carl Vitullo: So that's like the SDK, like if you're using TypeScript to do some build tools, using it in JavaScript yourself, that's not feature complete yet? [00:03:00]

Mark Erikson: Right. So yeah, so I, I don't know what all is and isn't- [00:03:09]

Carl Vitullo: Right. I've never used that, so ... [00:03:14]

Mark Erikson: intended to be included in the API. But like, for example, in Replay's code base, we have some programmatic linting stuff that uses the TS Morph package, and TS Morph depends on being able to import the TypeScript as a library and create- Right [00:03:15]

a program instance and programmatically type check. And so that sort of thing might not fully be available in 7.0, but maybe in 7.1 in some form. [00:03:30]

Carl Vitullo: Yeah. That makes sense. Interesting. Yeah, I mean, that stuff's always a little bit... Usually, when you're trying to use it as an SDK in that way, it's because you're doing something a little bit more finessed and complicated, so it makes sense that that takes a little more time to, to settle out. [00:03:43]

Mark Erikson: I know that there's, in general, a lot of issues because people have reached into TypeScript's internals to im- be able to import methods that were never really intended to be exposed- Right ... to the public. [00:03:57]

Carl Vitullo: Classic. [00:04:08]

Mark Erikson: As well as just the fact that it's one thing when it's TypeScript importing TypeScript. [00:04:09]

It's another thing when the TypeScript implementation is now in another language, Go, and so how do you expose that back to TypeScript client code, as well as how do you do so performantly, 'cause you're now crossing the language barrier? I know that's what the, like the Oxlint folks have been dealing with in terms of trying to implement typed linting, but needing to go back and forth between pieces written in different languages. [00:04:14]

Carl Vitullo: Mm-hmm. The parallelization is interesting. I, I... Like, that's such a good reason to reach for Go, is to introduce parallelization, 'cause, like, Go routines and, you know, whatever. Go is good at that. Well, that's really cool to see that TypeScript is now doing... It says, "Now performs many ch- steps in parallel, including parsing, type checking, and emitting." [00:04:43]

Anytime you can break work down into smaller units that can be isolated from each other and executed in parallel is awesome. So love seeing that being brought into TypeScript. Like, that's so core and foundational. That's awesome. [00:05:01]

Rolldown 1.0

Mark Erikson: And then on a similar note, the Void Zero folks announced that Rolldown has hit 1.0. [00:05:15]

And to recap what that is, uh, Vite had been using two different bundlers, had been using esbuild, which is fast and written in Go for development mode, and had been using Rollup, which was a written-in-TypeScript JavaScript bundler for production builds. And so in order to both make it go faster and harmonize things, you're doing both dev and prod builds with the same pipeline, they essentially re-implemented Rollup but in Rust and called it Rolldown. [00:05:20]

So yet more build tools being written in Rust, and it's been a long time coming. Vite has been using Rolldown in various betas for a while. And Rolldown itself has now actually hit 1.0. [00:05:52]

Carl Vitullo: Cool. Yeah, I was just trying to refresh my memory on... 'Cause we've, I feel like we've been talking about Rolldown 1.0 for, like, a really long time. [00:06:05]

So I was like, "When was that?" It looks like we had the, there was an RC of 1.0 back in January. So, like, that's some pretty serious, you know, d- I don't know, dedication to stability and rollout. Can we just add one more, it's a suffix to roll by s- describing this as a rollout? We'll get the, the rollup, Rolldown rollout. [00:06:13]

But yeah, so okay. So they've been in RC. They've had a Rolldown 1.0 RC out since January, and they're calling it good. They're shipping it. That's awesome. [00:06:32]

Mark Erikson: Yep. Wonderful stuff. [00:06:40]

Carl Vitullo: Love that. Great. Well, yeah, and you can, uh, listen to our January episode to see, uh, to hear us discuss that previously. [00:06:42]

Mark Erikson: All right, and then one other release to announce. [00:06:48]

Fate 1.0

Mark Erikson: Christoph Nakazawa has released Fate 1.0. So we, uh, we'd mentioned this a couple times previously, but Fate is a new React-based data fetching library. My closest comparison is it's kind of like a GraphQL in the sense that the client is specifying pieces of data to fetch. And to be honest, I still don't have a, have a f- really good grasp on how this works. [00:06:51]

I've just seen some of the d- some of his descriptions. But it's meant to be composable queries, normalized data fetching, and integrating with React's new async and suspense-based features. My understanding is that this is very heavily... I'm not gonna say, I'm not gonna say vibe coded. I, I know he's, like, been very intentional in how he's built it. [00:07:18]

My understanding is most of the actual code here was written with AI tooling, with a lot of intent behind it. [00:07:43]

Carl Vitullo: Yeah. That's fair. I don't know. Written with AI tooling and vibe coded are not the same thing. That's interesting. I don't know. This definitely looks kinda interesting. It looks like it's trying to be something, like you said, kinda GraphQL-ish, re- relay-ish, TanStack, you know, ish. [00:07:49]

But I guess, like, from first principles in the server components era- I guess is how it feels to me reading this. That's interesting. That's valuable. That's a really good exploration, but is- I don't know, something about this says r- like, research project more than something I would bet my, you know, bet my work on. [00:08:05]

Mark Erikson: My vague sense, and this is just, you know, me eyeballing things as always, real project, not just a, an experimental toy. Early obviously, and I would assume no one else is actually using it at the moment, but it's the kind of thing that I could see getting some- Right ... amount of adoption over time. [00:08:26]

Carl Vitullo: That's curious. [00:08:42]

That's interesting. Yeah, we'll s- have to see how it goes. That's really interesting. Love having more explorations on ways to do data fetching better. I'm having thoughts come up that I know I'm also going to wanna discuss when we start talking about Remix V3 in a little bit. It's so s- funny to me how much exploration has been done over the last 15 years in, like, how do we transfer data and UI across the network? [00:08:43]

We're still figuring that out. So I, I have more to say on that when we t- talk about Remix V3. But, you know, this is interesting. This looks like a valuable exploration. Christophe Nakazawa is definitely someone to take seriously. [00:09:09]

Mark Erikson: And int- interestingly, I believe he actually joined Void Zero as a company, and his day job stuff is now around some of the, like, the Void server framework pieces that they're building. [00:09:21]

Carl Vitullo: Oh, yeah. Interesting. He says he's product at Void Zero on his Twitter. Curious. That's cool. Very cool to see him still so, like, deeply embedded in the ecosystem, and then doing, like, little research side projects like this. Prototypes of alternate usage patterns. Cool. [00:09:32]

Main Content

Mark Erikson: Okay, onto something resembling main content, and something resembling React core-ish stuff. [00:09:48]

React Core

Mark Erikson: So this first bit is something that I surprisingly don't actually have much of a link for, but I'm going to try to pass on a summary of bits and pieces and conversations that I've had in multiple places. [00:09:56]

React team status after Meta layoffs?

Mark Erikson: Loosely put, I have no idea who's even still on the React team at this point, for multiple reasons. [00:10:09]

So Meta just went through two rounds of layoffs, and from watching things, I know that there was some shuffling in and around r- the React organization. For example, I think the Relay team used to be considered part of the React org, and now they're part of a separate organization. But a number of people that I know have, appear to have left the React team one way or another. [00:10:17]

Uh, for example, Lauren, who'd been working on the React compiler, is now over at Cursor. I believe I saw that Sebastian Markbagha has left Vercel and is possibly not labeling himself as being part of the React team at this point. Joe Savona, who was essentially a lead on the React team for the last year or two, I heard a rumor that he has been reassigned to something else AI related. [00:10:43]

These are all bits and pieces. I don't have, you know, direct links for them. But the picture I'm getting is that what we would consider the React core team has been kind of decimated. If you were to ask me right now, like, who am I pretty sure is on React core at the moment, about the only people I could still point to would be Andrew Clark at Vercel and Rick Hanlon at Meta. [00:11:11]

There's still a bunch more beyond that, but just, I, I, like, I literally don't know who is working on React right now, which is not a thing I would've said last fall at React Conf. And so, this also brings up a number of other questions because Seth Webster was the head of the React org at Meta, and he also spent the last few years quietly trying to put together the React Foundation, which got announced. [00:11:34]

And I've been trying to keep an eye on, you know, any news and discussion of where the foundation is. Seth himself just moved over to Expo. That was publicly announced. And I believe he's still going to be the head of the React Foundation, but I also have seen no evidence of anything as far as actual work or output from this foundation, either in terms of community involvement or events or taking over the day-to-day technical work on React itself. [00:12:00]

I actually did see in a PR yesterday, Sebastian Silbermann, who is essentially part of the React Core and Core team externally at this point, did make a mention of moving repositories over to a React Foundation org, at which point they might be doing some, you know, kill and kill AI and bot spam type cleanup. [00:12:38]

So all this says to me that they're, like, things are changing around React's development process, both who's doing it and where it's happening, but it also feels, just me observing things, it feels like things are fragmenting and stalling. And I actually legitimately do not know what that means in terms of technical development on React itself in the near future. [00:13:02]

Carl Vitullo: Strange, curious, yeah. So I'm in a, I'm in a Discord for the React Foundation, and I noticed over the past several months that virtually nothing has happened in there. [00:13:28]

Mark Erikson: There's been essentially no conversation except maybe there was a little bit of chatter about something React Native related, like a week ago. [00:13:41]

Carl Vitullo: And I saw something about a contributors Discord as well, so I think there's a private space being set up for people who are act- actively contributing code to React Core. But I, as someone who does not contribute code to React Core, I'm not in there, and I, so I don't know exactly what's going on. I do note that the website, you know, react.dev Meet the Team, lists Sebastian, lists Lauren. [00:13:48]

So it lists a number of people who are, you are saying, have been publicly confirmed as no longer- [00:14:11]

Mark Erikson: I think Lauren may still be involved with the compiler. I don't think she, I don't think she entirely left the team, but she certainly left Meta overall. Sebastian, I got the impression he's, he's out for now, but- [00:14:16]

Carl Vitullo: Well, certainly at least job titles are out of date, 'cause, you know, Lauren Tan says engineer at Meta, and so if she's no longer at Meta, that's wrong. [00:14:30]

This website has not been updated. So yeah, oof. That's, uh, yeah, okay. Certainly lack of community engagement, I would say. [00:14:38]

Mark Erikson: Having said that, I have spent a lot of time over the years just watching the list of PRs in the r- in the React repo, just to get a sense of what's going on, and I hadn't done that much over the last few months just because of travel and life and work and stuff. [00:14:45]

React Compiler port to Rust still in progress, latest PR

Mark Erikson: I was looking at it the other day, and the bulk of the PRs that I'm seeing at the moment do actually have to do with either things like updating some of the release process or, uh, some work on the React compiler port to Rust. And in fact, Lauren just confirmed on Twitter the other day, that is still actively being worked on. They are testing it out internally at Meta. I believe she's still involved in that from her side. They are trying to push that along. I do think that's gonna be a big deal for c- for a couple reasons, because eyeballing things, to me, the biggest blockers to people adopting the compiler right now are the comp- are the requirement that you still have to use Babel as part of the build process, as well as the speed of the compiler. And so if porting the React compiler to Rust makes it faster and eliminates the need for Babel, then those two roadblocks go away [00:14:59]

Tanner Linsley is "projecting" React (it's definitely not a fork)

Mark Erikson: All right, so, uh, that, that brings us up to a very interesting and somewhat controversial article, which is Tanner Linsley not quite forking React itself, projecting React. So the, the idea here is the React team has spent a lot of time over the last eight-plus years adding all these new fancy async concurrent features to React. [00:15:54]

As we've talked about, they had a general vision for what they were trained to build, and they've essentially arrived at what their vision roughly was. But, you know, a lot of us are still building React apps that don't make use of the new features or don't, you know, just don't need all the capabilities that are in there. [00:16:19]

But React as a package is delivered as a giant monolith. There is no option for, like, disable concurrent mode or something like that. And so all the code that implements this goes in the bundle whether you're using it or not. And that also means a lot of the logic and the checks that take up time are still in there. [00:16:37]

And so Tanner actually went out and he cloned the React repo, and he told an AI essentially, "Rip out all the pieces of React that I personally do not need," and he was able to rebuild React with a lot of pieces stripped out, and it drastically shrank the bundle size, and it sped up SSR. And he is actually running his own personal website in tanstack.com on this personal modified fork of React. [00:16:59]

He didn't wanna call it a fork, 'cause that term has a lot of political implications, so he called it a projection of React, in the sense of, like, projecting data or, like, viewing a subset of the data. And so technically he's made the changes available, but he is very intentionally not telling people to go try this. [00:17:32]

Like, this is not Tanner saying, "I'm forking React, use my version." This is, "I played with something and if you want to look at what I did, it's over here, but I'm actually kind of telling you don't use what I did." And I've seen mixed reactions to this. I saw a number of people say, "This is a horrible idea," because, you know, LLMs can make mistakes, and if we start modifying packages, then there's the risk of introducing new bugs and security problems that w- that got handled in the original, and if you're mod-- If, basically if you're making changes, you run the risk of breaking stuff. [00:17:55]

And I get that But I'm actually kind of in favor of this idea for a number of reasons. Like, code is not sacred. Code is there. A license says anyone can modify this if, you know, however they want. If Tanner wanted to fork this, that would be a totally valid thing to do morally, legally, ecosystemly. Maybe not a good idea, but it's a totally valid option. [00:18:31]

But also, React exists in its current form because the React team wanted to pursue certain ideas. It's totally valid for other people in the ecosystem to say, "I would like to pursue different ideas and trade-offs and see what happens." And especially given the way that it looks like React development is kind of fragmenting and stalling slightly, I am entirely in favor of people trying to do different experiments. [00:18:55]

Carl Vitullo: Yeah. Like, this is making me think back to some of our, some of the conversations we've had over the years at this point. And like, you know, so something that I, I've expressed pretty consistently is this sense of React as a, like, research project, pushing the envelope of what's possible with UI over the network. [00:19:24]

And I think a very real tension with React versus how it's used is not everyone is trying to push the envelope of what's possible with UI over a network. Some people just want it to fucking work, and React needs to serve everyone In a way that they want. So, it... And so, you know, okay, so bringing it back to this specific blog post, Tanner Linsley projecting React, his motivation here was React's bundle size is quite large, and that's true. [00:19:42]

It's quite big, and it's quite big because it's trying to do a lot of things in a generic manner for a lot of different people. And so I think there's a very real argument here that if React is trying to do five different things for five different customers, I am going to use AI to remove the code for the four customers that I am not. [00:20:14]

I am only using this surface area. This surface area has pretty clearly defined contracts and testing guarantees, so I am going to rewrite this part of the surface area that I am touching. And I think that makes a ton of sense here. [00:20:38]

Mark Erikson: Yeah, and it, it also ties into another theme that we've seen going on a lot lately, where people are taking publicly available tools, libraries, whatever, AI rewriting them to an- another entire language, but because all the tests are already there, you can verify that your rewrite is still valid. [00:20:52]

And in this case, I think the risk of, you know, accidentally introducing, you know, major new bugs or security problems is a lot more limited, because you still have all the original React tests for all the functionality you care about, you're just deleting the tests and the logic for the functionality you don't care about. [00:21:11]

Carl Vitullo: Which makes me think, we brought this in, I think, two or three months ago. Actually, it might have been the episode that we lost the audio for, come to think of it. [00:21:31]

Tests are the new moat

Carl Vitullo: But we talked about this blog post from a mutual acquaintance of ours, uh, Daniel Sawitz, Tests Are The New Moat. And I think that's what you're talking about, is, like, if the tests are out there, if you can assert that your code passes this test suite, then what's the difference between your code and their code? [00:21:47]

You know? If it's behaviorally the same as guaranteed by the test suite, and you trusted the test suite to guarantee the behavior of the original, then that's fungible, in a way. That's in- you know, one thing interchangeable for the other, assuming the tests are good enough. So yeah, that's interesting. I see a comment here that I wanna bring in. [00:21:54]

The risk, I think the risk is the fragmentation. Yes, sure, but, like, th- there's risk of fragmentation, but it's also, like, what risks does the fragmentation introduce? Like, fragmentation is not a risk on its own. It leads to other things. Like, if there's too many tools to maintain, then maybe it's harder to guarantee the security of any one thing. [00:22:13]

But we already have that situation, as, uh, devin- as evidenced and demonstrated by all of the, you know, the Shai Hulud attacks, as evidenced by, we're gonna talk about this soon, TanStack getting compromised and 40 packages getting pwned with malicious versions published. So, like, in that sense, it's kind of safer to write your own. [00:22:34]

Like, okay, sure, it's, you know, it, it, maybe it has its own vul- security vulnerabilities, but, like, you're not exposed to the supply chain risk. So I, yeah, I think the advantages are not clear-cut. [00:22:54]

Mark Erikson: So overall, like Tanner heavily emphasized, this is an experiment. I tried it to see what would happen. I'm writing up the results of the experiment. [00:23:04]

Please don't actually use this. But I actually see this as a valuable experiment. [00:23:13]

Carl Vitullo: Yeah, I would say don't m- don't use this, but consider recreating it with something else that you find 80% good but not quite suitable. If there's a test suite, try throwing an AI tool at it. Anyway, interesting. [00:23:20]

Brooks Lybrand thoughts on React + community after React Miami

Mark Erikson: And then one other sort of adjacent bit, which is, uh, Brooks Lybrand, who's one of the Remix React Router developers, put up a post with his thoughts on the React Miami Conference. [00:23:32]

But one of the s- one of the big sections is how are people feeling about React? And some of this was, well, you know, a little bit of the enthusiasm has gone out because AI is hot and React is not. But there was also... He also specifically makes the comment that, quote, "There's basically now two Reacts," and it's kind of how using React today feels. [00:23:45]

There's old style React, and then there's all the, the new fancy Async, Suspense-y stuff, and they're almost, like, two different frameworks at this point. And so it's kind of a mindset thing. [00:24:08]

Carl Vitullo: I did read this post from Brooks. It echoes a lot of, uh, kind of what I've experienced. I don't know about the two, two Reacts part, but React Miami has been a really great conference that I've attended it for a number of years, but I haven't the last two, unfortunately. [00:24:22]

And I know that this was Michelle's last year organizing it, and I wanna shout out Michelle Bakels for being a phenomenal organizer and going on to bigger and better things. [00:24:35]

Mark Erikson: Wonderful human being, great job organizing the conference. She has put together an amazing community there. [00:24:44]

Carl Vitullo: And I believe is now organizing or doing, like, developer relations type things for Open Code, if I'm not mistaken. [00:24:51]

So yeah, do... Power to her. Wanna throw out some recognition while discussing her conference. That's what we gotta say on there. [00:24:58]

TanStack is exploring how to expose Server Components

Carl Vitullo: Let's go into RSCs on TanStack. [00:25:04]

Mark Erikson: We've talked a lot about server components over the last few years and, you know, which frameworks support them and how does it work. One of the biggest issues with server components is that Next.js had them first, and has had them the longest, and has been the only major way to use server components for a long time. [00:25:06]

Our mental model of server components is still very much based on how does Next.js offer them in the app router. And so TanStack now has... And TanStack Start now has server component support, but they have approached it in a very different method from, from an API design and usage perspective. I've seen some of the examples. [00:25:24]

I've looked at- Some of the bits and pieces I, I half understand what's going on here. But m- my rough explanation is that they allow you to do some of your own server rendering, and then you treat the response as data to the point where you, you would actually use, like, TanStack Query to fetch the dreamed data from the server, and then just sort of include the output on the client side. [00:25:47]

Another way to put it is they are trained to keep TanStack Start as a client-first framework, where you very clearly say, "This piece of code runs on the server." Whereas Next in the app router is, we are starting your component tree as the server, and you have to explicitly break out and say, "This is where this..." you know, "This is a client component," et cetera. [00:26:14]

So they're trained to flip the server component usage pattern up, kind of almost, like, upside down compared to how Next.js does it. And I think this is good. I see a lot of benefits here in terms of mental model and complexity, and just even just being able to read the code and say, "This code runs on the server, this code runs on the client, and I understand what's happening where." [00:26:41]

Carl Vitullo: Yeah. That's definitely the tough part of RSCs. I applaud them for giving it a go, but that, that is a challenging problem space to be working in. [00:27:08]

Mark Erikson: So we've, we've got a couple different posts here. [00:27:17]

Who Owns the Tree

Mark Erikson: And the TanStack folks put up two posts on server components your way, and who owns the tree, treating server components as a protocol and not an architecture. [00:27:19]

RSCs in TanStack

Mark Erikson: And then Adam Rackis did a post on Frontend Masters where he explains server components in TanStack as if you had never heard of server components before. So in other words, rather than trying to say, "Here's how it compares to Next.js," just, "Let's kind of teach this up from first principles." [00:27:31]

Carl Vitullo: Heh. I, I appreciate that, because the other, the, um, React server components your way blog post on TanStack.com starts with, "What is, what are server components? Yeah, no, this is not a server component crash course." so okay, they got, they got both audiences covered. [00:27:51]

Okay, into some stuff that we have referenced already in this episode. Some new and notable stuff in the ecosystem. [00:28:05]

Remix v3 beta preview

Carl Vitullo: Starting off, I guess, we've got Remix v3 beta preview. Beta preview, not just a beta, not just a preview It's a beta. It's a beta preview. [00:28:12]

Mark Erikson: Isn't that called an alpha? [00:28:23]

Carl Vitullo: I think that that does seem like an alpha, but I guess... No, I, 'cause I guess an alpha implies that it might change before a beta, so this is teasing the beta. It's not gonna change, but this is what it's gonna be. Fair enough, whatever. It's okay. It's great. [00:28:24]

Both Remix and TanStack are exploring "what if no React"?

Carl Vitullo: Yeah, this is interesting. Th- th- so Remix is no longer a React-based framework, which it, you know, a- and I'm just kinda reflecting on the conversation we just had about TanStack projecting React. And so it seems like it, it... There's some real ecosystem appetite to do things that are not literally built upon React while being heavily, deeply inspired by. [00:28:35]

And, like, a, a true, not just inspired by, but, like, a true lineage. Like, you know, it, Remix and TanStack, if both of them are looking at what it means to not bundle React, then that's a really serious evolution for them as projects that have historically bundled React. So I don't know. That's interesting. So they're announcing this Remix 3 beta preview. [00:28:57]

It's a pre-release, not production ready. I guess the core argument, their, the thesis of Remix 3 is that, I guess I would say it's, their opinion here is that fra- modern frameworks try to reinvent too much of what the web platform already provides, and so they're trying to strip away some of that complexity that they view as needless on top of just, like, web standards and available, you know, protocols. [00:29:18]

Which is, I'm sympathetic to that thesis. Like, I think there's a lot of stuff that React is doing that maybe it would be better for, l- or React, Next, TanStack, that may be better for the platform itself to take care of. Like, we definitely could be doing a lot more at the protocol level. Like, a thing I've been seeing people talk about like it's a brand-new fancy technology is, like, adding .md as a suffix to your URLs to make it render, you know, what would have been a HTML page in Markdown. [00:29:47]

And I'm like, "We have a header for that." Like, you can do an Accepts MIME type header to say, "This accepts HTML. This accepts Markdown." Like, w- that exists. Like, you don't need to invent some new technology for that. Like, we can do that. [00:30:18]

Mark Erikson: Okay, there's a comment in chat that says, "I do not understand what Remix 3 is." [00:30:33]

Fair. Let me try to recap where we are. Remix 1 and 2 were full-stack frameworks u- that used React. They mostly introduced things like using loader functions for data fetching. But they were, they were full-stack mostly in the sense of there is a server piece included. Remix 3 is a completely new and different framework that just happens to use the same package name And it is a very different way of writing your components. [00:30:37]

They also include a whole lot more stuff on the server. The blog post says they include routes, request handlers, responses, middleware, sessions, auth, forms, uploads, assets, data, database, UI components, theming, network, and tests. So in terms of what they provide, they're trying to provide a lot more out of the box. [00:31:12]

In terms of the client side code, this is not React. This is a brand new framework on the client side they have invented themselves. It looks a little bit like React in some ways. There's JSX syntax. But the logic and behavior are very different. For example, instead of a useState hook, you just declare a variable in scope, inside a closure, reassign to that variable, and then you call an update method, which is what actually triggers the re-render. [00:31:32]

So whereas in React, if you call setState, that both says, "Here's the new value," and tells React to re-render, whereas in Remix, you could say variable one equals A, variable two equals B, and then you call an update function to explicitly trigger it. They also have a bunch of things for mixing in behavior, like event handling and styles and things like that. [00:32:07]

There's inspiration from React. There's inspiration from earlier libraries like Backbone. It, it is a very React and yet non-React-based framework. [00:32:34]

Carl Vitullo: And I'm looking at this, you know, in this Remix III beta preview blog post, I'm looking at this small example copy to clipboard component that they show. And yeah, so Mix is what stood out to me here. [00:32:46]

There's, you know, a button and it's got, like, some ARIA stuff, 'cause buttons are, need to be accessible. And then instead of, like, style or, like, class name or, you know, onClick, on, you know, handlers, n- the rest of the props basically that I would expect for a, you know, a button component to have, it has this Mix attribute which, you know, uses the same JSX, like, you know, curly braces. [00:32:58]

Then the value is an array which has button.secondaryStyle and an on function which is being given, you know, onClick with a clickHandler async function here. That's interesting. So it's like, I guess, it's sort of React, but with manual updates instead of updating by reference, and it's got, like, this pseudo-functional composition style for arguments. [00:33:22]

But, like, weirdly, it seems to be mixing styling and b- behavior in this Mix attribute, 'cause it's both applying the secondary button style and an onClick handler as composed mixins, I guess. So that's, I don't know. Sure, that's an opinion you can have. That's, seems fine, but it's strange. [00:33:49]

Mark Erikson: All that to say that they've been talking for a while about how they're trying to do their own thing, and they are clearly doing their own thing. [00:34:07]

And I have no idea how much adoption this will get, but can sort of squint and see some of the inspirations. [00:34:15]

Carl Vitullo: Yeah, and somebody in chat just brought out React Router Framework, and it's like, oh yeah, they did that too. [00:34:22]

Mark Erikson: Brian and Michael have had a lot of ideas over the last decade. [00:34:26]

Carl Vitullo: Yeah. Boy, boy howdy, have they. [00:34:29]

I guess, uh, a thing I wanna bring in, speaking about over the last decade, so a decade ago is 2016. I remember in, like, 2012, I read a blog post from Basecamp talking about how they built their UI, and it was basically componentized HTML being cached aggressively and recursively sent over the wire. And, uh, as I have been watching React evolve, it's like, oh, we're basically evol- you know, uh, progressing towards the same thing. [00:34:31]

It's, you know... This f- this remix description of, like, and- advanced functions and like, you know, it's got frames, which are server-rendered HTML that you can, like, slot into your client code. And it's like, man, just, like, the number of times that I see something that, like, viscerally remind me of this thing I read in, like, like literally 15 years ago at this point, talking about sending componentized HTML over the wire in a efficient manner. [00:34:59]

It's like, wow, we're still trying to do that out, uh, generally. Like, we-- I feel like that's the tension. It's not that hard to do as a one-off, but it's really hard to do with effective semantics that let you author that type of experience in a generic framework or library. So we're just still chasing that high, I guess. [00:35:26]

So I don't know. That's where we're at. That's how I'm conceptualizing this Remix 3. And I, I also think of, like, Remix, you know, 'cause, like, Remix is, like, backed by Shopify and, you know, Michael and Ryan, they feel like they're in alignment with the Basecamp folks. And so it's interesting to see these, this similar set of ideas explored by a set of folks that I consider to have a generally similar set of ideas about the world. But yeah. [00:35:46]

TSRX, a variant on JSX

Mark Erikson: And on a very, very similar note, Dominic Ganaway is someone who has worked on multiple React frameworks. He originally built his own framework called Inferno. He was part of the actual React core team for a while. I believe he then went over and worked on some of Svelte 5, maybe. [00:36:11]

Someone who has a lot of experience building these frameworks. He has been working on a new framework called Ripple, which we've mentioned a, a few months ago, and one of Ripple's potential innovations was essentially an improved version of JSX syntax, and Dominic has extracted that into its own package and compiler layer called TSRX. [00:36:29]

So JSX has an actual specification. It's out there. It's in a repo. It's documented. It also has not changed in a decade, and part of that is because it's embedded. There's lots of different tools that know how to parse JSX correctly and do the transformations. Trying to push through any changes to the JSX specification would be hard at this point. [00:36:56]

Like, I would desperately love to have what's known as prop hunting, where, say I wanna pass my variable as a prop named My Variable. Why should I have to write My Variable equals curly braces My Variable every time? Like, that's silly. But the problem is the JSX spec says if you pass a variable name with nothing else, well, HTML treats that as a Boolean, so JSX is gonna treat that as a Boolean too. [00:37:21]

And it's like, but it would be so much nicer if I didn't have to repeat myself. Can't we improve the specification? And at this point, it's not gonna happen. So Dominic has gone in and created essentially a bigger, better JSX-like language that is specifically meant for writing components in a template-ish, JavaScript-ish, TypeScript-ish sort of way. [00:37:53]

Carl Vitullo: Agreed on, like, you cannot-- Like, changing the spec of JSX right now, like, nobody expects the spec to change, which makes it harder to actually change. Like, you know, if it had been evolving, it would be easier to continue evolving, but we have inertia saying it's fixed. So it's just tough to evolve. I'm not sure if I love this as a, you know, new DSL. [00:38:21]

I have been thinking about the value of DSLs in this, you know, agent- agentic AI era that we're, you know, that we find ourselves in now. And, like, so much-- I feel like there used to be a strong argument for not changing things because you have to do this, like, educational push afterwards. You have to do the developer relations of, like, "Here's how to use the new thing," and you have to, like, yada yada. [00:38:45]

And that's different now that so much of the new code is being consumed by agents. It's not an educational cycle. It's not workshops and, you know, courses and talks and conferences. It's like you update the markdown. You update the docs that the AI is reading 'cause it's an amnesiac and you have to start from zero every time you give it something. [00:39:06]

That's an interesting, like, unlock for changing some of these core assumptions. Like, yes, sure, it's embedded, it's deeply embedded into the training program. But like I've been pleasantly surprised by things that I expected to be challenging because it's not deeply embedded in the training data, or it, it runs counter to things that I know are deeply embedded in the training data, like wanting to do functional patterns instead of object-oriented. [00:39:27]

Because, I mean, so much code is object-oriented and it's been trained on all of the existing code. I have to say, like something like TSRX, it seems interesting to me from that lens of like... So your thesis is that JSX has rough edges and foot guns that make it less effective, less intuitive, less comprehensible for its intended purpose. [00:39:53]

Mark Erikson: Just make a whole new thing. [00:40:16]

Carl Vitullo: Just make a new thing. Just shave those off and call it something else so that the tools you're using to author these implementation details don't get confused about what you're using. Or, you know, have lint rules, static, you know, tools available to ensure that what they've written is valid and g- intended. [00:40:17]

Ah, that's interesting. That's cool. That's useful. I don't know. [00:40:33]

Mark Erikson: And just looking at this code snippet, a few practical examples of how this is different from JSX. So you've got a component keyword instead of the function keyword. It is statement-based, so you can have like an if statement directly in there, and then you don't do like a return anywhere. [00:40:36]

It's just like if condition, key tag In other words, it, like, if that's true, you insert the P tag, but you don't have a, like, a return statement anywhere in there. Uh, and then it's also got an embedded style section as well. Another interesting thing is that this is not actually tied to a framework directly. [00:40:54]

There are packages that allow you to use this with React in Preact, Ripple, Solid, and View if you really wanted to. So you could, in theory, actually drop this into a real project right now if you really wanted to use it. Did you use it? Probably not, but it's a very interesting exploration. [00:41:16]

Carl Vitullo: Yeah, definitely really interesting. [00:41:37]

Mark Erikson: Okay. Well, we are already almost an hour in, and we still haven't touched the security thing. So Carl, great job moving that to the end. [00:41:39]

Carl Vitullo: I knew it. [00:41:46]

Mark Erikson: Who knew that we would have stuff to say about everything else first? [00:41:47]

Carl Vitullo: What? You and I have opinions? [00:41:50]

Security! Everything is compromised

Carl Vitullo: As fucking ever, there's been a bunch of security stuff going on. TanStack Router got, like, hardcore compromised. I think it was 40-some p- compromised packages. Basically, like, all of- [00:41:52]

TanStack Router compromised, and Socket analysis

Mark Erikson: The entire TanStack Router set of packages was compromised. No other TanStack libraries were compromised. So, like, Query, Start. Or, well, Start because it includes Router, but, like, the actual damaged packages were all Router related. [00:42:04]

Uh, and the, the way it worked was incredibly complicated. So s- essentially, someone opened up an ex- a, an external PR that in its own depend... Like, essentially changed the package dependencies to point to some compromised poisoned versions. TanStack's CI was set up to have a shared package cache so that their CI runs would go faster. [00:42:22]

Someone opened up this PR, modified it a couple times, closed it, and in the process, their poisoned packages ended up in the package cache, so that the next time one of the TanStack maintainers actually did a real PR, the poisoned packages from the cache got installed, exfiltrated credentials, and then that allowed the attacker to then publish new versions of the TanStack packages with more malicious code inside. [00:42:49]

Uh, it's actually much more complicated than that, but that's roughly what happened here. [00:43:21]

Carl Vitullo: Yeah. It's... I, I wanna see if I can pull in a couple different details without blowing up the time we spent here. [00:43:26]

But, like, so they, they fork it, they obscure that it is a fork by renaming it to s- you know, configuration, so you d- it's not easy to find. [00:43:30]

They publish a commit with li- you know, a malicious payload, commit it with skip CI because they know that will suppress the CI from actually executing on this push. Then- Like open a PR, update the PR so that it appears empty, then close the PR. And in doing this, they have now poisoned the cache with their malicious payload so that the next time a legitimate CI run goes, it will pull in this malicious payload instead of the intended dependency code. [00:43:39]

All from a fork, that was never run, that was never actually executed, never had CI run or merged or approved. The timeline for this is they open the PR, do multiple force pushes, and then close the PR in under a minute, and that's how they poison the cache, so the next time a legitimate person ran CI, their credentials were compromised. [00:44:15]

Like, that's fucking crazy. [00:44:40]

They m- compromised a bit of code, organizational policies by the, by TanStack, and complex GitHub Action configuration. And all of this was ultimately enabled by the use of a PR target in their GitHub Action that is like known to be unintuitive. [00:44:42]

It's known to a- allow this type of attack. But like, ah, man, what a, th- like that's, that... What a reasonable thing to miss here. That's such a complicated set of th- steps to have to do to e- execute this. [00:45:01]

Mark Erikson: I've done a decent amount of like GitHub Actions CI config over the years for Redux. I have no idea what I'm doing. [00:45:15]

I don't like writing YAML as a way to do control flow. I'm not an expert on this stuff. I'm googling examples and copy-pasting, because I genuinely have no... Like I, I roughly know here's what I want to do. I don't know how to do it. So this stuff is so easy to mess up, and GitHub Actions is frankly a, it's very complicated and it's very badly implemented. [00:45:25]

Carl Vitullo: And it's so hard to test. Yeah. It's impossible to test some things. Like literally in, in some cases the only way to trigger the actual workflow is to do it live. And like, like you said, I'm not an expert in this. You're not an expert in this. Like nobody, almost nobody, especially in open source, is an expert in GitHub Actions. [00:45:49]

Like nobody's primary job is understanding GitHub Actions, but all of us have to write GitHub Actions because that's the way that you function in this world right now. So I don't know, it's oh man, what a rough state of affairs there. We all have to do this. Nobody's that good at it, and the experience of actually authoring it is- rough. [00:46:09]

It's bad. Like, it's not good. [00:46:30]

Mark Erikson: So the postmortem is fantastic, and just for the record, I've seen a lot of corporate post-moto-mortems that were nowhere near as good as this. So kudos to the TanStack team. I know Corbin and a bunch of the others were very involved in not only trying to deal with the actual fallout here, but, like, really, really professionally follow up on here's what happened and here's how we're fixing things. [00:46:32]

TanStack followup with followup hardening

Mark Erikson: And so they, they also put up a follow-up post with the list of things they're doing to try to make sure that nothing like this ever happens again. Unfortunately, this did have a lot of downstream consequences. [00:46:58]

Nx monorepo tool compromised as a result

Mark Erikson: So, uh, the Nx monorepo tool got compromised after that because someone from the Nx team installed one of the briefly live malicious versions of TanStack packages, and that led to some credentials getting exfiltrated, which led to a malicious version of an Nx VS Code extension getting installed. [00:47:10]

And then GitHub reported that someone had accessed a bunch of internal repos, quote, "Because one of our employees used a, broke a malicious VS Code extension," and I think I saw some articles indicating that it might be the Nx Console possibly. So it's possible that there were multiple chained attacks downstream, all starting from the TanStack Router compromise. [00:47:39]

Carl Vitullo: That's fucking wild. Yeah, so, you know, like, when people tell me about, like, the risks of introducing security vulnerabilities by hand-rolling your own little tool here or there, like, oh, I don't know, GitHub got compromised by this. This sequence of events to get to GitHub is compromised, oh my God, that's absolutely wild. [00:48:05]

I don't know. People talk about threat models and, like, threat actors. Like, how do you defend against what type of threat actor? Like, this attack, to me, the level of complexity and success and, like, capitalization upon their success- Says nation state actor. Like this is world-class— [00:48:24]

Mark Erikson: And to a certain extent, like it's not even worth trying to defend against someone who's that good. When they want to find a way in, they will find a way in. [00:48:41]

Carl Vitullo: Right. Meaningfully, in order to effectively defend against these... You know, if you think about it as like y- your available attention, you have 100% available attention, and, you know, there's that r- team, that malicious actor, 100% of their attention is on breaking you. [00:48:49]

If you are not as skilled as them and dedicating the same amount of effort to countering their actions, like you can't beat them. They will overwhelm you given enough time. So like that's the complicated thing about security. You know, it's like in physical security they talk about like there is no such thing as a perfectly secure lock. A line that I'm aware of is physical access precludes all security. Like if you're doing computer security things and you are sitting in front of the machine literally [00:49:07]

Mark Erikson: Sooner or later you will find a way in. [00:49:37]

Carl Vitullo: It is not possible to provide security guarantees there. Yeah, you know, like if you're trying to lock down your data, if they're sitting in front of the machine, they can just blast your RAM with freezing agent so that it powers off but still holds the bit pattern physically on the chip, and then you can recover it from there. [00:49:39]

I remember reading, uh, you know, proof of concept in an academic lab. Somebody had successfully exfiltrated data from a computer by using a high-sensitivity microphone from across the room and extracting the, like, buzzing pattern, the audible noise of the processor as it executed instructions. [00:49:57]

Like, by listening to the processor, they were able to exfiltrate data. Like, the bar for perfect security is so high, it's incredible. Anyway, that's the last thing I'll say there. [00:50:19]

Like it... So I don't know, just like when w- as you're thinking about responding to and defending against security threats, I think that's a really important context here, is that if your counterparty, if the malicious actor you're defending against is a hacking team that has been working for 25 years with the backing of a nation state national defense resources, like, sorry, you're not gonna beat them. [00:50:30]

That's-- You're not an effective counter to that. Like, it's not gonna happen. So I don't know. That's an important caveat that I think all security conversations need to have is it's fucking hard. It's grim. [00:50:54]

Mark Erikson: And then there's a, a couple more examples that I, I believe aren't even tied to the TanStack one. So Vercel got compromised, and that one appeared to be a sort of similar thing, where, like, one person was using an external tool, in this case called Context.ai. [00:51:06]

That tool got compromised, and then they were able to roll through, pick up tokens, and get into Vercel's interior. And then the same people who have been doing this mini Shai-Hulud set of viruses and attacks have actually been hitting a bunch of different packages across multiple different languages and ecosystems. [00:51:26]

So I mean, this, this is not like the proverbial guy in his basement. This is a bunch of very determined and sophisticated attackers. [00:51:49]

Three last lit-- um, quick little bits on React-related things. [00:51:58]

React2Shell recaps from Lachlan Davidson and Sylvie

Mark Erikson: So we had the entire React to Shell vulnerability a few months ago. [00:52:02]

The people who actually discovered that put up a couple of articles describing-- Like, the two primary individuals described their experience of what were they investigating, what was their process, what happened between when they found it and when it got publicly disclosed. [00:52:07]

Next 16.2.5 and more React CVEs

Mark Erikson: And then adjacent to that, Vercel put out a new release that appears to fix a number of new vulnerabilities and CVEs. And I know I s- w-when I saw this a couple weeks ago, I don't feel like I saw an actual blog post that accompanied this, which I found a little surprising. Maybe I just wasn't looking in the right spot, and I haven't gone back to look. But it seemed as though there were a number of new, like, denial-of-service and some authentication bypass issues found in b- in both Next and possibly Server Components again Okay. [00:52:25]

One last set of things that are adjacent to this, and that's with the package publishing [00:52:59]

Carl Vitullo: I like this 'cause it's, like, actionable. Here's things you can do to make your packages more secure. [00:53:05]

Mark Erikson: This is aimed more at people like me who are maintaining packages rather than people who are developing applications, but hopefully this is something that will benefit all of us. [00:53:10]

NPM adds “staged packages” and E18E adds guidance

Mark Erikson: So first off, npm is adding a new concept called staged publishing. Right now, when you publish, the package goes live immediately. And so the way I understand this is once you have this set up for your packages, every new attempt to publish goes into a holding area, and then you explicitly have to go in and say, "Yes, I approve this for actually, actually, actually being released." [00:53:19]

And I've, I've already seen Jovi de Crook, who works on Preact, trying to p- put together a tool that would be able to inspect package releases that are staged so that you can see what's inside them and what's changed. No idea how that works, but I c- I can see how that's been useful. So this would help for cases like the TanStack compromise because the m- modified, malicious, published versions of the package would never have gone fully live. [00:53:48]

They would've gone to the staging area, and then the TanStack team would've been able to see them and say, "Wait, no, we, we didn't intend to publish those. Those should not go out." And then on the consumer side of things, so all the different package m- managers now have some kind of an option for don't install packages until they are at least N days old. [00:54:20]

And they all have a different name and a different set of options for that field, but that's, that's the same concept. [00:54:44]

PNPM 11 defaults to min release age, NPM 12 will block by default

Mark Erikson: So I believe pnpm 11 is defaulting to turn on that option to at least a couple days. Meanwhile, the other problem here is that packages have the post-install script, which is essentially when your package manager downloads this package and puts it in node modules, it can then run any random script that the package says it should run. [00:54:50]

And that's bad because that's code that's running on your machine under your privileges and you have no idea what's happened, and it's just there because the package manager installed it. [00:55:13]

Carl Vitullo: It's literally remote code execution. Like, yeah. [00:55:22]

Mark Erikson: Yeah. And traditionally this has been used for things like, okay, let's figure out what operating system you have so we can download the proper native binary or build the native binary from scratch. [00:55:25]

And there's alternative other better ways to do that today. So pnpm has already been denying the ability to run post-install scripts for a while. And finally, npm appears to actually be making the same change. So it looks like they're gonna start warning about package scripts that have a post-install option in the version 11 series, and npm command l- and tool version 12 will start denying those by default. [00:55:38]

So we are trying to close up some of the outstanding holes in the ecosystem. So trying to make publishing packages safer, trying to make installing packages safer. [00:56:08]

Carl Vitullo: I will say, okay, if we're talking about voluntary remote code execution, you know, where blocking post-install is a good thing to do because it's against best practice, the other- Top of mind, similar instance where we are casually expected to fetch code over the network and run it is curl piped into bash as an install tactic for things. [00:56:19]

And like literally my entire career, people-- I have heard people talk about, "This is awful. We should not be doing this." Like, there are certain tools that will... I, I can't name, I can't think of any off the top of my head, but I do feel like I remember encountering this. There used to be tools that would ask you to, like, curl and then pipe it into, like, `sudo bash`, and, like, that's literally root access to your entire machine with arbit- code that you're not even inspecting from the network. [00:56:45]

And you know who still asks you to curl pipe into bash as the recommended install method? Claude Code. Like, you go to claude.com f- and the Claude Code thing, front and center, "Built for hackers. Get Claude Code. Curl, pipe, bash." Like, that is remote code execution. Don't do it. Use a package manager. If your work is recommending that people curl and pipe into bash, advise that you respectfully and through proper channels raise the issue that That's wildly insecure. [00:57:10]

It encourages remote code execution as a thing that developers will casually do. And when you casually do something like remote code execution, you end up with security vulnerabilities, like the types that we've been getting over the past year. So, ah, makes me annoyed. [00:57:42]

Mark Erikson: And then, uh, last item. [00:57:57]

Review your GH Actions, people!

Mark Erikson: So I, I, I mentioned earlier, I am not an expert on GitHub Actions. And after seeing all this stuff happen with TanStack, I, I was like, "We probably oughta do some looking at, like, the Redux actions," but I, I have no idea to what, what to even look for. The good news is that there's a number of people already working on scripts and AI prompts and other things to go inspect GitHub Actions. [00:57:59]

And it's, in fact, Francois Best, who's ma- the maintainer of the Nuxt URL State library, was actually working on one himself and was asking for repos to run it on, and I, I volunteered to have him run it on the Redux repos. And it gave me a bunch of things to go correct. Like, nothing major high security, but a number of things we could do, like making sure that all the actions were pinned to a hash, changing some of the permissions options. [00:58:22]

So there's a thread over in the E18E repo where they're collecting some different tools that can do scanning of GitHub Actions and try to work on hardening. And it kind of sucks that this is yet another thing that we gotta fix and we gotta make right, but guess what? It's good. You gotta fix it. [00:58:47]

Carl Vitullo: One more thing we gotta fix. [00:59:06]

That's just the rest of our existence forever. The debugging never stops. [00:59:07]

Mark Erikson: Yeah. Okay. [00:59:12]

Mark posted his big AI blog posts. Part 1: Fears and Journey

Carl Vitullo: You published your posts. [00:59:13]

Mark Erikson: Yes, I did. So I, I hinted at this, um, a, a month ago. Long story short, little over a year ago, I was firmly against ever using AI- Yeah ... for writing code, and I was having a bit of a mental crisis over what AI is doing to the software industry and how this would affect the industry as a whole and myself personally. I ended up trying to use AI- Found it was actually useful, and now I actually end up using AI to write all my code. [00:59:15]

And this has been a very long, very personal, very emotional journey for me. And I've actually now spent a lot of time configuring my own personal open code agent workflow setup, and I have a, I now have opinions on both how I set things up and the results that I'm getting. Just like I, I have act- I actually have experience now, and I, I have some preferences. [00:59:47]

Also, I didn't wanna get pulled into people yelling at me for having chosen to use AI. But when I was in Miami last month, I was talking with some folks, and some of those conversations literally turned into, "Mark, what tools are you using?" And I would describe it and people were like literally taking notes, acting like I actually know what I'm talking about, which is hilarious. [01:00:13]

And I'm like, "Okay, okay, fine. I've, I have been convinced to write a blog post about my own personal AI agent setup." And my brain would not let me write the technical blog post until I had written the personal experience blog post. [01:00:34]

And I sat down and I wrote 12,000 words in eight hours with a brief stop for supper. And then I wrote another 3,000 words on the flight home the next day. [01:00:51]

Carl Vitullo: I may have run that through a word count already. I can verify those numbers. [01:01:01]

Mark Erikson: I, I... This is very different from most of my blog posts. Most of my blog posts are, "Here is a concept that I've become an expert on, let me explain this, unpack the pieces, describe how things work, and I will cite dozens of sources as references." [01:01:05]

This post is none of that. This post is, "Here is my experience, my brain, my feelings, my journey." I am not trying to convince anyone. I am not trying to tell people, "This is how you should do things." this is me and my experience. [01:01:22]

And I did not write this for clicks. I did not write this to, you know, change the conversation or get a bunch of views. But I've also already read hundreds of people's posts where they say, you know, I- like, "AI is killing the craft of being a programmer, and I mourn the loss of that." and that was, it, I mean, that was a really big influence on how I was feeling over the last year. So there you go. [01:01:40]

There's a 15,000-word post that goes deep, deep inside my brain and my experiences and how my thought processes changed over time, and then it's got an awful lot of my opinions on where are we as an industry. And then I wrote another 6,000 words about my actual technical setup. [01:02:08]

Carl Vitullo: Real Casual, 21,000 words. At an estimated 500 words per page, that is just about 41 pages. [01:02:27]

Mark Erikson: People keep asking me to write books, and I'm like, "I don't write books, but I, I write the equivalent of books on my blog." [01:02:33]

Carl Vitullo: Right. Right, right. Cool. Love that. How much of both do you think you got into the previous episode we did? [01:02:39]

Mark Erikson: Bits and pieces. I, I don't r- Wait, you're asking me to remember what I said a month ago before my vacation? Come on. I, I talked about bits and pieces, but this went into a lot more detail. The biggest things are, like, beyond I use OpenCode, I use Opus, I use these MCP tools, et cetera, is that I've very explicitly chosen to stay very hands-on, conversational, and me driving what the agent is about to change, rather than spawning up a bunch of agents in the background to go do work and I don't care what it looks like. [01:02:45]

I have seen a lot of other posts and discussion, even just in the last few weeks, with a number of people echoing similar thoughts of, "Yeah, actually, maybe we need to kind of back off and keep things at a human comprehensible amount of effort." [01:03:16]

Carl Vitullo: Preposterous. [01:03:30]

I'm kind of frustrated. I don't know. I, I feel like I'm meaningfully following the edge of the state-of-the-art in agentic development. I built a harness for myself that does some really cool... Like, three months ago, I had a harness in place that was, like, keeping track of memories and doing a dream cycle and playing a game and writing its own code. Like, writing hundreds of lines of Python so that it could more effectively play this game, and it was doing a good job. It was actually pretty interesting. [01:03:31]

And I kind of shut it down 'cause, well, now, it, it, it was using `claude -p` to do everything- Mm ... and I realized, like, I kept working on it and I kept iterating it and I realized like, oh, you know what? Like, Claude is already doing a lot of this stuff. Claude Code is this agent. So what is, what does the orchestrator on top of the agent need to do? [01:03:59]

And I have an interesting, I have a really interesting body of work that's on my GitHub that is not currently being put to use anywhere, but it's like, damn it, I'm currently at the edge of the agentic whatever stuff, but I'm doing other things that are more personally interesting to me. And, man, I want... [01:04:18]

I, I have this project in place that I feel like is on par with stuff that I'm seeing people fundraise for from VC and I'm like, "Hmm, I don't wanna do that, but I do want money." So anyway, there's my, uh, there's my personal opinions around some AI stuff. I don't know. [01:04:36]

I'm g- I'm gonna have to find out... We're gonna have to talk more about AI and agents and whatever, 'cause I don't know, it's crazy. [01:04:53]

Mark Erikson: So, I don't know, adjacent thought. Like I'm, I'm, I'm in sort of a weird spot at the moment because I just got back from a combination conference plus two weeks of vacation plus conference trip. At my day job I've... [01:05:00]

Prior to that, I was writing MCP tools and then playing product manager and doing product and positioning stuff, and then helping try to figure out like demos and product direction. I'm back for a couple days. I've got more conferences coming up. I've actually done very little Redux maintenance work this year, and I feel kind of bad about it, but it's 'cause a lot of my time and effort have gone into, you know, replay day job stuff. [01:05:12]

I was trying to play with some of my like React Redux plus signals experiments on the way back home, and so I'm kind of getting some of that back into my brain. There's a lot of things I would like to sit down and spend time on, but I've just been running around so much and everything feels very scattered, and I don't feel like I'm focusing at the moment. [01:05:39]

So I've got a couple more conferences. I've got a c- bunch of travel coming up. I don't know. Maybe I will manage to find time to actually sit down and focus on some things. [01:06:01]

Carl Vitullo: As if. Cool. Well, I hope you do find so- some of that time. But I, I just know in my own self, any time I'm like, "Maybe I'll find time to do that thing that I want to do now," it's like, "Nah, probably not." [01:06:09]

Gotta make time. Can never find time, have to make it. [01:06:21]

Mark Erikson: I, I, I actually saw a post from Addy Osmani on Twitter just, uh, just this morning. A- Addy has written a number of really good posts lately about, you know, using agents and orchestration and, and agent anti-patterns and other things. Fine, I will, I will actually go look on Twitter and find the post rather than just describing it. [01:06:24]

Uh, here, oh, here we go. It's the first thing in the history. Wonderful. Uh, this one's called, this one's called The Orchestration Tax, and the key line that stuck out for me for this one was, "Human attention is now the limiting factor. It is the single-threaded lock that you need to be aware of." And so how do you pick what is the most relevant and important thing to be spending your time on versus your agent's, blah, blah, blah, blah, blah, blah, blah? [01:06:43]

Carl Vitullo: Right, right. The agents are good at a lot of things, but they are not good at building the right thing. You have to get them to do the right thing. That's definitely been my experience as well. I've definitely experienced the, "I can do everything. Throw 15 agents." Uh, and then you review the work and try and actually make use of it, and it's like, oh, this is making a lot of very basic assumptions that are not the assumptions I have. [01:07:10]

Which I, I... One thing to say, the closer your assumptions are to the basic assumptions, the better it works in some ways. So the less creative you're being, the more effective they are. Or the more, like, s- effective they are at doing their own thing. I don't know. That, that probably says something about, I don't know, scale. [01:07:35]

Mark Erikson: Yeah. I mean, that, that basically goes back to why I personally have chosen a workflow that is essentially just me augmented, rather than me spinning off a bunch of agents. [01:07:53]

Carl Vitullo: True. That's why I shut my harness down and haven't had it doing stuff, is partly, largely because I haven't figured out how to put myself in the loop of their work in a way that is effective. [01:08:05]

Uh, I, I had them running for, like, a day or two, and they, they did work. A lot of it was useful work, but they also did some work two or three times and left, like, page-and-a-half comments three different times on the same PR. And it's like, oh, okay, this is... The usefulness to noise ratio of this is not where I want it to be. [01:08:16]

Let me revise this. And I have not revised it, because that's something I'm trying to find time for, and I cannot find any time anywhere. [01:08:33]

Outro

Mark Erikson: All right. Well, I think we've about covered things today, and then some. [01:08:39]

Carl Vitullo: Yep. That's pretty good. Thank you so much. [01:08:44]

Mark Erikson: We had a number of people sticking around, which is great. [01:08:46]

Carl Vitullo: Yeah. That's really nice. I like that I put a title in the kickoff thing this time around, and we actually had people show up. So it turns out, if you, like, care about communicating with people, sometimes people actually read and respond. What? Community building? You have to show up authentically? Ah, damn. I hate that. [01:08:48]

Cool. Thank you so much for joining us, y'all in the audience who are still here 90 minutes after we started. That's awesome. Thank you, Mark, for putting together this resource on short notice. And yeah, thanks for everyone who's listening to this on the recording, uh, when I publish it in probably longer than I intend it to be. [01:09:05]

Yeah. Thanks so much. We are going to be revising exactly what this podcast is, but it is useful and good, so, uh, it, it will be sticking around in some sort. If this is a resource that you find valuable and wanna help support, give us a review. Send us to a friend. Put us in the random channel of your work Slack. [01:09:22]

Generally, like, I suck at marketing, I suck at distribution, so if you can help me get this in front of somebody who has never heard of it before, that is the single most helpful thing you can do. Or, I don't know, just send it to someone anyway, even if you don't care. Please, help. Yeah. Thank you so much. [01:09:40]

See you next month. [01:09:55]

Mark Erikson: Thanks. Bye. [01:09:56]