Screaming in the Cloud - When AI Starts Writing the Pull Requests with Madelyn Olson

Episode Date: June 25, 2026

AI-generated code is no longer just producing low-quality pull requests. According to AWS Principal Engineer and Valkey core maintainer Madelyn Olson, the quality of AI-assisted contributions has improved dramatically in just the last few months.In this episode of Screaming in the Cloud, Corey Quinn and Madelyn discuss how AI is changing open source development, the growing burden on maintainers, and how projects like Valkey are using AI to find bugs, improve security, and harden production systems. They also explore Valkey's continued growth, the future of software development, and why experience, operational knowledge, and community still matter in an age where code is becoming cheaper to create. *Since this episode was recorded without video, we thought it was the perfect opportunity to get creative with AI!Show Highlights: (00:00) Open Source Stability Push(00:32) Reinvent Afterglow Banter(01:40) AI PRs Get Better(04:36) Whimsy Versus AI Slop(06:14) AI Security Hunting Reality(09:12) Maintainers Adapt to AI(11:28) Valkey Fork Wins Adoption(14:43) Fighting the AI Tidal Wave(23:45) Next Five Years and Roadmap(27:02) Release Woes and Where to FollowAbout Madelyn: Madelyn Olson is a co-creator and core maintainer of Valkey, a high-performance key-value datastore, and a Principal Engineer at Amazon Web Services (AWS). She specializes in building secure, highly reliable systems and is passionate about collaborating with open-source communities. In her role at Amazon, Madelyn serves as a Principal Software Development Engineer for Amazon ElastiCache and Amazon MemoryDB, where she focuses on advancing distributed data technologies and contributing to the growth and success of the Valkey project.Sponsored by: duckbillhq.com

One of the things that we've been seeing inside the last sketch is we're trying to contribute more of our, you know, performance features, our efficiency features back into open source, because we think that helps us make the overall system more stable. Welcome to Screaming in the Cloud. I'm Corey Quinn, and it is a pleasure for me once again to speak with Madeline Olson, a WS principal engineer and core maintainer of Valki. Madeline, how have you been? Oh, I've been delightful. Thank you so much for having me back. Well, frankly, I'm astounded and grateful that you agreed to come back on the show because we gave a talk at Reinvent, and usually that's when the knives come out afterwards. Like, I can't believe you said that on stage, but apparently people liked it. One of my favorite things about our talk was that everyone came up afterwards and everyone wanted to talk to you, which is just so, it's so nice. Everyone usually wants to talk to me. It's so great I can be an introvert and just walk away.

It has its advantages and disadvantages. Sometimes people want to say something kind. Other times, they're They want, like, the thing that drives me nuts is right after you step off of a stage and people want to give you harsh feedback on the talk, which is helpful as a speaker. Don't get me wrong, but give me 10 minutes first to wind down from the high of having given the talk. Or, you know, ask me to sign their chest or get a selfie or smell my hair. Okay, it gets a little interesting, but we run with it. Oh, it's true. I have, you know, I have to deal with my small share of fame being one of the vacuum maintainers, but I'm sure you get much more of it. Hey, you're the one that got me into the Redis party.

That was fun. I think they would have let anyone in. Entirely, that's the beautiful part about being open source, then not being open source, then barely being open source again. So I have some questions for you, because so much has changed in the, what is it now, six months since reinvent, give or take,

where back then a lot of people were throwing AI pull requests to open source projects, and it was slop. I mean, no one would pass up a slop opportunity to wind up Yolo coding something at that doesn't freaking work. And at some point in that interim, it feels like something has shifted, namely, the AI generated code started being good. What's it like as the maintainer of a project that people actually care about and contribute to to be, I guess, facing that rising tide? So we definitely saw the increase of pull requests coming a little bit late last year, but by and large they were, as you said, the PRs were not very good quality.

They had obvious mistakes. They also often, they were often trying to find issues inside the project. They'd like go and search through the issues and find something and they would kind of just send the AI agent at it with a one shop being like, go fix this. And the result were what you'd expect. They were low quality. They didn't make very much sense. So we kind of quickly were starting to close them. We definitely noticed about three to four months ago that the average PR quality was both increasing a lot. basically average engineers were able to point their, you know, plot code or Kiro or some other types of harnesses at with the foundational like opus models with from Anthropic,

