# React Over Solid? with Armin Ronacher > Armin Ronacher compares React and Solid for coding agents, explains Pi Durable, and explores the future of generated interfaces. - **Collection:** Video - **Published:** 2026-10-14 - **Author:** Anthony Campolo - **Canonical URL:** https://ajcwebdev.com/videos/react-over-solid-with-armin-ronacher/ - **Markdown URL:** https://ajcwebdev.com/videos/react-over-solid-with-armin-ronacher/index.md - **JSON URL:** https://ajcwebdev.com/videos/react-over-solid-with-armin-ronacher/index.json - **Channel:** [Anthony Campolo](https://www.youtube.com/channel/UCpdzti0GURPfMjKzYK5FVSA) - **Original URL:** https://www.youtube.com/watch?v=qGyDgwK8qKA - **Original Label:** Watch original --- ## Episode Description Armin Ronacher compares React and Solid for coding agents, explains Pi Durable, and explores the future of generated interfaces. ## Episode Summary Earendil co-founder Armin Ronacher, the creator of Flask and Jinja, joins Anthony Campolo and Dev Agrawal to examine how coding agents change frontend framework choices. Ronacher traces his involvement with Pi, OpenClaw, and Lefos, then distinguishes Pi’s model and coding-agent layers from the newer Pi Durable core. He explains why explicit tasks, scheduling, concurrency, and recoverable execution matter when agents work without constant human supervision. The conversation then turns to his experience promoting Solid at Sentry and his pragmatic preference for React in generated interfaces. Ronacher suspects training and linting feedback help models avoid common React mistakes, while emphasizing that this explanation is speculative. Dev discusses Solid’s reactive edge cases, documentation, runtime feedback, and experimental compiler work. The group compares declarative JSON with executable components, explores TSRX and alternative UI languages, and examines how Rust’s data model exposes failures differently from TypeScript assertions. They also discuss JavaScript as a compilation target, model assumptions about familiar APIs, browser competition, and the prospect of agents creating their own application frameworks. The closing discussion considers shared integration interfaces, useful progress reports, conservative versus experimental agent workflows, token economics, and the personal pressure to keep agents running. They distinguish temporary interface widgets from generated applications that need to persist and evolve for months. ## Speakers - Anthony Campolo - Dev Agrawal - Armin Ronacher ## Chapters ### 00:00:02 - Armin Ronacher and the Origins of Pi Anthony Campolo and Dev Agrawal introduce Armin Ronacher and frame a discussion about React, Solid, and coding agents. Ronacher describes more than two decades of open-source work, including Flask and Jinja, his time at Sentry, and the founding of Earendil. He introduces Pi as both a coding agent and an underlying harness, while the hosts explain why his current preference for React is interesting given his experience with Solid. Ronacher traces his involvement with agents to Peter Steinberger, experiments in Cursor, and an all-nighter with Steinberger and Mario Zechner. Earendil initially pursued a cloud-hosted agent while Zechner developed Pi, and OpenClaw later helped bring Pi to a much larger audience. Ronacher describes Zechner joining Earendil and emphasizes that the company’s broader ambition remains useful AI for non-engineers. ### 00:05:51 - Consumer AI, Cloud Agents, and Lefos Ronacher describes the early design belief that reinforcement learning would make bash, filesystems, programming languages, and execution environments especially useful foundations for agents. He says the team was directionally right but too optimistic about scaling that approach into a cloud-based personal agent. Over time, Pi itself became more useful to the team as a personal agent than the cloud product they had originally intended to build. The conversation then introduces Lefos, a Pi-based project that exposed both strengths and weaknesses. Ronacher says Lefos helped produce the ideas behind Pi Durable, while also showing how difficult it is to transfer the gratifying coding-agent experience to non-engineers. Although consumer AI products may appear simple because the core can be only a few tools, cost, safety, installation behavior, and unpredictable model actions make the product design unusually difficult. ### 00:10:50 - Pi’s SDK Layers and the Durable Core Campolo asks where Pi belongs among personal agents, harnesses, and products such as Claude Code and Codex. Ronacher contrasts the team’s needs with Vercel’s AI SDK and the Claude Agent SDK, which he describes as a bridge to the Claude Code process. He separates Pi’s model-facing API layer, agent core, coding-agent library, and terminal interface, explaining that users can adopt the libraries without using the complete coding agent. The model layer preserves a transcript that can move between different models, while the small core is intended to extend itself through code. Ronacher then distinguishes Pi Durable from the existing coding agent: the latter still supports an established extension ecosystem, and moving it to the new core requires more than swapping an implementation. Pi Durable revisits the assumptions behind sessions rather than simply adding storage to the old loop. ### 00:14:33 - Concurrency, Checkpoints, and Unattended Recovery Ronacher describes limitations in Pi’s original session format around multiple writers, concurrent work, multiplayer use, distributed execution, and compaction. Adding Absurd above an agent that did not model these concerns exposed the wrong abstraction boundary. Pi Durable therefore combines explicit snapshots, scheduling, session storage, and streaming to observers inside the core, while retaining a relatively small implementation. Dev summarizes persistence between model and tool calls, and Ronacher clarifies that the older Pi already retained substantial state. The larger change is representing work as tasks with parent-child relationships and a distinction between failure and completion. That supports unattended recovery, background compaction, memory jobs, and nested code-mode tasks. Approval prompts or MCP elicitation can suspend execution several layers down without losing the surrounding state. ### 00:20:11 - Armin’s Solid History and Current Framework Choice The hosts pivot to Solid and reveal that Ronacher was once a prominent Solid promoter at Sentry. He confirms that he wrote Overlap and says he still likes Solid, having used it for Lefos and an internal Mailhook service. Dev asks about his experience, noting that their timelines with Solid may overlap, and the group positions the livestream as a serious discussion rather than a simplistic framework fight. Ronacher identifies adoption as the main reason Solid is not currently his preferred technology for a significant portion of Earendil’s work. He adds that Solid is not perfect for agent-generated code, especially when an agent is asked to produce a large interface without making mistakes. The combination of limited existing Solid code, Solid 2 changes, and model errors led him to reconsider its role. ### 00:23:31 - React Training, Linting, and Agent-Generated UI Ronacher says current models make fewer mistakes with React than with Solid, which he attributes partly to extensive training and possibly to training workflows that use linting or similar feedback to suppress recurring React patterns. He stresses that this is a suspicion rather than inside knowledge. React’s popularity gives models abundant examples and likely makes it easier for them to produce code that works acceptably, even when the framework itself has many historical footguns. Campolo connects this idea to an interview experience involving experts who correct AI-generated code for future training. Ronacher argues that laziness favors React because its problems are easy to lint against. He does not claim React is intrinsically better for humans; instead, he describes a pragmatic trade-off in which the agent’s present competence matters more than his own earlier preference for Solid. ### 00:26:54 - Generative UI, Stability, and Web Components The speakers discuss whether Ronacher is using React proper or a meta-framework, and he explains that the motivating problem is generative UI for non-engineers. A generated artifact may need to remain useful for months, survive library changes, preserve state, and support data migration. Ronacher doubts that a non-engineer can reliably manage those concerns, so his team is exploring reusable component libraries built around design tokens and a conventional React-oriented stack. He calls React a pragmatic starting point rather than a settled answer. The team briefly considered web components, asking whether they had finally improved, but Ronacher remains unconvinced. The broader issue is that existing UI technologies were designed around human developers, while agent-authored software may need more stability and explicitness. He leaves open the possibility that stronger models could eventually make today’s framework choice irrelevant. ### 00:30:21 - Framework Trade-Offs Designed for Agents Ronacher compares the design decisions behind Pi Durable with those in UI frameworks. He says earlier durable-workflow work optimized for human developers by hiding checkpointing and replay details, but those implicit behaviors are difficult for agents to infer. Pi Durable therefore makes checkpoints and versions explicit, allowing the model to name and manage them directly rather than depending on assumptions that may not be present in training. He suggests React, Tailwind, and related tools also encode trade-offs for human authors, not necessarily for models. A future agent-oriented UI system might favor explicit structure, predictable state transitions, and straightforward compilation. Dev says Solid 2 has considered whether its direction remains appropriate in an AI-heavy environment, but identifies documentation, tutorials, and demonstrations as current weaknesses in explaining Solid’s possible advantages. ### 00:33:22 - Intrinsic Correctness Versus Linting Dev asks what it means for React to be “lintable,” and Ronacher reframes the issue. In his view, React’s core model does not align cleanly with JavaScript because component functions are repeatedly reevaluated and small mistakes can produce difficult behavior. Lint rules compensate for that mismatch, but the need for so many rules may itself reflect a design problem rather than a virtue. Ronacher values Solid because its data model is harder to misuse intrinsically. For agents, he prefers designs where the code cannot easily enter invalid patterns, where state and behavior remain local, and where a component can be understood without reading the whole codebase. He says long-term stability could make Solid a useful target for durable generated UI, while acknowledging that declarative JSON or another model could ultimately prove more suitable. ### 00:36:24 - Declarative JSON, Native Apps, and Persistent State Dev argues that declarative JSON can represent static interfaces but becomes increasingly complex once the UI must react to changing data. At that point, a system may evolve toward a new DSL or back toward component logic. Ronacher broadens the question by considering predictions that native apps may replace web apps, which would restore the need for APIs that serve multiple platforms while agents handle the translation into application-specific interfaces. They focus on state management as a difficult boundary. Many web applications effectively need local-first state or server replication, and changing the UI architecture can affect server-side state. Ronacher criticizes approaches that collapse these concerns together because migrations, view changes, and hydration problems become harder. Generative UI therefore has to account not only for rendering but also for persistence, synchronization, and the lifespan of the artifact. ### 00:39:35 - Solid’s Reactive Edges and Alternative Languages Dev returns to the practical limits of Solid’s programming model. Although it stays closer to ordinary JavaScript than React, an agent can still break reactivity by destructuring props or reading signals in the wrong place. The speakers distinguish JSX transformation from the rules governing reactive computations, and Ronacher gives losing focus in an input field as an example of a visible failure. Ronacher connects the issue to Effect and TypeScript, asking whether a dedicated language could express the intended rules more naturally than a library inside an existing language. Dev mentions Elm, prompting a brief discussion of why technical design alone does not determine a language’s success. The question becomes whether a clearer language or syntax could prevent mistakes before agents generate them. ### 00:43:09 - TSRX and JSX’s Control-Flow Limitations Dev describes TSRX as a proposed alternative or subset of JSX designed for reactive frameworks, with syntax and control flow better suited to systems that track state. Ronacher recognizes the basic problem: JSX traditionally expresses conditionals through ternaries and lists through array mapping, even though those constructs do not naturally represent the control flow of a reactive framework such as Solid. The group notes that Solid uses constructs such as dedicated looping and conditional components, while React’s conventions became standardized because they worked well enough. Ronacher says the underlying issue is not exclusive to Solid and that React’s syntax could also have been designed differently. The discussion remains exploratory, with TSRX serving as an example of how syntax might be rethought for reactive behavior rather than inherited from an older JSX model. ### 00:46:13 - Compiler Feedback, Runtime Evidence, and Rust A question from Ryan compares compiler-enforced structure with runtime observability. Ronacher prefers catching problems before execution when possible, since runtime information requires running the program and agents sometimes create large test suites without exercising them fully. Dev points out that runtime tools can see application behavior and relationships that a compiler might miss. Ronacher argues that Rust’s useful guarantees come partly from its data model rather than the size of a compilation unit. Network bytes must be parsed into concrete structures, so malformed values fail near the input boundary. TypeScript assertions can instead claim that an unknown value has the expected shape, letting invalid data travel through queues, containers, or processes before producing a harder-to-trace failure. ### 00:51:43 - Runtime Validation, Error Paths, and Async Context The speakers examine the ease of running JavaScript before its TypeScript checks have passed. Dev observes that Rust’s parsing step is still runtime validation, guided by a concrete type. Ronacher agrees that compilers cannot eliminate runtime enforcement or express every logic constraint, and discusses typestate as one way to encode additional state information in types. The discussion moves to error paths and observability. Ronacher says developers and agents often spend too little effort making failures useful, while JavaScript’s async context limitations make it difficult to follow execution through promise chains. Dev describes Solid’s direction as a pragmatic attempt to provide better feedback within today’s language and runtime, while remaining ready to adopt improvements to the platform. ### 00:57:21 - JavaScript Transpilation and Model Training Assumptions Ronacher is optimistic about JavaScript as a compilation target even when its native syntax or runtime ergonomics are imperfect. He points to the history of transpilation, WebAssembly suspension, and async generators as openings for alternative language designs. Agents can make experiments cheaper to attempt, although explicit context passing may sometimes be preferable to async-local mechanisms with their own memory and lifetime concerns. Campolo asks whether a new abstraction loses the training advantages enjoyed by established frameworks. Ronacher describes mixed evidence: models can write changing languages such as Zig, yet familiarity can also make them assume a codebase still behaves as it once did. Work on CPython and the move between Tailwind versions illustrate how prior knowledge can help ordinary use while hindering changes to the underlying implementation. ### 01:02:17 - Small Cores, Agent Instructions, and Solid’s Compiler Campolo raises the debate over rules, skills, and AGENTS.md files. Ronacher uses Pi Durable to argue that a small, coherent implementation can fit into an agent’s context and be understood directly, even without extensive pretraining on its API. Large projects may need more guidance because the agent cannot inspect everything at once. He rejects the idea that new software cannot succeed simply because a model has not seen it before. Dev reports that recent models have improved at writing Solid and can use browser logs and test output to diagnose errors. He describes experimental compiler work intended to catch more problems before execution while preserving runtime checks for cases static analysis misses. His approach to JavaScript’s current constraints is pragmatic: improve what is possible now without assuming the language and runtime will remain fixed forever. ### 01:07:51 - Browser Competition and Framework-Free Applets Ronacher points to Ladybird as an ambitious browser project and argues that coding agents could make additional browser engines feasible. He sees the web as an enormous, security-critical platform with too little implementation variety, and hopes renewed competition will create movement. Dev asks what a different browser runtime might mean for React and the frameworks built around today’s assumptions. Ronacher describes side projects where agents create small applets and auxiliary HTML tools using vanilla JavaScript. When the human requests an outcome without prescribing a stack, the agent may avoid React and its compilation requirements. Dev counters that growing applications historically recreate framework infrastructure when they do not adopt an existing framework, raising the possibility that agents will do the same thing inside generated applications. ### 01:12:42 - Bespoke Frameworks, Integrations, and Human Visibility Ronacher compares agents building their own software environment with large companies maintaining internal platforms. A custom framework can be inexpensive enough for an agent to construct that its initial cost feels insignificant. However, he warns that services such as Sentry depend on common integration interfaces, which become harder to provide if every application has a private architecture. Dev imagines agents maintaining applications whose underlying language and framework no longer matter to the user, while still benefiting from proven infrastructure that reduces bugs, latency, and token use. Ronacher says he remains willing to spend additional tokens on understandable progress reports. They also note that agents routinely build auxiliary programs and scripts, including code that manipulates other code, while pursuing a larger task. ### 01:17:24 - Daily Agent Workflows, Personal Limits, and Token Costs An audience question prompts Ronacher to distinguish conservative work on Pi from experimental side projects, including a game made with his children. He uses separate checkouts and parallel Pi instances for investigations and tickets, but says he has not yet worked out how best to use subagents. He also describes the pressure to keep agents running, lost sleep, and the need to stop and decide which activities produce useful results. Campolo and Ronacher discuss how human-like systems can amplify unhealthy habits and blurred boundaries. Ronacher describes unusual messages from people whose AI-assisted projects used Flask, contrasting them with earlier open-source correspondence. The conversation then turns to flat-rate subscriptions and token economics: a cheap CarPlay-adapter experiment illustrates how subsidized usage can obscure the value of the work being attempted. Ronacher distinguishes useful orchestration from activity that consumes resources without proportional benefit. ### 01:22:59 - Solid’s Case, Durable Generated UI, and the Closing Dev concludes that several reasons given for favoring React may already have answers in Solid, but the community needs clearer explanations and demonstrations. Ronacher sees generative UI as an open design problem that may extend beyond the web. They distinguish a temporary session widget from an interface expected to persist for months, where state, migration, maintenance, and stable components become more important. Dev connects this problem to his compiler and agent-harness experiments. Campolo thanks Ronacher for decades of open-source work and for bringing that experience into AI. After Ronacher signs off, the hosts thank the audience for its questions and preview the next livestream with Kevin and Riccardo from the TanStack team. They plan to discuss Table, Pacer, Hotkeys, and related projects, and Dev closes with a final good-night message. ## Resources and Links - [Armin Ronacher on X](https://x.com/mitsuhiko) - [Pi coding agent](https://pi.dev/) - [Pi Durable](https://github.com/earendil-works/pi/blob/main/packages/durable/README.md) - [Absurd durable workflows](https://github.com/earendil-works/absurd) - [Announcing Pi and Lefos](https://earendil.com/posts/announcing-pi-and-lefos/) - [TSRX](https://tsrx.dev/) - [The Typestate Pattern in Rust](https://cliffle.com/blog/rust-typestate/) - [Ladybird browser](https://ladybird.org/) ## Transcript [00:00:02] - Anthony Campolo Hello everyone, welcome back after a long hiatus to AJC and the Web Devs. Um, thank you for people who are here. We're starting about an hour later from we originally planned on, but we are here. Happy to have Armin with us. Uh, Armin, why don't you go ahead and introduce yourself and tell us who you are and what you do? [00:00:21] - Armin Ronacher Uh, hello, sorry for pushing this back, I was commuting. My name is Armin. I have been doing open source for probably more than 20 years, is my guess, give or take. I've built a lot of things in the Python community. Mostly, probably the thing that most people know me for is the Flask web framework. And I guess nowadays, maybe more the Jinja templating engine. And for 10 years, I was working on Sentry. And I started a new company last year called Earendil. And I think that most people know probably what this company is doing is building a coding agent called Pi and the harness, agent harness underneath, also called Pi or like now Pi Durable. [00:01:04] - Armin Ronacher And yeah, we're trying to now make sense of AI. I think it's sort of how you can think of it. [00:01:10] - Anthony Campolo Yeah. Yeah, that's super cool. Very, very impressive resume. We could spend an entire stream just talking about like your history and all that stuff, but we're going to keep it pretty focused on some new stuff. And I definitely would be curious to hear about Pi because I've heard a lot of really great things about it. I haven't used it myself yet though. And, but what kind of kicked off this conversation, and I'll pass it to Dev, was some kind of React v Solid type discussion. And Dev and I are both big into Solid, but we also both have a lot of React experience and we are not partisans. So I think it'll be a fun conversation. [00:01:45] - Anthony Campolo But from there you can Take it away, Dev. And also, I'm getting over a cold, so if I'm coughing a bit, that's why. But I'll do my best to mute myself so to not be disruptive. [00:01:57] - Dev Agrawal Yeah, I mean, maybe a good starting point is just how you got involved with Pi. Like, I know Mario started Pi, so were you there like from the beginning or did you discover it and join it at some point? I know like you were kind of like partially responsible for making Pi as popular as it is today, because Pi is the coding agent behind OpenClaw. So I think earlier this year, OpenClaw just completely blew up. And then suddenly everyone was talking about the coding agent that made it all possible. [00:02:32] - Dev Agrawal So I'd love to hear about your history with [00:02:35] - Armin Ronacher Pi. So I think the funny thing is usually after, I don't know, 10 years to go back, it's like, how did it all start? But like, it feels like this is already like 7 years. My version of all of this is like AI years is like everything times 7. So we're in year 7 of the coding agent. And my memory of how this started is that in, I think around, I want to say like January of— sorry, it must have been a little later. Maybe it was like April '25. I talked to Peter, a friend of ours, um, who at this time wasn't actually doing anything. [00:03:17] - Armin Ronacher So Peter Steinberger, he wasn't actually doing anything, but he said like, hey, I, I, I'm in Cursor and I have like an agent that keeps pressing continue in Cursor so that the agent runs longer, um, and, and you need to go in this coding agent thing. And it was around the time I already left, uh, Sentry. I already knew that I'm going to start a company. I didn't incorporate it yet, but I was already looking around like, what am I going to do? And Peter got me hooked on, um, on this and actually told me to check out Claude Code again, um, which I sort of initially dismissed because of some really stupid reasons. [00:03:53] - Armin Ronacher My SSH config did something that broke the bash tool. And so I kind of— Peter got me onto this, and then there was an evening where Peter, me, and Mario were, um, pulling an all-nighter trying to build crazy shit with agents. And I don't know, whenever this was, June, July, I guess. And from that moment on, we were completely hooked. And, um, we started working. So me at the time was like me and Colin, we started a company called Earendil. And we started working on trying to build, um, like a cloud-hosted agent. And Mario was on the side trying to, um, like with a lot of energy, uh, trying to replace Claude Code for him because like Claude Code started doing stuff they didn't like. [00:04:34] - Armin Ronacher And so we were sort of like collaborating and we're trying to hire Mario, um, like throughout all of '25. And then in December, Peter's Claw— open at that time, now it's called OpenClaw— at the time I think it was called WhatsApp Relay. And then all kinds of stuff, um, including Moltbot, um, blew up. Yeah, and Peter already in end of December, I think like even earlier, I think in November already. Time's flying past. Not very good on the timelines here, but like at one point he already replaced the Claude Code SDK with the Pi SDK in there. [00:05:16] - Armin Ronacher And then Mario was willing to join Earendil and sort of bring Pi along because we already built, um, our own agent on Pi, um, and we liked, um, the design of it and just generally were super excited to have Mario on board. And so now, at least temporarily, Earendil is the Pi company, but that's really not what we want to do. It's just, it's a temporary inconvenience, let's say, to also have to, um, yeah, uh, to basically maintain this now. [00:05:51] - Armin Ronacher But yeah, I mean, like, we're super excited about what AI can do and we kind of want to bring it in the hands of non-engineers that really is what we started out with. And yeah, that shall be our goal. Not so much the coding agent, although we do like it a lot. [00:06:10] - Dev Agrawal Got it. So you started with, or I guess you're still trying to build something that brings AI to non-engineers, but ultimately what you ended up building was the The ultimate coding agent for engineers, for people who don't want to fully customize. [00:06:30] - Armin Ronacher Look, and yeah, and I think like the weirdness is in, I don't know, like July, August last year. So long before I would say like we had fully cemented under the agent design that we had, Mario and I were talking that really quite frankly, given how we think the reinforcement learning is happening on those models, it's probably a good idea to double down on bash and file systems. And I remember that that was not super popular at the time yet because at the time most agents were actually built on like just general tool execution, sort of RAG kind of stuff. [00:07:06] - Armin Ronacher And so while we were sort of abstractly right that bash is correct or like programming languages and execution environment is correct, we were a little bit too optimistic about being able to scale this to a personal agent at the time. And in particular, having it in the cloud actually held it back quite a bit. So over the months that followed, we actually started to use Pi as a personal agent a lot more than our own personal agent, which is a little bit disappointing. [00:07:40] - Dev Agrawal Nice. Yeah. So how does— and then eventually you ended up building something called Lefos. Uh, did I get that? [00:07:47] - Armin Ronacher Yeah, so that was— yeah, so Lefos was built on Pi. Um, and Lefos in many ways is like, it showed us some things which are good and some things which are bad. And like, some of what we learned with Lefos actually now sort of resulted in Pi Durable. Um, honestly, the— I think part of what sort of is confusing about this, like, I know there's Muse now and everything, and like, that's really cool, but Actually bringing sort of this really gratifying, like an agent is powerful kind of experience that we all feel when we use a coding agent, bringing that to a non-engineer is really tricky unless you walk down very sort of well. [00:08:34] - Armin Ronacher And like, I understand like OpenClaw has demonstrated like this is really great, but Um, like there's, there's so much subtlety in actually making the experience truly great for someone who just randomly walks into it. Um, we still feel like we haven't quite, um, gotten that, um, that balance right yet. [00:08:55] - Dev Agrawal Definitely. Yeah, I think this has always been, this has always been true of consumer products. We just have like a completely new category of consumer products that no one has ever thought of or tried to build before. So Uh, the, like, all the, uh, all the nuance and complexity that goes into building a good consumer product. Now we have— we need to do all the same things but from kind of like from scratch for a new form factor. [00:09:19] - Armin Ronacher But what is so confusing— what is so confusing about it is that it's like the, the, the, the, the narrowest abstraction ever over a technology. Like, you can literally go to an API playground and you have a program right there, right? If you hook it up with like a very basic sandbox, you You basically have an agent. So the product almost builds itself. And that's so weird because you build this very— like, Pi at the core of it is nothing else but a little bit of a transaction log and storage and an adapter to the different LLMs. But it's basically just 4 tools. [00:09:56] - Armin Ronacher And yet, because the models are getting better and better and better, you can do almost anything with it. Um, but you have to know that, and then it potentially goes very wrong, and it depends on randomly installing stuff on your computer. And then if you say, okay, now let's just put this into a sandbox, then like the cost of it is very high, right? It's like very basic sort of like get the experience going is like, it's too expensive for my mother to be wanting to pay that for. So like bringing that cost down without sort of like subsidizing it, uh, is, is tricky. [00:10:30] - Dev Agrawal Makes sense. Okay. I think if I'm going to go down, like, if I'm going to start asking questions about Pi and Pi Durable and code mode and all that, we'll probably be here forever. Actually, okay. Let's get Fuzzy's first question in. So [00:10:50] - Anthony Campolo Pi Durable, looking at the announcement, it doesn't give out much. What kind of abstraction are you all using? You persisting the durable layer? Actually, real quick, before we go into Pi Durable, I want to ask a higher level question. Um, so Pi, it's a personal agent or an agent harness or kind of both? And like, where does it sit in the level of abstraction compared to things like Claude or compared to things like Claude Code and Codex? The same abstraction, a higher level, lower level? Just so people who have a sense of those tools can kind of place it among the different things? [00:11:25] - Armin Ronacher So if, if we walk this back to, let's say, uh, October last year, the, the landscape in October— let's say December, December last year— the landscape was a little bit like this. The initial codebase in Lefos was using Vercel's AI SDK. Great SDK, but in many ways when we were using it, it was built, um, to like service a lot of needs that were not agentic yet in nature. And the other SDK on the market was actually the Claude Agent SDK. And what's weird about the Claude Agent SDK is that it is actually a JavaScript bridge to basically the Claude code blob. [00:12:04] - Armin Ronacher So it spawns Claude code somewhere. So that was actually never an option for us because of the way we were deploying this. So we couldn't actually have this massive binary run there. So Pi, as we were using it at Lefos, was an abstraction layer, Pi AI, to talk to the LLMs and to transform the upstream API request into a durable transcript that can be converted between different models. So if you have to make a switch from one version of model to another model, you can reuse that transcript. So if someone has a long chat with, I don't know, their personal agent, then even if the model changes, the transcript recovers. [00:12:43] - Armin Ronacher And then on top of that, there is the agent core. And on top of that, there is the Pi coding agent SDK. Sorry, the Pi coding agent library, which then is the Pi coding agent. And one thing that we always liked, Mario and me, is the idea that software should build itself. Like this idea, like you build a very narrow core and then theoretically, if you set it up correctly, it should be able to extend itself within reason. And Pi was an early experiment of this. So the problem with Pi a little bit is like we have 7 different things called Pi. [00:13:19] - Armin Ronacher So there's the Pi terminal user interface, and then there is the underlying library, which is also called Pi. So now it's a little bit easier because Pi is basically the coding agent, and then Pi Durable is the underlying library. But in principle, yeah, it's an agent core, an agent harness, and a coding agent that you could use or not. But their uses for just the library and their uses for the coding agent, they might not even be the same necessarily. [00:13:48] - Anthony Campolo Interesting. Okay. And then I think you hit on that a little bit, but just to flesh that out, how does Pi Durable then sit within that larger thing? [00:13:55] - Armin Ronacher Yeah. So right now Pi Durable does not sit in a coding agent, interesting enough. So we have not moved the coding agent to Pi Durable. And not for laziness. That is because, like, Pi has a pretty rich ecosystem of extensions that targeting Pi, and Durable is a reimagining of how the agent core should behave with basically fixing a bunch of issues that we had before. And there's always risky the second system syndrome, so you can sort of like overshoot this entirely. But really, we ran into a bunch of issues with the Pi core that really wanted us to revisit this. [00:14:33] - Armin Ronacher So one of which is, Pi does not work well if you want to have subagents or any kind of concurrency. So it does work, there are subagent extensions, but the core of the session format has originally not been built with the idea in mind that there can be multiple writers sort of relating to one session. The second thing is that it doesn't work particularly well for multiplayer setups or endless chats. So the JSONL file format sort of is an ever-growing kind of mess, and it doesn't really well support compaction. It doesn't work well for distributed systems. [00:15:09] - Armin Ronacher So that was another thing. And the last one, and this is sort of, I think, why the name, I think ultimately is sort of what defines it, is this concept of durability. We initially, when we built Lefos, were hooking up Pi via a library called Absurd, which is basically a minimal version of Temporal I can think of that sits on top of Postgres. But the problem is if you put that on top of a non-durable agent abstraction, you're kind of patching it at the wrong layer. And so we just realized over time that for a lot of the interactions that you want to do, you need to actually make the agent core itself be more like a concurrency layer with a scheduler and durability built in. [00:15:48] - Armin Ronacher So this Pi Durable combines the concept of sort of snapshotting similar to what you would do in Temporal, but explicit, a scheduling system, and a session storage abstraction layer, and then a whole bunch of other stuff to make this work for multiplayer scenarios. You can stream this out to multiple observers. It's a little bit of everything and the kitchen sink, but ironically, it's also pretty, pretty light. So we found that actually building on top of Durable now is a much nicer experience than then we'll sort of like not necessarily— well, Pi was thought through, but not necessarily for all the use cases that we kind of wanted to throw at it. [00:16:29] - Dev Agrawal Yeah, that makes sense. And I think if for people who might not fully understand what Pi Durable is at this point, I think one simple way that I have been kind of able to think of it is like in an— imagine in a normal agent loop, you have the transcript of the session in memory, and every time you make a call to the LLM, you store the response in the transcript. Then you make the tool call, you store the result in the transcript, in the in-memory transcript. Then you go back to the LLM, put that in the transcript, and that's how the loop continues. And what Pi Durable changes is that instead of, like, between every LLM and tool call, instead of putting the results in the in-memory transcript, you store them in the database so that you can then pick up right where it left off, so that if the agent crashes in between, you don't lose the entire transcript or you don't lose the progress. [00:17:21] - Dev Agrawal At every step, you're checkpointing things. [00:17:24] - Armin Ronacher We did checkpoint a lot in Pi 1, or we shouldn't call it Pi 1, but in the existing Pi coding, a lot of it was in the transcript, so it was quite durable. There's a pretty significant shift happening with with what people want to do with agents. We wanted to do this with agents, which is this shit should work if no human observes. And so, um, typically what you see in a coding agent session— and I know that some harnesses are already better than that— but like a very common thing is like, I don't know, after 3 retries it gives up and just hangs there and says like, I don't know, failed. And then you can do continue and hit enter and it continues. [00:18:01] - Armin Ronacher And the harness actually would know at this point that in fact we did not reach the goal. Like there's I can tell apart the error state from that turn completed state, but we are throwing away that information. And so with Pi Durable, what was actually happening is like every single thing that you do with the agent is basically modeled like a task, or like you can think of it like a thread. That is where we keep the state, which means that if you shut down the execution of that entire thing and you bring it back up and we didn't make it to the end of the call, we recognize this. We also understand the relationship of, um, a task and its parent task. [00:18:38] - Armin Ronacher So if you have multi-agent orchestration, there's a question to which degree this is successful, but you can model that now. And while it's fun to build subagents, there's a lot of other use cases where concurrency was really hard to model in the other one with durability in mind. So I give you a very trivial example. Compaction can be done async. Right? So you can, as you're running towards the context limit, you can already do compaction async. And then you can sort of splice in the results into the new kind of thing. It works on most LLMs on anthropic reasoning, but it's still very nice. [00:19:13] - Armin Ronacher But that is a concurrent task that runs on the side, which actually on compaction might want to do cool calls. Normally shouldn't do it, but it might want to do it. And so there's a lot of these sort of things that you might want to do, or you might want to run a task that just sums up all your sessions to build memories, or you might want to run a task which is a subtask of a code mode tool execution. And one of the problems with durability in Pi, as we did it originally, is that if you need to suspend at any point in time where the original harness did not expect there to be a suspension, we kind of lose everything. And so if you, for instance, want to do elicitation of the MCP, or you want to bring up an approval prompt somewhere, you might now need to suspend any tool execution. [00:19:56] - Armin Ronacher And this might be like 3 layers down within like a code mode execution. And that was just very, very messy before. And now it's sort of modeled directly into that layer and just makes it, makes it very obvious how you would create an agent like this. [00:20:11] - Dev Agrawal Cool. Yeah, that makes a lot of sense. I'm pretty sure in the last like couple of weeks or so you have and talked about all the different aspects of Pi Durable and everything. So I'm not going to keep you talking on that for much longer. [00:20:26] - Armin Ronacher You should talk about Solid. Great question. [00:20:29] - Dev Agrawal Thank you very much for bringing it up. [00:20:32] - Anthony Campolo Yeah, so this is the Solid Pill Armin episode. [00:20:35] - Armin Ronacher So the funny thing here is that I actually was chief resident Solid promoter at Sentry, I think. So I have a history of Solid. I actually like it. So, I don't know if you need to convince me. [00:20:46] - Anthony Campolo Did you write Overlap at Sentry? [00:20:49] - Armin Ronacher Yeah. For a couple of years. [00:20:53] - Anthony Campolo Okay. Cool. Just making sure. Yeah. Because that's important context. [00:20:57] - Dev Agrawal Yeah. I guess, yeah. I would love to hear about your experience with Solid. It's possible that you have used Solid for longer than I have. [00:21:07] - Armin Ronacher I don't know. How long have you been using Solid for? [00:21:11] - Dev Agrawal I guess I started trying out Solid at the beginning of 2023. I [00:21:18] - Armin Ronacher need to figure out when we hired Ryan because I used it before we hired Ryan. Okay. [00:21:25] - Dev Agrawal Ryan joined in 2024, I believe. [00:21:28] - Armin Ronacher Yeah. So maybe we started around the same time. Yeah. I have a lot of thoughts on Solid. [00:21:38] - Dev Agrawal That's why we have this entire livestream. [00:21:40] - Armin Ronacher The question is, like, where do we start? I think, like, part of this here has been— there was a tweet where— actually, so, okay. So the recent history on me rejecting Solid is, like, we built Lefos in Solid. Mailhook, which is an internal service, is built in Solid. And I still really like Solid. The problem with Solid, why that is probably not the technology of choice for a pretty significant part of what we're building right now, has actually been that Solid didn't have and continues not to have the amount of adoption that I wish it would have. [00:22:20] - Armin Ronacher And in a world of— and I will also say like Solid actually is not perfect. So in particular, if you sort of take an agent and say like, hey, build me a bunch of UI and it shouldn't fuck up, the agent just doesn't really fully understand how to build perfect Solid code. And the combination of there actually not being enough Solid code, that Solid is changing quite significantly with Solid 2, and the agent actually still fucking up, made me sort of like look at, okay, where is this potentially going? It's like, okay, probably until someone really fundamentally restructures this, React might actually continue eating the world. [00:23:01] - Armin Ronacher So why am I fighting this? So it's pretty as simple as that, which is like, when I myself still wrote code, I loved Solid. Now that the agent is writing code, seemingly it's good enough, it's suffering through React. So do I really care? [00:23:23] - Dev Agrawal Yeah, that's a fair position. Yeah. I'm curious, like, does the agent not mess up React code? Uh, [00:23:31] - Armin Ronacher a lot less, I think, a lot less. And, and, and I think primarily just because probably someone actually massively trained it specifically to work around, or like to— so my suspicion is that one of the things, like, this is sort of pure guesswork, I'm not working in those labs, but I do think that over time people started linting against shitty patterns on React. And probably what they're doing in a, in a training run is sort of like linting, like basically like Your agent probably doesn't succeed if it fails the lints. So it sort of steers away from shitty patterns that humans actually do. So I noticed in general, like, good present state models, they are writing React code that is maybe a little bit more annoying to write, but does not, it sort of mostly steers away from bad patterns. [00:24:20] - Armin Ronacher And my suspicion is that they intentionally trained this. I don't think it's an accident because, like, in general, there's so much shitty React code out there. Um, it should have absorbed a lot of shitty patterns, but it, I think it's, it's pretty good, um, in, in sort of avoiding this. [00:24:37] - Anthony Campolo Yeah, the, the closest thing I have to inside knowledge on this, I had just like a one-round interview for, um, xAI and for a role where they're basically looking for someone to come in and find and give, they'll be given examples of when an AI agent was asked to do a certain task in a certain language and it messed up. And then you as the expert developer would give it the information of how to do that correctly so that they could use that to like train it. So that's a big question, like resources, like what issues are you actually going to hire those people to solve the issues? [00:25:09] - Armin Ronacher Yeah, look, I think I know nothing about data labeling in the sense that I'm assuming like data labeling just doesn't scale very well and it's probably not very fun, but it's very important and people are being tasked to do that. But what I can tell you is, like, laziness will win. And React is very lintable, right? So, like, over the years, React has so many damn footguns that really the only solution to this problem has been better lints. And so linting is very easy to do during the training run. So my assumption is just, like, you just start there and it probably gets rid of a lot of, like, bad React. [00:25:48] - Armin Ronacher Just as a result. [00:25:51] - Dev Agrawal Yeah, or like using the React compiler, which I don't know how much that— [00:25:55] - Armin Ronacher but I don't know if like, does it exist? It's like, this is like the never-ending story of like, I don't know, does it exist at this point? I don't even know what— like, you have to imagine this, this is sort of my thing here. I loved React when it came out originally at Sentry. When we started Sentry, I remember like David still had The Sentry Next branch at the time was still Angular. I was like, dude, no Angular in my life. So, or React. But it was like React with createElement. There were no class-based components. Like, it was like the early ones, like pre-hook everything, right? And sort of React took a life on its own. [00:26:31] - Armin Ronacher And it did become better in many ways, but also became worse in other ways. And I eventually stopped writing React code at Sentry. And whenever I did anything, I did Solid. So I don't even know if the React compiler exists right now, even though now I have a lot of React code. I never look at it. I have no idea. Is the React compiler real? Like, is it a thing now? This is how much I know about this. [00:26:54] - Dev Agrawal It is. And I think it's also been rewritten in Rust at this point. So it's— you'll never do that unless it's real. [00:27:04] - Anthony Campolo When you're talking about writing React, are we talking React.js proper? Are you using any meta frameworks? [00:27:11] - Armin Ronacher Look, so the scope of that conversation initially was generative UI, where it's like, how do you create— and I think like when we talk about generative UI, we don't really know what we want, but we have sort of some nice-to-have kind of elements. And one of which is, in a world where software should emerge, and it should emerge Um, for a non-engineer, then sometimes that non-engineer might create an artifact that should stick around, right? [00:27:48] - Armin Ronacher Like, they have created a thing now. Now obviously I can use another agent to sort of like modernize it as like libraries change, but, um, state management and like hooking up for this and like data migration and everything continues to be horrible even for software engineers. So like, what's the chance that non-software engineer is going to get this right. So what we were looking for is stability. Like, what's the likelihood that the ecosystem doesn't change? And that's what's like, if Solid 2 wouldn't have happened, probably I would have been a lot less worried about it. Um, but the other thing which was quite important was that we didn't feel at the time, and maybe our opinion will change here, that the solution here is to restrict an agent to only producing structured JSON and then have some sort of other layer come in and produce the UI out of it, right? [00:28:33] - Armin Ronacher So the assumption was like, okay, there has to be a little bit of both JavaScript and sort of JSX and, and like stuff to create this UI, but then you should be able to freeze it down into some sort of reusable component that this sort of agent sort of manipulates and does stuff together with, right? So, um, do I use any component types here? Like, I don't really care. This is sort of like, what do I have? How do I have to structure this so that the agent can use it? And so, um, we have 2 folks at Earendil writing reusable component libraries for these to work, and they're mostly based on design tokens and very basic sort of Node, Tailwind, um, like, like state of the art, but like specifically targeted at React right now. [00:29:15] - Armin Ronacher Um, we will see where this goes. I don't know. There's a good chance that like maybe 3 months from now the models are so good that we're all like you know what, the best use of our token spend right now is to build the future of UI component frameworks. And, and that's what we want. But, um, given that we also want to ship something, React felt like a pretty good starting point. I'm probably going to regret this. Like, Mario is already sort of like making fun of me for sort of— because he wanted to do this with web components. Actually, like, the, the entire experiment started with like, did web components finally get fixed? [00:29:51] - Armin Ronacher And the answer to me seems to be No, still shitty. So, um, I don't know. Um, yeah, I don't know. It's just like, I, I don't think we're happy with it. It's just, it's a pragmatic choice, probably. [00:30:04] - Dev Agrawal Yeah, I think web components is a different story. I think every 3 or 4 years someone gets optimistic about web components, tries it out, and realizes that no, it's— there we go. You said web components. [00:30:17] - Anthony Campolo You just had someone summoned Ryan. [00:30:21] - Armin Ronacher Uh, yeah, um, look, I, I think like in some way maybe— so first of all, I don't think web components is like the solution here, and I, I don't even know if web components can be the solution. But there are people out there that think very strongly of web components, and I will let them think about their web components what they want. But, um, all of this technology that we have predates in many ways, um, sort of the trade-offs that we want to do for agents. And I think, like, for me, like, working on Pi Durable was, was one of those moments where I built a durable workflow engine just 9 months before, or maybe 12 months before, which was this absurd thing. [00:31:01] - Armin Ronacher And the trade-off I made there is, like, make it as easy as possible for human developer to construct durable workflows. Um, terrible trade-off in the world of AI. Because I basically, I made it more, I made it, there was implicit stuff in there, implicit checkpointing, replayability, stuff like this. Sucks. I mean, it always sucked for a human too, but the benefit for the human was less code to write. And so with Pi Durable, for instance, we said, okay, fuck it. Now that the agent is writing it, let's do explicit. The agent can name the checkpoints, it can version it, it can deal with all of it. [00:31:39] - Armin Ronacher And it's going to be easier for the agent to just write the damn thing out than to be having to deal with implicit assumptions that might not even be trained into the damn thing. And this is sort of the, I think, the trade-offs that all these UI frameworks did, including React, if you want to call it a UI framework, and Tailwind in particular, were really for a human. They were not like now with what a model probably wants, you would make very different trade-offs. So I think maybe there is sort of the solid for agents that really needs to be built. [00:32:14] - Armin Ronacher Um, but I don't know. [00:32:17] - Dev Agrawal Yeah, no, I, I totally agree with that. And I feel like, uh, the direction, the direction for Solid 2.0, um, um, like, uh, once obviously once AI got popular, like, uh, we were all kind of like taking a look at like, does this direction still make sense? Should there be a different direction? And the kind of, uh, I guess the conclusion, uh, for the team was that no, the, the current direction is already like a good direction for like Solid for agents. Um, so, uh, uh, I mean, I guess the biggest problem we have so far is that we don't have great documentation or like kind of tutorials or things that actually show why Solid is like better for agents. [00:33:02] - Dev Agrawal Um, so some of my goal throughout this conversation is to like figure out What kind of content do we need to put out so that we can convince people that, hey, this actually works better for agents? So I think I want to go back to the earlier point you brought up about React is very lintable. So obviously Solid has had ESLint releases. [00:33:22] - Armin Ronacher I don't know if it's lintable, it just happens to have a lint. Right. [00:33:26] - Dev Agrawal Okay. So how do you define lintable? What's the difference? [00:33:37] - Armin Ronacher I mean, I think React sets it— like, I really don't want to shit on React, but I think React sets a pretty low bar in a way because its core design— its core design doesn't make a ton of sense in a way because you're constantly splitting up. Like, you're kind of forced to diff the damn thing all the time. And then, like, none of— like, it's just— I think it is cool and it was great, but, like, it is a massive hack and it doesn't fit into the language that it's being hosted in, right? [00:34:16] - Armin Ronacher Because, like, you're basically reevaluating those functions all the time. And, like, as a result of this, like, you get one conditional wrong and all of a sudden, like, like, this You fight the— there's an API that actually doesn't fit into the language that it's hosted in, right? So it's like that you have to lint it because otherwise you can easily screw it up, but you wouldn't need all those lints in the first place if you didn't make this design misstep, right? And I love Solid for the fact that it's very hard to misuse because like it just intrinsically makes a lot more sense. So I don't think the goal for making it great for an agent is to make it lintable. [00:34:54] - Armin Ronacher I think the what makes it great for an agent is if inherently you can't screw up, right? And I'm not saying this has to be typed to the extreme extent of which I think a lot of people see the solution for these problems in types. But I think a good intrinsic data model makes it much harder for an agent to mess up. I think a lot of it has to do with locality. If you only need to read the component on its own and you understand most of its state, don't have to pull in the whole rest of the code base, it's also harder for the agent to mess up. And so I think Solid is actually on a, like, on a very basic level, it's like if Solid doesn't change as much. [00:35:37] - Armin Ronacher So let's just assume there's a new version of Solid coming out and it commits itself to like longer-term stability. And not in a crazy amount of sense, but like in a sense of like people want to build Durable UI, they want to put it into something like MCP app, whatever, over time. It can become a standard of sorts for people to target. Like, that's sort of, I think, a little bit what's missing. Um, but then maybe actually this is all wrong and we should be doing declarative UI with JSON more. I really don't know. It's hard to say. Um, I think it's very hard to predict right now what's needed here. [00:36:15] - Armin Ronacher But we have some general ideas of what works better in LLM and what works less well. And [00:36:24] - Dev Agrawal yeah. Yeah. In terms of, like, should we just do declarative JSON constructs for UI or should we let them write UI component logic? I've gone back and forth between the two of them a lot. I think my, my thought on at least on that issue so far is that in a like fully declarative, like JSON style, uh, like you can represent static UI pretty well, but as soon as you want to like have the UI itself change over time, like based on data, um, uh, you will, you will slowly start moving towards like just writing the whole component logic anyways. [00:37:03] - Dev Agrawal Uh, so it's like Static JSON, it's good for one-time UIs. But if you want UIs that once you write them, they just automatically update with data, you eventually have to move to the other end. Otherwise, you invent a whole new DSL like Retool and stuff. [00:37:23] - Armin Ronacher But I think this is actually an interesting situation as well now. Because you have people like Toby who are like, okay, it's the death of web apps. We're going to native now, right? And this will then automatically put us back in a situation where we were a couple of years ago where, like, the API layer is much more sort of the thing. Like, there has to be one API that sort of targets all these different apps now, but it doesn't matter anymore because, like, we have the agent solving this problem. But a lot of these, like, cruddy kind of experiences, they really need state in both places. [00:37:59] - Armin Ronacher And so you actually, like, I think a lot of these React apps actually at the end of the day, they want to be local-first apps, or like they have some sort of replication server. A lot of the state is actually held in the UI and sort of replicates down to the server. And then you, you'd naturally end up with like some sort of architectural requirement where like something deals with this. And that might not be the UI system. Maybe it's just like something like TanStack Query or like whatever, like like this thing. But it's so dependent on the UI. So if you want to change how the UI works, all of a sudden your state on the server changes. [00:38:34] - Armin Ronacher I mean, this is the biggest problem with, like, the React Server Actions kind of stuff. It's like, it messes up this— it assumes that you can just, like, collapse them down into, like, one massive large concoction. But then migration problems and, like, view shift and, like, hydration errors that never were a problem in the world before And so I don't know, like, I feel like we never solved any of those issues, but all of a sudden we're pretending like we have solved them because the agent is so good at dealing with them. It's weird. It's very weird to me. But if there is the return of this idea of like native apps to replace what right now are like these web apps that are multi-platform, then will that not open up all those really questions again that sort of like React sort of tapered over? [00:39:24] - Armin Ronacher Um, I don't know, particularly if then you have like generative UI. I didn't know, should it show up in like the iOS app and the Android app? And like, I don't know if Windows still exists. [00:39:35] - Dev Agrawal Yeah, I, I think I can go and go a whole hour talking about like the native versus, uh, like the death of web or like cross-platform stuff. Um, but I think going back to the, the topic. I think that was an— I really enjoyed hearing your take there. Not just because you were shitting on React. But it does make sense that when you bring a different language like React into a host language that doesn't fully match it, you have to— you're kind of forced to put a lot of lint rules to make sure you don't footgun yourself. [00:40:15] - Dev Agrawal I think the one place where I think Um, maybe you might be giving Solid a little too much credit, is where like Solid itself is still like, okay, it's much closer to the metal in compared to React in the sense, but it's, it's still like a slightly different language from regular JavaScript, uh, [00:40:35] - Armin Ronacher because it [00:40:35] - Armin Ronacher needs to transpile the whole thing. Um, [00:40:38] - Dev Agrawal the, the transpilation is more for the JSX. Um, like the, the only thing that gets transpiled is like JSX turns, it gets turned into like effect nodes. But what I'm thinking more about is destructuring props or reading signals inside component bodies rather than inside memo. These are some things that are helpful for— to place a linter in. And it's definitely like— it's much smaller surface area than React that you have to lint. But there's still that little bit of area And I think in my experience where I have seen agents mess up the most, it's basically been in this one, uh, kind of one tiny edge where, uh, they would read, uh, read some data or they would read some signal where they shouldn't, they're not supposed to, um, which kind of like either breaks reactivity or like makes react— like makes things like over-render or overrun sometimes. [00:41:39] - Dev Agrawal Usually it just kind of breaks reactivity. [00:41:42] - Armin Ronacher Yeah. The main thing I notice is, like, my input box all of a sudden loses focus. Right. Yeah. The classic case. [00:41:49] - Dev Agrawal Yeah, definitely. [00:41:51] - Armin Ronacher I mean, I had the same argument with the Effect people just recently. Like, Effect is also— it's a cool system, but it's, like, held back by TypeScript. Like, I much rather— I want to, like, show me what an effectful TypeScript looks like rather than this sort of other mess that we're looking at. So maybe this is also like, I think really like in the same way as eventually Microsoft and I guess Meta built TypeScript as a sort of like, well, we really should be doing JavaScript differently. Maybe we should consider, I don't know, Effect UI script. [00:42:32] - Armin Ronacher I don't know. Maybe that would be an interesting sort of, like, experiment where you can't mess it up because it's actually no longer required to be JavaScript. [00:42:44] - Dev Agrawal Yeah, I think someone tried that last decade and called it Elm. [00:42:51] - Armin Ronacher Yeah, but I think Elm mostly died because of— yeah. Other reasons. I don't know how to say that politically correctly, but I think like Elm was held back by, um, yeah, by, uh, project leadership. [00:43:09] - Anthony Campolo Interesting. We're gonna have to not dig into that, but I'll be really curious to— I'll ask you that after the stream, what you meant by that. But, um, uh, is this too much of a tangent, or do we want to talk real quick about TSRX? [00:43:21] - Dev Agrawal Sure. Have you looked into TSRX at all by Dominic Gannaway? [00:43:27] - Armin Ronacher No, absolutely not. I'm assuming I know what it is, but I have no idea. I'll Google it now. [00:43:34] - Dev Agrawal Yeah, it's an attempt to make— [00:43:36] - Armin Ronacher Oh no, I saw it. I saw this. Yeah, someone showed it to me in a discussion that I was part of. I saw it. [00:43:43] - Anthony Campolo Do you want to first give, like, what is TSRX high level, and then we can discuss it real quickly? [00:43:50] - Dev Agrawal So, the best way I understand TSRX is that it's kind of like a subset of JSX or it's like a better JSX that is more well-designed for reactive frameworks or frameworks that kind of track state or have control flow built into the JSX or into the UI layer. So, it has— Uh, there's like a lot of syntax ergonomics, uh, that, uh, that it improves on compared to JSX. I have not personally like, uh, used TSRX much myself. [00:44:25] - Dev Agrawal I know Ryan has looked into it. There is like a— [00:44:29] - Armin Ronacher I mean, I think the, the main, the main part basically is like if, uh, JSX as it was built, uh, like the, the extent to which you can conditionals in there is, um, Like, I don't even know what you call this operator, like ternary operator. And, and the loops are like array map. And none of that actually maps to something like Solid. And then you end up with this like ugly looking for and like show and hide and whatever. Right? I think like that's the core of what they wanted to fix, I think. [00:45:04] - Dev Agrawal Yeah. [00:45:05] - Armin Ronacher And to be honest, it should have been fixed for React too. Like, it's also dumb in React. It's just like, it worked good enough. That's sort of like a shitty solution, sort of standardized. [00:45:16] - Dev Agrawal Yeah, the ternary and the .map. I think any, uh, like, uh, anything that tries to make list rendering more performant eventually ends up like adding that for component, uh, back. Um, yeah, so Solid just kind of like tries to do it from the start. [00:45:34] - Armin Ronacher Um, but it's just a question of syntax, right? Like, that could have been from the start, that could have been that in there. And I think like, maybe I misremember this, but I thought Hack, for instance, had that still. Maybe I misremember, maybe it was something else. [00:45:50] - Dev Agrawal Sorry, what? Hack? [00:45:52] - Armin Ronacher Hack, the PHP, where JSX— I think, I think maybe I misremember. I thought they had like a conditional not conditional, like a loop. Maybe the chat can tell me off. [00:46:13] - Anthony Campolo We do have a question from Ryan. What do you think about compiler-ahead forced structuring versus runtime-enforced? I see a lot of focus on syntax Go guide ages, but what if your whole app is observable? [00:46:25] - Dev Agrawal Yeah. So, this was like— this was one of my tweets that kind of led to this discussion where I was I think my tweet was basically like, what if we tried to bribe Armin with very rich runtime observability tools? [00:46:40] - Armin Ronacher It's a good question. I think honestly, at the end of the day, it's hard to say right now because in isolation, we don't really know how these things are going to behave. I think one of the problems with solving problems with runtime, um, with runtime information is that the code needs to run for you to get that information. So that seems just inherently worse, even if it's super great, right? So like, I much rather prefer not having to run the code to get like a sort of a good understanding of it. [00:47:19] - Armin Ronacher Um, and I think one of the failure cases that we see a lot right now is agents write a lot of shitty tests. So you end up with a lot of tests. And then because the agents also hate running all the tests, they're testing such a small set of it that, like, the whole thing gets really weird anyways. And so, like, I kind of want the compiler to check everything, because then, like, there's a lot less that I would even need to run. Particularly with JavaScript, which is dog slow anyways. Um, so I, I don't know if I like— I mean, I work for observability company, right? [00:47:58] - Armin Ronacher So it should be all, all observable. But, um, I just— I, I mean, I, I got so hooked on Rust like years and years ago because it just— I felt so confident that once it compiled, it probably like for the most part doesn't screw up. And I liked it a lot. I really, really liked it a lot. I hated the compiler slow, but I think it's still a great, great feature that it— yeah. [00:48:27] - Dev Agrawal Yeah, that makes sense. It's definitely— yeah, runtime diagnosis can certainly have like that additional barrier that you can't just write the code and hand it to a compiler. You have to actually run the code and you have to like kind of see what, uh, like everything that kind of came out of running the code and look through that instead. Um, like running it in tests and looking at those logs, it's pretty straightforward. But yeah, like you mentioned, some— the agents sometimes will write way too many tests, and sometimes they don't— they won't even run all of them. Um, so it's not always as easy to, uh, like catch all those issues that way. [00:49:07] - Dev Agrawal Uh, the other side to that is like the runtime will all will often catch issues that the compiler simply cannot. Because the first thing is that the runtime can see the entire app. The compiler usually sees one file at a time. So it can't really see through your entire project. Or if you do build that sort of compile— Rust does kind of, I guess, see through the entire project. Rust doesn't compile one single file at a time. I'm not fully sure about that. [00:49:37] - Armin Ronacher I don't think that matters that much. I think it's just a question of, like, as an example, for instance, I think a lot of the failure cases right now where TypeScript does not catch something is just this casting to unknown and then some type, right? And it is largely happening because, like, what a lot of TypeScript code does— so one of the big differences, I think, like, in, in terms of like how reliable a Rust codebase is to a JavaScript codebase, is that in Rust you cannot just take a bunch of bytes from the network and then say like pretend that this is JSON of the right structure, right? [00:50:17] - Armin Ronacher So most serialization libraries in Rust, as a— because they have to stash the values into very specific fields on a struct, they don't have ever the situation where they're expecting a string but actually getting an integer because like it wouldn't be able to stick it in the struct in the first place. Most getting bytes from the wire code in JavaScript is like, well, it's going to work as unknown as whatever my record type is. And then like all bets are off because like around the, um, like obviously it's still going to blow up at runtime, right? But, um, But the way it sort of blows up is, is very different because in Rust it blows up in a very specific place, which is like where I'm going to parse the input into my structure, whereas in JavaScript blows up all over the place. [00:51:06] - Armin Ronacher And in particular, you have so much code where like the origin of this stuff that came from the wire somewhere, it's actually incredibly hard to track down because you sort of like you take it from a container and then you place it individually on some other thing, and maybe it even goes back to a queue and shows up another process and it's all messy. Um, so that I think is the biggest difference here. I don't think it's like how the compiler does the type checking or what the size of the compilation unit is. It's just like in Rust you have no chance at all to cast to any. It just doesn't work. The data model doesn't support it. And in TypeScript it's so common. Um, I think if it wouldn't be for that, it would come down give or take the same. [00:51:43] - Armin Ronacher And the other thing is like you can and agents will run the thing just like not doing the type check. They're like, okay, let's run it first. And then maybe at the end they do the type check. But it's not like, it's TypeScript, let's do the type checking first and then run the thing. It's like the order is like run it, right? And so, um, like the fact that you can run Node without type checking, and that is the common way even, or like a very common way for the agent to run it is also just a silly kind of effect of the whole thing that— and Python had the same problem, but like you don't have that problem in Rust. [00:52:20] - Armin Ronacher Like there's no way you can bypass the type checker. [00:52:24] - Dev Agrawal Yeah, that makes sense. But what I'm hearing so far is that compile-time checks are not enough. You need to actually check things at runtime itself. So what you're describing is that Rust takes some bytes, of the network. And then at runtime, it performs this operation of like stashing them into this specified schema. And that's how it knows that something went wrong. So it's not just that you have a compiler checking things, but it's that the compiler tells the runtime how to actually perform these checks. And then the runtime lets you know that something was wrong. [00:53:00] - Dev Agrawal Is that a fair, uh, way to phrase it? [00:53:02] - Armin Ronacher I mean, I think, I think the way is like there are a certain class of problems that you can catch at compile time, and I think they should be caught there. All the logic bugs and everything, like, I— like, that would be silly to express in a type system because, like, I mean, like, a lot of it I think is undecidable, so you can't even do it. And even the parts where you could potentially— like, in Rust, for instance, you can do, um, uh, I forgot what the pattern is called, where you basically express on the type system, the state in which the system is. So you can, like, I think call it type state, which is just a generic parameter. [00:53:39] - Armin Ronacher So you can express a lot of your logic in it, and you can— but, like, Rust doesn't have affine types or linear types, so there's still a lot of situations where, like, you can't express it. So I don't think you can ever get rid of, or should get rid of, like, runtime enforcement. Um, and you probably need way better integration of observability. I mean, one thing that I learned at Sentry, and I think it's probably not very surprising, is that people hate spending time on making errors work well, and they will never do it, and neither do the agents. So like, usually what you get out of errors is just like whatever, like the least amount of creativity ever. [00:54:17] - Armin Ronacher And a language that would pay more attention to the failure path, either by forcing you to use result types of sorts, or by having really, really great observability into the error, they would just inherently be way more observable than, than any of the stuff that we have today. So we would need to fix the runtimes a lot, which in JavaScript is incredibly hard to do. Because like the browser vendors are like, I think at this point, they don't even want to catch up with like what the standard committee wants to have in JavaScript. I think at one point, they even said like, we're not going to implement everything. So, like, for instance, like, I absolutely hate the fact that async locals exist on Node, but they are still not in the browser. [00:54:58] - Armin Ronacher It's not like the greatest thing since sliced bread, but, like, in the absence of async locals, it's going to be really tricky to do things like observability, where you need to follow the logical flow of execution through a promise chain. And with async/await, there's not even a monkey patch that's going to fix that for you. So, like, this is just so bad in JavaScript that I kind of, like, we need to fix that language to solve the runtime reporting really well. Or we need to do stuff like Effect where we stop using async/await entirely. Because damn shit doesn't work. [00:55:37] - Dev Agrawal Yeah. There is a proposal for the browser. I don't know if it's ever gonna get implemented. And, yeah, for— I think [00:55:42] - Armin Ronacher it's like 10 years old. 10 years old at this point. I'm guessing. I don't know. Ryan might know how old it is. [00:55:50] - Dev Agrawal Yeah. Both React and Solid have APIs that they wish they didn't. And they only exist because async context exists. And it leads to a lot of footguns, actually. And if async context was just there, then the world would be a nicer place. If the runtime was better, if the type system could detect some errors. The world would be a nicer place. But I feel like we are kind of stuck in a place where the language isn't going to move much, the runtime isn't going to move much, TypeScript is probably not going to move because they're trying very hard to rewrite it without losing compatibility, which is nearly an impossible task. [00:56:31] - Dev Agrawal So, I feel like the way— the approach that Solid is trying to take is like do the best possible thing that we can on top of the existing language. And if we do, if we do in fact like get a better language at some point, we should be able to just take the improvements that we have and like kind of trickle them down so that everyone gets the much better experience. But if we are kind of like locked into whatever the current version of JavaScript that runs in the browser and whatever version of TypeScript we're using today, what's the best possible thing that we can do to catch the most issues, to give agents the best feedback, to make sure they don't run into those issues? [00:57:18] - Dev Agrawal Because agents are going to run into issues. [00:57:21] - Armin Ronacher I'm not so pessimistic that you can't make JavaScript better. And in part it's because the actual core language is pretty good. Right. And, and I think that we have a history of transpilation in JavaScript. This goes back to like CoffeeScript earlier, right? Or like Rollup. And I don't know what all these things were called. So like, the— and it's, I think it's like one thing that JavaScript did so much better than Python, for instance, was never to like force types into the core of the language. [00:57:57] - Armin Ronacher I mean, they're sort of there now, like the syntax is preserved, but like the type erasure process of TypeScript and Flow was always the right thing because it meant that the core language doesn't need to deal with any of this nonsense and you do it in a step before. Now we're living in a world where we're doing this blankable TypeScript where like the sort of the creativity in the transpilation process is sort of like we don't want that anymore, or at least some people don't want it anymore. But like, it is a community of transpilation. And given that it is a community of transpilation, it mostly just needs a target JavaScript underneath. [00:58:33] - Armin Ronacher Modern JavaScript is a pretty interesting compilation target. One, because WASM, for all the shit that it has, has suspending. So you can actually implement within WASM, you can have something like a blocking syscall, and it will actually allow you to await the promise on the JavaScript side. And I think that in alone, allows for a lot of creativity of what you could do within that runtime environment. And on the other hand, you have async generators, which are an interesting compilation target. Like, there's— the syntax is shit, but if the language that you're writing actually, like, just happens to transpile down to async generators, then you're not forced to do this async/await stuff. [00:59:21] - Armin Ronacher Which allows you certain things that async/await doesn't. So I wouldn't dismiss this entirely just because, like, I'm pretty sure we'll see it anyways. There will be, like, so many people on the internet like, okay, it's a good idea, let me use, like, I don't know, 2 months worth of, like, Opus budget to experiment with all kinds of crazy language contraptions. Like, this is going to happen and someone is going to build something cool enough that someone else wants to jump on it and also try it. I, I'm pretty bullish on, on, on like at least the transpilation part. The fixing JavaScript part thing is trickier, but I don't think you have to fix everything for that. [00:59:59] - Armin Ronacher There's also like the async local stuff is also like a massive footgun in terms of memory and like leakage and everything else. So it might even be better to just transpile with an explicit object passing or some, some, some other sort of out of, out of bounds mechanism. [01:00:14] - Anthony Campolo I want to bring it back real quick to something you were saying earlier about how you feel like React agents succeed at it more because they had a lot more training data on it and potentially they invested more in just making it work well. So do you see a tension here where we could build all these runtime or compile time or whatever solution we think would improve the agents, but then the further you get into whatever this new thing you created is, you then get further away from what it was trained on and optimized on. So do you see— do you think there's a tension there? Do you think eventually the models won't need so much training data to be able to perform well with a new abstraction? [01:00:53] - Armin Ronacher I don't know. It's a— I, I think it's, it's an open question. Like, I'm always surprised how good it is at Zig, despite that Zig basically is the most unstable language ever, right? It's like every release is completely different, um, and yet they're really good at writing Zig. On the other hand, I don't know, there's ample training data for— I don't know, what's a good example? Yeah, it also, I think, like one of the— this is less of a failure case now, but like I find it's like, I know that, I don't know, even earlier this year, I still had a conversation with some CPython maintainers that said, like, well, they love using LLMs to, like, I don't know, program on their side projects, but using an LLM to work on a CPython compiler sucks because it doesn't want to read the code as it exists right now. [01:01:50] - Armin Ronacher It makes assumptions about the code because, like, it knows what Python is. So if you change Python, then sort of like, like, you want it to actually know less about Python. So I don't think it's so clear-cut if it's a good idea to be in there or not. Like, if you want to change— like, they had the same problem with Tailwind, right? Like, when Tailwind 4 came out, there was like a period of like sadness where the damn thing just kept writing Tailwind 3. So [01:02:17] - Anthony Campolo yeah. And then another thing related to this that I think about a lot now, I don't think we've really hit on yet in this conversation, is there's a kind of debate right now about How much extra scaffolding in terms of like rules or skill files or AGENTS.md do you add in? And some people are saying you should like delete all those. Those are just gonna like slow down the new models because you wrote them for the old models. But I'm kind of listening to a lot of this conversation. It's like a lot of the issues that we're hitting, it's like if you just have like a well-concise written rule that is written in a way the agent understands it, like it will be able to get around those issues even if it won't do do it natively. [01:02:54] - Anthony Campolo So I think there's, there is a potential space here where [01:02:57] - Armin Ronacher I have a little bit of data point [01:02:58] - Armin Ronacher here, right? So, and this is like not, not to like hammer down the point of Pi too much, but like Pi changes regularly. Pi Durable also still changed a lot, right? But one thing that's I think true for both Pi and Pi Durable is that if you want to have the agent build an extension or you want to build an agent have built on top of that, they don't have to read that much code. Pi Durable is tiny. And so it is easy enough for the agent to throw the entirety of Pi Durable into the context and fully understand what it's supposed to be doing. So if your core system is well thought through and very small, then I don't think it matters that much if you're being trained on it or not, because the agent actually, like, I'm not saying like the sort of, They're great expert programmers that understand every single API, but like, they're pretty good, right? [01:03:50] - Armin Ronacher But if your whole complexity of this project is like 2 million lines of code, then that strategy will not work anymore. So I think it depends really greatly on like how complex is the thing that you're throwing at the agent. [01:04:07] - Dev Agrawal Okay. Uh, so sorry, so it was like, um, so if, if you're giving it like a huge code base and lots of instructions, then you're saying that it, it's not going to be able to follow all of them coherently throughout the day? [01:04:24] - Armin Ronacher I think if you have a great code base, then you need the skill files, because otherwise it's like it's going to be lost. If you're whole— like, if you manage to create like, I don't know, the best ever Solid and it fits into 8,000 lines of code and it's a self-contained, like, verified system, like minimum number of state transitions, whatever, I don't think it will need that much guidance because it will like, oh, this is the best thing ever. It will understand it and it will build on it, right? It's like, I think like the inherent complexity of the problem is what pushes you one way or the other. So I don't subscribe to the idea that there cannot be innovation because like you need to be like There needs to be a lot of training data. [01:05:06] - Armin Ronacher There seems to be like, we would not be able to use these coding agents for our own software that it has never seen if it was true that it can only program what is sort of on the training trajectory. [01:05:18] - Anthony Campolo Yeah, that's what I was always saying like 2 or 3 years ago when this conversation was kind of a lot. So like this is a big thing people used to talk about, not so much these days. [01:05:28] - Dev Agrawal Yeah, I was just saying that it's funny because this was my argument against Code.js, but that's probably for another time. [01:05:37] - Armin Ronacher But there it's different. I think this is the important part to understand is the code that it writes versus the way to orchestrate the agent. Those are— they're going down different trajectories. [01:05:49] - Dev Agrawal Got it. Okay. Yeah, I think in my experience with agents writing Solid, they used to get confused quite a bit in the pre- Opus 4.5 days. I think in the last few months I haven't really seen that happen much. I've also been like having them write Solid too a decent bit. And usually they can look at like browser logs and like logs from tests and get like a pretty good idea of what they're doing wrong. [01:06:29] - Dev Agrawal Wrong based on the runtime diagnostics. I'm also currently in the process of writing a compiler for Solid. Not like a core project right now, but kind of like going into this logical extent of how much can we tell about the code before we even run it. Kind of what you were saying earlier. Sometimes you don't want to run the code to see what's wrong with it. You want to be able to see detect as many issues as you can before you run it. Obviously, that means you're going to miss some issues. But it's good that Solid will catch them at runtime if the compiler happens to miss them. [01:07:07] - Dev Agrawal Obviously, it's better if the compiler doesn't even let that happen. But I also want to make sure I don't— like my earlier comment about JavaScript is not going to move, it's not a pessimistic argument that Uh, I am not— I'm not, uh, like, I, I don't think things will move. It's more of like, I guess I, I, I wanted to frame it as more pragmatic, that I don't see anything moving right now. There's, uh, I, I, I almost certainly expect things to improve over time. Like, uh, hell, if in the last few weeks AWS actually released some good like UX improvements, if AWS can make their UX better, I, or like can invest into making their user experience better, I have hope for the world. [01:07:50] - Dev Agrawal I [01:07:51] - Armin Ronacher mean, I think that the bulliest thing for me would be, and I'm expecting it, is like when Andreas started working on this Ladybird browser, it was like, this is fucking ambitious. But we need it. Like, I don't know if he's going to go anywhere, but we need competition to Chrome and WebKit. But now it feels like we will have competition with or without Ladybird because it's possible. And in fact, it is such a, such a humongous security target. [01:08:29] - Armin Ronacher Like, I, I, like, I'm not, I'm not one of those people who's like everything needs to be rewritten in Rust for security reasons, but like, this is, these are humongous code bases and they have been written by humans with all the failures and everything. And this is one of the most important platforms that we have. And there's no variety in it. So there should be people that are like, now is the moment to build other things, right? Like build, build another browser. And like, I expect that to happen, right? [01:09:05] - Armin Ronacher I expect there to be at least one other browser engine now that sort of looks at this Like, how would you build a browser engine in the year 2026 with coding agents and everything? And so I remember when Firefox displaced IE6, right? It was a long time ago. And there was nothing for such a long time. And then it was, like, instant, right? So, like, I mean, it wasn't instant because, like, IE6 never completely went away. But it's like, but it went from, like, impossible that Internet Explorer would be displaced to it's actually happening. [01:09:42] - Armin Ronacher And I think that could be one of those things that, that will start to, to bring some movement into it. It's not going to happen right now. But there's like almost everything is up for grabs right now, and including JavaScript. I'm just convinced of that. [01:10:02] - Dev Agrawal Yeah, for sure. Do you expect to still be— like, imagine if we get a much nicer browser and a better runtime for browser-side scripting. Do you still imagine to be using React? Or would there be— like, would the current frameworks work on top of them? Or would there become brand new frameworks? And would the brand new frameworks represent the frameworks we have today? [01:10:29] - Armin Ronacher I mean, I probably would not look at the code anymore, right? So I, I, one of the things that I do, like on Pi, we're very conservative, right? Like people would be shocked to how non-AI-pilled we are when working on Pi. But like on everything else, we're like sort of like as insane as everybody else, I guess. Um, and I have a lot of this sort of like side projects where I do all kinds of stuff. And like, I really, for a lot of them, I really don't care what the agent is doing. And every once in a while I'm looking at like, what do you actually do there? And it's very rare that it uses React, right? Like, I've— I have the agent build so many like little, let's call them applets or whatever I call them. [01:11:09] - Armin Ronacher Like, here's the thing that we're actually doing, but also we need a bunch of like extra HTML thing on the side to debug it or to— and it never uses React. Um, and I think it doesn't use React because like it just doesn't want to deal with the compiler. And yet it sort of seemingly works. And so if we just assume that there will be a lot of people who are starting projects like this, they're not going to say, like, hey, let's build this with Tailwind and React, whatever. It's like, hey, I need this. And whatever comes out of the machine is going to be the default experience. And it might just be that it will just not be a framework at all. [01:11:48] - Armin Ronacher If nothing else, that's probably the most likeliest outcome, is that like React will lose out to vanilla JavaScript just because the agent just doesn't want to deal with it. [01:11:57] - Dev Agrawal Okay, so, but, but does that— so the reason that frameworks exist is because if you don't use a framework and eventually your app grows into a certain size and complexity, you just end up building your own framework, bespoke framework, inside your app. Or at least that's, that's what like the running theory has been. And I feel like it's going to be the same for agents. Like if they, if they, like if they're building little applets without frameworks, that's fine. But if you start moving the, if you start getting them to build those out into like bigger apps, then the agent will just invent its own framework inside the app. [01:12:33] - Dev Agrawal Uh, if it doesn't end up using one, is that something [01:12:36] - Armin Ronacher exactly what it's doing? [01:12:38] - Dev Agrawal Okay. Right. So, so in that word, Yeah, go ahead. [01:12:42] - Armin Ronacher I think, like, isn't that exactly, like, how Google and everything else works? Like, my experience of hiring people out of Google has been, like, there's this world that everybody of us is in where, like, you use React, use all of this. And then there's the Google world where, like, you solve all the problems yourself. And, like, if you then transplant it into a world where that's not the case, you're, like, confused for, like, 6 months. And, and, and I think like an agent basically becomes mini Google very quickly, where it's like, it's, it's sort of like it builds its own little world. [01:13:20] - Armin Ronacher And like, we're kind of intentionally forcing it down this path anyways very often. Like, like, I know that I do this, but I've seen so many other people do it. Like, hey, I want to build this other game now. I want to build this other project now. Let's quickly discuss for 15 minutes What would be the optimal setup for us to be very quick at iterating on it? And then just like, okay, yeah, we should build this debug tool, we should build this. Like, you started building— like, step 1, build a framework. But because it only costs you like, I don't know, half an hour of waiting time, you don't mind that it's doing this, right? Um, I, I don't think that's necessarily bad. I think there are problems with it, right? [01:13:55] - Armin Ronacher Because like, for instance, like now, how the hell are you going to put like re— like Sentry, for instance, would live very hard in a world where everything is bespoke. Because all of a sudden, in order for Sentry to work in this, you're going to like, hey, I don't know how to use Sentry here, but agent, please figure this out. Because Sentry could no longer at that point provide a generic integration just because everything has its own framework. So everything that needs to fit together on the interfaces will have a very hard time if there are no standardized interfaces. Um, but with agents, do we— I don't know, it feels everything was different. [01:14:34] - Armin Ronacher Maybe it's— maybe it will not change that much. It's just like I'm observing it being absolutely fine without a framework. [01:14:41] - Dev Agrawal Yeah, I mean, I, I mean, I'm even imagining a world where like I have a fleet of agents that are managing like all their own like applets or bigger apps, whatever they are, and all the integrations. And I don't care about the code at all. I don't care what framework it's using, what language it's using under the hood. Um, but the agents probably do. Like, it's— they are doing the work of maintaining these applications, or, or like, and even the framework that they have built. So if the agent has a framework that makes it easier for that agent to continue building things, basically, I mean, it's not changing my, my experience, but it's probably costing me less tokens and, uh, like less latency, uh, and probably even less bugs over time. [01:15:31] - Dev Agrawal Because if, uh, like if I just let an agent build the framework, it's not going to be as battle-tested as like a, like React or Solid. Uh, [01:15:42] - Armin Ronacher it might also— I think it could also improve your experience Right? Because like, if, like, if, if you don't have an opinion at all, it's like, okay, if you make it good for yourself, that's like, okay, it's, it's one thing you can do. But like, it doesn't cost you that much more to also say like, hey, by the way, also I kind of want to know what you're doing. So also do that. Um, and, and then maybe you do give up a little bit of token efficiency to do this extra thing to make it understandable for you. But like in, in many ways we are the bottleneck. And I understand like that is people that like all hands off, just do everything on your own. [01:16:19] - Armin Ronacher But, um, I haven't managed to bridge that yet. So I'm actually willing to forego quite a bit of token efficiency for the agent to also give me great reports of what it's doing. Um, so I don't know, I, I wouldn't, uh, but the, the thing with this, this behavior that we're seeing from the agents right now is that They're actually everywhere, all over the place. They are, as they're seeking the solution to the goal, which is like make this thing work, they're building so many mini apps along the way, right? Like, like all these new models, they're like, if there's an edit tool, I don't care, I'm going to write a little bit of Python to do string manipulation because I don't know, I learned that in the RL environment and I keep doing that. [01:17:06] - Armin Ronacher And this is all so bizarre because it's like it's writing code to write code and it's moving it into a completely new environment. To that degree, I don't think we have seen it before. [01:17:23] - Dev Agrawal Got it. Okay, [01:17:24] - Anthony Campolo cool. We should hit just a couple of questions in the chat. We have 2, but they're related. Basically, like, what's your kind of daily setup? Are you running in the terminal? Are you using a VPS or orchestrator? And this kind of similarly, like, what's your preferred way to build, you know? [01:17:40] - Armin Ronacher Yeah, a huge difference between me working on Pi and me working on side projects, right? Pi does not operate the factory. Um, um, I haven't figured out at all, by the way, how to use subagents, but I do use parallel Pis to do investigations and open tickets. Um, and Pi, we're super conservative. Um, On my side projects, I'm like nuts. Like, I have a game that I'm building with my kids, and I like— there's all kinds of like side projects. Like, I'm trying to figure out like where does it go, right? And so like that, the stakes are low. [01:18:16] - Armin Ronacher I don't really care. I want to see where it's going. Um, yeah, but, but that is in many ways I think a performative art. So like for, for actually solving a problem Kind of conservative and just like have a bunch of checkouts on a bunch of Pis. One, like, I going back and forth on this, like, have Pi running on a computer that I have, like, keep running when my laptop is closed and just actually— because, like, I think part of the problem that I'm having at the moment is, uh, look, it is after midnight, I'm still awake. I woke up at 3:30 in the morning. [01:18:53] - Armin Ronacher And it's like a reflection of the fact that I don't sleep as much as I probably should, right? And so I'm actually like, I'm like a lot of people, myself included, feel like if the agent is not running, then like, what am I doing with my life? And I just more and more think like that is a huge trap. Like, I shouldn't be working like this. So I'm like actually kind of forcing myself to do that less. And that might be a mistake because maybe we all should be like having these things do stuff like to insane amount. [01:19:30] - Armin Ronacher But yeah, it's like I have this like everyone's— I have to say, yeah, I need more of that. And then I feel like actually that was a like a horrible waste of tokens. So like we did all of the things I'm doing, did this actually result in anything? And I'm sort of like forcing myself way back to like Okay, let's just focus on what's important. And then actually I don't need all of this. So it's a mix of both. It's exciting, but also I think kind of unhealthy at the same time. And I don't know myself how to deal with this yet. [01:20:03] - Anthony Campolo Yeah, no, I think agents can feed into lots and lots of developers' neuroses and can create and exacerbate mental health issues and all sorts of stuff. [01:20:13] - Armin Ronacher That's the only game I can think of. [01:20:15] - Armin Ronacher I mean, I will keep telling this story over and over, but I Um, these models have been trained on Python initially, right? So a lot of people wrote stuff into ChatGPT and they got the Flask app. And so I've been on the receiving side of emails from people about their kind of stuff for like 3 years at this point, right? And like my inbox is a collection of not, not the massive amount, but like a lot of really people where I feel like I should call a doctor because like I should not receive that email, right? [01:20:53] - Armin Ronacher Or like what they're writing in there is like there's clearly something wrong. And I've never seen that in both 4AI times. Like I've— like I only got nice emails from people like, oh, thank you for your open source software. And now I'm getting all kinds of stuff that is like partially really disturbing. And it's because like somehow they had a conversation with the machine and they figured out like they should talk to me. Like, there's— because it behaves so similar to a human and sort of is so unsettling, I think it— like, if something is like your borderline, that can tip you over and that's not healthy. [01:21:28] - Anthony Campolo Yeah, or if you're staying up late, just sleep deprivation or, you know, people who are taking lots of like amphetamines and stuff like that to work also. Like, that's a very, very dangerous combination. Which I could actually say from experience. [01:21:44] - Dev Agrawal Yeah. If you're getting those emails, I don't want to imagine what the React team is getting. [01:21:51] - Armin Ronacher Yeah. [01:21:54] - Dev Agrawal Cool. Okay. So the conclusion is that graph engineering, loop engineering are all performative. [01:22:00] - Armin Ronacher No, I think that there are people that do it really well, but I think a lot of tokens are being— and I think the I mean, I don't want to say like the token subsidies is the reason for this, but like, um, because we're paying a flat fee for the subscription, we're not really thinking much about like if the use of those tokens for any particular problem is good value for money. And once you're not in a token subsidy kind of situation, well, or not a flat fee kind of situation, like The world is a different one. And I keep telling the story, I paid $25 for like a Chinese Wi-Fi CarPlay adapter, and then I burned 3,000 tokens on trying to do the thing that I actually wanted. [01:22:44] - Armin Ronacher And I would never have spent $3,000 on that if I had to pay that, right? So, um, yeah. Because everything is out there right now. [01:22:59] - Dev Agrawal Makes sense. Yeah, I think if— I think I'm hoping to make the case soon that your agents spending tokens on building bespoke frameworks for your app should be counted similarly as like, don't do that, just have it pick an existing one. But we've still yet to make like a good case for it. And yeah, I definitely— this has been a very helpful conversation. Uh, I, I know, right, uh, Ryan said he had been listening quietly. I'm sure he has a lot of ideas as well after this. Um, because, yeah, I think the TL;DR is that my conclusion so far from this conversation is that there are like, uh, kind of the, the issues that at least you kind of brought up for why you prefer React. [01:23:44] - Dev Agrawal I feel like we have— a lot of those have been addressed, but we haven't done a good job talking about them. So, um, yeah, that— I mean, uh, definitely. [01:23:53] - Armin Ronacher I mean, I, I would say like generative UI, I'm pretty sure it's going to happen. I don't know if it's a web-only problem. It might be there are some people that really want that to extend to native UI. It, it is not solved. Maybe you can be part of that solution. [01:24:12] - Dev Agrawal Yes, that generative UI has kind of like definitely contributed to like why I'm working on a compiler right now. Um, obviously I, I have my own agent harness as well where I'm trying to build like some sort of generative UI. Uh, obviously the current approach is just like let it, let it write JSON descriptions of the UI, but, um, that's, that's obviously not going to work out in the long term. I think Claude Code Mods do something. Uh, I don't think they are just like JSON descriptions. I think in the— in like Plot code, they're actually like writing UI components, uh, that do things, but I haven't looked into that too much. [01:24:53] - Dev Agrawal Um, yeah, so [01:24:55] - Armin Ronacher it's easier if UI doesn't need to be persisted. I think like if you have the desire that it's like things that should have been have a shelf life of like months, then you have different trade-offs. And if it's just like, hey, I need a little, I don't know, side widget to ask me about my Net Promoter Score for the session or something. [01:25:19] - Dev Agrawal Yeah, definitely. Those are like the 2 different categories of generative UI, which will have like 2 different ways of like building and authoring them. Okay. Yeah, this has been pretty helpful. Is there anything you'd like to shout out that you haven't already? [01:25:41] - Armin Ronacher No, I've been waffling enough. [01:25:45] - Anthony Campolo Awesome. Well, I just want to say thank you for all your open source work throughout, at this point, decades. Lots of stuff that's been very, very impactful. And it's great that you dove straight into AI and have been a really big part. Having been involved in open source for so long, because I think that's really important. And, you know, the whole open source dead, not dead stuff, like we're not gonna get into that conversation, but it's like, you know, you're, you're a good example of like, that's obviously not true, you know? So, yeah. And we'll, we'll probably let you go since you're up late, but I would love to just keep the conversation going. I'm following you on the Twitter now and yeah, definitely really happy to, to have you here. [01:26:25] - Armin Ronacher All right. It was fun. Bye-bye. [01:26:29] - Anthony Campolo All right. And then for everyone watching right now, thank you for asking questions and engaging. I had a really good, um, audience today. We're gonna be back tomorrow with, um, Kevin and who else, Dev? [01:26:42] - Dev Agrawal Uh, Kevin and Riccardo from TanStack team. So we're gonna be talking about TanStack Table, Pacer, hotkeys, and all the fun stuff there. [01:26:51] - Anthony Campolo Awesome, awesome. Okay, so we will catch you guys tomorrow, and yeah, we'll end it here. So thank you everyone, and catch you next time. [01:27:01] - Dev Agrawal Good night. ## Discover Related Content - [SolidJS with Ryan Carniato](https://ajcwebdev.com/videos/solidjs-with-ryan-carniato/) (Video) - [Advanced SolidJS Techniques with Dev Agrawal](https://ajcwebdev.com/videos/advanced-solidjs-techniques-dev-agrawal/) (Video) - [Marko 6 with Dylan Piercey](https://ajcwebdev.com/videos/marko-6-with-dylan-piercey/) (Video) - [SolidJS Agent Doc Audit with Dev Agrawal](https://ajcwebdev.com/videos/solidjs-doc-audit-dev-agrawal/) (Video) - [Are Software Factories a Scam? with JLarky](https://ajcwebdev.com/videos/are-software-factories-a-scam-with-jlarky/) (Video)