PurePerformance - Can AI Save the Planet — Or Is It the Problem? Building Green Software With Anne Currie

Episode Date: August 17, 2026

When AI can generate and optimize code at scale, does that make software greener — or just faster to get wrong - or does it cost more to train and run those AI models then the savings we have optimizing our own software? Anne Currie, co-author of O'Reilly's Building Green Software, joins us to untangle the paradox. US data centers are on track to consume over 10% of the national grid by 2030 with a growing part of that energy going to AI workloads, yet it may also be our best tool for writing more efficient software — if the training data is any good (spoiler: for C, it often isn't; for Rust, it's a different story).In our episode Brian, Andi and Anne get into the fundamentals that most teams are skipping: operational efficiency. Turning off systems you don't need, rightsizing what you do — these unglamorous moves can slash your hosting bill in half, and they're the prerequisite for any code-level green gains to actually matter. Plus: graceful shutdowns, grayouts, and why we'll probably need AI to eventually rewrite itself.Links we discussedAnne's LinkedIn: https://www.linkedin.com/in/annecurrie/Her podcast: https://www.asynchronousunreliable.com/Chapter 3 of her O'Reilly book: https://www.strategically.green/chapter-3-code-efficiencyFull book on Amazon: https://www.amazon.com/dp/1098150627Brian's story on Myst: https://www.youtube.com/watch?v=EWX5B6cD4_4

It's time for pure performance. Get your stopwatches ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody. Welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have with me, my co-host Andy. Hey Andy, I've got like a song stuck in my head now. Why?

Are you familiar with the Muppets? I do. I am. What was one of the big songs Muppets, Kermit sang? you mean Kermann the Green Frog, right? Yes. I don't know.

It's not easy being green. That was my Kermit impression, so it's great for everybody. I don't know why it's in my head though. Well, it's because it's the opening quotes to my book. Oh, look at that. Look at that. Look at that. That's amazing.

Who are you? Who is that mysterious voice? And I think this was the best way to introduce or to put yourself into the podcast now. So now go ahead. Who is this mysterious voice? So hello. My name is Anne Currie.

I am one of the co-authors of O'Reilly's Building Green Software, which was just introduced there as the first quote at the beginning of the book was Kermit and Frog saying, It's not easy being green. Look at that. Brian, did you know that? I did not. I did not know that. So sorry to say, Anne, I did not read the book.

She caught me. Very good. Hey, Anne, thank you so much for being on the podcast. I know you also run your own podcast, mind reminding us what that podcast is about and which guest you have. Yes, so the podcast is called asynchronous and unreliable, and it's about modern code techniques, which includes performance and code efficiency and operational efficiency and distributed systems,

and as well as an awful lot of how you agree, how you be sustainable. And I get all kinds of, I've done 20 episodes now, I get lots of different guests from all kinds of those areas, so performance efficiency and sustainability. Or a couple of security people as well. So actually really quite aligned, I suspect, with your guests. Yeah.

And it's funny, Brian, how long? We've been doing this. We mentioned this in the last recording. We've been doing the podcast now for a little over 10 years. Yeah. Yeah. And in the early days, and for you as a background, both Brian and I, we have a performance engineering background,

performance tester, performance engineering. Currently, we both work at Dinah Trace where we see and help a lot of our customers getting insights into their apps and we help them based on the insights try to figure out where inefficiencies were, I think, slow. I also remember in the early days

of my career, we wrote a book on Java performance optimization and detecting patterns. And I was also reading through Chapter 3 of that book. And there's a version available, I guess, for

free from O'Reilly, which people can read and also use as long if you quote it, then you need to obviously reference the source and everything. But you also talk about patterns. I think you talk about inefficient callings of APIs. Brian and I typically talk about the N-plus-1 query problem to the database or a downstream system. So this is why it's so fascinating to have you on the podcast, because I believe we share obviously a common passion for this, but I'm pretty sure you bring in maybe your own.

perspective because we all interacted with different people. So yeah, that's why it's really cool to have you. Oh, it's really cool to be here. Yeah, yeah, we do have a passion. It's although, you know, obviously I want to be green and I want to save the world and I will want to save the world by making code more efficient. I just really like code to be efficient. I think I'm even older than you two.

