TMiR 2026-09: React 19.3; a eulogy to software engineering?

Transcript and URLs 𐄁 ★ Support this podcast ★
Reply on Bluesky

• (00:00) - 2026-09: React 19.3; a eulogy to software engineering?
• (01:08) - New Releases
• (01:09) - Redux has a unified docs site now
• (03:39) - React-Redux `useSignalSelector` hook alphas
• (04:13) - Vite+ 1.0
• (06:10) - Vitest 5
• (06:30) - Vinext 1.0
• (07:01) - Lovable OJ vite-mostly-compatible dev server
• (07:37) - Preact 11
• (08:23) - MSW 3
• (09:28) - React Router 8.4
• (09:47) - Remix 3 RC
• (10:43) - Shopify bought Tailwind
• (11:01) - Jotai 3
• (11:59) - Poimandres Glyph typography engine
• (13:05) - Vidact
• (14:14) - Tanner Linsley’s Redact
• (15:19) - TMiR has a new website!
• (16:31) - Sponsored by Cloudways Velocity
• (17:32) - Main content
• (17:34) - React 19.3 is out!
• (17:45) - View Transition support
• (18:43) - Fragment Refs
• (19:43) - `use(browser())` API
• (21:30) - Oops bundle is bigger
• (22:37) - bundlejs.org
• (23:52) - React Devtools 8.0
• (25:25) - "React Now Rusted All The Way Out"
• (26:10) - React concurrent store prototyping???
• (27:23) - A eulogy for the software engineer | Dave Kiss
• (30:42) - We are all product engineers now | Laurie Voss
• (41:25) - "Do Frameworks Matter Anymore?" | Brooks Lybrand
• (41:50) - "How do you care when nobody else does?" | François Best
• (42:23) - “What motivates you to build software for others anymore?” | Sebastien Lorber
• (46:04) - AI Contribution Policies
• (56:05) - Lightning rounds
• (56:07) - Nobody pays for open source. We can force them to. | Laurie Voss
• (59:19) - Agent hacking swarms
• (59:48) - Schema Benchmarks 7 month update
• (01:00:37) - State of Devs 2026
• (01:02:50) - some quick misc thoughts about why MCP is so much better than CLIs | Rhys Sullivan
• (01:05:43) - The Grand Unifying Architecture of Frontend | Ryan Carniato
• (01:06:52) - Simon Willison: 2026 in LLMs So Far
• (01:07:35) - Shopify switching from React Native to native apps
• (01:08:07) - Discord migrated to RN New Architecture
• (01:08:31) - Conferences (React, Javascript)
• (01:08:34) - React India, Oct 30
• (01:08:43) - React Summit NY, Nov 17
• (01:08:49) - React Day Berlin, Dec 4

Creators and Guests

Host

Mark Erikson

An engineer maintaining Redux and Redux Toolkit, working at Replay.io to make smarter AI chat bots and debuggers using time travel.

Producer

Carl Vitullo

Solopreneur just vibing, posts are probably bullshit. Community lead at Reactiflux, the largest chat community of React professionals.

What is This Month in React?

How busy professionals stay on top of the React ecosystem. We give you a 1 hour recap of the latest news and nuance in React's development and ecosystem, upcoming conferences, and open source releases. New episodes the first week of every month, with live recordings on the last Wednesday of every month in the Reactiflux stage.

Hosted Mark Erikson (Redux maintainer), Carl Vitullo (startup veteran), and Mo Khazali (head of mobile at Theodo). See something for us? Post to #tech-reads-and-news

Carl: Hello. Thank you everyone for joining us for the September edition of This Month in React, as we recap what's going on in the React, React Native, and across the whole web ecosystems. We're coming to you live here in Reactiflux, the place for professional developers using React.

Carl: I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I do community programs like this event and the event I did yesterday, and build tools to help keep the community operating, and unfortunately, somewhat neglect those tools after several years of maintaining them, resulting in some, uh, we've had a couple of people get kicked by accident because of some changes that happened there, but we'll fix that.

Mark: Hi, I'm Mark. My day job is still at Replay, where we're still building really awesome time travel-powered dev tools and an automated QA layer on top of that that can find bugs automatically. and boy, am I still doing a lot of Redux stuff in my spare time. Woo!

Carl: Yeah, you've got a few new things to announce there. The, the big headline here is we've got a new, you know, React minor version, 19.3. people are continuing to eulogize software engineering as a field, so we're gonna keep talking about that. I feel like we've been touching on that more and more the last couple of episodes.

Carl: Let's start off with some new releases

Mark: so speaking of me being busy, um, the first item on the list is that the Redux family of libraries now has a single unified combined docs site. we'd al- always had multiple separate doc sites because we had multiple separate libraries, each with their own repository. The Redux core, which also had all the tutorials and the usage guides, Redux Toolkit, React Redux, and then Reselect.

Mark: and so each of them had their own markdown files. They each had their own Netlify site and, and build previews and everything. And people had filed complaints over the years saying that it's confusing that I have to jump from site to site to follow links or, or information. Uh, the sites all had the same look and feel, which was good, except you get confused which site you're looking at, some pages were duplicated across sites just in case.

Mark: I had said for years, "I can't do that," because the only way I can think of to do it at the technical level is to combine all of our repositories into a giant monorepo, and this will require massive amounts of Git history surgery and changing all the pipelines and the issue management.

Mark: And, like, I'm doing this in my spare time. I... There's no way I can put hundreds of hours into this effort. Well, last year, actually pre-AI, I had very briefly prototyped an alternate idea, which is what if I just cloned the other repos whenever you do a Redux core docs build, and then you got the files on disk, and then Docusaurus lets you combine multiple sets of content into one site.

Mark: And so I'd at least proved that it was possible in theory. And so, as I'll talk about later, I'm doing a whole bunch of Redux-related cleanup work at the moment. And over the last, like, just two to three weeks, I said, "What if I just point my agent at this and say, 'Do it for me?'" And we worked through all the complexities.

Mark: We got all the content up and running in one site, worked through a bunch of issues around PR previews and other things, and I, uh, officially shipped it while I was 34,000 feet over the Atlantic on Monday. and so there's now a single site, redux.js.org. It's got a dropdown to s- you select which set of library docs you're looking at, de-duplicated pages.

Mark: I also did a massive cleanup sweep to find every place we had out-of-date explanations and content, and so that's all up there.

Carl: you got another news to announce too

Mark: Yep. so for the last couple months I've been saying that I was working on a new React Redux hook. It is now in alpha. It's called useSignalSelector. It is a drop-in replacement for useSelector that uses proxies and signals inside to try to optimize updates. It should not be the default one that you choose.

Mark: It's meant for large apps with thousands of connected components. It does have a larger bundle size, but it speeds those up as well. So, it's pretty solid at this point, and I'd love people to do some real-world testing on it.

Carl: Oh, yeah.

Carl: We mentioned this last month, as an RC, but it's now out for real. Vite+ has a 1.0 release. They... This l- this is pretty neat. It looks like it's trying to offer, like, a general kind of one-stop. I guess it's a little funny. It's kind of an abstraction over, you know, what we would typically do for NPM scripts.

Carl: , instead of, like, npm run, npm create, npm install, it's got vite+, you know, vp create, vp install, vp dev. That's interesting. It's, it's trying to provide d- sane defaults for a lot of these really common behaviors using, you know, the current cutting edge of tools, Oxlint and Vitest and Vite 8 rolldown.

