When AI Starts Writing the Pull Requests with Madelyn Olson

Episode Summary

Episode Video

Episode Show Notes & Transcript

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 Follow


About 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

Transcript

Madelyn: One of the things that we've been seeing inside ElastiCache 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

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn, and it is a pleasure for me once again to speak with Madelyn Olson, AWS principal engineer and core maintainer of Valkey. Madelyn, how have you been?

Madelyn: Oh, I've been delightful. Thank you so much for having me back.

Corey: Well, I, frankly, I'm astounded and grateful that you agreed to come back on the show because we gave a talk at re:Invent, 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.

Madelyn: 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 okay. I can be an introvert and just walk away.

Corey: It has its advantages and disadvantages. Sometimes people wanna say something kind. Other times they want... Like, the thing that drives me nuts is right after you step off of a stage, and people wanna 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.

Eh, okay, it gets a little interesting, but we run with it.

Madelyn: Oh, it's true. I have, you know, have to deal with my small share of fame being one of the Valkey maintainers, but I'm sure you get much more of it.

Corey: Hey, you're the one that got me into the Redis party. That was fun.

Madelyn: Uh, I think they would have let anyone in.

Corey: Entirely pos- 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 re:Invent, 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 sl opportunity to wind up YOLO coding something at, that, 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 people actually care about and contribute to, to, to be, I guess, facing that, that rising tide?

Madelyn: 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-shot being like, "Go fix this."

And the result were what you would 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, Claude Code or Kira 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 were 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, 'cause the AI models still aren't great at, like, making sure the code is adhering to, like, sort of the ethos of the project, but it's much better at being technically correct

Corey: Which is, of course, the best kind of correct.

Madelyn: Of course, it's the best kind of correct. So yes, it doesn't crash, but it also is gonna be hard to maintain. AI models still love generating code, so even if there's a perfectly good function you could rewrite a little bit, they're gonna totally just go off and build their own. My favorite thing with like Claude Code is, so the whole Valkey project is written in Tcl, a archaic language, but the, the...

Sorry, the infrastructure, the testing is all written in Tcl. The AI loves to just write its own Tcl frameworks every single time if you don't like hold it to the fire and you're like, "No, you have to use the framework we built." It loves writing new Tcl 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 opened in the last couple of months. And that's sort of been the big thing we've been trying to deal with, like how do we as a open source project deal with this, these increases in contributions that w- take a lot of maintainer time to actually think through?

'Cause they don't have bugs, they just kind of aren't great, but they're not bad either.

Corey: I, 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, 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.

Uh, 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. 'Cause if you're gonna put out slop, at least be funny about it.

Madelyn: Oh no, for sure. People hate the, the, the... There's like that speak that especially I think, you know, ChatGPT 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 give much funnier responses. It's like, "Yes, I am deliberately trying to sabotage you." It's a lot more fun.

Corey: 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, it's become this weird, uh, I have something super special. Can I... Can, can other people see it? No. Then you had, uh, GPT-55 come out, which apparently is similar, only other folks get to use that one, and it has definitely re- raised the bar.

I will say that I have the numbers on this, which I'm sure your friends in AWS PR are gonna 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 gonna cross a threshold this month. For the record, we are now at the beginning of May

Madelyn: Yeah.

So AI does have a great ability to go and force multiply in a way that individuals can't, and I think where I was kind of talking about, like, the harnesses around the MLs have gotten a lot better, and, like, I don't have access to Meet Those. I don't know anything that I can share publicly about, you know, access to Meet Those.

But inside the Valkey 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 do- go try to fix it.

We've been actually generating a lot of PRs and fixes recently inside the Valkey project. I think the total's up to, like, 25 or 26 in the last month or so of not CVE caliber bugs, but, like, 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, I- 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 do... use that to find bugs, and I'm sure Meet Those is the same, and I, I think AI will really help us harden the code.

Corey: Oh, it has. I mean, my, my code is no great shakes, but 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 gonna go ahead and do a security audit of this thing.