So at the beginning of my career, the hardware was very, very flaky and very weak. And we just had to write more than code. But as hardware has got better, a lot of those skills and the need has disappeared. But that makes code quite wasteful. And that upsets me. Yeah. And actually, this was one of the questions that I had. You wrote this book, I believe, about two, three years ago, if I'm not mistaken.

And I got to admit I only read, you know, through that particular chapter. And as you just said, in the early days, coding was very hard. If I think back, I started learning a sampler in the 90s. So I'm familiar with how to try to write efficient code. And then in order to make developers more efficient, we provided them new tools, new abstraction layers, new frameworks to make them more efficient. But meaning making them more efficient, the result was not that efficient. Now, but here's my twist and my question.

Because you mentioned in that chapter, it would be not sustainable from an engineering time perspective to re-implement every piece of code on individual different hardware platforms, right? It would be ideal if we could do this, but it's inefficient because we don't have as much developer resources. Now, with AI, this all changes. So my question would actually be choosing a language or having the ability to just say, we regenerate that code because regeneration is so cheap does this change the game

or not? Well, I mean we're really desperately hoping so. I mean, it's the irony of AI, isn't it? At the moment, AI is itself. The code is very inefficient. And therefore it's causing massive, massive increases in energy use and electricity use

by the tech industry, which had been flat for years and years and years. And now, of course, it's I think there have been estimates that data centres are currently drawing 10% of electricity for the US grid. It's, you know, huge amounts of money are going into data centres and to run quite inefficient code. Because at the moment, AI is not optimized? So the question you're asking there is, is AI the solution to that, though? could AI be making itself more efficient?

And there are multiple, because this is something that's really been interesting me. On my own podcast, I've brought on a lot of people in asking them that question, what's standing in the way of AI making itself more efficient, making all the code more efficient. And there are at least two things at the moment, because it's not making as good progress as you might hope, because this AI is showing incredible value as something that's able to rewrite code in a more efficient way.

One is which language you choose. Now, there are lots of languages out there. For example, a lot of the efficient code at the moment is written in C or C++. But the code that is produced by AI in C++ is not that good quality. because there's so much C and C++ code out there and a lot of it is old and doesn't follow modern practices. So the training data set for C and C++ is quite contaminated apparently.

But the good news is rust is quite good. AI is very good at producing rust and the rust is of reasonably good quality because rust is quite modern. and the Rust code because Rust is so hard to write the code that actually does get written and published in Rust is quite good and it's quite modern and it's quite recent

so yes if we still have to work out how we're going to train the AIs to produce good quality performance code but that is at least one way of doing it is to write it in Rust having said that Oh, well, I mean, stepping back, we all know that there are lots of problems with writing perform and code,

which is why engineers don't do it. You know, it tends to be specific rather than generalized. It tends to be really quite specific. And then it's often quite hard to train the AI to know when to apply specific techniques versus general techniques, because a lot of the codes out there, even the Rust code, is still quite generalist. So it's learning from generalist code, but to do a good job, it's going to have to be quite specific and non-generalist. So I had, I don't know if you've, the ex-CTO of Docker and Justin Cormack,

who was one of the founding teams of the Unicernels project, if you heard that was about a way of producing much smaller, lightweight and more performance, Unix kernels, as much smaller Unix kernels. he does quite love looking into what's going on with languages and whether they're getting better at writing A in the moment he's thinking the best one out there is Rust but he did mention the language pony

which is a bit of a niche language it's such It's your little pony It's my little pony sorry I was making a dumb There's an old cartoon It is yeah my little pony Yeah my little pony yeah They're my little pony.

But it was a really good example of a language where it's a small niche language. There wasn't a great huge amount of training data out there for it. So the guy behind it, and it really is like a guy, produced his own training set, which was very targeted to the particular use case for pony. And I'm not an expending pony, so I don't really know what that data set would have been. But it worked out very well. apparently it's working very well for niche languages to produce their own training data sets. And it might be with performance code.

