Ep. #41, Containers at the Edge of AI with Phil Estes

Brian Douglas: Welcome to another installment of Open Source Ready. John, you are here.

John McBride: I'm here. I survived. I survived the dentist.

Brian: Yeah. In the summer weather, all the changes.

John: Yep.

Brian: You had lightning storms up in the Northeast recently.

John: Yeah, it was nuts. New York was getting hit and there were all these people stranded in flooded interchanges and stuff. And yeah, our guest is also on the east coast, so we can talk all the weather with Phil.

Brian: Yeah, so Phil, welcome to the show. We'll talk about quite a few things but like recently around containers you had a really good talk about maintaining the maintainers and doing open source. But can you introduce yourself but also tell us how the weather is in Virginia as well?

Phil Estes: Yeah. Nasty summer heat in Virginia. Lots of daily thunderstorms coming through, but thankfully no crazy flooding like up from further north. Yeah. I'm Phil Estes, I'm a principal engineer at AWS. More people might know me from being fairly involved in kind of the open source container world for quite a while now.

But yeah, so I end up sort of providing that link between the upstream open source container world and a lot of systems and services AWS that run containers and they all use open source software to do so.

John: Yeah.

Phil: And yeah, fairly involved in the cloud native CNCF, OCI communities as a byproduct of being involved upstream.

John: Phil, you're very humble. As somebody who used to work at AWS and on some container technologies, yeah, I think you're vastly understating your impact across the ecosystem. So, yeah, we're really excited to just chat containers and the ecosystem and open source at large.

Phil: Sure, yeah.

John: I am so curious, you know, and maybe this is kind of a gotcha question, but what is a container? What would you say is a container in this day and age of things that people say are containers that maybe aren't containers? Haha.

Phil: Yeah, I mean, it's a great question that people have been asking for quite a while and especially I think Docker ended up being somewhat of a lightning rod for people when they brought containers to the masses, I guess is one way we could say it, because before that a lot of people had been playing around with these concepts that were already in the Linux kernel. These ideas of name spacing, a process ID or a mountain namespace, controlling it with resource limitations from C groups.

So it's interesting that what Docker provided has kind of become what we all say containers are. You know, a set of file systems that are isolated in a sort of normative set of ways.

And now we have the OCI that tells us, hey, here's a specification that tells you, you know, you write this JSON and you can say, I'm isolated in these specific ways with these constraints. And we've all kind of come to accept that. But yeah, I mean I'm sure we're going to be talking AI and there's all kinds of people doing sandboxing these days and some things look more like a traditional container and some don't.

So, yeah, the definition has always been fuzzy and the OCI sort of brought some normalcy to what we think of that. But yeah, smarter people than me have debated those things for a while and you know, another AI insertion in the conversation is just all the security vulnerability work happening that, you know, almost anyone can point a model at a code base and say, find me vulnerabilities and, you know, all kinds of interesting edge cases that maybe there are ways we thought isolation was working that it isn't.

And I think AI will flush out more of that. But maybe I'm getting far ahead of our conversation starter there. Containers are interesting in that unlike so many other principles in software, there is no one thing that we could say, "this is a container."

Brian: Yeah. So like where we are today, it feels like Docker definitely took over like a large portion of the market, like the mindshare. Like my introduction to containers was Docker, and then we saw Docker, like an attempt at an enterprise thing, and then like the company split, like there's a whole other conversation that we don't have to bring in here.

But then this thing that had been around for a bit, like Containerd was a thing. There's some other approaches for doing containers. Do you feel like what we document as containers is a done primitive and we can move on to the next stuff now?

Phil: Yeah, I think for a lot of the workloads that we're running today in containers, I hate to say "good enough" because that's almost a negative connotation, but in the sense of like, we understand that world. Like you said, so many people came to containers via Docker and Docker Build and Docker Files and push to a registry and run.

Like those concepts are just ingrained in maybe millions of developers now. That doesn't mean there aren't interesting potential approaches, but what we found for example in the OCI and I've been around that community since it was launched, it was actually around Covid that I think people had more time on their hands sitting at home on their computers. And we ended up collecting kind of an online note that community's HackMD markdown files.