Carl: I see TS Down mentioned, for packing libraries. It has a monorepo awar- aware task runner with caching. So you know, it's, it's trying to do a lot. I would love it if one tool did all of this. That's really great. I hope it works as well as advertised.

Carl: Stuff like monorepos gets really complicated. I'm actually, m- currently in a project where I'm looking at options for monorep- repos across different languages. You know, I wanna, I want to not lock myself into only using TypeScript, so that's, you know, that's a whole different prospect. so yeah, I'm curious. I'll have to play with this. I'll have to see what it actually looks like in practice. But yeah, so, Vite+ has a 1.0 now.

Mark: It, it is interesting to compare it to earlier similar things. Create React app at least tried to provide pre-built configs for Webpack and Jest and Babel and everything else so you didn't have to do it. And then the Rome project was originally supposed to be linter, formatter, everything else, one AST parse, and everything is fully combined.

Mark: And then it flopped as a company, and we were left with just the standalone formatter that became Biome. So kudos to the Voidzero folk for managing to build the separate tools and then figure out how to get a layer on top of that, sort of flipping the process.

Carl: We've also got Vitest 5. you know, I, I don't know. It's a test harness. It's advertising a lot of performance improvements, which is great. It's always good when our tests run faster. Not seeing a ton of, you know, major changes that would get me excited about a new test runner, but, hey, new version.

Carl: L- V- Vitest is great, and now it's great-er.

Carl: , we talked about this a couple of months ago. Uh, Cloudflare produced a open source Next runtime, so you can self-host it more effectively. they

Mark: a slop, it's a slop fork

Carl: It's a slop fork for sure, but you know, hey, the, the, if we have functional tests, what's the problem? so yeah, it's a slop fork.

Carl: We talked about this in February. Uh, they are now announcing a 1.0 seven months later, so it was a slop fork, and hey, maybe it's now revised down into something a little bit less sloppy. And it's a 1.0, so that's great.

Mark: , so Lovable spins up tens of thousands of dev servers for all the different apps that they build, and even with Vite using Rolldown and Rust powered inside, they decided it wasn't fast enough for them. So they, they similarly have reimplemented some of the guts of Vite to make it even more Rustified in some way, and this has apparently been fast enough to handle the, the speed of all the dev servers they need to spin up

Carl: Nice. Cool. Yeah, I mean, certainly they're dealing with a lot, l- large volume of code right now. Improvements they make and the, friction they experience is gonna be pretty representative of the industry. Cool.

Carl: Again, something we talked about last month as an RC, Preact version 11 was released.

Carl: We talked about most of the benefits last time, so I'm not gonna, going to exhaustively, you know, re-discuss them. In reduced package size on disk, you know, install size of the whole module. they're talking about tree shaking, which, man, you know, everyone always talks about how it's all tree shakable now, and then I feel like the next version talks about how it's really tree shakable for real now.

Carl: So I just always take that with a hefty dose of salt. But hey, they're advertising it. It seems great. Tree shakable per feature, which is lovely. Yeah, lots of deeper in the weed stuff. They're saying hydration 2.0, hydrating while lazy chunks are loading makes zero DOM mutations. Cool. Love that. yeah, Preact version 11 seems great

Mark: Meanwhile, MSW, Mock Service Worker, just released version three. This looks like it has some pretty meaningful changes. They're going ESM only, like a lot of other libraries. More granular entry points, which sort of ties into the tree-shaking sides of things. Um, they now support, uh, GraphQL subscriptions built in, and there's a whole new API for defining network sources that's kind of like a, an, an improved version of the handler definition approach that it had.

Mark: and it also has lower level support for being able to directly intercepts all the way down to the socket layer, even with, even within Node. So I know Artem's put a lot of time and research into figuring out how to make network interception more effective, so this one feels like a pretty big release.

Carl: Yeah. Love that. MSW is, I haven't used it lately. The times that I've had to reach for it, it's been like an absolute essential part of achieving whatever task I was working on. Like, if you're doing integration tests, then like, ugh, MSW is so good. so yeah, exciting.

Mark: React Router put out version 8.4. They've done some internal re-architecture and changing their context structure to reduce re-renders. they've also got some optional more efficient route matching. So I guess if you've got apps with lots of routes and that's a possible performance bottleneck, then they've got an option that will try to make that faster

Carl: Cool. And, uh, Remix is advertising its, V3 release candidate. I don't know, where... At what point do we stop including Remix in here? 'Cause they're, like, very publicly not a React framework anymore, you know? We're leaning on it for its historic relevance at, this point, starting to.

Carl: yeah, they're saying since the beta, it's grown a lot. A complete database workflow with migration seeding, status checks, full stack hot module replacement, reload server modules, improved public asset serving. So, you know, it's, it's a, full web framework. They are moving away from React.

Carl: They are... I believe it's pretty heavily relied on at Shopify, which I think we're gonna talk about later too, is, uh, moving off React Native. So I, yeah, wow. I g- you know, hey, come to think of it, actually, Shopify generally seems to be exiting the React ecosystem if they're doing Remix and native apps.

Carl: Interesting

Mark: And I, I don't think we actually have the link in here, but I believe Shopify just bought Tailwind

Carl: Oh, did they? Curious. Oh yeah, on September 9th. I missed that. Okay. Remix is great. Technically, our website, one or more of our websites runs on it for Reactiplex, or has run on it. I've lost track at this point. But yeah. Definitely paying attention

Carl: Jotai has a v3 release.

Mark: So Jotai is an Atom-based state management library. I believe Recoil was the original library from Facebook that introduced that paradigm. Recoil died. Jotai was a smaller version from Daishi Kato. Version three is mostly clean up. I believe it, it also went ESM only, and changed a few exports and shuffled around some API locations.

Mark: So mostly clean up, but there, there's a definite trend of libraries going ESM only at this point.

Carl: Mm-hmm. Oh, yes. Yes, we've talked about that trend several times in the last couple of months. Love to see it. Finally. Ugh

Mark: I heard an earful about it at a React Alicante last week. That may be a separate discussion topic

Carl: Ooh, interesting. Okay, cool. An earful about ASMR

Mark: the, uh, let's just say that a couple people have very, very strong opinions about this.

Carl: Against or for?

Mark: Uh, mostly against

Carl: Fascinating. Okay. All right.

Carl: again, something we talked about is, uh... we referenced this earlier 'cause, uh, this is a Pointmanders project, and they released a, a charter a couple of months ago, listing this as a project they were gonna be pursuing. But they've, uh, announced something.

Carl: - Pointmanders Glyph is a typography engine for web graphics. So, like, we're doing text rendering in WebGL, and generally in, you know, graphics pipelines is actually pretty complicated because of the way, like, sub-pixel grouping and, like, kerning and... I don't know. Actually, typography is an- typography and typesetting is an absolutely insane depth of, you know, complication. The closer you look at it, the weirder it gets.

Carl: so writing a new one f- from scratch i- targeting a new environment is a huge undertaking, and they have announced one. Um, so that's pretty cool. I don't do very much WebGL stuff. But especially if you work on fancy landing pages, check this out 'cause it can make your text look better, probably.

Carl: , yeah, Pointmanders does tons of WebGL stuff if you're not familiar with the name. So yeah, definitely h- I personally have a lot of trust for them in, in this domain. Looks pretty cool.

Mark: I feel like I've been, we've been seeing an explosion of more React-alike or React knockoff or React variation libraries. We talked about one recently called Octane from Dominic Ganaway. That was essentially React, but it has to have a compiler, and it tries to clean up some of the rough edges, like hook dependencies.