We're just going to need to start producing our own niche training datasets for that so that it is polluted by the majority of code in every language, which is not very performance. And this brings me to a question, Brian, that the two of us have brought up a couple of episodes ago. because we had a discussion about currently we're using AI to make it easier for the human to generate code on languages that were designed to be used by a human.

What about if we would design a language to be used or like with the target audience of an AI? So could we, would we now design completely different languages because we don't need to care about the human anymore that the human understands everything and needs to write it?

would that lead us to better languages with better outcomes? I think in the long run, that has to be the case, doesn't it? Or even you stop with the languages at all that move straight to getting the AI to write assembly code. It means that humans couldn't read it or maintain it, but then you also need to get the AI to read and maintain it. So, yeah, it's, so the interesting thing there is you're both associated with, diagnostics, telemetry, tracing. To do that, you need to basically hook up the AI to be optimizing the code based on telemetry, on information.

But then not necessarily. So the telemetry becomes incredibly important and the testing becomes incredibly important. But maybe the code isn't really all that important and certainly doesn't need to be human readable. Right. Yeah. We also discussed, I'm not sure if you know him, and I need to quickly look him up.

It's called the Phoenix Primitives. Oh, yeah, I was just writing some about that. Yeah. So Chad Fowler, and just a shout out to him, I also saw his presentation. He made a really, he had an interesting blog post and also several conference talks, and his idea, and I just read the sub-header of his article.

The article is called the Phoenix Primitives, and it's called the architecture of a regenerative system is defined entirely by what you can't delete. And he makes the point that, like we said earlier, generating code used to be very hard. And therefore, you know, we spend a lot of time and we focused on the coding, not so much about writing everything down what it's supposed to do. But now, if we are focusing on the spec, if we do spec-driven development, then today we can decide this service should be implemented in Java, for whatever reason.

Tomorrow we may decide to have it re-created in Rust because maybe Java has a non-security vulnerability. It was just detected and who cares in which language it's written if it does what it does. But for that you need obviously good specs and also good tests and good evaluations. And so I think to your point, right, this is then where the language itself becomes completely, will most likely become completely irrelevant. as long as we are as humans confident enough that we don't need to understand what the code actually looks like that in the end compiles down anyway to machine codes.

Now having said that, I had this conversation on my podcast with Justin Cormack that Docker CTO Unicamp's guy and he said that he still thought there was at the moment at least vast benefit to particular languages and he specifically said that Rust is probably at the moment the best one, because it's kind of a way of telling the AI what you want it to do overnight when you're asleep and it's writing the code for you. Because Rust is very opinionated and the Rust compiler is very opinionated.

So you can just basically say, well, what will Rust allow you to do? And what will the Rust compiler allow you to do? You can just effectively, you can get Codex or Claude or whatever, can just be putting things through. the compiler and the compiler can be saying, no, I'm not compiling that, and it can iterate while you're asleep and come up with something. It's effectively, the compiler, the Rust compiler being so opinionated is a way of directing the agent while you are not present to do the direction. So at the moment, Rust is massively ahead because it has that massively, it has that incredibly

opinionated the compiler. And I think that the Rust vote know that, and they're adding even more stuff to the compiler. And I know there are adding support for functionality that humans wouldn't really write, like new types of tests that are really, really expensive and difficult for humans to write, and are difficult to apply, difficult to write all the tests. There's a whole load of new kind of testing going in to be supported in Rust because they know that actually the amount of tests you can write has suddenly expanded out massively. So they, Rust really are, they're with the program, you know.

They know what, they know how people are writing Rust now. And as you said earlier, Rust is a rather modern language that means there's not so much, I wanted I wanted to write the white words without saying bad and legacy but yeah there's not as much experimental code

thank you for the training material yeah that's really interesting I got another question for you obviously ideally we optimize our code

to use less resources, right? So doing what it's supposed to do. I think you also make a good point. Real good is a code that does exactly what is supposed to do, not more and not less. The question is always where is the boundary and what does it need to do. But as soon we are optimizing everything and we are currently leveraging the big hyperscalers to host our code and their business model is obviously to sell us their capacity. If we all optimize the code, How will they make their money? Isn't it a little contradictory what we want and what they want?