they were able to point them at these issues and they're actually producing semi-decent code. And that started causing a lot of pain on a lot of open source maintainers because that took a huge amount of effort to sort of review and think through because the AIML still aren't great at like making sure the code is a adhering to like sort of the ethos of the project, but it's much better at being technically correct. Which is of course the best kind of correct. Of course it's the best kind of correct. So yes, it doesn't crash, but it also is going to be

hard to maintain. The AI I'm all still love generating code. So even if there's a perfectly good function, you could rewrite a little bit, they're going to totally just go off and build their own. My favorite thing with like Claude Code is so the whole Valcue project is written in tickle, a archaic language, but the, sorry, the infrastructure, the testing is all written and tickle. The AI loves to just write its own tickle frameworks every single time if you don't like hold it to the fire and they're like, no, you have to use the framework we built. It loves writing new tickle tests. But that's not very maintainable. So we definitely noticed in the last couple of months that they actually started doing a really good job of like, you know, kind of

getting almost the way there. And so we've seen about a 50 to 60% increase of actually decent pull requests getting open in the last couple of months. And that's sort of been the big thing we've been trying to deal like, how do we as an open source project deal with these increases and contributions that take a lot of maintain our time to actually think through? Because they don't have bugs. They just kind of aren't great, but they're not bad either. I have found that one of the problems with AI generated code historically is that people continue to make the same fundamental error about AI that they have been making for almost four years now, which is, hey, this thing talks like a middle manager. Therefore, it must be self-aware instead of the proper conclusion,

which is that middle managers are absolutely not. Where people hate AI slop, in my experience, from a narrative perspective, has been when it presents as mediocre, as milk toast, corporate speak. If you throw whimsy into it, people find it delightful. My AI generated code commits are no better than anyone else's, but I will say that my commits are the ones that have conspiracy theories about the code in the commit message. Because if you're going to put up Slop, at least be funny about it. Oh, no, for sure. People hate the, there's like that speak that especially I think, you know, chat GPT got known for that, you know, every time you're like, hey, that's just wrong. It's like, oh, you're absolutely right. I just didn't do what you told me to do.

But if you throw a little more whimsy in it, it is, it can get much funnier responses. It's like, yes, I am deliberately trying to sabotage you. It's a lot more fun. Everyone has been talking about mythos because it's a brilliant marketing campaign. We built this amazing model. Oh, too scary to release special. People can have it, but not you. And it's become this weird. I have something super special.

Can I, can other people see it? No. Then you had Gippity 5-5 come out, which apparently is similar. Only other folks get to use that one. And it has definitely raised the bar. I will say that I have the numbers on this, which I'm sure your friends in AWS PR are going to love me for. But I've done visualizations on the number of CVEs that AWS has published on an annual basis for the last five years. And we are going to cross a threshold this month.

For the record, we are now at the beginning of May. Yeah. So AI does have a great ability to go and force multiply in a way that individuals can't. And I think what I was kind of talking about, like the harnesses around the AI malls have gone a lot better. And like, I don't have access to me those. I don't know anything that I can share publicly about, you know, access to me those. But inside the Valki project, we've actually been quite successful at just kind of, you know, taking, you know, the frontier opus models and being like, hey, just go read through this code very deeply, try to come up with

hypotheses about what might be exploitable, and then trying to then go try to fix it. We've been actually generating a lot of PRs and fixes recently inside the Valki project. I think the total is up to like 25 or 26 in the last month or so. Of not CV caliber bugs, but of real bugs, like memory leaks and unintended server asserts. By just, you know, trying to, you know, use a lot of tokens. You know, it's nice that at Amazon I'm able to burn kind of as many tokens as I want, sort of doing these deep evaluations of the code base. And we've been able to use that to find bugs.

And I'm sure Methos is the same. And I think AI will really help us harden the code. Oh, it has. I mean, my code is no great shakes. my internal system for writing the newsletter is open to the public. And I finally decided that I had some spare cycles left in a session. And all right, I'm going to go ahead and do a security audit of this thing. So the pass-road to get in is a UUID.

It turns out that anything of the appropriate length would suffice. Like, okay, that's not terrific. Again, the blast radius is somewhat minimal on this, but still not a great failure mode. And then I found a bunch of other stuff, where it gets into the stupid things I don't really care about. Like, hey, because I'm the only user that has access to this, but I could potentially prompt inject myself. Great, or not prompt inject, but you know what I'm talking about.