And so people generated a bunch of documents and we ended up with all these discussions that were sort of humorously titled OCI V2. not humorous in the sense of there can't be an OCI V2, but it was like, well, we're probably never going to do a V2, but like, what are the fresh ideas about, you know-- Are tar files of layers, the best way to represent this set of files we want to transmit and run as a workload? And, you know, today I'll jump a little bit, but, you know, those conversations were great.

But what we found at the time is it's really hard to move the industry now because of the sort of entrenchment of all the tooling we built around the concepts that Docker started with.

And so, you know, EROFS, I would say, is one of the most impactful things in the last 24 months in the container runtime space. And it's sort of fitting, like we didn't have to create a new spec or a new model for how we build or run containers. There's some new tools coming around that.

But I think to maybe get back to a more clear answer, it's just hard to do something drastically new in this space because we have so much tooling in place and operational and in production. And so I think a lot of what we'll see are incremental things like EROFS as a file system is bringing some performance and capabilities we didn't have with traditional OverlayFS, but it doesn't mean we have to come up with a new image format.

Like OCI V2 had some crazy ideas about know new ways to think about images. So I think that's where it's not that what we have is, is the end all but it's, it's very hard to, to sort of throw all that out and start over.

John: Yeah. Do you think because there's all this tooling and all these ideas that with how AI has moved so fast that everyone's like oh we need this totally new primitive that is an AI sandbox. And like obviously there's security concerns or things that we want from maybe a Micro VM kind of architecture. But a lot of this was happening and I was like this kind of just sounds like the architecture of like a big container thing, that you would just like want to spin up a bunch of them and then spin them down. Like that's like containers, right?

Phil: Yeah, yeah. I mean I think it is a moment of kind of research-- I mean for example I was at the meetup where Intel proposed Clear Containers. this is like 2015, you know, Docker is just barely a year or two old and they're saying hey, like there's going to be breakouts, there's going to be issues with this sort of loose combination of Linux namespaces. You should really like wrap that in a lightweight VM.

And then for 10 years people have been playing with those concepts. Amazon created Firecracker and of course Lambda uses it. But you know the team at AWS also created the Firecracker Containerd plugin and Kata containers has been around forever now, which again Intel was part of that. Clear Containers kind of became part of that solution.

So yeah, it's interesting that we've sort of had a lot of fits and starts in that containers with a lightweight virtualizer and I think sandboxes are just going to, that's going to be the production use case that's going to bring us into that world where that's just how we run containers now. We use very fast minimal latency micro VMMS to run more traditional like container operations. And then we see that in Containerd there's a lot more interest in that space right now.

John: Yeah, it's really wicked tech. Like it's so cool to see what Firecracker has been doing and now the micro Lambda, micro VM stuff has been really cool to see as well.

Phil: Yeah. And the cool thing about that is that came out of the managed runtime work we were already doing. And I think the team, again I, I'm not on the Lambda team but from my understanding it's like, well, why wouldn't we give this, we're using this capability, why wouldn't we give this to everyone else? And I think it has been exciting to see that as sort of a new primitive around a simple way to run micro VMs.

Brian: Yeah. So could we talk about the AI space a bit too as well? So I used to work at GitHub for about five years and GitHub's had this crazy first half of the year where it's like constant stretching and downtime and agents are definitely putting it through its paces.

I'd be curious from your purview where you're working on, what do you see the world of agents changing how we're thinking about these different primitives?

Phil: Yeah.

I guess there's the huge meta topic of: Is open source over? As a Containerd maintainer it's interesting to think that there could be someone out there next Monday who says Containerd is silly written in Go, I want it in Rust tomorrow. And could they do that with enough Fable tokens or whatever model of choice? Probably.

Yet, it's also interesting to see that we're over halfway through the year and we have some stories. Vue.js we have some stories out there of, of people doing this, but it's-- Yeah, I just had this discussion. I took a big trip to China a few weeks ago and every young person there was talking about AI and using AI tools and you know, this discussion about open source and AI, will it survive? That came up.

But it's interesting again that I think the capabilities are there and we do have a few of those stories. But yet it seems like for stable, mature projects, people are still wanting a foundation to rely on that they know there's some expertise behind it. So again there's that. I know that could be a whole podcast in itself or 10 podcasts, but so far it's interesting to see that we still have Kubernetes and the Linux kernel and Containerd and hundreds and thousands of other projects continuing to march on.