Oh, yeah, probably. Well, the thing is the big hyperscalers, so my husband, who's regularly on my podcast, used to work for Microsoft. And he always used to say to me, remember, there is no Microsoft. There's no Microsoft, there's no Amazon, there's no Google. There's such big organizations. There's every possible view is represented within them. there will be some people at AWS who are going,

oh, no, we don't want them to write optimal code because then we won't sell them so many servers. I've spoken to a lot of senior people at AWS who basically say, oh, if only people would optimise their code, the specific way they would like people to optimize their code. There are a load of people on AWS who are still running older versions of Python, really early versions of Python, which are both insecure and.

and really inefficient compared to modern Python, at least they've got their core libraries in Rust, and they're five, ten times faster than the old versions. But most people, most enterprises are still running the old versions. So an awful lot of AWS hardware is taken up just, you know, running totally is wasted, running old versions of Python that could be running. And they would much prefer everybody to be moving, over to their new versions of Python

and using that hardware to do stuff that's more profitable for them. Because dumb use is not very profitable for them. And I suppose too, just the expense of the hardware itself and maintenance of it in the data center space, you know, if you can

have more, you know, there's probably a trade-off between the physical space, real estate hardware versus how much they make from people running stuff on there that's going to be a good balancing point I'm sure somewhere there. And question, I'm sure you talk

with a lot of organizations that have a lot of existing code. What is a good strategy to start figuring out where to focus your efficiency improvement program on? To you, is it, like,

where do you start? Well, I always tell, in building green software, for most of the enterprise, so we said that always where you start is is making your operations more efficient. It's like, it's before we get to your point, before we get to chapter three, which is about code efficiency,

we're first looking at, do you have a whole load of just stuff that machines turned on, they're not doing anything, massive over-provisioning? That's usually the way you can cut your hosting bill. You know, cut your hosting bill by 50%

by just turning stuff off is, is the usual place to start. because the code efficiency is quite hard and the operational efficiency is relatively easy compared to that and as well if you don't get your operational efficiency right first all that hard work to get your code efficiency working well is wasted because you're running maybe you're only utilising maybe you were utilizing 10% of the machine

maybe you moved to only utilising 1% of the machine because you've improved your code efficiency 100-fold. But actually, that doesn't really save you very much. Yeah. So it's interesting because obviously, you know, there's a lot of politics around the idea of green. Yeah. Right?

Yeah. But the other definition of green doesn't have any politics, which is the money saved from it, right? And I think it sounds like, the more efficient code and the more greener environmentally your code is the more green money you're going to save. And that's, you know, especially from a business point of view and it's like bottom line. Like that's, I think, the huge incentive there because, you know, as, you know, Andy and I talk to all of our customers and it's, you know, are we running efficiently from a financial point of view? Are we, do we have what are our biggest wasted AWS instances and how can we right size?

right so that comes directly back down and the benefit of it is like yeah now you're using less energy and it's much greener so you you don't even have to for for places or certain countries i won't name that are resistant to the environmental movement um you know you don't even have to talk about it in that sense you know it could just come down to to like financial operations it's really awesome that it ties directly to it you know yeah we're quite careful with it in the book, because we don't cheat, oddly enough, we don't get to choose the names of O'Reilly books. O'Reilly do that. We probably would have gone something like good and efficient software.

But they said, no, you should call it green. We're trying to come. I'm happy to call it green. But we all quite careful in the book to say, well, the definition of green software is good software, a software that is good at what it does. It's not wasteful. It's good.

It's performance. It's not overly costly. It's not insecure because you haven't got loads of hardware running that you don't know what's going on and it's wasted and therefore no because it's paying attention to it so it gets hacked. It's more resilient. Modern resilience practices where you kind of use auto-scaling for resilience rather than duplicating servers. It's more resilient and it's also more efficient. So, you know, good software and green software are not two different things. I feel.

It's also, I want to come back to the, and I took some notes, I think you said, if you don't get your operational efficiency right, you really don't get the benefit of code efficiency, which is much harder to achieve. And so besides shutting things down, I remember on the Kubernetes side, I'm a CNCF ambassador,