I could effectively, I could do SQL injection against my own code base where I have admin rights anyway. That's not the threat. Rando's coming in off the internet. More of a threat. No, yeah. And one of the great things that AI is it scales really well. So you can use it and go and hunt down all of these things at the same time. Obviously, the ones, those threats that you talked about, like the false policy.

positive rate, still the real problem that we're dealing with. I mentioned, you know, we were able to find like 25 or so bugs in Sack-Dalkey. That's nothing compared to how many false positives it generated. It generated like 150 false positives. It was like, oh, if, you know, this variable somehow got modified, then you could, you know, cause a remote code execution. Like, yeah, but that can't, you can't modify the code that way. That's not how this works.

But, you know, my expectations, they're going to keep getting better and we can keep using these tools to basically harden the systems that we rely on, which I think is a school. I will say it does feel like it's gotten harder to contribute to open source given the proliferation of AI, which is counterintuitive because it has never been easier for me to find something annoying in a project written in a language that I don't know, you know, English, and then I can basically bully the AI into writing a pull request against it. But I worry that if I do that, then I'm actually part of the problem because no matter how much I work on that and tweak it and get it to do the thing and add tests and jump through all the hoops you're

supposed to, there's very little signal, you know, other than the conspiracy theories, to differentiate this from any other slopportunity people are jumping on. Yeah, and that's a very fair, valid concern. And I don't know if we've really figured this out in Valki yet. But one of the things that I know I've seen a lot with other maintainers is they've been a relatively slow embrace of AI because they've seen these, you know, waves of slop. They don't like dealing with them. They often just close them. But I have seen. more of a shift recently. The various maintainers in Valki, I work with a maintainer from Google named Jacob. He started using AI to do a lot more reviewing of the code. We also have an engineer

from Erickson who's been using Kiro along with Klaude to do more reviews of the code. And so I think right now it definitely feels like there's this tension, but I think that we're kind of all trying to figure out what the future of open source development looks like with AI. And I still appreciate when someone is trying to fix a bug. you're not required to submit PR. You can also just open an issue. And one of the nice things about generative code is, you know, I can also just go try to fix your bug with my own GMAI,

so you don't have to deal with it. But I still appreciate when people try to open PRs. So I definitely don't want people to start feeling like that's, like they're contributing to the problem by trying to help. Most people are good intention. The people I really don't like are the people who like use like open claw and like they just point at the Valky Project. been like, yeah, just go try to fix all the issues.

Like, generally those issues are there because we'd like people to learn about the project, involved in the project, or maybe there are issues that aren't very important. So the people that just use AI to brute force and try to solve lots of problems are the people that are really causing the problems, not the average individual who's trying to make the project better. So I want to talk a bit about it. It's now two years since the launch of Valki. And in some ways, it has succeeded, from the customer perspective,

at the biggest concerns that folks had with Redis. One was the attempted rugpole, great, awesome. The community made a definitive decision to fork, which is great, and that in turn unblocked a lot of features that, not to sound uncharitable, it felt like Redis was intentionally holding back as a form of business model protection, and now the open source version is awesome. How has it been from the other side of it?

Because I'm just the customer, and to be direct, I'll use whatever version of this that my AI agent picks most of the, time, but you see it very differently. Yeah. So the first year after the fork, there's definitely this big open question of, hey, will Valky survive, right? Most forks don't work out. Most forks fizzle out. And one of the great things we did see about Valkies, it did end up surviving in part because it was sponsored by a large number of organizations. We had a very diverse community that was helping build it. And we even did see some validation when Res ended up moving back

to AGPL so quickly, right? They moved from a very permissive license to proprietary license back to AGPL. And the users from our project that saw that kind of saw that as validation that, hey, like the Valki project is, it's real, people are thinking about using it. And over the last year, we've seen basically more and more adoption of the project because people are seeing it stick around. They're seeing it build functionality that, you know, wasn't showing up in Redis. The things you mentioned, you know, like we built LDAP supports, which was a long time a proprietary feature of Redis. And that helps build a lot of confidence that we're willing to build stuff that in users once. I was even talking with a financial company this morning.

And they're like, hey, we're now all in Valki. We'd like to talk about it. We have some very esoteric features that we were never able to get merge into Redis. Like, can you help us merge it? They're doing some. They basically want like a chaos testing like API and Valki so that they can better verify their availability guarantees of their service when the cash goes down. And those are really cool things. And so, like, you know, the power of Al QA right now is still its community.