Mark: Dominic had also put out the TSRX, like, improved JSX syntax layer as well. There's a, there's a new React-alike called Vdact, which is also React with a compiler, but rather than having, like, the fiber runtime underneath, it acts more like Svelte and just compiles straight down to DOM manipulation code.

Mark: Have not tried it, have not looked at it, but it has some examples on the front page of you write a React component with a useState hook, and it just gets directly compiled into, like, createElement div and DOM append calls immediately. So keep the friendly syntax, skip the runtime, and presumably things end up smaller.

Mark: also, several months ago we had mentioned that Tanner Linsley wrote a post called Projecting React where he said, "I really don't need all the concurrency features that the React team has spent years building, and they're kind of making server-side rendering slow. What if I slop fork React to just rip out all the stuff I don't care about?"

Mark: And so he said he had done it, and technically the source was available somewhere if you looked very carefully. The repo is now more actually available, and he's calling it Redact, so React with a letter D in the middle. It's still essentially like a you probably shouldn't use this, but it is there and the source is available, and it is on npm if people really want to use it.

Mark: we're seeing a lot of people looking at React and saying, "Well, if this is kind of the default way to write apps today, but we don't like some of the behaviors or the syntax, what are some alternate ways we could rework this to fit our needs?"

Carl: you know what? I, this was a late addition, but it's a new release.

Carl: Uh, we have a new website.

Carl: I threw it together. This is, you know, it's sloppy. I threw this to a new model just as, kind of to explore capabilities. I've been, I've literally been meaning to rebuild our website for years at this point, um, because I just, you know, jerry-rigged it into the existing infrastructure we had for Reactiflux, and that was not built for this. So it was not a good experience, and I knew that the entire time I've been doing this.

Carl: so now we have a better one. It's, it's significantly better. Typography is way better. behavior of, you know, you can... Now we have a sidebar with all the links instead of them just being at the top, and if you click on one of them, it will jump the play ahead to the right time so you can start listening as you read.

Carl: we've also got some link search, some topic search. It should just be... I, I have already used this website a few times for myself as I'm doing the documentation or, you know, prep notes, and like, "When did we talk about that?" hey, it's already useful for me. Uh, it's live. There's a couple things still broken.

Carl: Please don't sign up for the newsletter, 'cause it doesn't work. I haven't set up a publishing flow, and you will get test emails if you do. Sorry.

Carl: You know, I'm, I'm calling it slop because I used AI to make it, but it's better than that. You know, I put more effort than slop into it.

Carl: yeah. Anyway, reasonably proud of that.

Carl: we actually have a sponsor this month, I'm proud to announce. Yeah. If you have ever launched a full-stack React, Next.js, or Remix app on serverless hosting, you know the pain points. Cold start latency on that first request, and then out of nowhere, unpredictable bandwidth bill at the end of the month.

Carl: Cloudways Velocity gives you fully managed, persistent Node.js and full-stack hosting built specifically for developer speed. Because it's running on always warm infrastructure, cold starts are off the table. You get seamless Git push deployments, zero downtime rollouts, built-in Cloudflare enterprise CDN, and enterprise security, all managed right from an intuitive UI.

Carl: No configuring nginx, no SSH head-scratching, and most importantly, flat, predictable monthly pricing with no surprise bills. Stop overpaying for serverless spin-ups and stop wasting time on server administration. Go to cloudways.com/velocity, deploy your project in minutes, and experience how fast your apps should be running.

Carl: , start your free trial, and you can use promo code CWREACT for 25% off your first month, exclusive to React to Flux. Yeah. Give it a shot if you're deploying a Next.js or full-stack React app.

Carl: Okay, cool. Main content.

Carl: There's a new React minor version, 19.3

Mark: Nice. And this has a couple features that we have, as usual, talked about multiple times already, partly because they've been in Canary for a while.

Mark: the first is official view transition support. There's now a new view transition component that is built in. once again, like I don't work with front-end code myself.

Mark: I don't write view transition-y things. But this is a major new capability of the web platform as a whole, being able to do crossfades and a- other animations between parts of a page, separate pages, et cetera. It's built into the browser, but there's a bunch of nuance in how you set it up and how it works properly, and my understanding is, is that React's component is doing a lot of heavy lifting for you internally to be able to set all those up properly.

Mark: if you look at the 19.3 release notes, there are a lot of examples in here on how you use the new component, how you specify different kind of animations, and apparently it also even integrates with Suspense as well. So that's a pretty major new feature.

Mark: The other one is fragment refs, and this is another... This deals with a longstanding pain point in React where you could get refs to an individual DOM element. But let's say you have, like, a list component where there might not even be a parent, a single parent DOM node. It's just a flat list of children. There might not be anything to get a handle to.

Mark: So fragment refs allow you to attach a ref to a fragment element in your component, and React essentially pretends that there is a fake synthetic parent wrapper around all the children and gives you the methods that you can call to interact with them just as if there were a real DOM element there. They've had to put a lot of work into this, and this definitely solves a gap in React's interop abilities.

Mark: There's also a new feature called Browser. Anytime you're doing server-side rendling, rendering, you run into the problem of I have some code in a component, and the component gets rendered on both the client and the server, but this bit of code should only run on the browser.

Mark: And so frameworks like Next.js have had their various, like, dynamic import or SSR Only or whatever other flags are in there to try to limit what logic runs in what environment. So there's now a new function called Browser in React DOM, and you call it and you pass the result to the Use hook. So it's Use, parentheses, Browser, parentheses, and that throws, that triggers suspense, and at that point, React on the server says, "Oh, I shouldn't actually render this.

Mark: Leave the hole." And then when it gets to the client side, it runs again and says, "Ah, yes, this is client-side code. We will only actually run it there." So it's an official built-in solution, again, for something that people have needed to do for years

Carl: Yeah, I like that. I like that a lot better than the, was it use server that was the,

Mark: Use server and use client are bo-are both directives. This is a, a function that you import and call inside of a component

Carl: I've been, like, casually whining about the use of directives for that and how I don't like directives because the, the whole thing with the use strict when we invented directives was just the one, no more.

Mark: and then they proliferated

Carl: and, like, this seems great. If you can just say this needs the browser APIs, then okay, if it doesn't say that, then you have free reign to assume that it might not have access to them, so cool.

Carl: , that seems like a, you know, I love that. This seems like a big improvement to me

Mark: One thing that's not listed in the release notes, but I, I saw some discussion somewhere on the R- React to Flux side, and it, it ties into the Preact thing. Bundle size. I don't have the hard numbers in front of me, but I saw some comments saying that 19.3 had a very significant jump in bundle size.

Mark: And React DOM is already a very, very large library, and clearly the view transition support and fragment refs and, you know, whatever other bits they added add a s- it's just a significant amount of extra code. And that code is in React, and React itself is 100% untree shakable. It's all intertwined together.

Mark: So your bundle is going to be getting the view transitions code whether or not you ever use a view transition in your app, and it keeps growing. And, you know, view transitions look like a very useful feature, but is anybody over there actually considering bundle size as an objective? I suspect not

Carl: Sure. Do you know what the best site to check bundle size is anymore? It used to be Bundlephobia

Mark: bundlejs.org. the problem with Bundlephobia and a couple of the others the npm and npmx websites just tell you how big is this on disk in node modules. Uh, Bundlephobia tries to figure out how big it is, but it's kind of simplistic in how it looks at the entry points.

Mark: and right, and so, you know, like number one, if you, if you just look at React, React itself is the platform agnostic piece. It's React DOM that matters. And in React 19, they changed the entry point structure, so it's React DOM/client. So you have to specifically know that's what you're importing from, and then it's actually in like a third file inside of that.