and therefore that's a very close community for me. I remember the Cube Green was a project, project or is a project that allows you to exactly schedule pods to go down to zero. This was in the early days, like really shutting things down that you don't need, because obviously there was no concept in the beginning that a pod is always running, right, but scheduling it to zero. Also right-sizing your deployments in terms of resource and memory limits, and therefore maybe you can run your workloads at a certain time during the day on fewer or smaller Kubernetes

nodes. And then, so I think this is just, again, a reminder for everyone. I really like the way you phrase that if you don't get your operational efficiency right, you don't get the benefits of any coal efficiency, right? Doesn't make sense. Are there other operational efficiencies besides right sizing and shutting things down? Well, there's, so it's obviously there's right sizing, they're shutting things down. There's, I mean, they are the two main ones.

I mean, the other one is work shifting. So things like spot instances, where if you write code so that it can just be turned off and then delayed. So if you're basically less latency sensitive in your code, so you can delay it until the sun shines or the wind blows. Or effectively, that the electricity becomes cheaper on your... grid because the sun's shining and the wind's blowing, then that's incredibly green. It's also very resilient and it's a heck of a lot cheaper. Yeah, so it's basically patch processing. So you're doing certain things in batch or like your work item processing, whatever the right

term is. Yeah, you delay things. Yeah, that makes a lot of sense. So there's another, so I always used to like to use the analogy of the internet. So why does the internet stay up? Why is it so stable? One of the reasons, one of the ways that it is stable is it's very good at supporting what in the electricity grid, on electricity grids you would call brownouts. So fundamentally you say, well, hang on a minute. The electricity has dropped or for the internet, the bandwidth available has dropped. I will just do try and provide a good enough. service on less bandwidth. And we do that. That's how we keep the internet up.

That's how we always kept the internet off. You go, well, hang on a minute. Let's make this video conference call a bit choppier. You know, let's drop quite a lot of the frames and let's concentrate on the bit that's really important, which is the audio. We are very, on the internet, we've been very, very good at graceful downgrades. So you kind of keep 90% of the, you know, or 80%, you're, your Pareto principle, keep 80% of the functionality for 20% of the resources used,

which is quite common, is it that you can do that. That kind of thing is resilient and it's cheaper and it's green. So it's good software. Green software is good software. Brian, this reminds me of the Super Bowl discussions we had years ago, where I was GoDaddy, who were the first ones to say during the story, this first story that I remember, where they were for the Super Bowl. basically deploying a stripped down version of their website,

just optimizing it exactly for that peak load. And they were not going down. They had great conversion rates. And then instead of talking about, look at this website, went down again because we're so successful. They actually said, look, we stayed up because we did the right thing.

Yeah. Yeah. The other thing I think about too, and I don't know if this is part of the discussion, Andy, this ties back a little bit to last weeks or two weeks ago's, podcast. So when you think about AI and token consumption and all that, right, a lot of companies, unless you work for one of the big token manufacturers, right, developers are given a budget

that they can use, right? $50, $100, $200, whatever it might be. And they have to learn how to use AI within that consumption model that they've given. So they have to figure out all these ways to, you know, put it in skills or, you know, different things to reduce that. Now, if you go back, again, if we go back to the way past where you had floppy disks with 250 kilobytes on them, or even if you remember the game missed, right? Mist had no business

fitting on a CD-ROM. There's actually a fascinating story on how they made that work. I think it was like Apple Pages or some kind of weird program they were able to use to be able to fit it onto a CD-ROM. So part of the built-in efficiency back then was just restricted amount of size

that a program could be. Nowadays we hear about like, oh, there's like, you know, 500 million lines of code in your car, right? Would, are, is anybody looking at making a practice of giving developers quotas in the size of their code to try to help force efficiency? Because it just seemed like, you know, I remember I installed Windows 2000 from five floppy disks at one time, you know, the many ones, right? And then, you know, years later, not even many years later, you sit there like, oh my gosh, most, like half of my heart. drive is just the is the operating system. So is there any

kind of push or movement to try to get people to like write code within a size quota to force efficiency upon it? Well, yes, there is. Oddly enough, not in America, you'll be unsurprised to hear that America is not very much

