0:02Hello 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 Armen with us. Uh, Armen, why don't you go ahead and introduce yourself and tell us who you are and what you do. Uh, hello. Sorry for pushing this back. I was commuting. Uh, my name is Armen.
0:27Um 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 uh probably the thing that most people know me for is the flask web framework. Um, and I guess nowadays maybe more the ginger templating engine. And for 10 years I was working on Sentry and I started a new company last year called Arendelle. And the thing that most people know probably what this company is doing is building a coding agent
0:57called PI and the harness agent harness underneath also called pi or like now pi durable and yeah we're trying to now make sense of AI. I think that's sort of [snorts] how I can how I can think of it.
1:10Yeah. Yeah. Uh, it's a super cool, very very impressive resume. I could 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 um, some new stuff. And, uh, I definitely 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 um, but what kind of kicked off this conversation and I'll pass it to Dev was um, some kind of React volid [clears throat] type discussion. and um Dev and I are both big into Solid, but we [clears throat] also both have a lot of
1:40React experience and we are not partisans. So, I think it'll be a fun conversation. But, um from there, you can uh 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.
1:57Yeah, I mean, uh I I maybe a good starting point is just how you got involved with Pi. like uh I know like 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 you were kind of like uh partially responsible for making Pi as popular as it is today. Uh because uh Pi is the coding agent behind OpenClaw. So uh I think earlier this year Open Claw just completely blew up and then uh
2:26suddenly the every everyone was talking about like the coding agent that uh that made it all possible. uh say love to hear about your history with um so I think the the funny thing is like usually like after I don't know 10 years to go back it's like how did it all started but like it feels like this is already like seven years [laughter] my my version of all of this is like AI years is like everything time seven so we're in year seven of the coding agent
2:55and my memory of how it 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 friend of ours [snorts] um who at this time wasn't actually doing anything so Peter Schlamburger he wasn't actually doing anything but he said like hey I I I'm in cursor and I
3:23have 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 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 what am I going to do? And Peter got me hooked on um on this and actually told me to check out FL code again. Um which I sort of initially dismissed because of some
3:52really stupid reasons. My sales age conflict 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 allnighter trying to build crazy with agents and I don't know whenever this was June, July I guess.
4:09And 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 Arendelle 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 cloud code for him because like close code started doing stuff they didn't like [snorts] and so we were sort of like collaborating and we're trying to hire Mario um like
4:39throughout all of 25 and then in December Peter's claw open at that time now it's called open claw at that time I think because raw relay and then all kinds of stuff um including mold mold mold bot um blew up and Peter already in end of December I think like even early I think in November already times time's flying past not very good
5:07on the timelines here but like at one point here already replaced um the cloud code SDK with um with the PI SDK in there and then um Mario was uh
5:23willing to join Arendel and sort of bring Pi along because we already built um our own agent on Pi [snorts] um and we liked um the design of it and just generally were super excited of Mario on board and so now at least temporarily Arendel 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 to basically maintain this now. [laughter] But [clears throat] yeah, I mean like
5:52we're we're super excited about what the I can do and we kind of want to bring it in the hands of non-engineers. That really is what we started out with. Um and yeah, that that that shall be our goal. Um not so much um the coding agent, although we we do like it a lot.
6:10Got it. So [clears throat] you you started with or I guess you're still trying to build uh something that brings AI to like non-engineers but it like ultimately what what you ended up building was like the the ultimate coding agent for engineers for people who don't [laughter] want uh look and yeah and I think like the the the weirdness is um in I don't know like
6:38July August last year so long before I would say like we had fully cemented under the agent design that we had. Mari and I were talking that really quite frankly like given how we think the reinforcement learning is happening on those models it's probably a good idea to double down on bashed 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
7:04rack kind of stuff um and so while we were sort of abstractly right that bash is correct um or like programming languages and execution environment is correct we are a little bit too optimistic about being able to scale this to a personal agent at a time. Um and um in particular like having it in the cloud actually held it back quite a bit. [snorts] Um so um over the over the month that followed we actually started to use PI
7:32as a personal agent a lot more than our own personal agent which is a little bit disappointing.
7:38[snorts] Nice. Uh yeah. So, so how does and then eventually you ended up building something called Leos. Did I get the name right?
7:48So, that was Yeah. So, Leos was Leos was built on Pi. Um, and Leos in many ways is like it showed us some things which are good and some things which are bad.
7:58And like some of what we learned with Leos actually now sort of resulted in pyurable. Um, honestly the I think part of what sort of is confusing about this and like I know that there's muse now and everything and like that's really cool but um actually bringing sort of this this this really gratifying like an agent this powerful kind of experience that we all feel when we use a coding agent. Bringing that to a non-engineer
8:26is really tricky. um unless you walk down very sort of well um and and like I I understand like like OpenCL has demonstrated like this this is really great but um like there's there's so much subtlety in actually making the experience like 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.
8:55[clears throat] 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 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 and new but is so confusing what is so confusing about it is that
9:24it's like 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 basically have an agent um so like the product almost builds itself um and that's so weird It's because like you you you build this very like PI at the at the core of it is nothing else but like a little bit of a transaction lock and and and like storage and like an adapter to like the different LLMs
9:53but it's like basically just four tools 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 like okay now let's just put this into a sandbox then like the cost of it is very high right so like very basic sort of like get the experience going is like is too expensive for my mother to be
10:22wanting to pay that for. So like bringing that cost down without sort of like subsidizing it u is is is tricky.
10:30Makes sense. Okay. Um, I think if uh 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. [clears throat] Um, actually, okay, let's let's get Fuzzy's first question in [snorts] the PI durable. Looking at the announcement, it doesn't give out much.
10:54What kind of abstraction are you all using? Are 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 codeex? Is it the same abstraction, a higher level, lower level? Just so people who have a sense of those tools can kind of place it
11:23among among the different things. So if if we walk this back to let's say uh October last year the the landscape in October I don't know it was October let's say December December last year the landscape uh was a little bit like this the initial code base in Leos was using Brazil'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 authentic yet in
11:51nature and the other SDK on the market was actually the cloud agent SDK. And what's weird about the cloud agent SDK is that it is actually a JavaScript bridge to basically the cloud code blob. So it spawns cloud code somewhere.
12:07[snorts] 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 in Leos was an abstraction layer PI AI to talk to the LLMs and to transform the upstream API request into a durable transcript that is uh 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 you have if someone has a long chat
12:36with I don't know their personal agent um then even if the model changes the the transcript recovers and then on top of that there is the agent core and on top of that there is the pi agent pi coding agent SDK [snorts] sorry the pi coding agent library which then is the pi coding agent and one thing that we always liked uh Mario and me um is the idea that software should build itself like this idea like
13:06you 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 seven different things called pi. So there's the pi terminal user interface and then there's the underlying library which is also called pi. Um so now it's a little bit easier because pi is basically the coding agent and then pyurable is the underlying library. Um but in principle um yeah it's it's an agent core an agent
13:36harness and uh a coding agent that you could use or not but they they use it for just the library and they use it for the coding agent they might not even be the same necessarily.
13:48Interesting. Okay. And then I think you you hit on that a little bit but just to flush that out how does pi durable then sit within that larger thing?
13:55Yeah. So right now pi durable does not sit in a coding agent. Interesting enough. Uh so we we have not moved the coding agent to pi durable and not for laziness. Um that is because like pi has a pretty rich ecosystem of extensions that targeting pi and durable is um a reimagining of how the agent core should behave with basically fixing a bunch of issues that we had before. And um there's always risky the second system syndrome. So you can sort of like
14:23overshoot this entirely. Um but really we ran into a bunch of issues with the PI uh core um that really wanted us to revisit this. So one of which is PI does not work well if you want to have sub agents or any kind of concurrency. Um so it does work there sub aent extensions but the core of the session format has originally not been uh built with the idea in mind that there can be multiple writers um sort of relating to one
14:53session. The second thing is that it doesn't work particularly well for multiplayer setups or endless chats. Um so the JSON L file format sort of is an ever growing kind of mess. Um and it doesn't really well support compaction.
15:07It doesn't work well for distributed systems. So that was another thing. And the last one and this is sort of I think by the name I think ultimately is sort of what defines it is this concept of durability. Um 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 postgress.
15:27But the problem is if you put that on top of a nondurable 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 a concurrency layer with a scheduleuler and durability built in. So this pyural combines the concept of um sort of snapshotting similar to what you
15:54would do in temporal but explicit um a a scheduling system and an a session storage abstraction layer and then a whole bunch of other stuff to make this work for multiplayer scenario. So you can stream this out to multiple observers. Um it's a little bit of a of everything in 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 than what sort of like the not necess
16:23but not necessarily for for all the use cases that we kind of want to throw at it. [snorts] [clears throat] Yeah, that makes sense. And I I think if uh um for people who might not fully understand what pi pi durable is at this point, I think one one simple way that I 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 that transcript. Then you
16:52make the pool call, you store the result in the transcript in the in-memory transcript. Then you go back to the LLM put that in a 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 and in between you don't lose the entire transcript or you don't lose the progress uh at every step
17:22you're like checkpointing things. We did checkpoint a lot in pi 1 or we shouldn't call it pi one but like in the sort of the existing pi coding a lot of it was in the transcript so it was quite durable but um so there's a there's a pretty significant shift happening with um with what people want to do with agent we wanted to do this with agents which is this should work if no human observes and so um typically what you see in a coding agent session and I know that some harness is already better than that but like a very common thing
17:52is like I don't know of this three tries it gives up and just hangs there and says like I don't know failed and then you can do continue and you hit enter and it continues and [snorts] 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 the term completed state but we are throwing away that information and so with pyor what's actually happening is like every single thing that you do with the agent is is uh is basically modeled like a task or
18:20like you can think of it like a threat that is that 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. So if you have multi- aent orchestration, there's a question to which degree this is successful, but you can model that now. And while it's fun to build sub agents, there's a lot of
18:50other 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.
18:58Compaction can be done async, right? So you can as you're running towards the context limit, you can already do compaction async. [snorts] um and then you can sort of splice in the the results into the new kind of thing. It works on most LLMs on entropy reasoning, but it's still very nice. But that is a that is a concurrent task that runs on the site which actually on compaction might want to do cool calls normally shouldn't do it but might want to do it. And so there's there's a lot of these sort of things that you might want to do or you might want to run a
19:26task that just sums up all your sessions to build memories or you might want to run a task which is um a subtask of a code mode tool execution. And one of the problems with durability in PI uh 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 elicitations to MCP or you want to bring up an approval prompt somewhere, you might now need to suspend
19:55any tool execution and this might be like three 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. Um and just makes it um makes very obvious how you would how you would create an agent like this.
20:11Cool. [clears throat] Yeah, that makes a lot of sense. Um I'm pretty sure uh in the last like couple weeks or so you have 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.
20:26We should talk about solid [laughter] great question. Thank you very much for being this is the solid pill armor episode. [laughter] So the funny thing here is that I actually was chief resident solid promoter at Sentry I think. Um, so I I have a history of solid. I actually like it. So I don't know if you need to convince me.
20:47Did you write Overlap at Sentry?
20:49Yeah. Yeah. Uh, for for a couple of years.
20:52Okay, cool. Just making sure. Yeah, because that's important context. [laughter] Yes, I guess. Yeah, I would love to hear about your experience with Solid. Uh, you've it's possible that you have used Solid for longer than I have.
21:06Um, I don't know. How long have you been using Solid for? And I guess I I guess I started trying out solid at or at at the beginning of 2023. Um I need to figure out when we hired Ryan. Um because I used it before we hired Ryan.
21:24Okay. Prian joined in 2024 I believe.
21:28Yeah. So maybe like we started around the same time like I Yeah. I I have a lot of thoughts on solid. Um [laughter] that's why we have the entire live stream.
21:40The question is like where do we start?
21:42Um 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 leos in solid. Um mail hook which is an internal service built in solid and I still really like solid. Um the problem with solid why um that is probably not the technology of choice for a pretty significant part of what we're building right now has
22:11actually been that solid didn't have and continues not to have the amount of um adoption that I wish it would have and in a world of um and and I will also say like solid actually is not Perfect. So, um, in particular, if you sort of take an agent and say like, "Hey, build me a bunch of UI and it shouldn't up." Um, the agent just doesn't really fully understand how to build perfect solid code. [laughter]
22:40And the combination of there actually not being enough solid code, that solid is changing quite significantly with Solid 2 and the agent actually still up. Um, made me sort of like look at, okay, what where is this potentially going? It's like, okay, probably until someone really fundamentally restructures this, React might actually continue eating the world. So why am I fighting this? Um, so it's it's pretty as simple as that, which is like when I myself still wrote
23:09code, I loved solid. Now that the Asian is writing code, seemingly it's good enough at sufferings for React. So do I really care? [laughter] Yeah, that that's that's a fair position. Yeah. Um I'm curious like does does the agent not met up mess up React code? Uh a lot less I think a lot less and and and and I think primarily just because probably someone actually massively
23:39trained it specifically to work around or or like to so my my suspicion is that one of the things like look this is sort of pure guess work. 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 in a training run is sort of like linting like basically like your agent probably doesn't succeed if it fails to lint. So it sort of steers away from shitty patterns that humans actually do. So I noticed in general like good present
24:08state 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 from bad patterns and my my suspicion is that they intentionally trained this. I don't think it's an an accident because like in general there's so much shitty React code out there. Um [laughter] 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.
24:37Yeah. The the closest thing I have to inside knowledge on this, I had just like a one round interview for um X AI and for a role where they're basically looking for someone to come in and find when give or 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
25:06are you actually going to hire those people to solve the issues why you I know I know nothing about data labeling in the sense that I I I'm assuming like data lab just doesn't scale very well and it's probably not very fun but 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
25:35problem 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 like bad React just just as a result.
25:49[snorts] Yeah. or like using the React compiler which I don't know how much that but I don't know if like does it exist like [laughter] this is this is like the the never ending story of like um I don't know does it exist at this point I I don't even know what like you have to mention this this is sort of my my thing here I loved React when it came out originate Century when we started Sentry I remember like David still had the the Sentry next branch at the time was still Angular I was like dude no Angular in my
26:18life [laughter] so or React But it was like react with create element. Uh there were no class-based components like it was like the early on like pre hook everything right. [snorts] Um and sort of react took a life on its own and I it did become better in many ways but also became worse in other ways. Um and I eventually stopped writing react code at century and whenever I did anything I did solid. So I don't even know if the real compiler exists right now even though now I have a lot of real code because I never look at it. I have no
26:47idea is the real compiler real like is it is it a thing now?
26:51This is how much it is. And I think it's also been re rewritten in Rust at this point. So it's uh you you'll never do that unless it's real [laughter] when you're talking about writing React, are we talking ReactJS proper? Are you using any meta frameworks?
27:11Look, so the the the scope of that conversation initially was generative UI where it's like how do you create and and I think like when we talk about generative UI um we don't really know what we want but we have sort of some some nice to have kind of elements and one of which is in a world where software should emerge and it should emerge um
27:40for a non non-engineer then sometimes that non-engineer might create an artifact that should stick around right like they have created a thing now now obviously I can use another agent to sort of like modernize it as like change but um state management and like hooking up for this and like data migration everything continues to be horrible even for software engineers so like what's the chance that a non-s software engineer is going to get this right so what we're looking for is stability like what's the likelihood that the ecosystem doesn't
28:10change and that's was like if saw the two 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? So the assumption was like, okay, there has to be a little bit of both JavaScript and sort of JSX
28:38and and like stuff to create this UI, but then you should be able to freeze it down into some sort of reusable component that the sort of agent sort of manipulates and does stuff together with, right? [snorts] So um do I use any component types here?
28:52Like 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 we have two folks at at Arendelle that are writing reusable component libraries for these to work and they're mostly based on design tokens and very basic sort of no tailwind um like like state-of-the-art but like specifically targeted react right now. Um we will see where this goes. I don't know. there's a good chance that like maybe three months from
29:21now the models are so good that we're all like you know what the best use of our to spend right now is to build the future of UI [snorts] 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 and the
29:51answer to me seems like no still shitty. [laughter] So [snorts] um I don't know. Um yeah I don't know. It's I I don't think we're happy with it. It's just it's a democratic choice probably.
30:04Yeah. I think web components is a different story. I think every three or four years someone gets optimistic about web components tries it out and realizes that no it's there we [clears throat] go. you you said web component sub [laughter]
30:21uh yeah um look I I think like in 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 the web component what they want but um all of this technology that we have predates in many ways um sort of the tradeoffs that we want to do for agents. And I think like for me like working on Pyural was
30:51was 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 and the trade-off I made there is like make it as easy as possible for human developer to construct durable workflows.
31:10um terrible trade-off in the world of world of AI because like I basically I made it more br like I made it there was implicit stuff in there like implicit checkpointing replayability stuff like this sucks I mean it always sucked for a human tool but like the benefit for the human was less code to write and and so like with pyuro for instance we said like okay it now that the agent is writing it let's do explicit right like the agent can name the checkpoints it can version it can deal with all of And
31:39it's it's going to be easier for the agent to just write the damn thing out than to be um like having to deal with like implicit assumptions that might not even be trained into the damn thing. And like this is sort of the I think like the trade-offs that all these UI frameworks did including React if you want to call it UI framework and Tailwind in particular were really for a human. They were not like now with with like what a model probably wants you would make very different trade-offs. So
32:08I think maybe there is sort of the solid for agents that really needs to be built. [snorts] Um but I don't know.
32:16Yeah. No, I I totally agree with that and I feel like uh the direct the direction for solid 2.0 um like uh once obviously once AI got popular like we [laughter] 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
32:45like a good direction for like solid for agents. Um so uh uh I mean I guess the main 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. 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 is this actually works better for agents.
33:14Um, so I think I I I want to go back to the earlier point you brought up about like React is very lintable. Um, so obviously solid has had like ESLint.
33:22I don't know if it's lintable. It just happens to have a lint I think. Right.
33:26So [laughter] how do you define like lintable? What's the difference for me? Um, I mean, I think React sets like I I really don't want to on React, but I think React sets a pretty low bar in a way because its core design
33:48[clears throat] its core design doesn't make a ton of sense in a way because you're constantly splitting up like you're 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 because like you're basically re-evaluating
34:17those 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're you're fight 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 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
34:47more sense. [snorts] Um so I I don't think the goal for making it great for an agent is to make it lintable. I think that what makes it great for an agent is if like if inherently you can screw up, right? And I'm not saying like this has to be like typed to to the extreme extent of which [snorts] um I think a lot of people see the solution for these problems in types. Uh but I think like a good intrinsic data model makes it much harder for an agent to mess up. Um I think a lot of it has to do with locality. If you only need to
35:16read the component on its own and you understand most of its state and you don't have to pull in the whole rest of the codebase, it's also harder for the agent to mess up. [snorts] Um, 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. 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 not in a crazy amount of sense but like in a
35:44sense of like people want to build durable UI. they want to put it into something MCP app or whatever over time [snorts] 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 [clears throat and snorts] but then maybe actually this is all wrong and we should be doing declarative UI with JSON more. I really don't know.
36:09It's hard to say. Um [snorts] I I think it's very hard to predict right now what's what's needed here. But we have some general ideas of like what works better in LM, what works less well. And yeah.
36:24Yeah. [snorts] Uh yeah. In terms of like should we just do declarative like JSON constructs for UI or should we let them like write UI like component logic? I' I've gone back and forth between the two of them a lot. Um I think my my thought on at less 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
36:51like 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. Uh so it's like static JSON it's good for like one-time UIs. Uh but if you want like UIs that's like once you write them they just like update automatically update with data. Uh you eventually have to move to the other end. Um [snorts] otherwise you like
37:18invent a whole new DSL like they um like retool and stuff. Um but I think this is actually an interesting situation as well now because like you have people like Toby who are like okay it's the death of web apps. uh we're going to do native now, right? And um this will then automatically put us back in the situation where we were a couple of years ago where um 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
37:48have the agent solving this problem but a lot of these um like cruddy kind of experiences uh they really need stayed in both places 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 set a lot of the state is actually held um in the UI and sort of replicates down to the server and then you you naturally end up with like some sort of architectural requirement
38:17where like something deals with this and that might not be the UI system maybe it's just like something like tense the query or like whatever like like this thing um [clears throat] but it's so dependent on the UI so if you want to change how the UI works or a sudden your state on the server changes. I mean, this is this is the biggest problem with like the React server actions kind of stuff. It's like it it messes up this it it it assumes that you can just like collapse them down into like one massive large
38:46concoction, but then migration problems and like view shift and like hydration errors that never were a problem in a in a world before.
38:53[snorts] And so I 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.
39:03It'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 this 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 um I don't know particularly if then you have like generative UI that know should it show up in like the iOS app and the Android app and like I don't know if Windows still exists.
39:33[snorts] Yeah, I I I think I can go and go a whole lot talking about like the native versus uh like the death of web or like for crossplatform stuff. Um but I think going back to the the vint uh topic. I think that was an I I really enjoyed hearing your take for there and not just because you were sitting on React, but um it does make sense that if when you bring like a different language uh like
40:03React into a host language that isn't that doesn't like fully match it, you have to you're kind of like forced to put a lot of lint rules uh to make sure like you don't gun yourself. Uh I 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 uh in the sense but it's it's still like a slightly different language from
40:33regular JavaScript because it is to transpile the whole thing um the the transpilation is more for the JSX um like the the only thing that gets transpiled is like JSX turns gets turned into like effect nodes. But what I'm think what I'm thinking more about is like dstructuring props or readings reading like signals inside component bodies rather than like inside memo. Like these are some things that are helpful for like to place a llinter in.
41:02And uh uh it's it's it's definitely like it's much smaller surface area than React that you have to lint, but there's still like that little bit of area. Um, 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 they shouldn't they're not supposed to. Um, which kind
41:31of like either breaks reactivity or like makes react like makes things like over render or overrun sometimes. Usually it just kind of breaks reactivity. Um, yeah. The main thing I notic is like my input box all of a sudden loses focus [laughter] the classic case.
41:49Um, yeah, definitely.
41:51I mean, I had the same argument with the with the with the effect people just recently like [snorts] like effect is also is a cool system, but it's like held back by TypeScript. Like I much rather I want them to like show me what an effectful TypeScript looks like rather than this sort of other mess that we're looking at. Um, [snorts] 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
42:21like well we really should be doing JavaScript differently. Maybe we should consider I don't know effect UI script. I don't know. Um 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.
42:44Yeah, I think so. Someone tried that uh last decade and called it Elm.
42:50Yeah, but I think Elm mostly died because of um yeah, other reasons. [laughter] I don't know how to say it politically correctly, but I think like Elm was held back by um yeah, by uh project leadership.
43:09Interesting. We're going to have to not dig into that, but I'd 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?
43:22Have you looked into TSR TSRX at all by Danov?
43:27No, absolutely not. [laughter] I'm assuming I know what it is, but I have no idea. I'll Google it now. Um, yeah, it's it's an attempt.
43:36No, sorry. I did I did look I saw this.
43:38Yeah. Yeah. I someone showed me in a discussion that I Yeah, I was part of [snorts] um I saw you want to first give like what is what is TSRX high level and then we can discuss it real quickly. [snorts] Um, so the best way I understand TSRX is that it's a it's kind of like a subset of JSX or it's like a better JSX that um um [snorts] is more welld designigned for like reactive frameworks or frameworks that like kind of track state
44:06or have control flow built into the JSX or into like the UI layer. Um so it has uh uh there's like a lot of uh syntax ergonomics uh that uh that it improves on compared to JSX. I have not personally like uh use TSRX much myself.
44:25Uh I know Ryan has looked into it. there is like a I mean I think the the main the main part basically is like if uh GSX as it was built 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 tenorary 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
44:52ugly looking for and and like show and hide and whatever Right. I think like that's the that's the core of of what they wanted to fix, I think. [snorts] Yeah. Uh and to be honest, that should have been fixed for React, too. Like that's also dumb in React. It's just like it worked good enough. That's sort of like a shitty solution sort of standardized.
45:16Yeah, the turnary and the map. I think any like uh anything that tries to make list rendering more performant eventually ends up like adding that four component. uh back. Um yeah, so solid just kind of like try tries to do it from the start. Um [snorts] but it's just a question of syntax, right? Like there could have been from the start there could have been that in there and I I think like uh maybe I misremember this, but I
45:45thought he for instance had that still. Uh maybe I misremember maybe it was something else.
45:50Sorry, what heck? hack the PHP where like GSX I think I think I maybe I misremember I thought they had like a conditional um uh not conditional like a like a loop maybe the chat can tell me off um [snorts] we do have a question from Ryan uh what you think about compiler ahead for structuring versus runtime enforced
46:19see a lot of focus on syntax go guide agents But what if your whole app is observable?
46:25Yes. So this was like this was one of my tweets that kind of led to this discussion where I was uh uh I think my tweet was basically like what if we tried to bribe Armen with very rich obser like runtime observability tools.
46:40[laughter] Uh it's a good question. [snorts] Um, I think honestly at the end of the day it's like hard to say right now because like in isolation we don't really know how these things are going to behave. And [snorts] I think one of the problems with like solving problems with runtime um with runtime information is that the code needs to run for you to get that information.
47:08So that seems just inherently worse even if it's super great, right? like I I much rather prefer not having to run the code to get like sort of a good understanding of it. Um, and I think one of the failure cases that we see a lot right now is uh 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
47:38anyways. Um, 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. Um, particular with JavaScript which is dog slow anyways.
47:54Um, so I I don't know if like I worked for observability company, right? So I should be all all observable. But um I just I I mean I 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 hate that the compiler is slow but I think it's it's still a
48:22great great feature that it [snorts] Yeah.
48:27Yeah. Yeah, that that that makes sense.
48:29It's definitely uh yeah, runtime diagnosis can certainly [snorts] 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 uh 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
48:58tests 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. Uh, the other side to that is like the runtime will will uh often catch issues that the compiler simply cannot. Um, because the first thing is that the runtime can see the entire app. The compiler usually sees like one file at a time. Um, so it can't really see like through the through your entire project. Uh, or if
49:27you do build that sort of compile like Rust does kind of I guess see through the entire project. Rust doesn't compile like one single file at a time. I'm not fully sure about that.
49:37I I don't think that matters that much.
49:38I think it's just a question of like like as an example for instance um I think a lot of the failure cases right now where uh typescript does not catch something is just this casting to unknown and then some type right there's a and and it is in largely is happening because like what a lot of typescript code does so one of the big difference I think like in in terms of like how reliable rust code is to a javascript code is is
50:08that in Rust you cannot just take a bunch of bytes from the network and then say like pretend that this is chasing off the right structure right so most serialization libraries in rust as a because they have to stash the values into very specific fields on a strct 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 to stick it in the strct in the first place most getting
50:38bytes 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
51:06and in particular like 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 it shows up another process and it's all messy. [snorts] 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 isn't
51:35supported 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 and the other thing is like you can and Asians 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 hm 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
52:04can run note without type checking and that is the common way even or like a very common way for the agent to run it um is 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 like there's no way you can bypass the type checker yeah that makes sense um but what I'm hearing so uh so so far is that compile time checks are not enough you need to
52:32actually check things at runtime itself.
52:34So the 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. Is that a fair uh way to I mean I think like I think the way is
53:04like there are certain class of problems that you can catch up in compile time and I think they should be caught there.
53:09All the logic bucks 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 if rust for instance you can do um uh I forgot what the pattern is called where you basically express um on the type system the state in which the system is. So you can like I think called type state which
53:38is basically just a generic parameter. So you can express a lot of your logic in it and you can but like rasp doesn't have a fine types or linear type. So there's still a lot of situations where like you can't express it. Um, so I don't think you can ever get rid of or should get rid of um like runtime enforcement.
53:56Um, and you we probably need way better integration of observability. I mean, one thing that I learned essentially and I think it's probably not very surprising is that people hate uh 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. And um a language that would pay more attention to the failure path either by forcing you to use re result types of
54:24sorts or by having really really great observability into the error. Um 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 [snorts] 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. Um so like but
54:52it's just like I absolutely hate the fact that async locals exist on node but they're still not in the browser. 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 um like observability where you need to follow the logical flow of execution through a promise chain. And with asynch there's not even monkey patch that's going to fix that for you. So like this is just so bad in JavaScript that I kind of like
55:22we need to fix that language to solve the runtime reporting really well or we need to do stuff like effect where we stop using weight entirely because damn doesn't work. Um yeah there there is a proposal for the browser. I don't know if it's ever going to get implemented. And yeah, for I think it's like 10 years old at this point.
55:45Yeah, I'm guessing. Actually, I don't know. My Ryan might know how old it is.
55:50Yeah, [clears throat] now both React and Solid have APIs that they wish they didn't and they only exist because async context exist and uh it leads to a lot of foot guns actually and if async context was just there then the world wouldn't be a nicer place. um the 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. Uh
56:19Typescript is probably not going to move because they're trying very hard to rewrite it without losing uh compatibility, which is nearly an impossible task. Um so I feel like the way the the approach that uh 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 um we should be able to just
56:49take the improvements that we have and uh like kind of trickle them down so that everyone gets the much better experience. Um but if we are kind of like logged into uh whatever the current version of JavaScript that runs in the browser uh and whatever version of TypeScript we're using today uh what's the best uh like what's the best possible thing that we can do uh to catch the most issues to give agents the best feedback to make sure they don't
57:17run into those issues uh because agents are going to run into right I'm not so pessimistic that you can't make JavaScript better And in parts it's because like the actual core language is pretty good, right?
57:29Um and and I think that we have a history of transpilation in JavaScript.
57:38This goes back to like coffees script earlier, right? Uh or or like roll up and I don't know what all these things were called. So like it the 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. I mean they're sort of there now like the syntax is reserved but like the type eraser process of TypeScript and flow was always the right thing because it meant that the core language doesn't
58:06need to deal with any of this nonsense and you do it in a in a step before.
58:10Now, now we're living in a world where we're doing this blankable TypeScript um where like the the sort of the creativity in the transpolation process is sort of like we don't want that anymore or at least some people don't want it anymore. [snorts] Um but like it is a community of transpolation and given that it is a community of translation that most just needs a target JavaScript underneath.
58:33modern JavaScript is a pretty interesting compilation target one because Wom for all the that it has has a spending. So you can actually implement um within WOM you can have something like a blocking SIS call 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 uh of what you could do within that runtime environment and on the other hand you have async generators
59:02which are an interesting compilation target like there's the syntax is but if the language that you're writing actually like just happens to transpile down to async generators. Um, then you're not forced to do this async await stuff. Um, which allows you certain things that async away doesn't. Um, so I wouldn't dismiss this entirely just because like I'm pretty sure we'll see it
59:31anyways. 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 two months worth of like 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 translation part. The fixing JavaScript part I think is trickier but I [snorts] don't think you have to fix everything for that. there like the
1:00:00async local stuff is also like a massive foot gun in terms of memory and like leakage and everything else. So it might even be better to just transpire with an explicit object passing or some some some other sort of out of out of bounds mechanism.
1:00:14[snorts] 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 [clears throat] 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
1:00:43tension there? Do you think eventually the models won't need so much training data to be able to perform well with a new abstraction?
1:00:53I don't know. It's a I it's an open question. Like I'm always surprised how good it is at sik despite that sik basically is the most unstable language ever right like every release is completely different.
1:01:05Um and yet they're really good at writing sik. Um on the other hand I don't know there's ample training data for [snorts] what's a good example.
1:01:21Yeah, it also I think like one of the this is less of a failure case now, but like I found is like I know that um I don't know even even earlier this year I still had a conversation with some CPI maintainers. I 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 CPY compiler sucks because it doesn't want to read the code as it exists right now. it makes assumptions
1:01:51about the code because like it knows what Python is. So if you change Python then sort of like like you you want it to actually know less about Python. Um [snorts] so I don't think it's so clearcut 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 yeah. [snorts] And then another thing
1:02:19related to this that I think about a lot and 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 going to like slow down the new models cuz he wrote them for the old models but I'm kind of the listening to a lot of this conversation is like a lot of the issues that we're hitting is like if you just have like a well concise written rule that and it's written in a way the
1:02:48agent understands it like it will be able to get around those issues even if it won't do it natively. So I think there's there is a potential space here where I have a little bit of data point here right so and this is like not not to like hammer down a 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 pyurable is that if you want to have the agent build an extension or you want to build an agent have built on top of
1:03:17that they don't have to read that much code pyural is tiny and so it is easy enough for agent to throw the entirety of Pyural into the context and [snorts] fully understand what it's supposed to be doing. Um, so if 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 they sort of they're great expert programmers that understands
1:03:46every single API, but like they're pretty good, right? But if your whole complexity of this project is like two million lines of code, [snorts] 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.
1:04:10Uh 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 I think if you have a great codebase 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
1:04:38of code and it's 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 then it will build on it [snorts] right it's like I think like the inherent complexity of the problem is is what pushes you one way or the other so I I 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 um that there
1:05:06seems to like we would not be able to use these coding agents for own software that it has never seen if it was true that it can only program what is sort of on the on the on the training trajectory. [snorts] Yeah, that's what I was always saying like two or three years ago when this conversation was kind of a lock. So like this is a big thing people used to talk about not so much these days.
1:05:28Yeah, I was just saying it's funny because this was my argument against JS but that's probably for another time. [laughter] Um but that's different. I think like this is the important part to understand like the code that it writes versus like the way it orchestrate the agent those are they are they're going down different trajectories.
1:05:49Got it. Okay. Um yeah I think I think in my uh in in my experience with agents writing solid uh they they used to get confused quite a uh quite a bit in like the pre uh opus 4.4. 4.5 days. Um I think in the last few months I haven't really seen that happen much. Um [snorts] I I've also been like having
1:06:16them write Solid 2 a decent bit and uh usually they can look at like browser logs and uh like logs from test and uh get like a pretty good idea of what they're doing wrong based on the runtime diagnostics. Um I'm also in currently in the process of like writing a compiler for for solid. Um not not like a a core project right now but uh kind of like go going into this logical extent of uh ho
1:06:44how much can we tell about the code uh before we even run it like kind of what you were saying earlier that uh sometimes you don't want to run the code to see what's wrong with it. You want to be able to see uh detect as many issues as you can before you run it. Um, obviously that means you're going to miss some issues. Um, but it's good that Solid will catch them at runtime if the compiler happens to miss them.
1:07:07Obviously, it's it's better if the compiler all like doesn't even let that happen. Um, but I I also want to make sure I don't like my earlier comment about uh like JavaScript is not going to move or like like it does. It's not a pessimistic argument that uh I am not I'm not I'm not like I I don't think things will move. It's more of like a I guess I I I I wanted to frame it as more pragmatic that I don't see anything moving right now. There's I I I almost certainly expect things to improve over
1:07:37time like uh hell if in last few weeks AWS actually release 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. Um, I mean I think what the bullish thing for me would be and I I'm expecting it is like when when when Andrea started working on this um Ladybird browser, it was like this is ambitious, but we need it. Like I don't know if he's
1:08:06going to go anywhere, but we need competition to uh Chrome and WebKit.
1:08:15But 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 like I like I'm not I'm not one of those people like everything is being written in Rust for security reasons but like this is these are humongous code bases and they have been written by humans with all their failures and
1:08:42everything 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 like now is the moment to build other things, right? Like build build another browser.
1:09:03Um and like I expect that to happen, right? I expect there to be at least one other browser engine. now that sort of looks at this um like how would you build a browser engine in the year 2026 with coding agent and everything and so I remember when Firefox displaced uh IE6 right there that was a long time ago and there was nothing for such a long time and then it was like instant right so it's like I mean it wasn't instant because like I never completely went
1:09:32away but like but it went from like impossible that internet explorer would be displaced to it's actually happening. [snorts] Um, and I think that could be one of those things that that will start to to bring some movement into it. [snorts] Um, 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.
1:10:02Yeah, for sure. Uh do you do you expect to still be [snorts] like imagine if we get a like a much nicer browser and a better runtime uh for like browser side scripting? Uh do you still imagine to be using React or would there be like uh 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?
1:10:29I mean I probably will 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 pil 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 these 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 they
1:10:58actually do there and it's very rare that uses react right Like I've I I have the agent build so many like little let's call them applets or whatever I want to call them. Like here's a thing that we're actually doing, but also we need a bunch of like extra HTML thing on the side to debug it 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. Um and yet it sort of seemly works. And so if we just assume that there will be a lot
1:11:28of 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. Um, so if nothing else, that's probably the most likeliest outcome is that like React will lose out of to vanilla JavaScript just because the agent just doesn't want to deal with it. [snorts]
1:11:57Okay. So [clears throat] but but does that so the 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 have building your own framework in 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 bu building little applet without frameworks that's fine but if you start moving the if you start
1:12:26getting them to build those out into like bigger apps then the agent will just invent its own framework inside the app uh if it doesn't end up using one is that something exactly what it's doing [laughter] okay right so so in that yeah go ahead I think like isn't that exactly like how Google and everything else works like like my experience of hiring people out of Google has been like um there's this world that everybody of us is in where like you use React use all
1:12:55of this and then there's a Google world where like you solve all the problems yourself and and and like if you then transplant it in the world where where that's not the case, you're like confused for like six months. And and and [snorts] I think like an agent basically becomes mini Google very quickly, whereas like it's it's sort of like it builds its own little world and like we're kind of intentionally forcing it down this path anyways very often. like I know that I
1:13:25do this but I've seen so many other people do this 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 one 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
1:13:55problems with it, right? Because like for instance like now how the hell are you going to put like re like sent for instance would live very hard in a world where like everything is bespoke because all of a sudden like in order for sentry to work in this you're going to like hey I don't know how to use centry here but agent please figure this out right because like sentry could no longer at that point provide an like a generic integration this because everything has its own framework so like everything that sort of needs to fit together on like [snorts] I know the sort of
1:14:24interfaces will have a very hard time if there no standardized interfaces. Um but with agents do we I don't know is it feel everything feels different. Maybe it's [snorts] maybe it will not change that much. I just like I'm observing it being absolutely fine without the framework.
1:14:41Yeah. 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 big 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 it they are doing the work of maintaining these applications or or like and even the framework that they have built. So if
1:15:11the 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 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
1:15:40React or Solid But uh it might also I think it could also improve your experience though, right? Because like if like if if you don't have an opinion at all like okay if you make it good for yourself it'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 be also do that um and and and then maybe you do give up a little bit of token efficiency
1:16:09to do this extra things make it understandable for you but like in in many ways we are the bottleneck and I understand like there is people that like all hands off just do everything on your own. But um I haven't managed to bridge that yet. So I'm actually willing to forgo 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 but the the thing with this this behavior that
1:16:38we're seeing from the agents right now is that they're actually everywhere all over the place. 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?
1:16:52Like 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 now I'm keep doing that.
1:17:06And this is this is all so bizarre because it's like it it's writing code to write code and [snorts] and it's it's moving it into a completely new environment that I to that degree I don't think we have seen it before.
1:17:20[snorts] Got it. Okay, cool. We should hit just a couple questions in the chat. We have two, but they're they're related. Basically, [clears throat] like what's your kind of daily setup? Are you running in the terminal? Are you using a VPS or orchestrator?
1:17:35in this kind similarly like what's your preferred way to build you know yeah a huge difference between me working on pi and me working on side projects right pi does not operate a factory um um I haven't figured out at all by the way how to use sub aents but I do use parallel pies to do investigations and open tickets um in pi we're super conservative um on my side
1:18:02projects I'm like nuts like I have a I have a game that I'm building with my kids. Um I like there's all kinds of like side project like I'm trying to figure out like where does it go, right? And so like that the stakes are low. I don't really care. I want to see where it's going. [snorts] 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
1:18:29of checkouts, run a bunch of pies one like I going back and forth. I'll just 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 and this is like an um a reflection of
1:18:56the fact that I don't sleep as much as I probably should, right? And so I'm actually like I'm like like a lot of people and 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.
1:19:17So, 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.
1:19:30But yeah, it's like I have this like everyone I have to say absolutely I need more of that and then I feel like actually that was a like a horrible waste of tokens. So like did all of the things I'm doing did this actually result in anything? and I sort of like forcing myself way back to like, okay, let's just focus on what's important and and then actually [snorts] I don't need all of this. So, it's a mix of both. Um, it's it's exciting, but also I think kind of unhealthy at the same time. And
1:19:58I don't know myself how to how to deal with this yet.
1:20:03Yeah. Know, I think agents can feed into lots and lots of like developers neurosis and can create and exacerbate mental health issues and all and all sorts of stuff. That's all he I mean I have I I I will keep this telling the story over and over but like I um these models have been trained on Python initially right so a lot of people wrote stuff into CHBT and they got the flask app and so I've been on the receiving
1:20:31side of emails from people about their kind of stuff for like three 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?
1:20:53Or like what they are writing in there is is like there's clearly something wrong. [snorts] Um and I've never seen that in both for AI times. Like I've like I only got nice emails from people like oh thank you for your open source software and I'm getting all kinds of stuff that is like like partially really disturbing. Um, and it's because like somehow they had a conversation with the machine and they figured out like they should talk to me.
1:21:14Um, like they because it behaves so similar to a human and sort of is so unsettling. I think it it like if something is like your borderline that can tip you over and that's not healthy.
1:21:29staying 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 can actually say from experience [laughter] yeah if if you're getting those emails I don't want to imagine what the react team is getting
1:21:54uh cool okay so the conclusion is that uh graph engineering loop engineering are all like performative.
1:22:00No, I think like there people that do it really well, but I think like a lot of tokens are being and and I think like this 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 in a particular problem is good value for money. And once you're not in a token subity kind of situation or not a flat fee kind of situation,
1:22:30like the world is a different one. [laughter] And I keep telling the story, I paid 25 bucks 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. And I would never have spent $3,000 on that [laughter] if I had to pay that, right? So um yeah is everything is out there right now makes sense. Yeah, I think if I think
1:23:01I'm hoping to make the case soon that agent your your agents spending tokens on building bespoke frameworks for your app should be sim should be counted similarly as like don't do that just have it pick an existing one but we've still we've still yet to make like a good case for it and uh yeah I definitely this has been a very helpful conversation uh I I know like Ryan said he had been listening quietly I'm sure he has a lot of ideas as Well, after
1:23:30this um because yeah, I think the TLDDR is that my conclusion so far from this conversation is that there are like kind of the the issues that at least you kind of brought up for why you prefer React.
1:23:44I feel like we have a lot of those have been addressed, but we haven't done a good enough job talking about them. So, um yeah, that we uh definitely I mean I I will say like generative UI I'm pretty sure is 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.
1:24:07Maybe you can be part of that solution.
1:24:12Yes, that generative UI has kind of like definitely contributed to like why I'm working on a compiler right now. Um obviously I 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 cloud code
1:24:39mods do something. Uh I don't think they are just like JSON descriptions. I think in the in like cloud code they're actually like writing UI components uh that do do things but I haven't looked into that too much. Um, yeah. So, uh, it's easier if UI doesn't need to be persisted. I think like if you have the desire that is like things that should have be have a shelf life of like months,
1:25:09um, then you have different trade-offs. And if it's just like, hey, I need a little, I don't know, site widget to ask me about my net promoter score for the session or something.
1:25:19Yeah, definitely. those are like the two different categories of generative UI which will have like two different ways of uh like building and authoring them. Um okay. Uh yeah, this has been pretty helpful. Uh I uh is there anything uh you'd like to shout out that you haven't already? Um no, I've been waffling enough.
1:25:43[laughter] Awesome. Well, I just want to say thank you for all your open source work like throughout at this point decades. um lots of stuff that's been very very impactful and it's great that you're you dove straight into AI and have been like a really big part having been involved in open source for so long cuz that's really important and you know the whole open source dead not dead stuff like we're not going to get into that conversation but like you know you're you're a good example of like that's
1:26:10obviously not true you know so um yeah and uh we'll we'll probably let you go um since you're up late but uh we'll love to just keep the conversation going um I'm following you on the Twitter now. And yeah, uh definitely really happy to to have you here.
1:26:30All 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 going to be back tomorrow with um Kevin and who else? Dev uh Kevin and Ricardo from Tanstack team. So, we're going to be talking about handstack, table, pacer, hotkeys, and all the fun stuff there.
1:26:51Awesome. 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.