Mark: Bundlejs.org lets you explicitly write some snippets of code. So if you wanted to do like export create route from React DOM/client, it literally downloads the files and bundles them and tells you how big it is bundle size is 222K, 70K gzip

Carl: There's also React Dev Tools, a new major version, version eight. I gotta say, this is, you know, surely this is just updating to match the latest

Mark: they have actually been doing a fair amount of work on it. I believe the existing profiler tab is now deprecated or removed, and instead they're, they now better integrate with the performance tab that's built in. on the other hand, there's now a suspense debugging tab that is part of the dev tools.

Mark: that's supposed to do actually some slightly time travel-ish things and show you like sort of a, a skeleton layout of the page and the suspense loading sections as they come in

Carl: Love that. Yeah, I mean, the profiler and the performance features were great, but, it was a duplication. We had our own performance tab in the Chrome dev tools already

Mark: I will point out that replay's time travel abilities in our MCP have some awesome React Performance Insights tools because I built them

Carl: . Yeah. I'm looking at - the past releases for the Dev- React Dev Tools too. It looks like they're doing a major r- release about every year. Thereabouts the past couple years. Although, yeah, the, cadence of follow-up releases has definitely dropped in the last three or so.

Carl: You know, I see version 5 and then 5.1, and then 5.2, 5.3, 6, 6.1, 6.2. But yeah, 7 just got a single patch release, and now we have 8. But hey, maybe that means it's settling down. It's stabilizing.

Mark: And then a couple adjacent tidbits that are related to React Core, but not from the React team themselves. ,

Mark: there was an article on how the... You can now build a React app with a whole lot of Rust-based tools start to finish. A lot of that actually involves the React compiler having been slop forked to Rust by the React team, and then the other bundlers said, "Actually, even in its Rust form, it's kind of hard to integrate, so what if we then further fork and customize the integrations with our own tools?"

Mark: And so, like the OXC people essentially h- now have their own variation of the React compiler that better integrates and runs faster. And so the article points out that you can use that and some Vite plugins and some other pieces to more efficiently build a React app start to finish.

Mark: and then we've actually had some very interesting discussion going on in our very own #react-internals channel, a channel that I watch like a hawk.

Mark: Last year I was really interested in the, this concurrent store API discussion that Jordan Eldridge from the Relay team was working on that was essentially supposed to be useSyncExternalStore, but Transition compatible. And then that whole effort stalled, for a whole variety of reasons.

Mark: And just within the last couple weeks, a couple of community members, Xander and Justin, have been actively working on their own improved polyfill implementations of what this might look like, uh, and making some pretty significant progress on both. It's a long way from community members saying, "We've built a seemingly working version of this," to it ever actually landing in React itself, but I'm very truly hopeful that something like this will actually land in React at some point, because this is the missing piece that libraries like React Redux need to actually be properly Transition compatible.

Mark: So I'm, I'm excited to see anybody putting effort into this right now

Carl: Yeah, I love it.

Carl: All right. Into the sad topics.

Mark: Into the sad topics

Carl: Dave Kiss put out a blog post titled A Eulogy for the Software Engineer. In loving memory of the software engineer, 1968 to 2026. a- I view this as slightly tongue-in-cheek. I think this is overstating it a fair bit. But yeah, you know, like, our profession is totally different here at the end of September as it was one year ago, you know?

Carl: When I think back to what I was doing September of last year, I was pretty aggressively using AI agents for the first time. But I was doing it very much from a perspective of you know, watching it like a hawk, reviewing its code. We're using it as a more of a collaborator. a thing we've said in the past is, automation versus mech suit.

Carl: You know, do you climb in and drive it, or is it let do its thing and check on the results of? And for me personally, it's definitely moved much more towards something I check the results of rather than reading all of its output. You know, d- having it, directly enable the code that I'm writing, per se.

Carl: We also have the state of devs, from, uh, Devographics to talk about, so we c- if we do, we can put that into some greater context a little bit later. Eulogizing software engineers, though

Mark: I mean, I, I wrote my own blog post, you know, on a, on a similar theme back in April, you know, detailing how I'd gone from the idea of hating AI to trying it, just over a year ago. It's actually been just over a year that I've been using AI to write code. And I, I am still very intentionally on, uh, if I understand the analogy right, the mech suit side.

Mark: I'm the one doing the driving and it's improving my abilities. That is a very, very intentional choice that I'm making to limit myself to my context-switching ability and what I can keep in my own head. I will say that even within the last few weeks, I've noticed that I'm willing to let, my chat sessions be a little more autonomous.

Mark: some of it's been the, "Hey, I need to go run errands for a couple hours. You have permission to actually, like, run a few more experiments and try some stuff out while I'm gone." And oh look, I'm, I'm getting work done while I'm running, running errands. It's great. but also I have more trust in the output.

Mark: one of the biggest reasons why I was scared to use AI at all was because I considered it completely untrustworthy. I saw too many hallucinations. It's nondeterministic. I did not believe that you could safely build software with AI. And yeah, I, I completely watched it like a hawk. And The models keep getting better, and now that Opus 5.5 and Fable actually talk to you like a human again.

Mark: Honestly, I have very few complaints about the code that is getting generated at this point. Like, could it be better architected? Probably a little. But it's perfectly readable. It's perfectly valid code. I've seen people write way worse c- I've written way worse code. It's more than good enough at this point. And it is still continuing to change how I actually do my job, and it's weird.

Carl: I'm gonna pull in the next link too. Uh, Laurie Voss, who has been very influential at NPM a- for a long, long, long time, put out a post, "We are all product engineers now." And, you know, it's like, hey, you know what? Like, that's the title I've been claiming for four years now. there's a funny part of this new world that feels weirdly like it was built for the set of incentives that I encountered my entire career.

Carl: . I'm thinking about, like, the code crafts people movement, and, you know, it's like, "No, we care about the craft of it. It has to be well-architected. It's gotta be, you know, this and this, the... It's about the process and not just the output." It's like, yeah. I'm gonna expand the scope of this for a moment. I tend to think of that kind of idea of, like, the craft of the work and the output of it as they're kind of inherently in tension. If you, If you want everything handcrafted and, you know, made with care and with a human's judgment and attention built into it, that's a lot of energy per unit.

Carl: And if something takes a lot of energy per unit, it's more expensive. And if it's more expensive, it's less accessible to people who have less money. If you think about anything that you buy, there's that tension between handcrafted and mass-produced. Like-

Mark: An Ikea table versus something from an Amish furniture store

Carl: And, like, you're gonna pay more for the other one. So it's, you know, it's a tax on morals. It's a tax on values. Yes, I am personally someone who finds a lot of value in the way things are done. You know, the ends do not justify the means. The means have to justify themselves. but it's also true that I am someone who values making things accessible for more people, and the way you do that is by operationalizing, productionizing, reducing the per unit costs.

Carl: And so, like, those are in tension. Those are naturally in tension. You can't have one without, you know, sacrificing the other. As we're eulogizing software engineering and, you know, the way things have been done, that's kind of the framework that I'm thinking about the next phase of this world we're in, is like, you know, yes, okay, it's an, it's... The craft is different. you know... Th- this is, analogous to, like, you know, full hand tools versus powered tools, electric tools. You know, are you using a battery-powered thing or are you spending your muscles to do it?

Mark: which which from what I've read is still a massive argument topic in like the wood crafting communities