Uh, so the passcode to get in is a UUID. It turns out that anything of the appropriate length would suffice. Like, okay, that, that's not terrific. Uh, again, the, the blast radius is somewhat minimal on this, but still not a great failure mode. And then I found a bunch of other stuff, which, 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. It... 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.

Randos coming in off the internet, more of a threat.

Madelyn: No, yeah. And one of the great things about 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, th- those threats that you talked about, like, the false positive rate's still the real problem that we're dealing with.

I mentioned, you know, we were able to find, like, 25 or so bugs inside Valkey. 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. I'm like, yeah, but that can't...

You can't modify the code that way. That's not how this, this works. But, you know, my expectation is they're gonna keep getting better, and we can keep using these tools to basically harden the systems that we rely on, which I think is cool

Corey: I, I will say it does feel like it's gotten harder to contribute to open source given the proliferation of AI, which, which is counterintuitive because it has never been easier for me to ha- find something annoying in a project in a la- 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, and get it to do the thing and add tests and do all, 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.

Madelyn: Yeah, and that's, that's a very fair and valid concern, and I don't know if we've really figured this out in Valkey 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 'cause they've seen these, you know, waves of slop. They, 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 Valkey, 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, uh, along with Claude 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 don't, you're not required to submit a p- 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 GenAI, 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 intentioned. The people I really don't like are the people who like use like OpenClaw and like they just point at the Valkey project and they're like, "Yeah, just go try to fix all the issues."

Like generally those issues are there 'cause we'd like people to learn about the project, get involved in the project, or maybe they're issues that aren't very important. So the people that just use AI to, you know, brute force and try to solve lots of problems are the people that are really causing the problems, not the, not the average individual who's trying to make the project better.

Corey: So I wanna talk a bit about it. It's now two years since the launch of Valkey, and in some ways it has succeeded from the customer perspective, uh, the biggest concerns that folks had with Redis. One was the attempted rug pull. Great. Awesome. The, 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, I'm just the customer, and to be direct, I'll use whatever, uh, whatever version of this that my AI agent picks most of the time, but you see it very differently.

Madelyn: Yeah. So the first year after the fork, there was definitely this big open question of, "Hey, will Valkey survive?"

Right? Most forks don't work out. Most forks fizzle out. And one of the great things we did see about Valkey is 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 s- did see some validation when Redis ended up moving back to AGPL so quickly, right?

They moved from a very permissive license to, 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 Valkey 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, 'cause 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 support, which was a long time a proprietary feature of Redis, and, you know, that helps build a lot of confidence that we're willing to build stuff that end users want. I was even talking with a, a financial company this morning, and they're like, "Hey, we're now all in on Valkey.

We'd like to talk about it. We have some v- very esoteric features that we were never able to get merged into Redis. Like, can you help us merge it?" They're doing some... They basically want, like, a chaos testing, like API and Valkey, so that they can better verify their availability guarantees of the pro- uh, of their service when the cache goes down.

And those are really cool things. And so, like, you know, the power of Valkey right now is still its community. And as I said, we're seeing more and more adoption. We're still seeing... We recently cro- crossed 100 million container pulls of the product overall. If you kinda look at the graph, it's been, like, a nice upward exponential graph as, you know, we see more and more adoption.

Corey: Oh, yeah. And as I mentioned in our talk that we gave, which I'll throw a link to in the show notes, uh, that there was a... They were pulling a number of, of upstream commits from Valkey into Redis. It has become the new... Uh, actually, Valkey 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 OPN 309, titled appropriately, Disagree in Commits. And we'll throw a link to that into the show notes because of course we will.

Madelyn: And yeah. And, you know, Redis is still taking commits from us, uh, which is great. We love to see it. You know, it's, it is definitely affirmation that what we're building is valuable to the end users, and we kind of believe in our long-term ability to continue to, you know, build things that our end users find valuable

Corey: And that's important.

It, it comes down to the customer obsession approach. So I, I guess the, the counterpoint that I, uh, 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, uh, several things happen.

One of them is GitHub falls down more often than grandma. I get it, scale is hard, and yet the other piece of it is that you wind up with a tidal wave of, I'm going to be uncharitable for a second, crap. How do you, how do you fight that? How do you push back against that upswell of massive nonsense?