I think what I do see changing pretty rapidly is that those of us who maintain these projects are seeing a huge influx in security reports from people who are not traditional security researchers and some of those match with, you know, the Curl creators very loud blog post this year that they're slop and others are not. You know, they're valid. There are findings that we have to go dig into and understand how to solve.

And then just general contribution we're seeing we as maintainers are using AI more for our own purposes and we as a project, you know, we see projects kind of falling on different sides of this divide. We don't like AI, we like AI, we accept AI contributions. And so we're, again, our maintainer group is leaning in that this is a valid tool, useful to even accelerate our own things that we want to do in the project.

And so, you know, our only request so far is just disclosure. And again, we know we can't enforce that. But yeah, it does make for interesting times I think GitHub as infrastructure has felt the pain of just this increase of activity. And so so far we haven't had major issues with the project or, you know, again, some of the infrastructure issues have been complicating factors to getting a release out.

"Hey, today our actions just aren't running well. Okay, I guess we're going to release tomorrow." But in general, you know, it hasn't been a catastrophe more than it's been definitely an interesting surge of kind of new activity.

Brian: Yeah. I'm curious though, because obviously thanks to tools like OpenClaw, the approaching of making contributions on behalf of humans is definitely a bit of an epidemic at the moment. Do you feel like, with Containerd being like a CNCF project, do you think there's more barriers to entry for AI to open a bunch of nonsense?

Phil: Yeah. I mean, I don't know if being in the CNCF or being sort of a core project that a lot of tools, higher layers rely on, like Kubernetes. The interesting thing is I think the project has had a barrier to entry in the sense of a container runtime is a bit niche. It's not flashy, it's not-- Demoing Containerd, which I've done over the years in talks. I always feel embarrassed myself. Haha. Like, what do you show in a demo of a container runtime? "Hey, it ran okay. My process is running."

So in that sense I feel like a lot of, you know, when you look at like the CNCF, the mentoring programs where people join for a summer and work with a CNCF project, like, we've rarely gotten a lot of interest, and that's totally fine. again, I think because to choose to work on a container runtime takes a certain "I care about sort of infrastructure level, plumbing level, concepts around how kernel namespaces turn into a process that's running certain isolation."

So you could see that maybe AI would sort of blow the doors off that. Well, now I don't have to even know or care about those things. I can just ask AI to make contributions on my behalf. But interestingly, I'd say we've seen very little of that. I think in the first weeks the OpenClaw was kind of exploding, We saw a few with like a claw something in the GitHub username it's like, okay, you know, someone's messing around with OpenClaw.

But like it hasn't been a fire hose of, oh wow. Everyone's using these autonomous agents to point at Containerd and say, go make a PR. So yeah, because we're sort of a unique project in sort of our focus and what it is, maybe it's a little bit off the radar for the kinds of people that are playing around with those tools.

Brian: Yeah, yeah, fair enough. So I wanted to shift gears and last year I was actually at this KubeCon, in Europe for KubeCon EU. London. It was London.

Phil: London, yeah.

Brian: Yeah. And you gave this talk about maintaining the maintainers. So yeah, really curious about your take now in this-- Well, I don't know if it changes for you because it seems like there's already structure and it's boring software until the world wakes up and decides that there needs to be a change or a new container protocol. Do you feel like you're good? You could fly under the radar for a bit?

Phil: Yeah. Like I said, it's been interesting to see all the stories, tweets, et cetera, about whatever prediction people make about open source and AI and the collision course that may or may not be in various communities. I think again, so far we do seem to fly under the radar in the sense that there are a core group of people who in some sense represent every major hyperscaler, including all the Chinese providers.

You know, that's our core group of committers, maintainers, reviewers, and that's been a pretty stable group for a long time. And so even as I look at our open pull request list or issue list, there are other parties, new names, first time contributors in there pretty regularly.

I haven't seen AI move the needle to where it's like, whoa, now 10% of our contributions are quote unquote us, the sort of known quantities around Containerd and now it's 90% who knows who these people are or bots or whatever. So it's been interesting to feel like we haven't had that kind of impact yet and maybe it's coming.

Some of the Maintaining the Maintainers talk was really around this idea that most of us have been in this community for a while and that includes the sort of big names in Kubernetes, for example. How are we going to attract or get interest from the next generation? And maybe AI helps there but I think they're also has to be sort of a necessary level of interest in the technology and I think that's what's interesting to me.