Carl: Totally. Yeah, and you know, like I have this, right behind me here, I have a, you know, a whole toolbox full of all these hand, hand tools, whatever. Including, you know, I've got like a little drill, you know, a hand drill thing that you can put a little drill bit in and you just turn it yourself and s- but I also have a battery-powered drill, you know, for putting holes into things that that would just take too much energy for.

Carl: That's how I'm thinking about this. you know, this We Are All Product Engineers Now i- from Laurie Voss is about y- you know, like the job of making software will become what the agents can't do.

Carl: I think that is a really good articulation of, like, generally work. you know, it's about any work that you do, any work that I do is about finding a niche that I can do relatively better than anyone else. And so now if agents are able to do a lot of things pretty well, then that just affects the boundaries of what I should be looking at, you know? So, like, and I've said, I, you know, I- I...

Carl: My point as we've talked about agents and this shift in the industry, my point has very consistently been around, like, asking questions of it. You know, it's, it's about communicating with your code, with your project, and setting the priorities and communicating intentions now more than actually the nuts and bolts, the, the, the bits and bobs of making it do the thing you intended it to do.

Carl: Like, you know, now it's about how clearly can you articulate your intentions and how aligned are your intentions with the real world? Like, are... I- is it achievable?

Mark: there's a lot of sense in which You can, like, you can go off and build any piece of software you want now essentially at the press of a button. It's more complicated than that, but if we assume that as a starting point, then it's a question of what are you trying to build? What are your intentions?

Mark: How well do you understand what the end goal is and what things have to happen to get there? How well can you hand your agent the right context so it knows what you want to accomplish? How much time and effort have you put into defining the guardrails to make sure it doesn't do something stupid? And some kind of measurements that it can use to decide, you know, I've actually finished the job successfully.

Mark: it's more about, I mean, constructing the systems that do the building, whether you're doing a w- a single chat conversation at a time, like me, or you're setting up, you know, entire automated software factories.

Mark: I took great pride in the craft concept. I never lived up to it as much as I thought I should, but I tried to live up to it.

Mark: I got huge amounts of satisfaction from spending hours beating my head against a problem and coming up with a really clever solution and jumping up and down and screaming, "It works, it works, it works."

Mark: it saddens me that that's not the exact thing that I'm doing at this point in my career. But it's also really, really satisfying to say, "Okay, I had, you know, a set of work tasks and I cranked them out exceptionally quickly because I was just able to point my agent at it and say, 'Here's the problem I'm trying to solve. Here's how I want you to investigate it.' And it did the really hard stuff, and we came up with a solution, and then I said, 'Here's the next step.'"

Mark: Or similarly, I have been massively productive in Redux work in the last two months. the useSignalSelector hook is an idea that I've had in my head for the last three years, and I'd only ever managed to do, like, two individual one-day explorations of it. And finally this spring, in between traveling to conferences, I said, "Okay, let's run a bunch of research tasks on 20 different signals libraries.

Mark: We have architect, you know, docs describing how they work. Okay, read these, synthesize them, propose to me a possible implementation that does the thing that I want it to do." And then built a prototype and iterated and wrote tests and found edge cases and improved it and iterated. I literally did not have the time or mental capacity to do all that work by myself.

Mark: the combined doc site is something that it's been asked for for years, and it just wasn't a priority for me because there was life going on. And over the course of a couple weeks I was able to say, "Okay," like I did actually technically do a prototype for this last year. Is this a viable solution? What would we have to do to productionize this? Do it for me.

Mark: And it actually got like the bulk of it working in one session in the course of like three or four hours, partly 'cause it wasn't as hard as I thought it would be. But I mean, the agent then proposed most of the cleanup work that needed to be done, and at that point it's me telling it, "Okay, yes, do phase three, do phase four, do phase five."

Mark: So like I truly do feel excited and empowered by this. Like I have cranked out things that I've wanted to do for years, and even if it wasn't me carefully crafting the lines of code, there is a lot of personal satisfaction in seeing that stuff come to life. So that's where I've landed

Carl: Yeah. I agree. What Laurie says here about, They talk about what, what's next on the chopping block, what's possibly safe. And you know, what they say is possibly safe, deciding what to build in the first place, deciding the definition of good and making it delightful. And like, yeah, you know what?

Carl: Like, those are matters of taste. And, like, a thing that I think that we keep saying in this podcast, I keep saying it generally, is that, like, AI fundamentally has no taste. It is designed to enable people to offload cognitive tasks into something that, can do base cognitive work.

Carl: It has no way of judging whether its own work is good. It can determine whether it passes objective metrics and whether it meets these clearly defined requirements. But if you give it, if you ask it to define what good is, it can't do it. It can't do it in the way that you or I would.

Mark: it's how we get purple backgrounds and gradients

Carl: Right. Right. And but, like, you know what else cannot, fundamentally is unable to determine a y- workable definition of good is, like, a corporation, a large team, you know, a committee. To me, all of the same criticisms being leveled about AI outputs rhyme very closely with things like, designed by committee. " what's a zebra? It's a horse designed by a committee."

Carl: if, that aspect of productive work, the, you know, validation on outside objective metrics, like, that's what a corporation is really good at. Like, you just throw bodies at it, throw minds at it, to handle all of these incremental cognitive tasks of deciding what needs to be made, making it, figuring out what metrics you judge it by, recruiting people to evaluate it, and then synthesizing their feedback into, you know, a response of, "does this meet their requirements?"

Carl: They don't require taste to successfully execute, which is, you know, like, that's the stereotype of a, like, you know, the indie versus corporate. You know, the, like, artist versus sellout. This is a force multiplier in those - comparisons.

Carl: This is easily 100X. You know, now you don't have to hire 100 people. You just, you know, give five people a large token budget. To me, it's fundamentally approximately the same thing. So I, I don't know. That's Not to diminish the disruption and the change, but I don't think it's quite as, like, fundamental as a lot of people believe it to be.

Mark: Yep

Mark: So tossing in the, the additional relevant links we've got here. Thorsten Ball, who's part of the AMP Code Agent team, put up his thoughts on where software engineering is going. Some of these I definitely agree with, like code review is in the form we've known it, is probably going away. He also thinks unit tests and, and terminals and shells will go away. Those I'm, I'm less convinced on. But, it's a good set of thinking on the direction.

Mark: Brooks Lybrand from the Remix and React Router teams put up a sort of similar themed post on do frameworks even matter anymore? And some of it's the usual, like, okay, React won.

Mark: Some of it is, well, if agents can crank out code, does it really matter what the code is if no one's really even looking at it in the first place? And then a couple of discussions from social media.

Mark: Francois Best, who is the maintainer of the Nuxt URL State Library, put up a tweet where he said he's been feeling kind of burned out, and how do you actually keep doing this when nobody cares and all you're getting as issues is agent slop?

Mark: I definitely feel this one. We've been getting a lot more slop issues and PRs filed on the Redux repos, just within the last couple months. And so I've, I've definitely been feeling some of that myself as well.

Mark: And then Sebastian Lorber, our former co-host here on the podcast, also put up a tweet asking, like, why would you even spend time building software for others when anyone can have their agent just crank out code for themselves? And I actually replied to Francois with kind of my own thoughts. At this point, like for me personally, especially on the Redux side of things, it's really about responsibility. I took on the mantle of Redux maintainer 10 plus years ago. I'm the one who's put the responsibility on myself for doing all the work and keeping things up to date.