up for constraints. Bigger's better. But China, they were, you most of heard that the Chinese models have got, so when Deepseek came out at the beginning of 2025, they said, well, we were able to do more or less what the, the frontier model's doing at 10% the cost. And everyone went, no, it's that impossible. They couldn't possibly do that. It turned out they were just using a few algorithms that had been defined in the literature.

They didn't invent anything. They just, it was because they were, because they had a constraint imposed on them, which was that Biden had barred the exports of fancy Nvidia GPUs to China. So they only had quite old school not so good Nvidia GPUs. So they were forced to come up with ways to do the same, to produce more or less the same quality on those rubbish GPUs rather than the expensive ones. And as a result, they did. because there's tons of unexploited

efficiencies. Yeah, yeah, yeah, waste of optimist things, yeah. And you're right, constraints are the only thing that cause people to actually put the effort in to find them. Yeah, and this reminds me, Brian Wright, our previous guest, Michael, from 1.5, he said when they did their proof of concept of adopting AI coding agents, they were using cursor.

They got the option to get unlimited tokens for the PUC and they said, no, we don't do this. We are going to constrain our developers to whatever it was, 50, 100 euros. 50 dollars a day. Yeah, 50 dollars a day. Yeah. And to make sure that they are living within these constraints

and cannot just go off and go like crazy because A, it helps them to better leverage and understand the technology and B, once the PUC is over, there's no more unlimited. tokens and then going back to a constraint way is very hard.

Yeah, one of the difficulties at the moment is because AI is getting better at such an incredible speed. With one exception actually, which we should talk about, but generally AI is getting better at an incredible speed. So there is an argument

that people can't stop and optimise because they need to constantly be trying, you know, running to keep up with the leading edge. otherwise they might get left behind. So that's kind of like there's a bit of panic there and a bit of a race and therefore people aren't working with constraints unless the constraints are imposed on them.

But having said that, I heard an interesting thing the other day, which was that Gemini seems to have stopped attempting to keep up with the frontier models. So if you're on Gemini, you're not quite running. quite towards the leading edge as fast as with the other models. So that tends to suggest to me that Google is doing something else. It's like, what are they doing with their time? I mean, they won't have just given up on AI. It may be their, but their focus is not on, at least not on developing

cutting-edge frontier models that are exposed to the rest of the world in the same way. anthropic art or Claude is. We don't know what else they're doing. Is it efficiency? I don't know. Probably is some that it would be efficiency. It will be maybe cutting edge but targeted more towards what they need the cutting edge rather than a more general case cutting edge.

I don't know. But there are people out there who are starting to say, I'm not going to run as fast as possible anymore. Yeah. That's interesting. So maybe they just say, you know, we're not going to fight dead for war. There's another thing. that might be more lucrative and forward-looking

what's coming afterwards, yeah. But as I was saying before, all of the hypers are such huge organizations. They're usually doing all the things. But in this case, there is a specific thing they're not doing, which is they don't seem to be going head-to-head with codex and thought anymore. Looking at the book, so I've only had the chance

to read Chapter 3, which is a very, by the way folks if you're listening in as always or any relevant links we will add to the description of the podcast so people can follow up also and links obviously to your LinkedIn and to your website to your podcast website is there what other things in that book do you think would be it would be great for for our listeners to have a look at what other chapters besides chapter three should should what's the right word motivating to buy the book? Well, so chapter three is the code efficiency chapter,

which, oddly enough, when we wrote the book, O'Reilly said, the first chapter has to be the code efficiency chapter because everybody wants to read the code efficiency chapter. And we said, no, we're not going to make that the first chapter, because actually it's not the first place you start for me. You know, you start with operational efficiency. So there's the operational efficiency chapter that's before the code efficiency chapter, then the cod efficiency chapter.

And then, well, one of my first, favorite chapters is the networking chapter because that does talk, I think that's a really good worked example of greyouts and graceful downgrades, really, really useful tool to do. Oh, gosh, there are loads of good chapters in that. So for your, which is the most techie chapter. The introduction is pretty techy as well. To be honest, the whole book's pretty techy. It's fine. It's meant to be a beach read, which is not very common. No, Riley, but I'm going.