I think a lot of people consume Kubernetes and they consume container technology and we get a trickle of new contributions but we don't see a lot of people stepping up to say I want to work on this kind of technology and my employer allows it or I'm an independent. So that'll be an interesting thing to keep watching in this space.

Brian: Yeah and I'm curious because there's a lot of companies that represent contributors for projects. John and I both worked for the Linux Foundation for a moment. I worked with the CNCF when I was at the KubeCon previously so there's a lot of investment of these companies making sure the software moves forward and not just move forward, stay stable.

But I'd be curious if there's any conversations around how do you prepare for what's coming which is the AI native wave. I don't know if you have any connections to the Agentic AI Foundation but it seems like what they're doing is, it's pretty cool but it's also like it's MCP, it's vLLM there's a couple other new projects that Goose is another one that just joined. I just heard it's rumors of new projects that are probably going to be joining pretty soon.

So yeah, just curious like there's any interactions with like some of these more up and coming foundations and like do they try to buy time or borrow time?

Phil: Yeah, one easy interaction I have with the AAIF is that my boss David Nally is the board chair of the board of AAIF. So you know a lot of conversations here on our team we-- I think you had Stormy on, who's a peer of mine and she leads our open source strategy and marketing piece that David used to have and he's well known in the open source world for his work with Apache and very connected to LF as well.

You know the AAIF is obviously was it at their big event in New York that they mentioned they're now the fastest growing LF kind of umbrella foundation. So yeah, interesting to think what that does. CNCF has sort of been the king of foundation so to speak as far as like KubeCon, CloudNativeCon has been massive for many years. Does that change the game and where people who think they want to be involved with open source do they sort of shift their focus?

But I think there's a lot of collaboration there because the people that work on CNCF projects are going to most likely be adopting AI tools and creating MCP servers for interacting with their project. So definitely there's that aspect. but it will be interesting to see. As much as I'm a fan of the collaboration that comes under these foundations, we know there's a lot of money that moves around and the focus of large companies moves around with these foundation memberships.

So yeah, both myself but our org within AWS and our open source strategy team, our goal is to again see that these projects remain stable and viable and supported and funded. And yeah, I think AI necessarily stretches that in a sense because now there's more things to think about and more open source projects to consider and that may require some stepping up of activity and participation and hopefully not losing the old boring things that all this other new stuff is running on still has to be maintained. And maybe AI helps with that to some degree.

John: Yeah, I'm curious what metrics you would look at or your group would look at to see that something maybe internally needs to change or something needs to change in the community. We had Davanum “Dims” Srinivas from the Kubernetes community last year sometime and even then he was saying that we need to bring in new maintainers, we need to bring in fresh pipeline of contributors that can then grow up to be maintainers and you know, inevitably like lead a Kubernetes release or something.

And I'm just curious what you could see at like your kind of unique purview of like all this stuff happening. Like is it contributor pipelines? Is it like pull requests? PRs? Like what kind of stuff are you looking at?

Phil: Yeah, you know that, that's interesting because I just had yet another discussion on like project health. And I think you guys probably know about the LFS works with LFX Insights, that dev stats was a piece of that puzzle for CNCF. But now Insights is broader and there's been some churn around how do you clean this data? How do you validate this data?

John: We are all too intimately familiar. Haha.

Brian: Yeah, that was a project we went into Linux Foundation to work with. So yeah John and I worked with the team closely.

Phil: Ah, okay. Okay. So I'm touching, touching close to home. Yeah. But you know, it just seems like this evergreen issue of like, how do you measure whether a project's healthy or not? Again, the OpenSF has done some good work with the scorecards and know that's more focused on sort of the security metrics around a project and you know, we've opted into that as Containerd.

But you know, one of the things that we do look at internally and speaking of AI we have someone on the broader team who wrote a very nice tool and now generates a weekly report of all the projects that we perceive we care about. And you know, we can add to that and as time goes on.

But yeah, as usual, there are certain things that sort of are easy to track but then need some kind of assessment. Like, okay, is more pull requests always better? Does that mean the project's healthier? Does that mean there's some problem or more issues or, you know, more community activity, like the number of people opening issues and pull requests?

So yeah, I feel like this has long been debated in open source, how you measure project health. But I think trajectory over time read by people who've had a long sort of investment in open source there's some amount of natural understanding of, "okay, I know that project just went through a big release cycle. So yeah, there's a dip, while they sort of plan out the next cycle."