Mark: AI does not take that off my shoulders, and in fact, I've managed to make a whole lot more work for myself within the last couple months. But I plan on doing this for quite a long time. Redux usage is going down by market share. Absolute numbers up, percentage down. So honestly, I have no idea how many people will care if I improve the docs, if I ship a new API, but someone will get benefit out of the work that I'm doing.

Mark: I actually talked to some folks from large companies at conferences just the last week who are using Redux toolkit in giant monorepos, and it's like, "Yay, my stuff's being used in production. This makes me feel good." so I may not be getting a lot of direct feedback, but someone will benefit from the work that I'm doing, and so I'm going to keep doing my thing even if not as many people care.

Carl: Yeah.

Carl: I'm having some kind of reaction to this quote from Sebastian, uh, "What motivates you to build software for others anymore?" I think about it, like, a huge number of very successful open source projects were not made for others. It's somebody scratching their own itch, and then they posted about it, and other people went, "Oh, I have that itch too."

Carl: You know? So it's like a lot of the best, most impactful open source was not made in that way. It was not for someone else. Nobody was, like, doing user interviews to uncover pain points. It's just like, "No, I'm doing this work. I believe in myself. I believe this is valuable because it's valuable to me. I'm just gonna publish it and see what comes out of that."

Carl: And then, you know, over time it's become more and more reliable, or, uh, relied upon rather. The flip side of scratch your own itch and maybe other people have it is, like, maybe they don't.

Carl: Maybe the way that you're scratching that itch is, like, way more complicated than it needed to be and, you know, some, or somebody else already made a, a back scratcher and you just never looked for it, you know? Like, I run into that a lot. I reach for making my own thing before I do research into what others have made a little bit too readily.

Carl: So I don't know. That's Something about that framing made me really... And, like, how do you care when nobody else does? Like, I don't know. Sorry, but, like, that's fucking life. I don't know. some part of me bristles a little bit, just like . It gets my hackles up a little bit when people are talking about, like, pushing through motivation and pushing through, like, being ignored, and it's like, I don't know, that's just been my life. I've never had an, never felt like I had an audience.

Carl: I never felt like people were interested in what I was doing and I never had validation. I just kinda kept doing it for my own reasons. So, like, okay are you having to explore and find self-motivation for the first time versus validation from others?

Carl: like, yeah, sure, validation from others is very nice. We are very social creatures. But also, like, I don't know, believe in yourself. Some confidence that what you're doing is valuable. Like, uh, intrinsic motivation is way more durable than extrinsic motivation. so yeah, I don't know.

Carl: This feels very related. thank you Dogpaw Hat for reminding me.

Carl: there was an AI policy.dev website put together. I saw this when it was launched. I saw who had contributed to it and I am not...

Mark: I believe it's from, uh, James and some of the E18E folks

Carl: Yeah. E18e, uh, Daniel Roe and James Garbutt, both of whom are lovely people, really phenomenally thoughtful contributors, I think. Um, so th- yeah, so this is a, an attempt at, a generally useful AI policy for open source maintainers.

Mark: The comparison I would make is it, it's kinda like pre-made software licenses, just like the GPL and the MIT are pre-written ways to say, "Here's how you are legally allowed to use my code.", this is an attempt to predefine possible ways that you might accept or disallow AI-powered contributions to an open source project

Carl: Yes. and there are four policies right now. AI allowed, which permits generated code, written text, agent submission, agent PRs. Human voice, it requires the communicative text should be human authored. AI can help you, but it must never speak or think for you. Then human responsible, which drops that a little bit more. How you made it is y- your business, but everything you submit, you own, you are responsible for. And then just AI disallowed, nothing at all.

Carl: I'm thinking about where I fall on this, and I'm full-ass AI allowed. I don't write my own PRs, I don't write my own commit descriptions anymore.

Carl: I don't review the code in depth, and it, so far that's been working out, out pretty well for me.

Mark: I've been right on the edge, this actually ties to what I was saying in the, in the last, you know, the last couple months of both day job and Redux work. I've got a standing rule that my agent should not do any Git commits without explicit permission, and I have been allowing it to do some commits for, like, some long-running tooling migration tasks or some other things.

Mark: I have also not generally allowed my agent to open up any PRs directly. I have allowed it to do a few, especially, like, some one-off little quick, configuration fix PRs to the Redux repos.

Mark: Uh, other times I've said, "Okay, give me a PR description," and then sometimes I've still written my own bullet points and then put a separator and then pasted, "And here's the agent," blob.

Mark: But also there's been some times when I've just pasted the agent blob in directly. And so, like, I'm, I'm right on the edge of, well, I didn't write this, but, like, the text is readable and it covers things, and is it worth my effort to actually write it up by hand right now?

Mark: So like I'm, I'm, I'm, I'm right on the edge of, how I want to use that there.

Carl: Yeah. There's a part of me that thinks that I think some people will receive this as, you know, insulting or mean, so which is why I pause. But, um, there's a part of me that feels like if you're getting low-quality slop contributions in PRs and issues, then your contribution guidelines are insufficient.

Carl: Okay, in eulogizing the software engineer, I think that we miss that software engineering has never been a very mature field. Like, I've said this over the years in this podcast once or twice at least of, in other fields, if you have a professional engineering certification, you know, if you go that extra mile, you do all the school, you do the work as a, an engineer, an electrical engineer, a mechanical engineer, an aerospace engineer, um, a structural engineer, and you become a, you know, capital P-E professional engineer, then you are asked to sign off on designs.

Carl: And if those designs are deficient, if, you know, there's a failure, a design failure, then you are personally liable. Like, if people die, you are held culpable for their death. And, like, we don't do anything like that in software engineering. Like, there is absolutely no level of accountability in our field comparable to that in physical engineering fields.

Carl: And so, like, okay, sure, software engineering as we understand it is dying, you know, quote-unquote dying. it was never really that

Carl: mature. It was never-- We, we never held ourselves to the same pan- standards as other engineering fields. And in some ways, I think what we're looking at right now is going to enable us to do that, because it's, you know, like if, if you're reviewing a million lines of code, like, there is absolutely no way you can individually, as a, a single human person, say, "This will not have any defects."

Carl: Like, that's just not possible structurally. No way. And now it's much more possible. Talking about reviews, you know, I-- So I just submitted a PR it's one of the only projects I'm actually collaborating with others on at this point, to say that a lot of my opinions are based on, like, you know, the true, like, AI psychosis perspective of I'm not working with anyone else, and so nobody else's perspective matters but my own, except for this one, where I am collaborating with others.

Carl: I opened a PR. Somebody else reviewed it, uh, left a bunch of notes, you know, with their agent. Their agent left a bunch of notes, and that made me go, "Ah, you know what? I didn't actually really do my diligence on reviewing this." So then I set a goal. You know, I opened a Claude, and I said, goal, like, "Fix all of these review notes, and then do a clean room review in a, you know, very p-powerful frontier model sub-agent." then- Do it again.

Carl: Do that in a loop until our powerful clean room review sub-agent gives us a passing grade. And it did that five different times. It fixed all the things, did a review, fixed all the things, did a review, fixed all the things, did a review, and then it gave us a passing grade. And I, I actually did review that code to just be like,

Carl: "Okay, is this like... Did it go down a f- like psychosis rabbit hole and invented a bunch of bullshit? Or did it actually do meaningful work?" And it did meaningful work. And it was a bunch, you know, it's, it's stuff like w- there were caching issues, and, you know, like we had tried to configure this with a fetch wrapper so that you could intercept, you know, network requests being made for auditability of what behaviors it's doing and things.

