0:00I think I have to out myself.
0:02In the past 15 years, I have never done code review for somebody else's code.
0:09And I always push to main because fuck that.
0:10And he was like: "This is amazing." And I was like: "This is scary."
0:14I've taken down prod probably hundreds of times over the past 14 years.
0:19When shit fucks up, you create breathing room where you don't have to be stressed.
0:23Nobody's going to write the next React.
0:25Nobody's going to write the next TypeScript, Rust, whatever.
0:28The PR is a slop and the issue is a slop.
0:31The only way to deal with the slop is to slop back.
0:37Why in the fuck would I spend time be a person looking over your shoulders like, "Yeah, I don't like these things.
0:42There's a missing curly here or whatever." Don't fucking care.
0:46GitHub is just like a slop highway now.
0:48I liked the idea, I just couldn't make it work.
0:52I write the best TypeScript.
0:53I personally also want to get rid of the dependency on the big labs.
0:58Love you guys, but also fuck you.
1:01I don't feel the pain anymore.
1:04Welcome to The Next Token.
1:06Today is Friday, October 30th, 2026.
1:10I work at Cloudflare.
1:11They sponsor the show.
1:13And this is a podcast about three software engineers who don't have the time or energy to be hosting a podcast.
1:19Sunil decided to abandon us this week and is on vacation, so it's technically two software engineers.
1:31Today, we have two guests from Earendil.
1:33Armin, who is famously the creator of Flask, and spent 10 years at Sentry and founded Earendil, and also Mario, creator of libGDX and Pi, who joined Earendil this year.
1:46And they're here to talk about whether software is dead, robotic dogs, what Earendil is building now, and the stuff you can't get from the Pi launch post.
1:56Welcome, Armin and Mario.
1:58Thank you for having us.
1:59Thanks for having us.
2:00The first thing that I want to jump into is, Mario, you tweeted software is dead, which is great.
2:13I feel like there's a bit of that going around.
2:16The day that I saw that, Dillon, I was thinking to myself: "Damn." I was trying someone's browser, and then I wanted my own version of it, and I just told Claude: "Make me this browser." And then I woke up to a browser, and I was like: "Oh, okay."
2:33Famously, a great time in history to be creating your own browser.
2:38It's just on top of Very secure Chromium, but I don't know, it's a weird time.
2:43Do you want to walk us through that one?
2:46Yeah, basically, I was just rage baiting, so I get enough clicks and engagement, so I get X payouts, which I can then Oh, yeah funnel into our association for Ukrainian refugees.
2:56That worked out brilliantly.
2:58So now I'm here, and I wonder how I can get more money out of this screen here, but yeah.
3:06Actually, it's been a thing since last year, basically, since April last year when we all started to get our first AI psychosis.
3:13It was pretty obvious that things are going to change, not just in terms of how my workflow looks like.
3:19I couldn't give a shit about that because I'm old and tired.
3:23I've been programming for 30 years, so any removal of drudgery is actually awesome for me.
3:28But I also like the intellectual challenge, and I like the exchange with other people about those intellectual challenges, and I think this is going away too, and that makes me sad.
3:38And that's how software is dead, while it's simultaneously not dead.
3:42At least that's the TLDR.
3:44So you did turn around and say JK.
3:48What prompted the JK?
3:52Just because I'm a funny guy, an immensely funny guy.
3:59Honestly, I just thought it would be funny.
4:01We have a German term called Schleudertrauma, and it's something I want to induce in people.
4:06It's basically what you get in your neck if you have a car crash, like you fall back like that.
4:11Yeah, like a kink in your neck?
4:14And so Schleudertrauma is kind of like something is shaking you left and right, and you don't know what the fuck's going on.
4:19And so yeah, that was one of the intuitions behind that.
4:22No, but I think a lot of young people are really, really concerned what the fuck they're going to do.
4:28And I don't have a good answer for them.
4:30And writing software is dead from an account that has a bit of a following might upset a lot of young people, especially.
4:37So the joke was basically me telling them, "No, no, it's all good.
4:42All good, man." But I don't have a good answer for them.
4:44And actually, related to that, I think a lot of things that we've talked about and focused on this podcast in particular, like the change for people with what's happening.
4:55Just dealing with change in identity and dealing with, I have not been doing this 30 years.
5:02I've been doing it for almost 15, so half the time of you, but going through all this because I've been programming since I was 11.
5:10It's a very monumental change to even my day-to-day and identity.
5:15I am curious about, and we've talked about a bit, younger people and junior devs or new hires getting into the industry.
5:22I think this is one place where if I have any existential dread and uncertainty that I haven't worked through, it's this part.
5:32And I'm curious at Earendil, you guys have done some hiring and I don't know how many people work for you now, but do you have any staff that are on the more mid-level to junior side?
5:44And I'm curious how-- Obviously, you can't speak for them, but how do you perceive their experience of having onboarded onto a company in this time period being and also what have you guys done on your side to I guess, and make that easier.
6:06I really don't want to talk on behalf of Cristina here, but she did introduce herself on one of the talks I gave together with her as an AI native engineer which is basically a person that went in the industry after ChatGPT.
6:20And in fact, actually, as we see the path to juniors in the industry probably really, really negative, the juniors that actually manage to get in the industry, I think don't.
6:32It's more about the people that fail to get in the industry because right now the entire hiring situation sucks.
6:37The job market is really, really bad.
6:42But if you do manage to get into it, then it's actually fine.
6:45At least it seems like it's fine, because you have all this power and AI as a whole, I think, if you like it, then it's not terrible to work with it.
7:01I worry about it though, and particularly also because of what Mario mentioned earlier, which is the really enjoyable part of software engineering is actually engagement with other engineers trying to solve problems, the puzzling aspect.
7:14And we are all increasingly just to having this damn one-to-one conversation with whatever model we're using, and I hate it.
7:23It's so solitary, and it's so dumb and stupid.
7:26But yeah, I don't know.
7:28I try to go to Vienna every couple of weeks because I'm not leaving where the office is.
7:34Just so Armin and Cristina and David and everybody else in the office can stand around a blackboard or a whiteboard and draw silly squiggles.
7:42Not being productive, but just having the human touch.
7:48I've been doing remote for, I think 15 years now.
7:56And that was one of the changes that already took away a little bit of the human aspect.
8:00Although, that's manageable.
8:01I'm very comfortable in remote teams, let's put it that way.
8:04And I still manage to get the human juices out of such a setup.
8:10But with agents, it's just even that is gone now, where we would have talked about a stupid technical issue on Slack or Discord or wherever for an hour or two, or had a voice call.
8:23Nobody does that anymore.
8:25We just talk to the fucking agent and then we send the PR or we don't, and it's And it's because it's so much easier also.
8:31I think it's the worst one is, I think when we as a group individually like, "Oh, I have an idea." And then three go independently, research the same thing, come back more or less with the same answer because we all use Claude.
8:41Everybody's a meat proxy.
8:44"Here's what my agent said.
8:45Here's what my agent said." Well, okay.
8:48I can't recall if I had talked about it on one of the episodes or it was just me tweeting, but like you, Mario, I've been remote since the before times of COVID.
8:56I've been remote since 2016.
8:58And I've gotten very used to adapting to company cultures and being remote and injecting myself into company culture and I'm a yapper.
9:10And this year has been far more isolating than any previous experience I've ever had for the reasons you outline.
9:18And where I was going with that is my team on Artifacts earlier in the summer, we had a pretty bad incident where we took down our customers.
9:29We were on an incident call for six or seven hours.
9:34And despite the stress of an incident, it was also some of the most fun I've had this year because it was just the group of us together solving a problem for hours, and just the human part of that, I don't know, it was missing.
9:49And I think in the past week or two, a couple people at Cloudflare have been talking about what does the future of work look like?
10:01Because I don't think this isolated one- off person go off forever and be a meat proxy is...
10:09I don't think it's it.
10:10I also think this kind of plays into a conversation that we're planning on having later around code review and CI/CD and stuff.
10:17We've found, I think over the past couple of weeks, especially with Opus 5.5 coming out, that code review is becoming this thing where it is more like, "Hey, can you just have your agent look at my PR and if it has feedback, just tell me and I'll have my agent fix it." And it's just like Yeah what is the theater right here?
10:40Give me more tokens, basically.
10:44Some of the conversations I've been having is Justin Bennett put out a good response to something I said.
10:49I think he wrote a blog on this about what the future of work or software engineering or code review, I don't remember what it's about, but we can find the link and drop it in the show notes.
10:59But his premise was he sees a world where traditional code review is kind of dead.
11:04And he wants to either tie traces and sessions more into the review process.
11:13His premise was like, I want to see how this engineer was thinking and how the model pushed back and how they got to the decisions they got at, rather than maybe specifically, especially over time or extrapolating out into the future.
11:27It's less about the quality of the code and more about how did the human inject the ideas and steer it.
11:32And then he coupled that with it'd be great if we had multiplayer, multiple people working in the same session, which I think we don't want to spend a ton of time talking about, I guess, Pi Durable and Pi, because you guys have No you guys have been on the circuit talking all about that.
11:47For viewers who don't know what Pi and Pi Durable are, just go to YouTube and you'll find about 1,000 podcast episodes from these guys talking about it.
11:55But we have I've heard it runs on Cloudflare.
11:58It does run on Cloudflare.
12:00Or it can run on Cloudflare.
12:04But we have some people looking at basically that process of enabling multiple people working in a single session on Pi Durable and collaborating in that way.
12:16And I know the guys at OpenCode have joked about earlier in this summer about gang prompting in Slack with their OpenCode agent.
12:24I'm curious if you see the world going that way or if you're hopeful in that regard, or my question for actually all three of you would be, do you see more collaborative workflows kind of emerging out of this and maybe replacing some of the process we have become accustomed to over the years?
12:51The process we've become accustomed to being the one-on-one you and the agent and solitude and whatever.
12:57Yeah, basically, I suppose it has evolved maybe over the years isn't the best framing, but the current process of I'm going to work with my agent one-on-one, it's going to put up a PR, we're going to do a traditional PR review.
13:12I think out of necessity, we'll have to change because even just if you're a company that theoretically has a SOC 2 compliance, and I know that people are talking about you maybe don't need to review anymore, but realistically speaking, the standard mode of engineering will have to move somewhere else.
13:31What it's going to look like, I don't know.
13:32But it seems to me at least that we are holding onto some rituals, let's say, that are a little bit absurd at this point.
13:46And at least we always thought that multiplayer is a big part about it, but so far we haven't actually managed to really get sticky on multiplayer experiences.
13:59There's a lot of companies that are not even engineering-focused that have their Claudes or Codexes or whatever in their Slacks, and they mostly seem to like it.
14:08That sometimes is even productive.
14:11In the other company I'm involved in, we had mom since last November or so, and it's been a helpful thing.
14:20Everybody being able to chime in and talk to the same entity of sorts and give it things to do.
14:25But for the engineers themselves now, for the way-- So I think I have to out myself.
14:32In the past 15 years, I have never done code review of somebody else's code, and I always push to main because fuck that noise of PRs.
14:43I always found PR reviews to be mostly theater.
14:47In all the enterprise setups I had, it's the end of the day, you look through a bunch of PRs, it's like, "Yeah, sure.
14:55Oh, I don't like you?
14:56Okay, I've got to leave some stupid comment so you have more work." That was basically PR reviews or code reviews.
15:01I never found them really a good spend of time unless it's about knowledge transfer.
15:07But I'd rather have that knowledge transfer when working together with somebody, when pairing with somebody, when discussing designs and implementations with somebody than fucking reading 1,000 lines of code and figuring out what the fuck they wanted to do with this.
15:21So I was never a fan of that at all.
15:24I always think directly talking to the person or even doing pair programming is much better approach to that.
15:30So yes, fuck code reviews.
15:34I also think it's a matter of trust.
15:37I haven't worked in a big team in a very long time.
15:41And all the teams I've been on or worked with over the past years, everybody is somebody I can trust.
15:46If you take on something to work on, why in the fuck would I spend time on my end to kind of be a person looking over your shoulders like, "Yeah, I don't like this.
15:55There's a missing curly here," or whatever.
15:59You do your job, I do mine, and if there's some interaction, we talk.
16:03It's just much more efficient that way, and I think it also helps build team spirit if people can trust each other.
16:12But now we're going into the squishy part, so I stop here.
16:14We had this on the domains team, Dillon, I felt like, where I would get a PR from you, Ethan, or Elliot, and I'd just be like, "Okay, yep." Just the trust gets established, that it's like, "Okay, yeah, I know what you guys are doing and trust you guys to..." Anything super high level, I feel like would go through some kind of conversation beforehand, but for the day- to-day stuff, there was just a super high degree of trust where I was like, "Yeah, if there's a PR, it's probably correct."
16:42I actually really liked pull request reviews at Sentry, and the reason I liked them had very little to do with that I want people to have a friction in the whole thing, but because it basically level set everybody.
16:57So when you onboarded a new engineer who was a junior, he went through the same process as a senior person went.
17:02Whereas if you have a culture of everybody goes to main, then onboarding a junior, at least I found that really tricky.
17:11Even at Earendil, I find that a little bit sort of like-- I think the agent takes a lot of this away, so it's like the damage is lower now, but in a world where you needed a trust, you had to build a trust.
17:23So getting new people on, I found the pull request to be a very nice way of doing it, basically, because it's like you're all the same, at least in theory.
17:35But now I think it's just so different.
17:38And the other thing, actually, I wonder how many things we actually caught in pull requests, because Sentry still went down from bad migrations and mistakes we made.
17:47So it's not like there was a foolproof mechanism.
17:50But Armin still likes pull requests so much that I get one of these per week, and then the change set is like 600 files, 10,000 lines of code.
17:59And the PR comment says But the only PRs I make are "This is just a draft.
18:02What do you think of this?"
18:04The only PRs I make are where I actually want someone's input on, the rest goes straight to main.
18:11Yeah, but the things he wants input on are unreviewable.
18:16Honestly, that's the other problem.
18:18So actually, I wonder about this part a little bit.
18:20I used to hate pull requests that are over 200 lines of code.
18:24If something goes that long or 500 lines, somewhere there is a line where it's like, I don't want to deal with this.
18:30And now all the pull requests I'm making are thousands of lines because Yeah that's the only-- And actually, this is an idea.
18:37Have your agent help you read it or whatever, but like No, because I expect somebody on the team to be able to explain that idea in their own words to me so I don't have to read fucking 10,000 lines of code.
18:49That's the whole point of engineering.
18:50If you don't understand your system and your domain, it does.
18:53I don't need to look at the implementation.
18:55We all assume that Opus is doing a good job, but I need to know why the fuck we are doing it and how the fuck we are doing it, and what might be the foot guns that come out of it.
19:02And if you are unable to tell me that and ask me to ask my clanker to read your code to tell me all of that, then it's like Well, it does come with this why what am I even doing here?
19:10But I think the problem is that the pull requests have naturally become bigger because instead of saying, "Here's a little draft.
19:16I made a spike of, I don't know, 10% of the whole thing." It's like, no, actually, it's the whole thing.
19:28So, reflecting back while you guys were talking, and I think I've been very fortunate over the probably past five years of my career that the teams I've worked on have been very high-trust environments with very high agency people.
19:39And to Rhys's point, when we were working at Vercel on domains, there was a very high level of trust, and it was just like, yeah, I'm going to do a scan over, make sure there's nothing very obviously wrong here.
19:50And Vercel, I think to their credit, also had a very good culture of ship, do a blue-green rollout, and if something fails, just roll it back and we'll fix it quickly.
19:59And I think that helped enable that.
20:01But also, I think there is a good point to what Armin's saying.
20:05When I was consulting and helping, we would get hired into companies to help train up Java developers on TypeScript and React, and PR was the place where knowledge transfer and team culture transferred, I think.
20:23Expectation setting almost.
20:25It was also reflecting on companies I've been at before Cloudflare and Vercel.
20:31It was also the way I learned almost the personalities of the people on the teams around me and how to engage with them.
20:41Well, maybe that'll be a forcing function now that people have to talk to each other more directly, hopefully in the future.
20:47When you-- Did the personality learning happen in GitHub?
20:51Or did it happen in Slack?
20:55I guess it was more like I learned what people cared about as far as technical rigor.
21:02You would be able to figure out very quickly, oh, this person cares about end- to-end tests, or this person's just going to nit me on using a for loop over .map or .reduce.
21:15You just picked up those things over time, which I think the testing thing has more weight or water, but syntax nitting, I just do not-- I was always in the camp of I don't care.
21:29I'm never going to nit on syntax.
21:32When I was at Microsoft, I got a nit comment that one of my comments in the code was too long.
21:41And I had to go pull it and fix it so that way it wouldn't wrap text when the guy was reviewing the PR.
21:47But that kind of comes back to the initial thing.
21:51Does any of this matter anymore?
21:54And I totally agree that PR is a great way to figure out the non-verbalized technical, let's say, thinking of a person, because nobody would walk up to you and say, "I really like end-to-end tests." Or, "Please don't use for loops" or anything.
22:10You just see that as a small little comment over and over in a bunch of PRs, and you form your mental model of the person.
22:16But all of these processes, all of that stuff is now absolutely like nobody cares.
22:24Nobody fucking cares.
22:25I think we have the opportunity to get that, but amplified.
22:32I think I could learn a lot about a person by reading their agent traces and how they work and produce, work and get to I think we tried that, and then there was so much You tried that.
22:46Yeah, you didn't try it, but I initially asked even people at Earendil, this is already a year ago, to like, "Hey, put your Pi traces in the pull requests so we can figure out where we went wrong." But it's a lot of effort to actually read that.
22:59And as the speed is increasing, at one point it's like, okay, let's do some, I don't know, Jev analysis over all of our traces to learn something about us.
23:09That seems also silly.
23:12But I like the idea.
23:13I just couldn't make it work.
23:15I think I would maybe push back that I don't think the pull request surface is the place where I want to engage with traces.
23:23I would love to fork their session and then be able to ask questions in the fork of the session.
23:29Yeah, but I think that's what Armin That's what we did basically did, right?
23:32Oh, well, then I'm just wrong.
23:33Pulled on the session, brought up a Pi instance, and then interrogated it or looked at the transcript.
23:39For me, you send me a pull request, including your session, and if it's one from Armin, then I have 600 file changes, 10,000 lines of code, and a session that is like 300,000 transcript entry.
23:53No, I don't want to read the first thing.
23:54Why the fuck would I want to read the second thing?
23:56I learn so much more if I stand with him at the whiteboard and we just go through something that might not even be super relevant, but in the heat of the moment, we decided we have to argue about tabs versus spaces, basically.
24:08I learn so much more about his technical thinking and the things that are important to him from that than I do by reading a fucking transcript of an agent.
24:18But that's just me, old me.
24:20Sorry, one thing that really confused me a little bit is what is disappearing almost entirely is actually company engineering culture, where someone...
24:30In a lot of companies, someone at one point said, "Look, this is what we believe in.
24:34This is how we do it." And then through one way or another, that sort of permeates through the organization, never goes away.
24:43And that was the case even at Sentry, even though it didn't have the strongest one of those engineering cultures.
24:49And that went to also how you use a code style, or where do your comments, or how you define subsystems.
24:55And they're like really strong engineering ideas that you could say, "This is," I don't know, "this is Sentry code.
25:02This is Epic Games code.
25:04This is Splash Damage code." And you could tell it from the moment you step in the code base, what the people believed in, how they optimized it, what trade-offs they did.
25:13And now it comes out in whatever form Opus wants to do it.
25:16And But you can differentiate between Opus and GPT still.
25:21Opus has nice comments and line breaks, and Astra and concerts is just like, "Here's my code golf for today."
25:31Yeah, but I feel like that part of their culture goes away, and I think that is a little bit sad.
25:35I think Cloudflare's actually done a remarkably good job at preserving this in the age of AI.
25:42We have this thing called the Engineering Codex, which at the beginning of the year, basically, we had two big outages at the end of last year, and we went into basically what we called a Code Orange and a lockdown.
25:53Hardened systems, all these things, and part of one of the outcomes of this to consider its success was this Engineering Codex.
25:58And all of the principal engineers and all of the VPs of engineering kind of wrote these RFCs, and it uses the language.
26:09There's an official web RFC spec where it's like, you should, you must, that kind of language.
26:15That's how these RFCs are written.
26:17And we have it outlined for basically all of our engineering process at Cloudflare, whether that is what does good TypeScript look like?
26:27What does good Rust look like?
26:29What are our release processes?
26:31What are our incident response processes?
26:35And it's all very clearly laid out like that.
26:37And then I think most AI code reviewer products are really, truly terrible.
26:45And we ended up building our own AI code reviewer that runs on every single PR at Cloudflare.
26:51And in order to merge work at the moment, you have to get the stamp of the code reviewer.
26:55And the quality of it is remarkable.
27:00The signal-to-noise is very high, like upper 90s.
27:04There's very little stuff it's wrong about, and it catches most things.
27:08And it kind of fans out.
27:10It will spawn individual agents-- I think they refactored it recently to run on Pi Durable, but it'll run different agents that care about a single thing.
27:19So, one might be the TypeScript RFC.
27:21It will do a pre-pass and identify what are the relevant engineering codex RFCs that apply to this change, and then it will basically go over the code and look for those.
27:30Another example is we have a system that keeps track of system dependencies upstream and downstream, and it will look at how this change could impact that, or has this service been incident-prone in the past?
27:45And the amalgamation of all those and really having taken the time to formally capture what we believe good software is actually does turn out to make what I perceive to be a meaningful impact.
27:59Do you do this only on review, or is it also like, here's a reference agents.md file that sort of links to all the things that you should consider as you write code?
28:10So, like I said, it runs on every review.
28:12I would imagine most people are getting by this in review, but we also have an MCP server that links to the codex that an agent could choose to engage with at any time.
28:21I haven't used that, but also partially because I wrote the TypeScript codex, so it's kind of my standard.
28:28But But what you basically built with the Codex by hand originally is a great set of agents.mds.
28:37Truly, that is kind of what it is.
28:40And I think that's awesome, and I think that's how it should be done.
28:43The question then just becomes, what were the original motivators or triggers that made you write an additional RFC or update an existing RFC?
28:50And would you now, with agents doing most of the work, still find those triggers, have those triggers?
28:57That the agent doesn't come to you and say, "We should update this RFC," right?
29:01So, what makes you evolve your practices and the record of your practices now?
29:08And that is something that I'm struggling with, because for most of the stuff that I would have written in such an RFC, I don't care anymore.
29:17That is a good question.
29:19I don't have the answer to it because admittedly, I haven't updated any of the RFCs I've written for the TypeScript itself since they were published.
29:27Then again, like I It was probably perfect.
29:31I write the best TypeScript.
29:35I think we also did a good job in them.
29:37I read through a bunch of the other language ones where it was really not about particular technology choices or syntax or stuff, but it was high level, like how do you build resilient software?
29:50So, it's kind of more principled in that way.
29:55But yeah, I would imagine without building an intentional feedback loop, which I'm not sure exists today, like after an incident, have an agent review why did this incident happen, and what, if anything, could change in the codexes to have caught this or prevented it.
30:15So, maybe a feedback loop there.
30:18But yet it also comes off the back and the experience of engineers who I've taken down prod probably hundreds of times over the past 14 years and learned many, many...
30:30Everything I know is because I messed up somewhere, and I don't know.
30:34That's the thing I worry about with new people coming in.
30:38I have ideas about how you could effectively onboard AI native engineers that are more junior.
30:44Stick them on a back office product, and give them SLOs, and put them on call for it.
30:50One thought that I have is, so imagine for a second this future emerges that some people sort of generally envision, which is self-healing software.
30:59So all the easy things are sort of automatically no longer showing up.
31:04And then only the hard shit shows up.
31:08And I had a conversation with one of the DevOps folks at Sentry recently who said one of the regressions that he saw recently is that you go into an incident room, and there are more people asking the Claude about the situation than actually truly understanding what's going on.
31:26And this is terrifying to me a little bit, this idea that we now rely in the moment where it really matters on that.
31:39Yeah, but that I'm surprised we haven't seen more of the...
31:45I thought that the cyber stuff was going to push people to software factories or automation more to be able to quickly respond to things, and I feel like that's mostly not happened yet, which is interesting.
32:01It's because both Claude and GPT will fucking refuse any kind of defensive security work just as well as offensive ones.
32:08So, and ask me how I know.
32:13I'm a huge Kimi believer for cybersecurity stuff because it's the only one that just remotely doesn't refuse.
32:19It's just so painful.
32:21But I just want to come back to what you said earlier.
32:24So all of these hard-earned lessons, learned lessons that got translated into the codex, we don't have these hard lessons anymore, right?
32:33I don't feel the pain anymore.
32:35And as such, I don't have any motivation anymore to improve my processes because my processes are now abstracted away from me, and they're basically just prompt the thing.
32:45Did Pi Durable not come out of pain, though?
32:48Or is that Massive amounts of pain.
32:51But that was self-inflicted pain.
32:54How did you get familiar with, oh, well, this is the pain point and what needs to be done?
33:00I just kept building and building and testing.
33:04I think the pain here is not so much like, oh, the world is on fire.
33:07It's like you use your product and then you say, "Okay, this is way more complex than it should be." Or you can sort of feel it in isolation quite well.
33:16I think a lot of the hard lessons of a SaaS product is like shit's down or I pushed out a change, and all of a sudden...
33:25One of the first documents I wrote at Earendil, there was an RFC called Engineering for Breathing Room because I was like, here's how you engineer it so that when shit fucks up, you create breathing room where you don't have to be stressed.
33:39And now I feel like that document probably doesn't really matter that much anymore because I don't know if people read it or feel this the same way as we used to.
33:54I can just tell you about the pain with Durable, and I don't want to talk about Durable specifics, just about the process itself.
34:00What eventually came out is iteration eight, completely different design than what I started with in July.
34:06And most of that change, each iteration didn't have a user, right?
34:11Just me sitting in front of some code.
34:15I usually create scratch files where I use the APIs and implementations I build to feel out if they are good or not.
34:23And then I also now let the agent generate not just one scratch file where I can manually play around, but also examples of each slice of an API or each slice of a library or framework.
34:34And every time I was happy with all of that, I would talk to people.
34:40I would bring it to Armin or to Cristina, who's working on Lefos.
34:46And they would be like, "This is cool, but it also sucks.
34:51And here's why." And that would trigger the next iteration, right?
34:54And that is where the pain came from.
34:56Basically, you need some kind of stakeholder, not just an agent telling you it's amazing.
35:00You need a stakeholder, a real user, or a prospective user that can pinpoint technical issues with your current solution without actually having used it.
35:08Because most of our discussions were just me showing you what I did on a very high level, and you then going, "Mario, this sucks."
35:16Did you present it to any AI native, people that started programming in the after times without any before times experience?
35:25And how did their feedback differ from the people from the before times?
35:33That's a good question.
35:35I think these younger people, when they are within the context of a company, they usually take a step back and let the seniors talk during such design talks or reviews.
35:48Armin, maybe you have a better...
35:50Cristina is very Durable might not be the best example here, I feel like, because we actually spent so much time on it, and we read so much code.
35:59Durable, in a way, was two months too early.
36:02I don't know if we were to build it now, it feels like it accelerated again so much more.
36:07I read a lot of code when, and looked at the SQLite tables, and I did so many experiments trying to figure out how does it grow.
36:16I felt horrified for three weeks of what does it mean to replicate this data with a network?
36:22And I felt like I really was engaged in this entire thing of what does this look like when we sort of do the end version of this.
36:29And now I built some things with Opus on the side, and I was like, "I have no idea what it's doing, but it seems to be fine." Every once in a while, I check, like, "Now it's slow.
36:37Make it faster." And it's like, obviously, this is a side project, but I feel like at the time where we most worked on Durable, we read a lot of code, and that included Cristina.
36:48And it included everybody.
36:49But I don't think that's the norm anymore.
36:53I think we put this on ourselves as like a-- We still believe that good primitives are valuable for both humans and especially agents.
37:01And we thought this is our one chance to build a foundation for new stuff, where we take the time to make it really, really good.
37:10To cover all the things that we, at the moment, think our future will hold as a company in terms of products we want to build.
37:17And so there was some kind of real high stress there to actually nail it.
37:22And don't just let the agent build whatever the fuck it wants, and then be like, "Yeah, this looks right." And nope, you actually put in the engineering effort, and now 10X of that that you would usually do as a handwriting person because now the agent can spit out 10 implementations for you over the course of a couple of weeks or so that you can actually beat up and see if they work.
37:45And that's what we did, but in retrospect, I wonder if it's worth it anymore.
37:51But that might just be my depression.
37:54I have a question because when we initially started talking about software is dead, actually for me, I really felt greatly that software is dead mostly because of actually things like ArtCraft.
38:05Because I know this is going to be a little controversial, but if it wouldn't be for my stupid Adobe subscription, I probably would've canceled it at this point.
38:11It's just like I went through the cancellation flow.
38:13It's like, "Okay, I have to pay out this damn thing, so I'll just keep paying for a little while." But I actually still voluntarily use this vibe-coded Photoshop thing because the latency is better.
38:24And I think the fact that we are now basically so close to a lot of software just emerging on the spot makes me a little bit wonder what the future of software will be.
38:35I'm assuming there is going to be a future of software.
38:37I don't think it's dead.
38:37But surely it has to be different because I have a little anecdote here.
38:42So again, I'm actually coming from game dev, and my other thing is 2D animation and basically providing software for artists.
38:50Someone like Armin will be happy with ArtCraft or whatever it's called.
38:53Working artist will be like, "What the fuck are you giving me here?
38:58If I open this on a different machine, it looks different.
39:01If I have a different GPU driver, it looks different.
39:03It doesn't save half the things that I actually configured," and so on and so forth.
39:06So for Armin, it doesn't fucking matter.
39:08He just spits out a bunch of textures or whatever, and it's fine.
39:12For working artists, ArtCraft is not even close to being there.
39:17Is that And I think...
39:19Not to be too in psychosis, but is that something that goes away over time?
39:26It's a hard one of like, there's just so many issues with the software that it produces, where the software that agents produce is just kind of slightly wrong in so many ways.
39:39And they're getting better It's like the uncanny valley of software.
39:43I think the problem is like, is that person going to continue putting that energy into it to make it better?
39:49And I think there will be a lot of people that will, because there's an arbitrage opportunity here, as like Photoshop is the only thing in town.
39:57The other thing is a company got acquired, and then GIMP, which basically doesn't make a progress in gazillions of years.
40:03So there's a desire for that software to exist, so someone's going to build it, and probably hundreds of people are going to build it.
40:12There's also improving the loop is an interesting one, where I have some software that I made for myself of it put all my emails and X DMs.
40:24Obviously, I'm very much on this end of the spectrum of understanding engineering and exactly what I want a product to be like.
40:31But I put a feedback button in it, and the feedback button just went into a loop.
40:36The agent just had a loop where it was looking for the feedback that came into this piece of software it made for myself.
40:43So I didn't even have to open up the chat anymore to prompt the agent.
40:46I was just giving feedback in the product, and it was getting better because Claude was working on it in the background.
40:54And I think that's maybe an interesting My main use is Pi Durable.
40:56I have two apps now with Pi Durable directly in it.
40:59So it's like I can in the app have my agent in the app to change the app.
41:04I just feel that the limit for pain that you're willing to absorb with something that you built only for yourself is much higher than something that needs to work in a, I don't know, in a company setting, an enterprise setting, across an entire industry, let's say, like with Photoshop.
41:22I also have a lot of these.
41:26Sure, I don't care how you build it, and I just give you feedback, and it improves itself, and so on.
41:30That was Pi's original idea.
41:33But I've done this with a bunch of other little projects as well, and it works great.
41:36It's just so designed for me now that somebody else couldn't quite enjoy it as much as me because they have a different thing they want out of this piece of software, right?
41:49So, and with the traditional software, you have this one-size-fits-all.
41:53You have massive spaceships like Photoshop and so on and so forth.
42:00I'm totally convinced that somebody could take ArtCraft and just fix up all the things they themselves need, and then they have the perfect version of Photoshop for themselves.
42:10But I wonder if this scales.
42:11How many people do we know that can actually do this?
42:13And do we then still need the big companies to build those monoliths that you get and what you see is what you get?
42:19It's also if you bring engineers into your-- Sorry.
42:24If you bring artists into your company, and they've come from one company that has their own forked version of ArtCraft with all of the fixes and random behavior on top, and then they use a completely different version.
42:37The standard is totally like one of the benefits of Photoshop is Feel like that was computer games all the time Yeah, you can just Every company had their own fork of their own engine.
42:45I think that's not necessarily a new thing.
42:47And in movies, I think it's very common for movie studios to have their own software.
42:53I don't think that would be the blocker if it ends up being companies have custom versions.
43:00If everybody has a custom version, then I think it's no longer going to work because no file is going to be compatible with anyone else's software.
43:06Well, the files could stay compatible, but the way you generate the files change.
43:11Wait, the files, I Yeah, the .psd format or .obj stick around, but then it's like everyone's...
43:20I don't think it ends up this way, but there's an interesting world if everyone has their own piece of software that's specifically personalized to them, and they just bring it from company to company, and they're like, "I can produce all of the assets that I need, but I've got this very personalized piece of software to myself." I don't think we end up in that world.
43:40I would like to end up in that world, where you have your personal art toolset of customized bespoke software, but you still keep it interoperable with Armin's and yours and Dillon's and so on.
43:55That sounds like an interesting perspective.
44:00dramatic than, I don't know, the death of software.
44:05This is like the birth- ...
44:06of way too much software.
44:08But see, for me, I think software means different things to different people.
44:12As a user, software is just, I either go to a website or install an app on my phone or a desktop thing, and that's software for me, right?
44:19I'm not involved in the culture, I'm not involved in the technical details, and so on and so forth.
44:24That's software for me.
44:26But for me, as an engineer or somebody who, like Dillon, started programming at 12, software has been my identity, and the process of making software, and especially the interaction with other people making software, and finding new problems to solve and coming up with completely new, unique solutions to these problems that haven't been there before, and I feel like we are completely losing that.
44:53Nobody's going to write the next React.
44:54Nobody's going to write the next TypeScript, Rust, whatever.
44:58You don't have a use for it anymore because you don't care about what the language is, or you don't care how the UI is really implemented, and so on.
45:04So where will all the innovation come from, I wonder?
45:08I'm looking at FoldKit, and I'm excited about FoldKit, and that's my next React.
45:13And the only reason I care to move to FoldKit is because I'm like, "Okay, I can get better tests and states, and I can get better testing out of it, and I no longer need the niceties of JSX, and I can do those trade-offs." But again, the only reason I really care about-- I also am not moving to FoldKit yet because the agent writes React fine.
45:35That would be the next thing that I would say.
45:37Everybody, even if you implement something amazing and new and awesome, then the next thing people will say is, "My agent doesn't understand it.
45:43It's not in the training data yet," so it's stupid.
45:46Well, I feel like out-of-training data is mostly fine these days.
45:51It's writing pretty good Effect, and I don't know that anything has happened.
45:55I've written a lot more open source Effect, but I don't know that that's-- unless there's just someone at the labs feeding my Effect repos in, I don't know that that's made a difference.
46:07So I don't think it's all doom and gloom.
46:09I just miss the culture.
46:11I think the culture is going away, and it's replaced with something else, and I don't know if I like the new culture.
46:16I honestly don't care about people talking about their agent setups anymore.
46:19I just don't fucking care.
46:21It's such a trivial fucking problem, man.
46:23I don't care about all this Mario, if you're stealing a tweet, then...
46:25Oh, but you're not in a tweet anymore, so forget it.
46:28Don't be mean to Theo.
46:30I noticed that GitHub is completely dead for me.
46:34I don't open the issues anymore.
46:36I have the agent summarize the issues.
46:38Because all the issues that opened with AI, and so I just like...
46:44GitHub is just a slop highway now, where the PRs are slop and the issues are slop.
46:50And then the only way to deal with the slop is to slop back.
46:58And so I disclose Slop the slop.
47:02I disclose in the issue comments.
47:03I'm like, "Hey, this is Yeah.
47:04"I've sent this from my agent."
47:07You heard it here first.
47:11No, but I agree with you.
47:13I do the exact same thing.
47:16Originally in Pi, it was like everybody who posts an issue needs to write it by hand and is not allowed to use an agent.
47:22That's out of the door.
47:24But I'm also not like And so I myself started just interacting with issues and PRs through my agent.
47:30And have it post in my name with a disclaimer Yep that says this was blah, blah, blah.
47:35But also, we talked about this one in the last episode, Dillon, but I had an issue with Cloudflare, and I was very convinced that it was something on my end, and so I sent Opus off to root cause it, and it worked for two hours, and I came back to my computer, and Opus was on the support ticket for Cloudflare, and it was like, "Please let me submit this.
47:59It's a Cloudflare problem." And so then I was like, "Okay, fine.
48:06I will send this to the Cloudflare team.
48:09Make a gist and a reproduction." And it made a better gist and reproduction than I ever would've put the time into before.
48:18But then again, it's not like...
48:23The mechanics But actually, one of the are there, but the community isn't one of the things you said there, without really saying is, you assumed it was on your computer, so you probably already prompted it in a way that actually made it really exclude all of this.
48:36And I think that's Yeah one of the things where it's like Yeah you can actually tell quite a bit of what the person thought when reproducing it in the first place before it made the ticket. Because I think one of the things that still sets apart a good engineer to a bad engineer is know where the problem probably should be.
48:57Because Pi gets a lot of issues that are actually completely unrelated to Pi.
49:00That's like, "This should be in vLLM, this should be in a provider on OpenRouter, it should be somewhere else." But the fact that this eventually ended up in a Cloudflare ticket is because you actually really forced us first to assume everything else.
49:15The feedback, he sent it directly to me.
49:19I was the human ticket.
49:20And I had my agent go through Cloudflare's code bases, and it hunted down a bug that's had like 20 escalations over the past year, and it was in Hyperdrive, right, Rhys?
49:36And then I was able to give both a good reproduction, which in all of these escalation tickets, the team was struggling to get good repros, and I handed them this golden repo- ...
49:48or reproduction on a plate.
49:50And I was just like, "This is insane." And I had actually had similar experiences working with Kent C. Dodds earlier in the year.
49:57He was early in beta for Artifacts, and we would have our agents go back and forth on GitHub gists.
50:03We would use that as the message board between our agents, and my agent had access to internal Cloudflare traces and the Artifacts code base, and his had his, and they went back and forth and it was this mind-blowing experience because his code base and product got a bunch of optimization and fixes because they had misunderstandings of how Artifacts worked because of a lack of documentation or whatever.
50:31And then on our side, we also found two or three bugs that would've been really hard to find without having the good telemetry and traces from somebody consuming it on the application side.
50:41So this almost comes back to, I've always said over the past couple of years in a bunch of conference talks and stuff, that the hardest problems in software are not like cache invalidation, naming, scaling to the moon, it's people, process, org structure, and that remains to be completely true.
50:59And I think I've teeter-tottered between incredibly cynical and incredibly optimistic or maybe AI psychosis this summer.
51:10But- I think we're in a weird dip right now where the local maximum, I guess, or where most people are at, or at least most people that have already bitten the apple and like, "All right.
51:31This is how software's changing and I have to get People on a second and third AI psychosis stage.
51:36Like teams that have truly embraced it, they're now sitting here and I think a lot of people are feeling this feeling that processes of how we build software are what failing us.
51:49And I remain optimistic that we will push forward and have better tooling and more importantly, better processes and rituals at work for doing this because, yeah, I don't want it to be the way it is right now.
52:04Because you mentioned this sort of agent using GitHub as a message board.
52:09I had a really interesting conversation.
52:10I think I told this already a couple of times now, but I think it's really interesting to me still because I think us as the people that got really into AI, and they're also for a long time software engineers, we're really struggling with our emotions in one form or another.
52:29If you give this kind of stuff to someone who is not a software engineer, and in this case it's a friend from my kid's daycare.
52:38He's doing a trading bot with another friend, and they started exchanging, I think zip archives, because they're not really engineers.
52:44So they're both building a trading bot, and they both started drag dropping zip files into WhatsApp and they're sort of giving it to their own agents like, "Hey, this is what my friend did," and so forth.
52:52And they figured out after two weeks that the agent started to discover that they're copy-pasting code to each other, and they started setting up a communication channel in the zip archives agent to agent.
53:03And he was like, "This is amazing." And I was like, "This is scary." But it's No, I it's so funny.
53:12This is emergent behavior, and there's people like, "This is great." I don't know.
53:20I think there's a lot to be optimistic about.
53:23Even maybe euphoric to be about.
53:26I always bring this stupid thing up, like my shitty little robot right, I have disassembled here.
53:31I wouldn't have built this without my agentic tooling because there were so many pieces involved that it would have just taken too much time, right?
53:39I had to optimize an inference and two inference engines.
53:42I had to use the original Pi Durable version and make that work with the phone, and I had to web interface, blah, blah, blah, blah, blah.
53:49For me, the end result in this case was the thing that was important, and the AI enables me to do that.
53:55And I don't have to think about process and optimizations and other team members and so on.
53:59It's brilliant for that.
54:02Or my son voice prompting games into existence at five.
54:09There's some caveats to that, but yeah.
54:11It gives you some agency back if you don't have the skills, for example.
54:15And for our industry, as you said, I think we're in a dip.
54:18We're like, "Wow, this sucks now." It's kind of amazing, but it also kind of really fucking sucks.
54:25This is not how I want to work.
54:27But I think this is just a matter of, first of all, letting go, and maybe Sunil can educate us on that because I think he found his zen moment.
54:37Hoping to hear something about that Beaches in Miami in the next episode.
54:41So let it go, the Frozen way, and the other thing is just take it as an opportunity to figure out what the new processes should be.
54:49But just last week, David, a team member of ours who's heavily involved in Pi maintenance, we just sat together last time I was in Vienna and I was like Okay, need to preface this.
55:00How do we triage and process issues in Pi?
55:04Every day, we go in, look at the closed issues because we auto-close all the issues, and then pick out the good ones and reopen them.
55:13And I did this manually for months, and that's like 30 to 100 issues, depending on the day of the week Mm-hmm that I had to process that way.
55:22And I kept doing that.
55:23And I stopped doing it because we got David.
55:26And then David started doing it, and David, I think he almost quit over it because he couldn't bear the fucking mind- numbing work.
55:33So a couple of weeks ago, we sat together in the office, and we were just like, "Man, take Pi Durable, build a fucking issue triage bot that we know that we have signal in the issues to tell us what we usually select and what P level we would assign to that, and who's assigned to the issue as a human, so to speak, to have the responsibility." And we just built that.
55:55And now we have dozens of happy little Pi Durable sub-agents running somewhere in the cloud.
56:01I don't even fucking know where.
56:02And they automatically get triggered on a new issue.
56:05They automatically do the first analysis.
56:07They do a first fix, because most of the issues are trivial, and I know the code base well enough that I can just look at the diff and say, "Good." And it's been blissful now.
56:16It's just super cool.
56:17And they didn't Do you think some of that has come from the models, in particular, Opus 5.5 getting better?
56:24And I had this exchange back and forth with Thorsten Ball from Amp.
56:28He was like, "What would it take for you to start?
56:31What would it take for you to not read any code?" And I was like, "Well, it would be trust, and the only way I build trust is reading the code and it producing good results reliably over time." And it's starting to get there with...
56:46Maybe this is my psychosis talking, but it does feel like we're It's mainly the models.
56:52Everything has changed over the last years mainly the models.
56:55Yeah, I also think so.
56:56The models become good enough, so you can start trusting them with a lot of stuff you couldn't before.
57:00And Rhys had this idea much earlier in the year where that probably was kind of a more fringe idea was like, we can solve a lot of problems by just using more inference.
57:12And it's like now that models are getting good enough or better and coupled with...
57:18I'm using classifier models a lot more than I think a lot of people are because a lot of the things I want to automate are really just like, what is the decision that needs to be made here?
57:28So I've been really loving Jev and Clef.
57:31But so you would agree that the models getting better has enabled you to take that step in trust?
57:38They now understand basically my taste in selecting Yeah issues that are worth opening up and not based on previous historic examples.
57:46And it's basically like your Codex.
57:48We have a tiny little guide of Yeah of things that classify issues into specific categories.
57:54And that just gets now automatically updated as new issues are processed and signed off by a human and so on.
58:00And that works brilliantly.
58:01And that hasn't worked six months ago, or probably wouldn't have worked six months ago.
58:07And the other thing is what-- For me, a huge...
58:10I'm in love with Opus 5.5.
58:12I think I've mentioned this a couple of times, but a huge reason why I actually right now really on a base level enjoy the whole thing much more is because we have sort of moved across this horrible valley of unreadable AI-generated text.
58:27And Yeah most of what I'm doing is actually not writing code, it's trying to understand how the system should be.
58:33And so I use it a lot to sort of have this unfortunate one-on-one conversations with it, but produces me explanations and stuff.
58:39And now I can read them, and I don't vomit.
58:42And that is Yeah that is a huge thing for me.
58:46It's funny because I meant to say this earlier, but we talked about PR review maybe not ever mattering, and kind of being just this formality.
58:55But it's like, actually this summer, PR review was more important than it's ever been because the models were writing deceivingly okay code, and you had to catch it.
59:07And now it's like one in five PRs, I actually have to really nit something, or the only time I am really kind of not trusting of it if it's touching database indexes or changing columns or something, or changing RPCs where I could get version skew or something like that.
59:23That's really when I pay attention.
59:25So to Thorsten's credit, it's building the trust back up.
59:32I did want to Unfortunately, he's more right than wrong, and I hate it.
59:36Because he's very... a maxxer on this.
59:42I've always thought that Thorsten has been directionally correct, even if I didn't agree with him in the current moment.
59:49I just wonder where each of our trust level barometer is and what kind of task would I entrust the agent with today that I haven't yesterday, and where is my upper limit there?
1:00:02And I still find, and that might change, but I have reasons to believe it won't.
1:00:07I still find that they suck at system design and architecture.
1:00:11I think a lot about what I want to build before I build it.
1:00:16I'm finding that it's easier to convey my ideas, and this summer, where models were falling short was like I knew the system I wanted to build, I knew the core pieces, but then it would still screw up the abstractions and how they piece together, and that's where I constantly just was driving myself crazy trying to have lint rules and agents to review stuff to instill my taste and principles in it.
1:00:37But that feels like it's getting solved.
1:00:41They definitely are not at the point of being able to handle designing, especially distributed systems.
1:00:46They're not doing it automatically.
1:00:48I built this game with my kids, and so my oldest sent me a pull request, which is hilarious.
1:00:53So he's 11, so he's grown up now, and pull requests appear.
1:00:57It's actually amazing.
1:00:58And every He even posted that on Discord today and was very proud.
1:01:01His first Well, it's his 25th pull request.
1:01:04But pretty much every change that he lands, I have to go to him afterwards like, "Look, this is not wrong, but you made a one-off massive change to the engine here to land the special behavior of the boss.
1:01:18This will not scale." But I was already trying, like, if I put something into the AGENTS.md file, will it not do that?
1:01:25And it's like, no, it seemingly comes down to just still how you prompt it.
1:01:29If it will make a mess or if it will sort of But I think there's our answer what happens with AI native youngsters, right?
1:01:36Like the way you're now teaching your boys to have a better game.
1:01:43I guess that's probably how we do it in the future.
1:01:46I learned Assembly when I was young, right?
1:01:49Nobody fucking cares.
1:01:50Not even back then in the DOS games, most people don't care.
1:01:53And it has definitely shaped me as an engineer, but does Cristina need to know Assembly?
1:01:58Do your boys need to know Assembly?
1:02:01But they should know maybe something about complexity still, and how a GPU works maybe on the highest level if you want to do games and so on.
1:02:12We only have a couple of minutes here left, and I wanted to ask about Earendil, and the vision for the company, and what are you guys trying to set out to solve and build?
1:02:26I think we really like, at least I know despite all of the depression on what it does to our industry, I think we really like the fact that it's actually delivering true economic value for software engineering, at least if applied correctly.
1:02:39And we kind of want to see this sort of in many more parts of the industry.
1:02:45AI already has a pretty bad reputation overall.
1:02:47It would be great if this stuff works for my grandmother, this stuff works for my kids, and actually leaves a better world behind.
1:02:56So we want to find that, and I think where exactly that journey is going to take us is maybe something will change over the years.
1:03:05Right now, I think a pretty big focus is, on the one hand, we would like to establish Pi Durable and things like this for other people to build their own agents on top, but also for us to be able to build a version of an agentic interaction that's your data within your workflow and what matters to you with your control, and just create a really good experience there.
1:03:29And my kids are setting the house on fire.
1:03:32I've always been a dev tools guy.
1:03:35But I agree with Armin.
1:03:37Armin put it something like that a couple of months ago.
1:03:41Next year, around that point in time, we don't want to be a coding agent company.
1:03:44Because at the moment, we kind of are a coding agent company, and that was never the goal of Earendil in the first place.
1:03:50That was just a happy little accident.
1:03:53But I think that gives us the opportunity to start with a technical base of users and then expand into non-technical user bases, one after another.
1:04:01It doesn't have to be the entire world.
1:04:02We don't need to build a Muse or a Dots or whatever.
1:04:07So yeah, that's exciting.
1:04:08And I personally also want to get rid of the dependency on the big labs.
1:04:13Love you guys, but also fuck you.
1:04:17That's one of the biggest identity problems for me.
1:04:19I am now dependent on a handful of big companies and their stupid tokens to do my work.
1:04:24That fucking sucks.
1:04:26So whatever we can do to also help with the commodification of intelligence, of artificial intelligence, that would be a nice thing to do.
1:04:36Can't announce anything there yet.
1:04:39Well, I am certainly glad that you guys are pushing forward and I don't know.
1:04:47If anyone was to do it, I'm very aligned with your worldview, and I think probably all of us think about software and AI very similarly.
1:04:55And I certainly look to both of you as role models in this space, so I'm glad you are pushing the Aw pushing the paper forward there.
1:05:05But we could carry on with this conversation for hours and hours.
1:05:08I'd love to get into how you're building a business with AI, but maybe a conversation for another time.
1:05:21Thank you so much for your time and the conversation.
1:05:23I've really, truly enjoyed it.
1:05:28Thanks so much, guys.
1:05:30Now I have to We'll get you back in- That's it for this episode of "The Next Token." Tune in next time and let us know what you think.
1:05:38And now I have to go to a Halloween event with my kids