And as I said, we're seeing more and more adoption. We're still seeing we've recently crossed 100 million container poles of the product overall. If you kind of look at the graph, it's been like a nice upward exponential graph as, you know, we see more and more adoption. Oh, yeah. And as I mentioned in our talk that we gave, which I'll throw a link to in the show notes, that there was a, they want to pulling a number of upstream commits. from Valky into Redis, it has become the new, actually, Valky has become the new Redis Upstream, which is a terrific example of success. So for those who are not able to look at the show notes, this is OPN309, titled appropriately

disagree in commits. And we'll throw a link to that into the show notes, because of course we will. And yeah, and, you know, Redis is still taking commits from us, which is great. We love to see it. You know, it is definitely affirmation that what we're building is valuable to the end users. And we kind of believe in our long-term abilities to continue to, you know, build things that our end users find valuable. And that's important. It comes down to the customer obsession approach. So I guess the counterpoint that I want to bring up here, the sort of the elephant in the room,

such as it is, when everyone can have the AI service wind up writing and submitting code with less and less human effort, several things happen. One of them is GitHub falls down. more often than grandma. I get it. Stale is hard, and yet. The other piece of it is that you wind up with a tidal wave of, I'm going to be unchartedable for a second, crap. How do you fight that? How do you push back against that upswell of massive nonsense? You know, one of the things that's great about AI is it's non-determinism, right? If you ask it to build a thing, you'll build it 10 different ways, which is counter to what we want in what you just described, right? We want determinism. We want. We want,

things that stay up, stay available, and don't break, right? Which is basically things like writing tests, writing automation. One of the things that's important that was really internalized while I've worked at AWS is like we have huge suites of automated testing that does chaos testing, that does no regression testing. And like that's something that we need to be using AI to both write tests for to do verification against. Like one of the things I mentioned is Rennis is able to pull commits from us, but we're not able to pull commits from this. then for licensing reasons. And one of the things we built is some tooling around basically every commit that gets open to Valki,

we check to see if there's any chance that that commit might have originated from Rennis by comparing it against hashes of the codebase. And that's important for us because we really don't want to make sure we don't accidentally pull a commit, because it's very painful to unwind that. And then also stuff, you know, like we've been using AI to write a lot of regression testing. We built, we used AI tooling to build fuzzing against the Valki system to basically, test how it behaves when various nodes fails. And so, yes, on one side there is this rise of just non-deterministic generative code,

but we can also use that ability to generate deterministic code that we can verify that our systems are working the way they're supposed to. You know, that's what I'm spending a lot of time thinking about right now is how do we use these tools that we were given to basically harden all of our production systems, both through the security stuff I was talking about earlier as well as availability and, you know, testing. Testing. Well, here's the question, too, where I can take a look at any open source project now, or even any close source product. And with enough time and poking of cloud code and the tokens to back that up, it can spit out effectively a quote-unquote clean room build where, all right, I just rewrote your close source thing as an open source implementation, or I have taken your open technically or source available technically a code and now I have built a version

that I can do whatever I want with because it is not a one-to-one copying. There's no code reuse here. It is a re-implementation from first principles. That has always been theoretically possible, but a massive amount of work. Now it's just a medium amount of tokens. How is that changing things? The differentiation that I still see, right? So you can make kind of the same case about the last the managed service I work on. And the differentiation that we really see is that we've been running the service at scale for well over a decade. And you don't get that by just pointing Claude at the API endpoints and say, hey,

reproduce this, reproduce what this is working on, how this behaves behind the scenes. Like, one of the things that we've been seeing inside Alaska is we're trying to contribute more of our performance features, our efficiency features back into open source, because we think that helps us make the overall system more stable because we get more eyes on the code. The value proposition of open source that you're having a collective group of people trying to make code better is still true in the age of AI. Like more people are reviewing it, more people are thinking about it, more people are trying to hypothesize and come up with improvements. So, yes, the cost to write code has gone down a lot. But to be fair, my job has never been writing code.

Like it hasn't been writing code for seven or eight years, right? Like I back when I was like a college grad, I wrote a lot of code myself. And the fact that that's gone down significantly doesn't mean I'm like producing 10 times more. I like to make the joke that I can write code 10 times faster, but I'm about 20% more efficient because most of my job is just showing up in meetings and arguing with people. Me too. What the weird part is I'm not invited to those meetings, which is neither here nor there. But you're still appreciated.