Hey, on the network, what are, besides the graceful kind of degradation of services, are there also, I guess, common mistakes, configuration mistakes on the network, inefficiencies and data transfer, or what else can I think about, like caching or what are the common things there on the network? Yeah, so I talk a lot in the chapter about caching.

So at the large scale, obviously, CDNs for networks, but there's plenty of caching is a useful tool all the way down. I talk a lot about design, because obviously code efficiency is kind of, there are two kinds of science to do it, aren't there? There's the design. Have you designed in a way that code is being called unnecessarily or being called repeatedly when it doesn't need to be called?

repeatedly, especially if you're calling out over APIs or expensive network calls. So think about your design. Are you, is your design wasteful? Is it duplicating? Are you replacing, is it repeating yourself? But there's also the code. It's like tuning the code is a different problem to tuning the design. But for most of it, We know full well that performance tuning is trial and error. You have to have a really healthy attitude to trial and error if you want it to help produce performance code. I remember one of my presentations that I did.

I think the talk that I gave the most at any conference was called the top performance problems in distributed architectures. And it was exactly what you're saying, but inefficient. calls from one service to another, inefficient, like requesting too much data, pushing too much data around. I had an example of one of our customers, actually. They used to have a monolithic application, split it into microservices. And initially, the use case was getting a document and then the document was analyzed by

different capabilities and features. And every feature or every step needed a little different piece of the document. And when they ripped the monolith apart into microservices, they have a little bit of basically sending the full document, megabytes of data from one microservice where they only needed a little bit to the next one, to the next. And in the end, it was a complete waste of

sending data around, not only on the network, but also the whole marshalling, un-marshaling of the data, keeping it in memory. And these, so it's interesting to see that these patterns, and Brian and I we've been talking about the same old pattern, they never go away, right?

It's always the same things, yeah. Yeah, and the irony is that AI, so AI is very good at that kind of low-level optimization. So you say, okay, write some code and he's a metric and optimize this code against this metric. That's it's very, very good at that. It's like a dog with a bone. It will keep going.

You know, it's very great. It's fantastic trial and error for that kind of thing. But the larger scale thing, the design level choices, like, you know, stepping back, should we really be sending this document here, there and everywhere? What is that actually adding value? At the moment, that's humans really. still need to be involved to do that kind of thinking.

Yeah. Yeah, and you also need to have somebody that has the end-to-end understanding of the actual business case or the use case. Because as an engineer maybe that needs to then implement one of these services, I may not even ask the question. Does this make sense? Because do I know, do I get one document a day, or do I get 10 documents per second?

Indeed. Indeed. Yeah. And then you mentioned AIs are great for automating and trial and error. Brian, this reminds me of our friends from Akamas, from Italy, who are doing goal-based performance optimization. So basically what they do, they are looking at a system that is under load. They're looking at the telemetry data,

and then they can make tweaks, like changing the memory, changing garbage collection, changing thread pools, connection pools, all the hundreds and thousands of different things. Andops you can turn on the JVM on the data. base layer or anywhere. And they basically find the optimal configuration that you can reach your goal and you can express your goal as I want to reduce memory consumption by 50%, but I also want to make sure my performance stays within a 10%, let's say, corridor, right?

And so they're running experiments to find the right configuration of the system. Yeah. It's pretty cool. Yeah, that is very cool. So, I mean, of course, that's an interesting one because they've set that up. so that that could be automated. An AI could do that, but only because they've done the work to pull all the data together,

to pull all the telemetry together and provide an interface that... Yeah, exactly. Good. Hey, I know we are already getting closer to the end of our recording session here. Looking maybe a little bit into the future, I know we're all, before we hit the record button, we're all talking about that we're all living places right now where we've never experienced so hot and dry summers obviously the world is changing around us we can just try to figure out what we can do to contribute to not make this worse we believe all that green engineering