Carl: And like, oops, that didn't get put to 100% of use cases, it was only on these 20% of call sites. And so I just by doing that cycle, that one single line goal of just do a loop, do a review and fix it, do a review and fix it, got it to a state that was much better. That's, that to me is enabling a greater degree of like confidence in the engineering

Mark: I have two similar but different but similar anecdotes. One was I, I tried writing my own code review bot at work, because I didn't wanna sign up for, like, a CodeRabbit or a Codo, you know, existing commercial solution. built something and it works, and I was down to the point of trying out different models at different price points to see whether they actually found all the bugs in a set of examples, and also how long they took and how much they cost, and then I, I got busy with other things and I never merged it.

Mark: But yeah, like I... getting stuck in a loop and, like, every time it comes up with five new issues was a thing that I saw, and like, do, do you put in a cutoff at some point and say, like, "After three rounds we just don't try again" or something?, so that was one part. But then the other one was I use a, an open source third party web UI for OpenCode.

Mark: So OpenCode is the agent, but I don't use the terminal UI, I use a, a web UI. And, it's called Code Nomad, and OpenCode version two just came out, and so the third party UIs were having to update themselves to work with the new back end. I tried it, it worked. There were some glitches in the, in the UI in the new version, and so I had my agent take a look.

Mark: I filed four PRs to fix some glitches in the UI. Whoever is building this UI is doing all their work agentically, and so not only in the feature development, but then the PRs are all being agent-reviewed. And so I filed four little PRs and I thought that was the end of it, and they all came back with, "Well, have you considered X, Y, and Z? And this is a blocker."

Mark: And I don't wanna read none of that. And so I just went back to the, went back to the a- my agent session and said, "Read the comments and fix the problems." And we went back and forth on that, like, three times, and I was essentially not involved in this loop other than telling my agent, "Reread the latest comments and fix whatever it's complaining about."

Mark: And eventually we got to the point where his agent was satisfied and they got merged. And it's like, was I actually a necessary part of this process?

Carl: but like, has that not happened to you earlier in your career, like with somebody else on your team on a, you know, on a PR? It's like you, you know, you post a PR, they review it, you fix the issues, they review it, and then go like, "No, I'm not happy still." You fix the issues and

Mark: Yeah, but at least there I was actually thinking about what I was doing, and here I wasn't.

Carl: Sure, but you know, also, like, okay, but reframe that when they're wrong. Reframe that when they're arguing over st- points of style and technique and not actual, you know, resulting impact on the outcome. Like, I don't know. I go both ways on it. Like, to me that reminds me a little bit of the, when Prettier was introduced, and it was like, "Oh, we have to do our style by hand."

Carl: And I'm like, "No, I don't care. This eliminates a class of arguments." You know? And

Mark: I hate that this analogy works

Carl: Right? If you open a PR and the title says it does this, and you review it, and actually the title is inaccurate, then you have to make a judgment call of do we update the title or do we affect the PR scope?

Carl: You know? And like that judgment call is still yours to make. Like you were saying. You know, what, uh, do we kill it after three reviews, or do we add a, a, a different type of gate that's based on scope evaluation? You know? So like, to me it's, it's just, I love it. But also, you know, like, like I was saying, I have identified as a product engineer for multiple, multiple years at this point. So like, yeah, sure, of course I do. That's what we're all being forced to do right now.

Carl: Okay, loosely structured shenanigans.

Carl: One more from Laurie Voss. Let's move on. "Nobody pays for open source. We could force them to." Uh, eh.

Mark: So the argument here is that sponsorships and volunteer payments have never worked out sufficiently at scale. The only way that we would ever get, like, a, quote, "meaningful amount of money" flowing to open source maintainers would be if the registries themselves start charging companies and just redistributing the money automatically.

Mark: there's already third-party tools like TideLift and Thanks.dev which have the same logic, but it's still from voluntary donations. So what would happen if NPM itself just said, "Yep, if you wanna use NPM, you gotta pay up if you're a big company," and then they just automatically send that out.

Carl: Yeah, I don't know. That is truly one of the only levers that could, that could work. I'm not sure it would. I'm not sure that companies acknowledge the, you know, long tail of value available there. I thought a lot about this a, a long time ago. I haven't thought about it in depth in a number of years.

Carl: If forcing people to pay for something i- en masse is what taxes are for. Like, oh, no, do we have a tragedy of the common situation where the money being invested is not being adequately directed to support that common good? That's what taxes are for. But, like, nobody has authority,

Mark: this is third-party taxes for the good of the community

Carl: Right. And like, taxes only work when it's a regionally, you know, geographically based thing, because that's how governments work, is they control a geographic area and they say, "No, you are physically in the space that we control, and so you must do what we say in these ways, and we will respect your rights in these ways."

Carl: there is No, government for the internet. There is no one who can institute taxes. there are registries it's true, but yeah, I

Mark: I'm not saying that, like, this... Like, I acknowledge this is probably never going to happen, but I agree that if it i- if it would ever theoretically happen, I think doing it at the registry level is probably the, the only way it would

Carl: I would agree. I, uh, the reason that I challenge that it would

Carl: be effective is, okay, some registry locks itself down and says, "You must pay for access. We've put up a firm paywall." One person, one jackass, is gonna pay for it, break the whole archive, and then republish it for free. Like, that's how it works.

Carl: It'll be on BitTorrent in 24 hours. So then it's no longer gated, and it's, you know, free again. ultimately, the way you stop that is law enforcement. Now, we don't have that for the internet. - That doesn't exist. So yeah, I don't know.

Carl: I, want that to work. I don't think it does in practice, you know? There's a Calvin and Hobbes strip that I love to reference, which is, you know, his mom yells at him from the other room, "Stop running around the house." And he pauses and looks at camera and says, "The law is on the books, but it would take All of their resources to enforce it." and continues running. Calvin. And like, yeah, you can put a law on the books, but who's gonna make it happen? Who's gonna make it real? Who's gonna enforce it?

Carl: Okay. I said we were gonna blast through this and then immediately failed

Mark: at that.

Mark: Rolling through things. Uh, if you haven't been hearing what's going on with OpenAI and Anthropic and swarms of agents going off and proceeding to use random internet message boards a- and artifactory hacks as, message boards, you should read these articles because frankly, this is pretty scary stuff actually.

Mark: , and it's probably only going to get worse from here

Carl: True.

Carl: I'm including this in part because it was written by a Reactiflux member, and I just love it when people who are active and involved in Reactiflux are doing other things in the real world.

Mark: Redux maintainer

Carl: yeah. EskimoJo put out s- uh, an update for schemabenchmarks.dev, uh, which is seven months after the initial, you know, project kickoff, uh, trying to do performance benchmarking of different schema validation, you know, tools.

Carl: And love that. That's great. Schemas are, especially, as I've been doing more and more AI shit, I've been really, really appreciating the deep abiding value of a quality schema. More and more I'm seeing why you need to have schemas literally everywhere, which means that having high-performing schemas available is really important, and so this is a really valuable project. schemabenchmarks.dev. Love it.

Carl: little bit on State of Devs 2026. I don't know, this is kind of what we're talking about, this whole episode is, is the state of the devs, uh, where at least, you know, me and Mark are devs. It's kinda interesting looking at this. This is, you know, this is a look at the human side of things.

Carl: , the demographic surveys are very often like, "What technologies are you using? You know, what are you interested in? What are you familiar with, and what would you choose not to use again?" But this one, you know, the headings are just workplace, AI, health, worldview, hobbies.

Carl: So that's, that's interesting.