We're happier there. You bring some levity to it. Oh, exactly. I try. I have seen a massive proliferation in various online fora of people vibe coding. some SaaS thing, where it's clear that they do not know the first thing about the deep scale problems of this space and throwing it over the wall. And I want to be clear here, I'm as guilty as anyone. In fact, if you go to deploybar.app, you can see something I built where my

platypus hangs out in the macOS deploy bar and just has a persistent notification whenever GitHub, Versel, or GitLab are doing a CICD run. And it's free. Now, if you want to pay five bucks a month for it, Billy will stop making fun of you. Or, alternately, for the masochist out there, he'll really care and go much deeper into making fun of you. But the utility remains free. It's the snark and the cynicism. And I think the innovative business model of pay me or I won't be nice to you is kind of a good approach. But that's a bit of an edge case exception here. Because so much of it is just, I vibe-coated this thing last night. Who knows if I'll maintain it or not, pay me money, please. Yeah, I'm not very optimistic that those are going to stick around.

I mean, I'm sure some of them are, you know, finding unique markets and, you know, part of, you know, the whole startup world is trying to find product market fit while you still have cash. And so, you know, I do believe AI will help find, help companies find that product market fit faster. But I'm sure a lot of them are just going to go nowhere, right? If your goal is to try to just be a shallow copy of AWS or GCP, it's going to be very difficult, right? AIDOUS has so much institutional knowledge about how this stuff works. that it's going to be, you know, because it's the years we've run all this stuff in production, it's going to be hard to try to copy it just by pointing Claude at it.

Claude wasn't trained on, you know, a lot of this information. So it's trained on just kind of open-source stuff. And a lot of that stuff is, you know, just random stuff that people wrote on GitHub. And I think that that's not terrible. I'm giving a talk somewhat soon. And a key thesis behind it is the idea that the AI bots are terrible at writing terraform because there's no good terraform out in the wild. To be clear, I've seen a lot of great terraform,

but it's always for companies that have learned what bad terraform does and spent the time to explore it. I'm sorry, I should say open tofu now, but still it's the same principle, where it struggles to do things correctly in that space. And when it comes to infrastructure, at least, there's a blast radius here that there isn't as much in other disciplines. That's true.

And I mean, I know the big trend these days is to build skills to help with that type of stuff, build MCP servers that can provide these skills sort of on demand, and they help shape the LM so that they do the right thing instead of relying too much on their training data. And, you know, we've seen some good adoption of that. For example, we have an engineer working on building a Valki skill. So it's one of the problems that the LMs have is knowing what's a RUTIS feature or what's a Valki feature. It very quickly thinks they're, like, you know, sometimes thinks Valki features are in Redis and vice versa. Because it doesn't, it, it, A lot of this information is in the foundational models, so it's in all the trading data.

And it struggles to differentiate them. And so skills help be like, hey, this is a Valki feature, this is a Redis feature. And that stuff also would, you know, we'll hopefully solve a lot of these problems we have around stuff like Terraform and Open Tofu. There is a future here where a lot of this stuff slips below the surface level of awareness. That has been the case for a long time. We go back to the late 90s. and building and running a web server took an in-depth knowledge of GCC compiler flags and the better part of a week. Then RPM and D Package came out.

Then Yum and App came out on top of them. Then things like Puppet and Chef and whatnot came out, and it was simply just, you know, insure installed. And then it became a checkbox on S3. And so things that were hard today become easier yesterday. That has been an ongoing trend. I guess I didn't think that I would necessarily live to see. a world where an entire app fit into that bucket. I don't know how much you were ever using, like, the early GPT models,

but I used to use GPT2 and the early versions of GPD3 that Open Eye produced to help do, like, D&D tabletop campaigns. And like, that's about a decade ago when this came out. And the rate at which they've kind of been evolving is faster than I expected. But I imagine we'll continue seeing that type of progress. And yeah, as you said, I think those types of. Workloads will become commodities and not too much time. What do you think is next?

Because I want to be clear here, five years ago, if you had accurately predicted what the current state of the world is, in terms of open source, in terms of software development, you would have sounded like a lunatic. With that in mind, what do you think the next five years looks like? I do hate making predictions, but I'll do my best. I definitely see an increasing trend of the, you know, like the cost of writing code continues to come down.

And by cost, I mean both, you know, in terms of token, how much time engineers are being spent. But like the high context individuals who are driving a lot of this stuff still are driving it like they were a few years ago. So I kind of do expect to see just more and more, like, high velocity individuals sort of making a lot of stuff happen. So like the people that are able to, you know, like the Alaska service, I imagine will have fewer people,