But as you sort of zoom out, I think it starts to become clear when a project is sort of disappearing, you know, okay, there's been no commit for eight months. That sounds a little strange, especially just in terms of dependency management. You should probably be updating things more than every eight months in whatever language, you know, dependency tree management you have.

So that's what we're looking at is like what's our best estimate of activity and sort of freshness and release cadence. because those things at least can give you a trend that points toward, "okay, I want to dig in here because maybe nothing's wrong, but it's a little weird to see this sort of different trajectory than we've been seeing." So that's kind of what we're using. And it's all imperfect in one sense, but yet valuable enough to give you hints where to look.

Brian: Yeah, it's a hard problem because every metric can be very bespoke to your own situation. So where health for a project like Containerd would just be like, "hey, no one complained." Or like a project like Kubernetes is like, "hey, are we getting enough features into the future releases that people would care about?" But also how do you stay true to the project?

I was asking about the AAIF too as well because I was thinking like vLLM is like a project that John was pretty close to. He built a lot of stuff with us at the last company we worked on and I was actually surprised that that went to. I think that went to the Pytorch foundation, but it was like pre AAIF. But then there were a bunch of other projects that would have made sense to go to the CNCF.

And I spent a lot of time with Jim Zemlin chatting about this once. A lot of the stuff was actually ideating. It's interesting because as you mentioned CNCF, KubeCon, the darling of the foundations, now you have the AAIF where AI is definitely here to stay. We've got a lot of stuff to figure out and I think this is like top of mind where I will see--

I would put my money on this foundation is going to help build more the bedrock of what's to come. We might still have a lot of startups and labs that are still shooting from the hip a bunch of random stuff.

I have a read about this as well, which I'd love to get your take on but yeah, interesting times. A year ago I would not have predicted like where we are today where like the last time I opened up a like a-- Well I've opened up Vim, but I don't open up for like the reasons I did a year ago, which is like I've got to like get my fine tooth comb and like change specific things.

Phil: Yeah.

Brian: Now I'm basically like hey, file number-- or not even file number. Like last time I used a file number was like forever ago. So maybe file and then like hey, do this and expectations this and then like let it rip. It's a different world.

Phil: Yeah, it's super interesting. As I mentioned, as a container to maintainer core, thankfully we're all, you know, we don't have dissent or a lot of wildly different opinions, but yeah, just an acknowledgment that like the way even our own maintainers are developing pull requests has drastically changed in the last year. Even simple things that, you know, it used to be pretty straightforward.

Like, "okay, we need to update our Go version across all Containerd sub projects. Okay, that's Grep and this and that, you know, across a bunch of GitHub workflow files to do a big go version update."

And you know, you can still do it that way, but man, you tell Claude Code like, "Go, look at this, the last time we updated Go, here's a PR reference. Do the same thing with the latest Go version and instead of wondering if you missed a file or you fat fingered the Grep that was looking for where we defined all the different Go versions."

Yeah, it's just amazing how many workflows are different now. It can be vastly different.

Brian: Yeah, very cool. Well Phil, I really appreciate the conversation. I think there's a lot to ponder about this current state of the world and really open source, like man, in 2027 I do anticipate the world's gonna look very different. I hope we're still here and we're at least still controlling some of the knobs and the levers, but you know, you gotta be flexible.

Phil: Yeah, yeah.

Brian: With that said I got a question for you Phil, which is are you ready to read?

Phil: Sure, yeah, let's do it.

Brian: Excellent. So I actually had a read, which is very tangent to what we're just talking about where I saw yet again another project has rewritten the result into Rust. So Cursor-- Cursor is definitely in vogue. They're I guess helping ship rockets at this point? Haha. I'm not sure whatever the correlation to SpaceX is, but yeah, they had a team of agents rebuilt SQLite based on the original 835 page manual. I don't know if we needed this, but here we have it.

John: Yeah, I also want to know if they got their hands on the big private suite of tests. Isn't SQLite one of those that has non-- You don't actually know, but you can submit a patch and it'll be like, oh, you passed this secret suite of tests that you know it's in this foundation or wherever SQLite is. So it'd be very interesting to see if where they got some of this data to get to pass a hundred percent of their internal tests.