Madelyn: You know, one of the things that's great about AI is its non-determinism, right?

If you ask it to build a thing, it'll build it 10 different ways, which is counter to what we want in what you just described, right? We want determinism. We want things that stay up, stay available, and, like, don't break, right? Which is basically things like writing tests, writing automation. Like, one of the things that's important that, you know, I was really internalized while I've worked at AWS is, like, we have huge suites of automated testing that does chaos testing, that does, you know, regression testing and, like, that's something that we need to be using AI to both write tests for, to do ver- verification against.

Like, one of the things I mentioned is Redis is able to pull commits from us, but we're not able to pull commits from them for licensing reasons. And one of the things we built is some tooling around basically every commit that gets opened to Valkey, we check to see if there's any chance that that commit might have originated from Redis by comparing it against hashes of the code base And that's important for us 'cause, like, we really d- wanna make sure we don't accidentally pull a commit 'cause it's very painful to unwind that.

And then also stuff, you know, like we've been using AI to, you know, write a lot of regression testing. We built... We used AI tooling to build fuzzing against the Valkey system to basically test how, 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 where 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.

Corey: Well, well here's the question too, where I can take a look at any open source project now, or even any, any closed source product, and with enough time and poking of Claude 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 closed source thing as an open source implementation, or I have taken your open technically or source available technically 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?

Madelyn: The differentiation that I still see, right? So you can make kind of the same case about Elastichash, 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, you know, behaves behind the scenes." Like, one of the things that we've been seeing inside Elastichash is we're trying to contribute more of our, you know, performance features, our efficiency features back into open source, 'cause we think that helps us make the overall system more stable, 'cause we get more eyes on the code.

The value proposition of open source, that you 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, I haven'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, 'cause most of my job is just showing up to meetings and arguing with people.

Corey: Me too. What ma- but the weird part is I'm not invited to those meetings, which is neither here nor there.

Madelyn: Ah, but you're still appreciated. We're happy you're there. You bring some levity to it.

Corey: Oh, exactly. I try. Um, I have seen a massive proliferation on, in various online fora of people vibe coding some SaaS thing, uh, 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, and I wanna 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, Vercel, or GitLab, uh, are doing a CI/CD run, and it's free. Now, if you wanna pay five bucks a month for it, Billy will stop making fun of you, or alternately, for the masochists 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, is kind of a good approach. But, but that's a bit of an edge case exception here, because so much of it is just I, I vibe coded this thing last night. Who knows if I'll maintain it or not?

Pay me money, please.

Madelyn: Yeah. I, I'm not very optimistic that those are gonna 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, 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 gonna go nowhere, right? If your goal is to try to just be a, a shallow copy of AWS or GCP, it's gonna be very difficult, right? AWS has so much institutional knowledge about how this stuff works that it's gonna be, you know, 'cause the years we've run all this stuff in production, it's gonna be hard to try to copy it just by pointing Claude at it, right?

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

Corey: 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.

Uh, I... 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 OpenTofu now, but still, it's, it's the same principle where it, 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.

Madelyn: That's true. And I mean, the... I know the big trend these days is to build skills to help with that type of stuff, build MCCP servers that can provide these skills sort of on demand, and they help shape the LLM so that they do the right thing instead of relying too much on their, their training data. And, you know, we've seen some good adoption of that.

Uh, for example, we have an engineer working on building a Valkey skill. So it's one of the problems that the LLMs have is knowing what's a Redis feature and what's a Valkey feature. It very quickly thinks they're... It like, you know, sometimes thinks Valkey features are in Redis and vice versa, uh, 'cause it doesn't...

A lot of this information is in the foundational model, so it's in all the training data, um, and it struggles to differentiate them. And so skills help be like, "Hey, this is a Valkey feature. This is a Redis feature." And that stuff also would, you know, will hopefully solve a lot of these problems we have around stuff like Terraform and OpenTofu

Corey: There is a future here where a lot of this stuff slips below the surface level of awareness.

