Len Epp interviews David Campbell

Cleaned from YouTube auto-captions for readability. Speaker labels and light disfluency trimming added; obvious mis-hears corrected (JMeter, Leanpub, agentic). Raw SRT in the repo at docs/press/2026-05-16-leanpub-interview/transcript.srt.

Len: David, welcome to the Leanpub launch video for AI Performance Engineering: How AI is Transforming Load Testing. I was wondering if you could take a moment to talk to us a little bit about yourself, about what you do, your background, and what your book is about and who it's for.

David: Sure, yeah. Thanks so much, Len. The usual way I introduce myself is: I break things. I break stuff. It's, I guess, a natural talent for breaking. Performance testing, load testing — that's my hands-on background. You could say I was forged in the fires of consultancy, tending to be the interface between the consultancy and the end client.

David: I've always had a passion for tinkering. That's what drew me to my work — tinkering with the tools. I had an opportunity to go full-time as a consultant doing just that, because I used to wear many roles earlier in my career. I was being groomed as a project manager, grasped it with both hands, and gravitated towards leadership along the way — doing some saving of departments, building of divisions.

David: Then I got to a point where I was getting more hands-off and missing the hands-on. I had an opportunity to get more into innovation work and more hands-on again, tinkering with AI. I was opening up the architecture of JMeter, which was a performance test tool I was using on a client engagement, and tinkering with AI to try to solve some problems I was having in my work.

David: I went to the client I was working for at the time and said, "Look, I've got this thing — it's helping me using the tool. What do you think? Can we use it here?" And they said no. So I was like, but I really like this thing. I want to keep using it. So I guess that's how LoadMagic was born — a sort of accidental venture into solving some of my own pain in my own work. That created a convergence between my background in performance engineering, performance testing, and AI.

Len: It's interesting. Just before we move on to talk a little bit about the book, and maybe about LoadMagic as well — when you talk about breaking things and stuff like that, I think you're being modest. The things that you've worked on are like, you know, Home Office passport technology — I'm just looking at your LinkedIn — like the London Met, like a national fire service kind of system. Things where risk is very important. Not the Leanpub-style risk where it's like, oh no, our site's down for our users for a while, which would suck and which we don't want to happen — but like, you've worked on such a wide range of very serious things.

Len: I say this as an amateur, but I can see it in the language of your book and your descriptions, about how important it is — with all the magic of AI that we have now — to still have people who understand the fundamentals and respect the risk of these systems that we're building, and being able to test, and in particular test preparation. I was wondering if you could talk a little bit about that aspect of the book.

David: Yeah, sure. I mean, it really is just breaking things, right? So if you think about what performance engineering is trying to achieve — you break a system, and you want to break it before it breaks in the real world in a production setting. I always thought that was something I enjoyed.

David: But yeah, you're talking about preparation. I guess that's one of the parts of the performance engineering workflow that I struggle with the most — and probably still do struggle with the most. I know there's pain in other parts of that workflow and it varies on the individual, and maybe where they're at, what they're doing. But for me, it was mostly the preparation part.

David: We're basically taking a user flow which we're probably recording at the UI level — maybe a browser — and then we use tools to recreate that logic at the network level so we can replicate load at volume, without the heavy resources you would need to use in the UI. There's quite a lot of heavy lifting in that part of the work, which often goes unrecognized and, I guess, misunderstood.

David: Clients normally expect you to just turn up and start injecting load on the system. And there's a sort of continuous explaining — oh, it's not as simple as that. We need to — it might take about a day, on average, to turn an end-to-end user flow into a replayable load test script. And sometimes longer. Worst case, it's taking me about a week for very complex ones — for one user flow. And you might have ten, twelve, sometimes fifty user flows in an overall load test. So you can see, the amount of effort quickly piles up.

David: So for me, it was a no-brainer. That was the pain point I would always start wanting to automate, address first. But like I said, it wasn't really a planned thing. It was a tiny little bit of that — I thought, oh, we could use AI just for that thing. And then it sort of grew. I thought, oh okay, what about that one now, and then that one, and that one. By solving a whole bunch of very small micro-problems, it sort of ended up with oh, actually, I've solved the whole thing now. So it was a little bit organic, and completely unplanned.

Len: It's so interesting you say that. One of the features we've noticed from the really good books like yours — about people in tech working with AI — is how organic the process is. You can see from the way they talk about what they've discovered or learned, how organic the process is. It's such an exciting time where people are learning this new and rapidly-evolving technology.