Brian: Yeah, well, I don't want to speculate. Okay, so this is, well, okay, I'm going to speculate so like please don't strike this to record.

John: Haha. There you go.

Brian: But there was an article about Grok basically taking full sail private repos from local hosts up to the model. So like just pure speculations. I can't say this actually happened, but I can assume if they wanted the test they could get it just by one prompt.

Phil: Yeah, I saw that story as well about Grok.

Brian: So Phil, you think we need more stuff written in Rust at this point or are we just getting started?

Phil: Yeah, I mean definitely for infrastructure code, like Rust has been hot for a while. I'm not totally sure SQLite needed the Rust treatment. But hey, you know, if it's just a bunch of agents and you know, I mean that's just the interesting thing about our times is that it, you don't even have to ask, should we do this? It's like you can. If you want Rust--

In fact, I mean one of the earliest tests I did with one of my own, it's not a private project, it's a public project. But you know, I, I have a tool that builds multi R Docker Images and it's been around for years and I always thought like, it might be a fun thing to like use as my own learning tool for like rewriting it from Go to Rust. And every time I started I got stuck somewhere and was too busy.

So as coding agents started to make that turn from like, "this is silly" to "wow, this is amazing," I just pointed at my GitHub repo and said rewrite this in Rust. And I think it was 30 minutes later I was actually running my own tool and pushing and pulling multi platform images. I never validated that everything was 100% correct. But yeah, it's just interesting in that it's almost too easy to do these rewrites at this point.

Now the one point I've made when talking about AI tools, Rust's validation at the compiler step and it's very verbose guidance for errors does seem to pair really well with LLMs as far as letting it be very autonomous and fixing its own issues as it finds them you know, comparatively to other languages. So in that sense, you know, maybe more Rust code is going to give us a leg up with LLM based development.

John: Yeah, it's almost just a question of how many tokens do you have in your budget? Haha.

Phil: Yeah. It's always interesting when the, the experiment is done by the company selling tokens. I guess that's not necessarily cursors case but I know some of the past-- Was it the GCC sort of implementation by LLM that was done by one of the big labs?

John: Yeah, I think Anthropic did it. It was like Claude C Compiler, or something was what it was called.

Phil: Yeah. So you know, they had the tokens to blow on that.

John: Yeah. It's funny, I did actually recently look at this because I was looking back on like some old trends and that was one of them where people were just like oh my gosh, it like just went and wrote a C compiler and you can like compile something. At least Hello World. But it, it's funny because I mean they haven't gone back on it. I think it was more or less just like an experiment than anything.

But it does it does make me always wonder the like knowledge toll that that would take like moving a project from like one technology to the next. Like maintainers you leave behind, if you were trying to bring along maintainers, how hard a tool like that would be to maintain in a community ultimately. So yeah, 100% for like personal tools. I've done this a bunch.

But I'm so curious how it's going to go for the Bun community since that was kind of like we're just going to rip this, we're going to ship it. And I think a lot of people even in the community were like, whoa, okay. Like I spent a lot of time maybe getting good at Zig and now I guess I got to get good at Rust or at least prompting for Rust.

Phil: Yeah, I think that's a super interesting point and something I have thought a lot about, you know, these headline grabbers, or reality, you know, like Bun, I mean they're doing it is. You know a lot of the history of open source has been based around trust of the maintainers. Right? I mean we think about the Linux kernel and we think of Linus Torvalds and Greg KH and you know, the 50 other names that have been as prolific in that community.

And so in a sense like we don't just trust the code because it's on GitHub or whatever source control it's in. Because there's people behind it, we trust that they really care about the quality of the project.

And so when I asked, whatever, I can't remember the tool I was using at the time to rewrite Manifest Tool in Rust and it ran, I kind of stepped away from it because like, well, it seems right, but even myself, it's like it felt kind of weird, like I didn't know Rust well enough at that point to go through everything it had generated in 30 minutes and validate that it really was the sort of truest implementation of what the intent of my project is.

But it doesn't matter because it's just my thing. And yeah, I have some users, but yeah, I'm very interested in this crossover from like how we've trusted open source because we trust the people maintaining it and how AI rewrites change that game and do we still trust this output that maybe none of them fully understand every line of it?

