What Happens When AI Writes Battery Software 

HeatSpring instructor Peter Gruenbaum spent years writing software that tells batteries when to charge and when to discharge on utility-scale energy projects. When he built his course on battery energy management systems for HeatSpring, he leaned into AI as a core tool for the exercises. The results were instructive, not just for students, but for anyone thinking about how AI fits into real engineering work.

In this clip from a recent HeatSpring PRO Circle, Peter and HeatSpring founder Brian Hayden dig into the practical reality of using AI to build battery software, including two cases where it got things meaningfully wrong. You can learn more about HeatSpring PRO here.

The transcript below was edited for readability.

Brian: You mentioned AI and just kind of like how it can be a black box, so this idea of digging into the logic of how the software you’re writing works, so there are clear decision-making parameters you could explain to a customer and I think that’s an interesting thing. In terms of this course that you’re offering, how are you thinking about the use of AI in writing the software?

Peter: It was an interesting process. In talking to you guys at HeatSpring and coming up with this course, the suggestion actually came from you to use AI in the course. And so I ended up doing that, and it worked well in the sense that it allows the person taking the course to really focus on the concepts and not get stuck in the weeds. Like, how do I build this web service? How do I send messages back and forth? I don’t need to worry about the code or working in a particular programming language. The course is built so that you’re working with AI prompts, it generates the code for you, and then you can try it out.

I have you write some unit tests, because my personal philosophy is that AI shouldn’t write both the unit tests and the code. It should be one or the other.

It was interesting to see how easily it would generate something useful, but also that it had its limitations. I was working on a battery simulator, and I asked it to improve the software so that it has these safety zones at the very top and bottom of the state of charge. So as you get above 90% charge, it starts to limit the amount of power you can take in, and the same thing at the bottom, below 10%, it limits the amount of power you can take out. And then I was thinking: is this thing smart enough to notice the edge case where you ask it to charge into that zone? Because if you do, it’s no longer going to be able to put out the power that it started with. And the answer was no, it didn’t do that. I had to prompt it again, say you need to handle this case, and of course it said “oh yes, you’re right” and fixed it.

That struck me as probably a real limitation of AI: thinking through where things can go wrong and making sure the software handles those things.

The other situation was a very complex prompt about bid optimization.  And I actually made a mistake in the prompt. I had told it, whenever you do a bid, you’re basically saying at this time, I am going to bid this quantity of power for this time and at this price and the quantity is positive. From the market’s point of view, a positive quantity means you’re buying power from it and a negative quantity means you’re selling power to it. I told the prompt that’s how it’s going to work, and then I gave it a formula for calculating profit and I screwed it up. I put it backwards. A human being who understood the domain would come back and say “wait, that doesn’t match.” But AI just did the best it could, came up with something that looked kind of reasonable, and it took me two or three days to realize it wasn’t actually right.

So I see a lot of potential to get things going, to build out your infrastructure and set up the web services you’re going to need. But I think you still need a human being in there once the problems get very, very complex. For things like bid optimization, you need a real data scientist to make sure that what you’re doing is actually going to work.

The Take Away for Solar + Storage Professionals

The energy storage software space is growing fast, and the people who need to understand it go well beyond the engineers writing it. Trading group liaisons, asset managers, procurement leads, solar developers, they’re all being asked to evaluate, question, and work alongside this software. Knowing what it can and can’t do on its own is part of the job now.

Peter’s two courses at HeatSpring are built for people who want to move from adjacent to fluent in this space. The introductory course is free and designed for anyone who works with battery systems and wants to understand the software layer, no coding required. The second course is hands-on for software engineers and developers who want to build a simple version of the real thing.

Sign up for Peter’s Courses

Introduction to Software for Battery Systems – Free

Software for In Front of the Meter Battery Systems

This conversation was recorded as part of HeatSpring PRO Circles, a member benefit where HeatSpring PRO subscribers get direct access to instructors and practitioners across solar, storage, and skilled trades. Learn more about HeatSpring PRO.