Len: One of the stories along those lines in your book is the God Mode story. That kind of encapsulates a fair amount of what's going on in the book. I was wondering if you could just talk a little bit about the God Mode story.

David: Okay. So, God Mode — again, another accident. Which part of me does still bitterly regret. I'm still trying to iron out the wrinkles on that one. I did get lost in that whole God Mode episode. I won't lie — there were a couple of times I thought, yeah, I'm walking away from this.

David: Obviously there's a trend of movement in AI — the models are getting more and more intelligent, more capable, and more agentic. More autonomy. You can see how popular all this stuff is getting now, talking about AI assistants. So it was a natural thing to want to. And it fitted in with the workflow, in that my original concept with LoadMagic was really, really focused use of AI. Quite narrow, very specialized agents — which allowed me to make the workflow very efficient, and the use of AI efficient as well: fewer tokens, more cost-effective models, not heavy-hitting frontier models.

David: But there was a point in the workflow where everything else had failed, and it was like the last line of defence. I also saw some of the plugins and some of the tools were already moving in that direction. There's all this open-source code begging me to use it. So it was a natural evolution. This is the sort of final position — to bring the whole thing together. Basically giving one of the agents the ability to do pretty much anything — to manipulate the test plan in more or less any way possible. And to investigate, and to have all the tools and all the data at hand.

David: What I found is it worked very well with using frontier, senior models. But that was very expensive. It was quite slow, and maybe less predictable. So when it started getting complicated and messy was trying to make that more efficient. I went through various iterations, just trying out so many different things. I noticed there were subtle differences in behaviour with some of the different models I was experimenting with — in how they use tools, how they kind of split agentic activity between turns. Some of the providers and some of the models have behaviours that are not fully documented, that you really need… it's kind of trial and error almost.

David: I ended up developing some tests to basically very quickly establish how a model behaves under the circumstances we were trying to use them for. That was learning things the hard way. It did feel like a little bit the Wild West at times.

David: I went through different iterations of using different structures. I was using more efficient models for routing, decision routing at one point. In the end, we end up with a combination of a frontier senior model and different layers of intelligence — sort of shortcutting.

David: I guess you might call it like giving the agents emotions — like shortcuts. If you think about how emotions developed for us, biological creatures, it's just a shortcut. You feel a thing, you don't have to process all the data, and you can make a very quick knee-jerk reaction decision. You run away from the tiger very quickly. You don't have to read the whole book about the tiger — just leg it. You feel scared and you run.

David: So using that sort of approach really helped. We could use more smart code — more deterministic code — for some of those shortcuts. And then still, if those things don't work, you can still escalate to junior and senior. That was quite a challenging journey. And I'm not sure I fully resolved it yet — I think George still has like twenty or so tools I need to fully wire up. He thinks he's got forty, but sort of does — I need to wire up the final twenty.

Len: George is the name of the particular agent that we're talking about here. And you talk in the book about how you've named your agents, and why. It was really interesting when you just mentioned emotion. It reminded me of an interview I did a little while ago with an AI researcher who wrote a really good book on the fundamentals of LLMs and stuff like that, on Leanpub. I have a kind of pet hobby interest in autonomous vehicles. And he said: currently the thing that the AIs are going to be really good at is the kind of thing where your brain just goes blap — and you steer out of the way or something like that. It's not going to be so good at the kind of like reading the book about the impending collision.

Len: So it's very interesting to hear that someone like you is using concepts kind of along those lines — but thinking about emotion and a person, and relating to the agent that way, actually can be — not a way of making it cute, but actually a really kind of serious way of thinking about what agents are really doing and how you can relate to them. The idea of building some analog of emotion in your understanding of them is very interesting.

Len: We could talk for a lot longer. But the book — what we want to do is encourage people to get the book. If you want to learn more about the God Mode story, more about the other agents, your own personal agent you talk about at the beginning of the book as well — there's a very good passage about that. I'm just reading from a description here, underneath all the technological wizardry: the core principles of performance risk mitigation remain unchanged.

Len: I highly recommend David's very good book, AI Performance Engineering: How Agentic AI is Transforming Load Testing. It is very good and a very serious book. Thank you very much, David, for taking the time out of your evening in London to talk to me, and my early afternoon here.

David: Thank you. Yeah, I really appreciate the interest and support. We didn't talk about the most important thing, which is — are they alive? Maybe that's for another book.

Len: Sure thing. Thank you very much, David.