John: Yeah, 100%. I think I had a read as well, which was maybe slightly related to this. This was a fun little article about stealing Claude memories from people's like Claude sessions and stuff. And it was exactly this. It was like this guy basically proved that proof of concept exploit using like a small little tool that you would like to distribute and maybe everything like this is just like an SDK that you can distribute for a supply chain attack or you know, a small little binary or whatever.

But it was just fascinating because I don't think people realize the like, things they're like telling to Claude or OpenAI ChatGPT. Mine would probably be very boring. Like this guy uses Go and this guy likes, I don't know, TMUX or something. But there is like a whole swath of people who are, I don't know, on some like plane of AI psychosis, maybe talking to them like a therapist.

It's a crazy article. I definitely recommend the listeners go read it, but yeah. Brian, what would your Claude say about you if I stole the memories?

Brian: Stole the memories? Man, definitely "this guy does know what he's talking about." Haha.

What I love about AI is I get to ask all the dumb questions first to the AI, like, okay, I'm looking at this PR, like, what am I looking at? Can we do this? Can we do that? What was the intent here? So I think in a world that we are remote and it's been a while since I've been sitting in an office with somebody and be, hey John, question about this thing. Now you're thinking about taking away time from people.

So yeah, I tend to ask a lot of like random questions. I just recently did a dump of like a bunch of like, conversations with users and stuff like that. So there's a lot of like, Socratic method conversations back and forth. So that again, it'd be like, man, this guy keeps asking himself questions to himself. But, yeah, that'd be mine. Hopefully not a lot of secrets in there, like tokens or API keys. Haha.

John: Yeah, yeah, 100%. Phil, what about you? What secrets are in there? Haha.

Phil: You know what's funny is I don't remember making this decision, but I have both ChatGPT and Claude, like, personally, like outside of work. And I never talk to ChatGPT about technical things. I've asked the crazy things. Like we, we have a bunch of like, almost adult kids.

And so I basically have a fleet of vehicles at this point, which is depressing, but they're always breaking down. And some shop tells me I need 800 different things. And I upload the estimate and ask ChatGPT, like, "here's the model of the car, here's the mileage. Help me out, help me save money."

So anyway, ChatGPT is like my personal life. And then Claude is like all my technical, like, hey, help me update my very out of date personal website. You know, single page application stuff.

John: Yeah.

Phil: So it's pretty funny. It's like I'm very split brain in my tech Claude and my private life, ChatGPT. But ChatGPT has surprised me a few times because now I've been kind of doing that for a few years and I'll ask it something and it's like, hey, there was this time you talked to me about whatever, are you wanting to, you know, do this, go on this trip, or take this vacation. So it was a little surprising, like, oh, yeah, there's, there's a lot of stuff on me somewhere. But yeah, sadly, probably not too exciting, other than you might learn about all the cars I own and their problems.

Brian: You know, I do like that. I actually haven't thought about like, updating like previous service records into like a RAG or basically in the memory. Because I've done this, I've done it for a PC I built, so it knows about my PC. So I've ever, like, thinking about, like, other things I want to do with it or what other things I want to run on it. Like, ChatGPT knows it, but if my car, it sounds genius, like, I want to get an old car, like a truck and this, like, start from zero. And then now this thing, just knows. But hopefully it doesn't hallucinate on you and like tell you to like replace the head gasket or something. Haha.

Phil: Yeah, yeah.

John: I've actually done this with music gear before where I'm like, I have this, this and this guitar pedal, amp, whatever. Like, how can I get in like a Jimi Hendrix tone or something? It's kind of the bane of every guitar player is like dialing in the tone. Haha.

Phil: Yeah. Right.

John: But I've had it before. Be like, "oh, I know that you own this pedal. You should actually use this pedal." And then I'll be like, oh my gosh, you're so right. And it knows. It's even told me before, like, oh, this circuit is much closer to a circuit from, you know, 1969 or whatever in this pedal that you have versus the one you're trying to use or versus the one that, you know, you're looking at buying or something.

And then I'll just be like, okay, sure. And I still can't dial it in, so it doesn't always work.

Brian: Yeah, you need the state of the art models now at this point.

John: Yeah. Hear the tone.

Brian: Dial up the inference. Haha.

John: There you go.

Brian: Well, with that, this concludes our conversation. Phil, we just want to thank you for chatting through reads with us sharing some of your insider baseball knowledge about maintaining the maintainers. And listeners, stay ready.