Carl: This is, this is actually... This, they've kind of evolved into a sort of general, general purpose poll here. Like, worldview is, you know, global issues. 73% of US respondents cited rising authoritarianism as a concern, Which is not really... You know, that's not technical. It's true. But yeah, so this talks...

Carl: this is a sort of a data-driven... This is a quantitative look at some of the things that we've been applying a qualitative perspective on. Definitely broadly interesting. Let me pull in some AI. You know, the median respondent is using AI to generate 63% of their code. The median opinion on AI sentiment is exactly neutral.

Carl: It's 50%.

Mark: means everybody hates it or loves it

Carl: Yeah, right. A lot of this is very, like, smack dab in the middle. Like AI mental state, uh, AI tools have had a positive impact on my mental state. The median response

Carl: is a two That's actually interesting. It says median is two, but, looking at this, 45% said strongly disagree, or just regular disagree, compared to only 23% who agreed or strongly agreed.

Carl: So the median is smack in the middle, but actually, you know, the average, I think, would be a bit below. so yeah, I don't know. That's interesting to me because AI tools have had a pretty strongly positive impact on my mental health, I think. Maybe that's just, like, a measure of how serious my ADHD is. Like, I have so many ideas and now I can just put some of it, some of those thoughts into a robot. But yeah.

Carl: State of Devs has some interesting stuff on worldview and health and hobbies. Yeah. You can see where your, your choices in life relate to the average developer.

Carl: Okay, this is a tweet from Reece Sullivan, who i- I find very impressive.

Carl: I talked to him, uh, four or five years ago when he was doing some Discord projects, and I've just, like, watched him meteorically ascend into being somebody with real projects and real, you know, audience and whatever, and I love it. Love that for him. He posted some quick miscellaneous thoughts about why MCP is so much better than CLIs, which I found interesting because I have voiced the exact opposite opinion in this podcast several times.

Carl: So seeing somebody that I pretty highly respect on a technical level, well, both technical and product, because I've seen him choose interesting things to work on and then successfully execute them. Seeing him take such a strong stance in opposition to the one I have makes me think. But yeah.

Carl: His argument here is, uh, that MCP is better because it has indexable tool catalogs, letting agents scale, no requirements for a sandbox, consistent auth, multi-account support, things like that. Those are fairly strong arguments. but also, I don't know, there's a... The way that I've been using AI lately most aggressively has been trying to give it a s- bunch of tools that it can compose together, which relates to something I saw from Cloudflare a, a while back about code mode for

Mark: O- open, op- OpenCode V2 ha- has code mode built in. That's one of the reasons I upgraded. And, in fact, it, that might be the only way that agents can make MCP calls in, in V2. So, like, it might still only just do, you know, return one call, but I have seen it doing multiple calls in parallel and returning the results or doing some filtering, you know, writing little mini scripts to further alter the results when it gets back.

Mark: it feels like a useful step forward in the abstraction

Carl: Yeah. And so my opinions as I've been playing with these are that where I think it's gonna really end up is, I think relating into like JEV and stuff... The code mode is really interesting.

Carl: I still am so skeptical about MCP specifically, just like some of its other constraints, i, I'm, I'm not a fan yet. code mode is really interesting. That's very much aligned with how I've been using agents to play this little space game that I have been talking about now and again.

Carl: I just totally rearchitected their whole harness in order to do this. They have one tool, and it's run, and they give it code to run, and then it type checks that code, and if it, you know, passes All the validation, then it will actually run it. Otherwise, it'll kick it back to the agent to rewrite.

Carl: And so I think there's something really powerful there about stuff like JEV, which is doing decision-making, but not code generation or text generation. Highly constrained code inputs for actually interacting with things rather than just doing individual tool calls the way that a lot of people have been the last year.

Carl: And then just, yeah, I don't know. That's really interesting. I'm still skeptical about MCP, but this does make me reconsider some of it.

Mark: All right, I've said a number of times that I think Ryan Carniato is the deepest thinker we have in the front-end ecosystem in terms of architecture and async behavior and how all these pieces fit together. And he's also a huge.. He's really big on the history of how did the ecosystem evolve to where we got here.

Mark: And so he put up a post that he calls The Grand Unifying Architecture of Front End, where he says that front-end framework responsibilities ultimately come down to some combination of navigation on the client, content from the server, and how things f- fit together on the client for things like local UI or optimistic updates.

Mark: And every framework is, can essentially be fitted on a grid to figure out where it fits in amongst these pieces. Uh, I mean, nothing in the article is going to, like, change how you write code today, but it does help visualize different frameworks from Svelte to React to, you know, whatever else, and say these are all just taking different trade-offs in the same space.

Mark: And then completely separately, we've talked about a lot of different LLM-related things. Simon Willison is a one-stop go-to person for what are the latest developments going on, and he did a whole presentation on 2026 in LLMs so far that is pretty comprehensive. His blog is worth subscribing to just for the daily updates on the latest news in the ecosystem, and this one presentation is a pretty comprehensive look at how much stuff has changed just this year

Carl: Yeah. that is an interesting retrospective. I appreciate that. It's wild to think that Claude Opus 4.5 launched less than a year ago, that that alone had such a big impact on how I authored code.

Mark: All right, and then the last couple, a couple bits of React Native news. Shout out to both Sebastian and Mo, who are not here. Shopify is s- announced that they are pulling an Airbnb and are switching away from React Native for their primary apps, largely on the grounds that they can now just have AI generate Swift and Kotlin code and be building native apps directly.

Mark: So they tried it, they prototyped it, they feel that the apps ended up faster, and so they're dropping React Native.

Mark: On the other hand, Discord put up an article saying that they had just finished migrating to the React Native new architecture, and it took some work, but they're generally seeing improved performance and other good things that the new architecture was supposed to provide.

Mark: So two different takes on what are we doing with React Native from pretty big companies.

Carl: All right. Wrapping up with a couple of conferences.

Carl: we got React India at the end of October, so in about a month. Uh, October

Mark: Yep, and I, I know about all three of these because I will be speaking at all three of these

Carl: then there's React Summit in, uh, mid-November. That's gonna be in New York on, uh, November 17th.

Carl: And then another couple weeks later, React Day Berlin, December 4th. I might have to see if I can get a ticket to React Summit. It's in my hometown. I don't know. E- each of these would be great. I would love to go to each of these, but I just don't think I can. I just bought a house. I can't spend $1,000 on conference tickets. Maybe if I was speaking.

Mark: one of the major reasons why I enjoy speaking is I get to run around to these places.

Carl: Right? Every so often I get, like, a press, you know, I'm a member of the ecosystem, but I, you know, that takes work to, uh, do that outreach, and I haven't put that work in in the last 18 months or so.

Carl: Thank you everyone for joining us. Uh, we'll be back on the last Wednesday of the month here in the live stage at Reactiflux or back in your podcast feed just as soon as we can after that. if this is a show you get value from and wanna support, best way to do so is submitting a review wherever you listen. Tell your friends and coworkers about it. Maybe one day I'll get my shit together and post more little short clips so that people can, you know, retweet them and repost them, and that- that's really probably the single largest thing I could do to make this podcast more successful, but that takes continuous ongoing investment of energy, and energy is something I'm low on most of the time.

Carl: Set

Mark: up a Claw to do it for you!

Carl: I thought about it, but, ugh, it's a matter of taste! You can't do that. It's not good at it.

Carl: All right, cool. Thank you so much everyone who, uh, stuck around all through, all through the end of this. It's funny, I See a past manager of mine in the audience, which is cute. Cool. All right. Talk to you guys later.

Mark: See you folks.