is obviously one way we can contribute looking forward into the future any positive statements that you have any encouragement for people to really work on this hard Well, I would say that in the tech industry at the moment, you might feel, oh, my God, it's been with the baddies. And this is quite recent. Five years ago, we were the goodies. But now with the bad news because of AI, we're using so much electricity and building all these data centers. But the good thing is that data centers do not have to be evil gas-guzzling monsters. There are plenty of ways to do them in a way that would actually help the energy transition and help grids.

and be greener. I don't think there's any industry at the moment, apart from maybe the oil and gas industry, but there's almost no other industry where there's so much room for improvement that isn't that difficult to deliver. And we just have to decide to do it. We'll just build them in space.

Yeah. Yeah. Yeah, no, I mean, for me, it's like always been, I've had a love-hate relationship with AI, And because of all the energy stuff, you know, it leans more towards the hate side. But it's like if they can figure out how to make this efficient, right? Then it's going to be useful. But at the rate it's going, it's like, oh, we can't keep doing this, you know.

But, you know, and it's really ironic, you know, the idea of using AI to write more efficient code to save energy while using that. But again, there's that part of that loop. We just have to have people focus on. that. And I think it's really always, it always comes down to money in business, right? And if you think about just the amounts of money they're throwing into this stuff, that's unsustainable, I think that's going to be the biggest driver that's going to force that at a certain point. And, you know, we just have to hope the world doesn't burn before it gets there. Yeah, we really do have to hope that. I mean, it's an interesting, there's a, there's a saying, physician, heal myself. But,

Yeah. And really, you know, AI rewrite thyself is kind of like, once the AI gets good at rewriting code to be more performance, we need it to rewrite itself. Yeah. Because, you know, we were managing before AI came along, but we need that code is very inefficient because everybody's in a race and it's very new.

Yeah. So we will need the AI to rewrite, yeah. I'm taking some notes here also for the good sound bites that we were going to use to promote this. We will need the internet rewrite itself. This has been amazing. And is there any wrap-up conclusion you want to say to the audience? No, I think that the wrap-up conclusion is don't give in here. I mean, there is AI has immense possibility to action.

improve the situation. The risk of misquoting another quote, the only thing we have to fear is fear itself. If we think that AI is only going to be bad and it can't fix itself, then it won't. Because we need to try. The first stage in trying is believing that it's possible. So don't let anybody convince you

that there is no way that AI can rewrite it. itself will be more efficient or contribute to the energy efficiency, to the energy transition because it can. We just need to find a way. We just need to make sure that it does. Yeah. And I think I'll use the right British phrase for this. You know, AI is still in its infancy stage, so it's still in nappies, right? Indeed.

And it's all those dirty diapers that we're dealing with right now, right? But this has the potential to grow into a wonderful adult human being that can contribute greatly to the world. We're just in that phase where it's spitting up everywhere and just creating chaos and havoc. But I think we can all see what it can become. And we just have to get to that phase, you know? Yeah. Yeah.

And believe that phase and expects it. So something that I was quite hardened by, today actually was the news out of the US that lots of the anthropic and open AI and people are saying, well, can we call a halt on frontier models? Can we just say actually stop for the moment and catch up with where we are? Because while we're not doing that, we're not making things more efficient. We're not finding ways to make money at them. And the frontier model, are just blowing cash and they're not having time to do that either.

So I think, oddly enough, halting AI for a bit would actually be great for the productivity of the world. Yeah. Hey, thank you so much for this conversation. Brian and I always say the best thing about hosting a podcast is you get to talk to so many amazing people that have different perspectives on topics that we also care about.

And thank you so much for doing it. Also, keep doing your podcast. We'll definitely promote it through our listeners. So, folks, check out all the links in the podcast description. And stay cool out there in this hot summer. I'm going to throw a link in there, too, to the, how missed, are they able to fit it on the CD-ROM? Because it's just a great thing in there.

And I do want to make fun of you one last time before we leave. the day, Andy. One thing I started noticing is whenever you talk about, we're going to put a link in a show. You address our listeners and say, if you're listening, the link will be in the show. Yeah.

So, anyway, thank you again, and this has been a lot of fun. Appreciate it, and everyone, yeah, stay hydrated. Thanks very much. Bye-bye. Thank you.