Now, that has been the case for a long time. Uh, 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 Dpkg came out. Then Yum and Apt came out on top of them. Then things like Puppet and Chef and whatnot came out, and it was simply just, you know, ensure 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.

Madelyn: I don't know how much you were ever using, like, the early GPT models, but I used to use GPT-2 and GPT, uh, the early versions of GPT-3 that OpenAI produced, uh, 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 in not too much time.

Corey: What do you think is next? Because I, and I wanna 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?

Madelyn: I do hate making predictions, but I'll, 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 like 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 be easier to do, have them all... Like, one of the big innovations that happened recently was just like you could basically prompt the Claude code and it will figure it out.

I imagine that'll continue to happen sort of in all aspects of life. But like 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 gonna happen five years from now.

Corey: Yeah. I'm, I'm hoping it sorts itself out before the time my elementary school kids have to enter the workforce, but we'll find out.

Uh, I, I will say you can probably make some better predictions because, again, Valkey is open source and it is not AWS controlled or restrained. What's coming in Valkey?

Madelyn: That is much easier to make predictions about. So the Valkey project, the main things we're working on are basically improving durability.

So Valkey has, Valkey and Redis have historically had a durable version called append-only files, which was pretty much self-instance. We're trying to make it a durable multi-node distributed system, and this will allow people to actually run stuff. Like we kind of want to replace Kafka 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 similarity search where you actually do want the indexes durably committed. So those are the 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 Valkey project's 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 mil- microsecond reads, um, which is still 100 times slower than DRAM, but as long as you carefully orchestrate how you're fetching the data, it's can almost be free.

So those are the two big things we're working on as a project. But yeah, we're al- always hopeful to get more things. Those are features that are probably gonna come out in the next six to 12 months. And of course, there's a lot of other stuff. We're releasing Valkey 9.1. It should be out by the time this pod comes, podcast comes out.

That adds performance improvements, memory efficiency stuff. Those are the bread and butter that-

Corey: Well, that's putting an awful lot of faith in GitHub, uh, staying up long enough to ship a release. I'm sorry, that's unkind. Fair, 'cause it's very expensive, but unkind.

Madelyn: I, I sh- I wasn't gonna complain about GitHub, but I'm still not gonna complain about GitHub.

Uh, all the current problems we're having are our own problems. We're trying to release when... As, as of recording of this podcast, we're trying to do a, a, a patch release of Valkey and it is taking forever.

Corey: 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 and it's sincere.

However, they're also shoving Copilot at anything that holds still long enough, and many things that don't. So it's, it feels like you, you don't get to sell the problem and then complain about it.

Madelyn: I mean, that's capitalism, right?

Corey: Oh, it is. I just... It's, I, I sit here and I shake my fist and it makes me angry.

If, if people wanna learn more about what you're up to and what's next in the exciting world of Valkey, where's the best place for them to go to find you?

Madelyn: Best place to find me is probably on Bluesky. I'm reconditerose, uh, bluesky.social. You following the Valkey project, valkey.io, there's a blog section which we publish relatively frequently.

We've almost gotten enough content that we have a weekly blog release cadence about everything new and exciting on the Valkey project. Uh, LinkedIn is also a great place to follow both Valkey and me. I mostly just repost stuff, but it's kind of what's going on in the project. We're, we're planning to ho- uh, host a Valkey event, uh, at the Open Source Summit in May.

That will probably not... Maybe we'll be in time, but more likely we're hosting a, an event called Unlocked this week, but there's also gonna 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 Valkey, we're planning on hosting an event there later this year.

Corey: 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.

Madelyn: Excellent. Hope I, hope I wasn't too AI-pilled for you.

Corey: Not yet. That's okay though, 'cause I'm gonna write conspiracy theories about it myself.

Madeline Olson, AWS Principal Engineer and core maintainer of Valkey. 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 on 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.

Get the Newsletter

Reach over 30,000 discerning engineers, managers, enthusiasts who actually care about the state of Amazon’s cloud ecosystems.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Gnarly cloud cost questions?

Good news: we’ve got answers (and coffee). Meet the Duckbill team for personalized advice on your thorniest AWS challenges.