but they're able to drive more stuff, build more features. And I imagine more of that will happen both in the startup world and individuals. I haven't used like OpenClaw or those types of tools too much for my personal life, but I imagine that will become more ubiquitous. Like, I think we'll see a lot of just the same of just, you know, being able to force multiply through AI, having it get easier to do, have them all. Like, one of the big innovations that happened recently was just like, you could basically prompt the clod code,

and it will figure it out. I imagine that'll continue to happen sort of in all aspects of life. But that's kind of what I see happening kind of across the next five years. Like this is the first time I think I would ever say that I don't really know what's going to happen five years from now. Yeah, I'm hoping it sorts itself out

before the time my elementary school kids have to enter the workforce, but we'll find out. I will say you can probably make some better predictions because, again, Valki is open source and it is not AWS controlled or restrained. What's coming in Valky? That is,

much easier to make predictions about. So the Valky Projects, the main things we're working on are basically improving durability. So Valki and REST have historically had a durable version called Append-only files, which was pretty much self-instance. We're trying to make it of a durable, multi-node distributed system. And this will allow people to actually run stuff. Like we kind of want to replace Kof-glass workloads. We would love to replace stuff like some very simple key value primary data store workloads. There's some interesting use cases and stuff like vector similarities, where you actually do want the indexes durability committed.

So those are type of things that we're building out. We're trying to also, you know, the DRAM shortage is, you know, on everybody's mind. One of the big things that's been on the Valky Projects roadmap for a long time is figuring out how to natively store data onto SSDs without impacting latency and performance. There's been a lot of innovations in the last couple of years that have made SSD read latencies, like,

very competitive with RAM, like sub 10 microsecond reads, which is still still. a hundred times slower the DRAM, but as long as you carefully orchestrate how you're fetching the data, it can almost be free. So those are the two big things we're working on as a project. But yeah, we're always hopeful to get more things. Those are features that are probably going to come out in the next six to 12 months. And of course, there's a lot of other stuff. We're releasing Belkeen 9.1. It should be out by the time this podcast comes out. That adds performance improvements, memory efficiency stuff. Those are the Brenner. That's putting an awful

lot of faith in GitHub staying up long enough to ship a release. I'm sorry, that's on kind. Fair, because it's very expensive, but on kind. I wasn't going to complain about GitHub, but I'm still not going to complain about GitHub. All the current problems are having our own problems. We're trying to release, as a recording of this podcast, we're trying to do a patch release of Valci, and it is taking forever. I'll be direct. My problem with GitHub right now is they are simultaneously saying that it is not their fault

because they are being slammed by a deluge of AI stuff, which I believe it is sincere. However, they're also shoving co-pilot anything that holds still long enough and many things that don't. So it feels like you don't get to sell the problem and then complain about it. I mean, that's capitalism, right? Oh, it is. I just sit here and I shake my fist and it makes me angry.

If people want to learn more about what you're up to and what's next in the exciting world of Valki, where's the best place for them to go to find you? The best place to find me is probably on Blue Sky. I'm Rekondit Rose, blue sky. At social. Following the Valky project, Valky.com, there's a blog section, which we public relatively frequently. We've almost gotten enough content that we have a weekly blog release cadence about everything new and exciting on the Valki project. LinkedIn is

also a great place to follow both Valki and me. I mostly just repose stuff, but it's kind of what's going on in the project. We're planning to host a Valki event at the Open Source Summit in an A that will probably not, maybe we'll be in time, but more likely we're hosting an event called Unlocked this week, but there's also going to be another one in Prague, hopefully in Q3 So we're trying to organize that. So if you're interested in coming and learning a lot more about Falki, we're planning a hosting event there later this year. Wonderful.

And we will, of course, put links to that in the show notes. Madeline, thank you so much for taking the time to speak with me. As always, it is a pleasure, and I'm looking forward to the next time. Excellent. I hope I wasn't too AI-pilled for you. Not yet. That's okay, though, because I'm going to write conspiracy theories about it myself. Madeline Olson, AWS principal engineer.

and core maintainer of Valki. I'm cloud economist Corey Quinn, and this is screaming in the cloud. If you've enjoyed this podcast, please leave a five-star review in your podcast platform of choice. Whereas if you hated this podcast, please, leave a five-star review

on your podcast platform of choice, along with an angry comment that no doubt will present as AI Slop.