AI Test Automation: Ship Twice as Fast with 10x Coverage

Hey, Today we're going to try to separate hype from reality. What does an AI test agent actually do inside a real CI pipeline? What changes for QA teams? And what still requires human judgment. Hey, I'm Joe, and in this episode of the Test Guild podcast, I'm joined by Kareem, founder of Dunders. Kareem sold his last company, which was a 250 person SaaS operating in 60 countries, and learned the hard way that QA was the one thing that nearly killed growth. Now he's building what he calls a manual tester on steroids. So we're going to dig deep into what that actually means. A real case study where a bank shrunk a three year test effort down to four months. And Cream's blunt warning about testers who ignore AI. You don't want to miss it. Check it out. Hey, before we dive in, this episode is brought to you by Dunders. If you want to see AI tested in action, head to Thunders AI or a free two week trial. And I always say seeing is believing. So you can test it without creating an account. Just drop in your URL and watch it build your first test case in less than 40 seconds. Actually, let me take my own advice and try this for myself. I'll go to Thunders, type In my URL test guild.com, see what happens. That's all I did was type in the URL. Let me add in my tester URL email that I use for everything, right? So it looked like it created a test case for me. I didn't tell her what to do. Let's. Let's execute it and see what happens. Pretty cool. It already navigates to my website. It's testing. It's testing my login for the website, it's testing my join the community email popup, And it's also testing my tool matcher button to make sure that that's working. Pretty cool. I didn't tell it anything other than give it the URL, but I highly recommend you actually book a demo where you could talk to Dungeons directly to get expert advice on what your goals are. And get a live walkthrough of the Dunders platform. And more importantly, personalized recommendations on how to bring AI to your testing process that you're probably struggling with. So I highly recommend you book a demo using that link down below. See it for yourself. Hey, Kareem. Welcome to the guild.

Hi. Thank you.

Great to have you. Really excited. You know, I learned a little more about you at Automation Guild 2026. This year you have what looks like a really innovative product I think uses AI test agents. So I know it's a hot topic and I like to dive into the real nitty gritty of what's real and what's not. Before we get into though like, you know, I think you had an exit and, and then you started this new solution or this new space. Why the testing space?

Well, it's pretty simple. Me, I'm from a nerdy background. I actually created my first company. I was 16 building software for cyber cafes. Then joined Microsoft. For seven years I was building tools for developers. I was part of the Visual Studio team, then moved to the cloud team and I really fell in love with testing there. I realized at Microsoft that actually testing is not that evil task that you have to do at the end, you know, like a necessary evil that you do at the end. It is actually from an engineering and intellectual perspective something that can be really interesting sometimes even harder than building a product. Testing it can be harder. And so I fell in love with testing. Then as you said, I created a relatively big SaaS called Expensia. So for our US folks it's, even though I don't like these kind of comparisons, but it's the extensify of Europe. Okay, so it's more or less the same size, although it's, it's a different product. With the European challenges of, you know, many languages and all of that. And that's a product where we really suffered with quality assurance. We were operating in 60 countries, 17 languages. When you operate in 60 countries it means regulation changes two, three, four times a week. You know, if every country changes twice a year for you it's like three times a week. And so as we were scaling, we started to slow down. Every new release is more painful than a previous one. We have large enterprise customers that were not used to having multi tenant SaaS. You know, our product was, we were doing upgrades every day. And then if you break some defense contractor, they just don't understand. They're not used to having everyday updates. And so after we sold our business with my co founder, the same as for Thunders Jihad. So after we sold our business, we thought, okay, we built a business that, that was worth more than 100 million. But it wasn't a unicorn. What could we have done differently? And we both agreed on quality assurance. We did a market study. Then we verified that we, you know, we had it in us to go for another bigger adventure. And the answer was yes. So that's how it started.

Love it. Love it so curious to know, when you said QA was a big problem with the first company, was it regression test, flakiness, coordination, was there a specific task? You're like, oh my gosh, this is actually block the growth, not just slowing us down.

Absolutely. That's, I would say four different dimensions to that problem. One was our developers and QAs were building automation. We had around a million line of playwright, just to give you an idea, around a million line of Playwright code. So that was just resources that we wish we had available for just evolving the product. So that was the first dimension cost. The second dimension was the complexity of a full campaign because also of the complexity of our product. Like we had corporate cards and we connected banks, we connected travel agencies, we connected things like that. So a major release, if we need to have the. If we want to have the right level of quality, a major release is at least four weeks of test campaigns or five weeks of test campaigns, which limits the number of major releases you can do. A third dimension was just maintenance. Product was evolving often and maintenance was insane. For example, we did the rebranding at some point and a redesign of our brand. Just updating the automation test was like six months of work just to get these cleaned up and working. And the fourth dimension in all of that was just collaboration. Like, I hated the fact that my teams were working Waterfall, although we were, you know, pretty agile company, pretty innovative, using a lot of AI. Our product was AI based, although pre GPT and the company was 250 people. But you couldn't easily answer the question, what did we test? You see what I mean? Like there wasn't enough of a transparent system to know and to be able to say to this large enterprise customer, what did we test in our product and in the customer setup with high confidence.

Yeah, it's a huge problem. Interesting. You said you were using Playwright, so a lot of people think, I'll just use Playwright. Well, back a few years now, it was the latest and greatest. What made you like think, all right, we can actually do better than Playwright or traditional automation and codeless tools? Because I get hit up by thousands, like hundreds maybe of automation testing tools a year. So what made you go, okay, not only is this space somewhat crowded, but we can actually do better than what I've seen with these traditional tools.

Sounds good. So, yeah, I slightly oversimplified when I said we use Playwright, we actually were using different technology. So we had, of course, a test management system. We were using Azure, DevOps and some other tools to manage our testing. We had a web and mobile platform as well as a banking layer. And so we were using different technologies for each of these. The mobile, we were using something called Waldo that now is disappearing. So we had a big portfolio. So what made us think we can do better is actually we think we can do different. And the technology we're using did not exist a few years ago. Okay? The generative AI as a technology, although I hate the word generative because it puts an image in your mind that is different from the technology itself. But generative AI is a radical new tool and a radical new technology that allows to completely rethink every dimension of what we are doing. And so we are rethinking testing based on generative AI. We wouldn't have started this business if generative AI wasn't there. I think Playwright is a great technology. I think we'd be using some of the best technologies that are out there. And they weren't good enough for our ambitions, but they were what they were. You see what I mean? And generative AI radically changed, changed our perspective. And we were like, okay, we can do radically differently. And so our position is to say when you test, you basically have two families of testing. Okay, you test manually, meaning you have humans in front of your products or your products, whether that's your QAs, whether that's your partners, whether that's even your customer. You know, when you do a beta phase, that's actually manual testing, but. But at scale with the customers. So that's one family of testing. What is amazing with manual testing is the level of quality that you get because you have actual humans that can give you subtle feedback on top of your test scenarios. They can tell you things about the ux, they can tell you things about performance. It's usually high quality with humans, but it just doesn't scale. Just doesn't scale. The cost is immense. So you end up with pretty low coverage if you do manual testing. The second type of testing is automation. And automation meaning you use experts, whether it's engineers or people that know how to use this or that. No code platform or that low code platform. Use these experts to write code and then you can run that code. Obviously it's super scalable but expensive to build. You need specific profiles. It creates these collaborations issues because now your functional leader, your product leader, business analyst, needs to transfer knowledge to someone else that has expertise to build these tests. And so you end up with immense inefficiencies and immense maintenance issues. Okay, so these are the two worlds. Thunders is an Emanuel tester on steroids. That's who we are. Okay. So our model is to say we want the quality of a manual tester. We want the flexibility of a manual tester. You know, when you have a great QA in your team, you can just explain the feature, you can throw a document at the person, you can onboard the person in your team, and they figure it out, they test it and it's high quality. So that's who we want to be, but with the efficiency and the automation of test automation. So that's who we are. And then we can together dive in. What does that mean? But that's the vision. If you want to summarize, we are a manual tester on steroids.

Love it. Love it. So I love how you said you weren't replacing testers or developers. I know the big phase here now. Not the phase. The phrase a lot of people are saying are calling agents, like AI test agent. You hear a lot of people making huge claims about these. You don't need a human anymore for any job. It's all going to be agents orchestrating themselves and doing their own thing. So let's clarify, is that what we're talking about here as a test agent? That's different.

No, I actually, again, I don't like when it's just a tag word or a tagline, it gives you that image. So I don't like to say agent too much, although it's on our website because it means different things to different people. I like to say it's the QA assistant. Okay. I like to say we are the vibe tester, if you want, meaning it can both be used by super senior QAs. Okay. So people that know testing and with us they can do 10 times more. But also it can be used by people that have the. I would say the functional leadership, meaning they know how it's supposed to work, but they can't automate today because they don't have these coding skills or they don't know the different frameworks or we give them the superpower of now they're autonomous. And so to answer your question more precisely, will this destroy jobs? I don't believe short term, at least. Although I tend to be in the AI space in general, I tend to be slightly pessimistic. I think we need as a society to understand where we're going as a group. Okay, And I will close that parenthesis. But on testing specifically, it's not meant to destroy jobs. But it's true that teams that have strong functional leaders could use us instead of going out and hiring QAs. It is a reality. I won't hide that. But at the same time, we have a lot of very happy QAs using us. And what they tell us is I can finally have a high level of coverage while maintaining the same level of quality.

Absolutely. So can you just paint a picture of someone that's just listening? What does this look like for maybe a QA engineer's perspective? What are the outputs? What are the inputs? How does it assist them?

Makes sense. So it has two main modules, and then we can talk about how do you build on top of that, two main modules, one module that we call Test Clan, what it does is that you start with the functional description. That can be a user story, that can be a JIRA ticket number, that can be a full functional specification, that can be a prompt. You know, you start with something that defines how your product is supposed to work. And then with your knowledge base and with the help of AI, it is going to lead you step by step into building your test cases. Okay. So it's going to say, okay, out of your functional spec, I'm identifying these test sections. Here are scenarios that I think we should be testing together. And that document that it generates is collaborative. We can be multiple humans working on it. I can invite my customer if this is a project that I'm doing with my customer, and I can also ask AI to edit it, so I can edit it myself, or I can ask AI to edit it. And then step by step, I will go from these scenarios to test cases to test steps that would be as detailed as if I wrote a Selenium script or a Playwright script. And I'll get to that. So that's the first module, okay? Helps me go step by step into a formal, high coverage test plan. And then I can select out of that test plan, what are the cases. I really want to have them part of my assets and run them regularly, and which ones I don't want to, I don't want to have with my assets. So that's the first module. The second module, if I oversimplify it, is a plain English Selenium. Okay? So it is like a test automation code, but our programming language is pure English and it's as simple as that. So you will say, go to this page, click on this, enter this information in that field, click next, do this, verify that you actually have this, verify that the app you're looking at is compatible with this Figma page, et cetera. And so that second module is AI. We call Them Personas that are capable of going through your script, which is pure English, and execute it. And the power of natural language is its immunity to maintenance issues. Let's say you're using Selenium and your instruction is you want to click on next, but that button now is an arrow. It's an image. It's no longer a button. Your test fails because it can't find the item in Thunders. The AI will figure it out when it arrives to that step. The step says click on next. It looks at the page, it doesn't find the next, but it figures out that there is an arrow that probably means next. And it's going to proceed and it's going to leave you feedback so that you improve your instruction to avoid any regressions. Okay, so that's in a nutshell, our product.

Nice. So where do these Personas live? Can you have it like post deploy, where you deploy something and something breaks in production is able to. I'm a user Persona in the wild. I'm checking out my account. Are you able to do stuff like that? Is it just pre merge where this, this agent comes into play?

It's a good point. So for now we really, really focused on doing natural language. Selenium, meaning we are used by teams that are formal, that have processes. So it's a little bit waterfall, meaning you build tests and you run tests, you get feedback and the AI iterates on it. So it's not an agent that you throw at your app without instructions and it would travel and find bugs. No, you can do that. You can throw an agent at your app, but what it's going to do is it will at the end write a test case that you can reuse. Okay, so we are building these assets as we go. So the AI is building assets that then you can plug to your CI CD that you can run from the web app, that it's really an asset, as if you have built Selenium at the end, meaning you can plug it anywhere. But the difference with Selenium is that the power of AI in natural language is that you get additional automation on top of just running your test. I'll give you an example. Let's say the test failed and it used to pass yesterday. What the AI is capable of doing is to first describe that failure. It says, okay, you actually asked me to verify that this is read only form because my user is not allowed to edit. For example, I was expecting this, but actually one of the fields is editable. So this test failed and it's Capable of looking at your previous run and tells you what actually changed since your previous run and what is what changed in your page, what changed in your logic. It's capable of looking at previous steps and say, okay, actually this is not just not read only, but it is actually because your user has more capabilities than it should. You know the role of your test user changed. So it's capable of doing all of these. And at the end, if you both agree it is an issue, it will create a ticket in Jira or whatever system you're using. And that ticket will be well detailed with all repro steps in it and ready to be tackled by another AI. Okay, meaning what our customers do usually is they plug us to the Jira and then they plug the JIRA to something like Cursor or Devin or an AI for coding. And now they have an end to end flow where they run a test, they found an issue, AI fixes it, and then we verify that the fix is good by rerunning the test. Does that make sense?

Yep, absolutely. Very cool. So you mentioned Selenium a bunch of times. What's is. Is, are people able to see the code? Is it Selenium? Is it Playwright? Does it not matter? Because it's just English. It sounds like you're writing almost like a gherkin test. So it doesn't matter what's underneath, but what is underneath for people that do care?

It's. It's a, it's a good question. There is nothing underneath and it is actually a key element, meaning this is not something generating code, running it. Then when it breaks, it tries to auto heal by fixing the code. This is really interpreted as we go. Okay, so it is literally executing English. So we built an AI model and architecture that is capable of taking a step, understanding what that step means. It looks at the browser in case of a web app. It looks at the browser content and figures out what to do. Of course, under the hood, under the machine, we of course have a ton of caching and a ton of smart ways to avoid burning AI tokens and avoid this being slow. But there is no code generated. And I think that's the power of it. Our code is English.

Nice, nice, nice. So just curious to know then, do you ever get any pushback? Like, I want to see what, what's the code? I mean, is that like a mindset shift that you have to fight? Because it seems a little too good to be true. You're fighting plain English. It's doing things for you, but you can't really see what it's doing. I don't know if that makes sense.

We have actually two different ICPs in terms of users. We are like the vibe testers. So we look like vibe coding. And so we have people that are used to do test automation. They used to have code and they do sometimes ask that question or pushback because they need to to wrap their head around the fact that they're used to having their code into git and it's their code, they know it, they can look at it. And now they suddenly are doing plain English in some cloud platform. And so what you explain to them is that you actually don't need to change your process. My code, which is plain English, you can actually commit to your git. You can make it like you can through an API, you can synchronize our system with your git and you can have every test in your git. It just happens to be a JSON file with plain English. As simple as that. So that's the first ICP or the first type of users. The second type of users are PMs, POS manual QAs. They don't really care about what is under it. What they care about is, is that my intellectual property, is that my ip, where is it? How does it work? How do I debug it? Like, they ask these kind of questions, but. But they don't really care what is behind Thunders and so they don't really think about it.

Gotcha. Now, I know you mentioned this a few times. I just want to clarify. It's AI. It's a QA assistant that you mentioned. And what I like about it is, I think you said it gives you feedback. And then you have to, as a human, look at it sometimes and say, oh yeah, the screen change, did it make the right choice? So is that the guardrails that exist right now where teams can review version approve changes, or is there an option just go wild? I trust you. Just do your thing.

So that is, you can. The default option is go wild, meaning when a test is written, it can run with it. Where we put guardrails is humans decide if it's a defect that the AI found or not. Okay. And then you have a learning loop. So you can say this is not a defect, and then the AI will learn from it. Okay, I'll give you a simple example. You can go and write in a couple of lines. You can say, go on test guild, look at the list of partners, click on each partner and verify there is no typos on the page. Okay, as an example, as a sanity check. And so the AI will do that. It will go line by line. It will go on the page, click on partners, and then it will find that you have maybe 12 partners, and it will do a loop by itself and click on each partner, see the page, see the typos, and then go back. Now, let's imagine a partner has as a name something that doesn't exist in English, which is very common. Right. The AI might say, this is a typo. And you have to be able to say, no, this is not a typo. It's actually expected. And the AI will learn that XYZ is actually a brand. And I shouldn't bother you again with saying this. XYZ is actually a typo. Does that make sense?

Yep, yep, yep. All right. So you know, when you say it's just English, though, can't people write bad English? Like, how. How good of a writer of English do I need to be? Do certain people get better results because they write the prompt better? Or like, sometimes you give too much information and throws the AI off, Sometimes you give too little. Is there a sweet spot? Like, how do you navigate that?

Okay, so we have done a ton of engineering to make it simpler, but there are a few rules of thumb that AI will never work around. Okay. And how I like to put it to my customer, I tell them, if the instruction you have written, you give it to 10 different humans and they don't all do the same thing, then that's bad instruction. You see what I mean? So ambiguity is the main thing. Your English doesn't have to be good. It's good around typos. I mean, we've done a ton of engineering to remove that fear of am I prompting right or am I typing the right steps? But ambiguity is a bad thing. So, for example, in the next release, in a month from now, in the next major release, we adding a helper that will actually score your prompts, it's going to take this. And this step that you have written is actually low quality, and it will explain why. I'll tell you an example. Let's say you say click on the blue element. Okay? That is actually a relatively poor quality instruction because you have I don't know how many shades of blue. An element can be a button, it can be a link, it can be a text that happens to be in blue. And so we will tell you, look, this is something we can execute, but it's low quality because there is maybe six different elements that could qualify for that. Okay. And so we are adding more and more helpers to help you write well or autocomplete what you're writing.

So if someone's a tester, this, to me sounds like a win win. Because now, like you said, a tester could focus on testing or even whatever, whoever's doing the role, a domain expert who actually knows the application, the rules will probably write a good prompt because they know what it's doing. And it's the best of both worlds. They're using AI to do the AI stuff, but they're using the thinking of an expert, a domain expert, to do the English prompting, right?

Yes, exactly. So what we tell them is we tell them you can focus on strategy, and we are your army of testers. We are like your army of interns that can test infinitely fast in parallel what you tell them to test. But you can focus on the strategy of testing, which is, you know, we all know the complexity of testing. You have an infinite number of scenarios. So you have to decide what to test and when. So that's part of the strategy. We're not doing that for you. You define what to test. You define a strategy of testing. You def the inputs. So you need to decide what is my test data. Okay, so we help you with the execution, and you can upload your test data and all of that, but you still have to be in control and understand your infrastructure. And we are your army of testers. And of course, we help you writing these tests, because every time I say it's like Selenium in plain English, but people don't write the steps. One by one, they can, but actually we give them tools to go faster, whether they start with a product specification. We have a recorder that looks classically like Record and Rerun tools, but actually with a twist, because when you record your scenario, we actually turn it to plain English. So instead of saying you clicked on this coordinate or this id, or we actually build the story of what you have tested so that it's now suddenly something that is plain English and has the advantages of testing plain English. And so we have many ways we have built to write your tests, including an mcp. And so you can go on Claude or on cursor and have it write your tests for you, run them, debug them completely. Hands off if you want to go that route.

So if someone's vibe coding it fits right into their flow right there, they could just call it nice. Nice. All right, so you said the underlying technology doesn't really matter. Like, it's there's nothing behind what's driving the browser. So I forgot to. Is this just driving a browser or QTest anything? Does like the technology not matter at all now as well? Like you just tell it what to do. It knows this is a Salesforce app, this is a mobile app, this is a mainframe. Or is that too, too, too much right now?

No, it is exactly what you said, but with some limitations. The limitations are the AI consumes the product through technology, right? And so today we can consume API apps or browser based apps, whether they're really browser based or through Citrix. Okay. Because the AI uses the browser to actually access your app. And in a few weeks you will be able also to test any native mobile app because now our AI will have access to a device farm and so it will be able to, you know, start an iPhone and test your app. Okay, but then the technology of your app doesn't matter. You know, it could be modern, could be old. Like the AI is simply doing what a human would do when they open a browser. It's as simple as that.

Nice, nice. So if a QA manager is listening in, what do they do more of using this technology or less? Or what skills matter?

It's a good point. There is one generic answer I will give you that I truly believe in and then I will focus on testing. I think what generative AI and agents and whatever we call them is bringing as a challenge to us as managers and as leaders is that we need everyone in our company to become a manager, which is a skill that is not enough taught, you know, through education and through. Now we all become managers. We are no longer individual contributors which, which changes our flow. Whether you're a developer, whether you're a product or like me, I still write code and, and I like it. I obviously stopped writing my own code. Now I use, you know, AI to write my code. But it feels so natural to me because I've stopped being an individual contributor for 15 years. And so my day looks like, I wake up in the morning, I decide what are the 10 tasks I want to build by my team of agents. And then I take a couple of hours of focus to write all my prompts and then I give them to the different AIs and then I come back and interpret the result and then I complain of the done a poor job and all of that. So I am a manager of engineers that are writing the code. They just happen to be AI engineers and now transpose that to every other job. That's what is going to happen. To our societies is we need to learn to be managers. And so to QA managers today, the question they should ask themselves is, is my team ready to become QA leads each of them. I won't. I will no longer have a traditional QA going forward. And this is not just because of Thunders. This is a movement of the whole industry now. I need to make every single individual in my team think and act like managers.

So how do I learn that? How do I learn to think like a manager? That's a good question.

Follow test Guild's content.

That's right. Good answer.

On top of that, it is really like companies need to go through that transformation and teach their teams through internal resources, through external trainers, through online platforms, on how do you organize your day? How do you delegate? Learn how to delegate. Well, how do you delegate while owning? As a tester, you shouldn't rely on, hey, I have Thunders. Thunders is doing all my quality work that doesn't work that way. You still have to own the quality even if you delegate to Anders, you're the owner. Same for developers. Even if AI is writing, you know, a ton of code, you have to own it. You have to feel comfortable debugging it. You have to. And so these are all the skills that need to be to be learned. And with platforms like Thunders, the heavy lifting, the expensive, painful part now is done in a, in a couple of clicks.

All right, so I'll be honest, the Test Guild audience is pretty skeptical and they hear of a new AI tool every day. Any case studies or real world examples of Thunders of maybe like before and after, real numbers, real case studies. Was this now actually using Thunders, Bam. Did this?

Absolutely, absolutely. I can give two examples. One that me as an engineer I really like and another one where as an engineer, parts of what I'm going to say makes me slightly uncomfortable. But both are ROI driven examples. I will start with the one that makes me slightly uncomfortable. This is a company that approached us and said, hey, it's a company that does around 50 million revenue. Okay? Software editor, 50 million revenue. So midsize and growing very fast. They said, hey, we need to cut on our costs, okay? And so we are actually letting go our testing manual and automated. And that's a done decision, strategic decision. And so we are looking at how do we transform our product team so that they don't just own specifications, they need to also own design and own testing. Can we go through that transformation with you? We went through that transformation and we both learned a lot because we also had to improve our product through that transformation. And. And it actually worked. So they turned nine product managers in their team into people that build the specifications, but also build all the test cases through Thunders, and they no longer have manual or automation test. Thunders is the automation platform for everyone. Obviously, it makes me uncomfortable because that means people lost their job through that process.

People aren't liking hearing that.

Yeah. But, you know, I'm a pretty transparent guy, so I like to give you, you know, honest examples.

I mean, that's real world. You need to deal with it.

And the company already decided to lay off. And so we were here to ensure that quality doesn't collapse after they have laid off that team. And the transformation. In the beginning, like, the product team was skeptical because they felt they're getting more workload they used to design, but now they have to test. And so what we have proven through that case is that of course it adds work to them to use standards, but they save all the time they were spending explaining to another team what to test, how to test and analyzing the results of the other team. Now they are in control. And so we have proven through that that they actually spend less time using Thunders than time they were interacting with the test team. So that's the first example. It's for us, a massive roi. Makes me slightly uncomfortable. Another example is, is a large bank, okay, A large bank in Europe that was upgrading its core banking system. Okay. And core banking are massive systems, highly customizable. So they have built a ton of apps on top of it. This core banking. They were very nervous to do this upgrade. They were planning three years for it and three years of testing, uh, and with a team of 10 QAs. And so they put an RFP out who can help us increase the quality, lower the risk, lower the cost. And so in that example, using Thunders, they moved from three years to four months. Okay, because they were able to do it because first they expanded beyond the 10 QAs they had. Now they used the domain experts to actually build test cases by recording scenarios. So they built knowledge. They had a knowledge gap. They built knowledge by just having the people that know how to use this or that app just use it. And we recorded everything. They took user sessions that already had in their system, and they built a tool to extract a scenario and push it into Thunders from user sessions. And also they were simply able to convert all of their Selenium, Cypress, Playwright code, et cetera, of the old version of the core banking into Thunders. And what is really cool, is that once you upgrade your core banking, there is little change you need to make in Thunders. Okay. Even though the UI changed and the apps actually changed in radical ways, it doesn't really matter for Thunders because a mortgage is a mortgage regardless of the version of your core banking. Right. And so if you wrote functional tests on how is your mortgage flow happening, Meaning someone is entering all the details, it generates a credit score, it goes through approval flows and then it impacts accounting. And so they were able to build a bunch of test cases, upgrade the core banking and then only spend, only codes. Only spend four months maintaining these tests, fixing them, running them, ensuring they have high quality, and then finish the core banking upgrade. So these are two examples I'm pretty proud of. All right.

Oh, hold on, that's an interesting example. So tests are written in English, so you're not writing the guts of call this API, do the SQL statement to this database. So like you said, if someone does radically change the technology behind the scenes or popping out APIs a new. It doesn't matter. It doesn't. It's still going to work and run. Right?

Exactly. That's, that's our promise. The reality is that it still took them four months of work to, to do the full upgrade. So I think we, we, we are 80, 90% in that direction. But the example I want to have in your mind is if you're applying for a mortgage, regardless of how the app is built, it is still the same thing functionally, you're still filling the same fields. Maybe instead of being one form, it is a four step form. Maybe instead of being this component is that other component, but functionally it is still, you're still applying for a mortgage. And so if you were building all your tests using Playwright or Selenium or whatever, you probably have to rewrite your test from scratch. Right. Because every selector changed every. As you're using Thunders, you have to do minimal changes for that test.

All right, Just a crazy thought. So in theory you could create almost like an insurance module, a finance module, I don't know, whatever it is, domain knowledge module that knows how to test a mortgage app.

Right?

Right. And it could just consume that module of best practices or what you need to do to test. Does that make sense, is that it

makes more than, it's more than making sense. It is what we are doing with partners right now. Meaning we have partners that for example, there are consulting companies that are specialized in. For example, I'll give one concrete example. It's consulting company that specializes in car leasing. Okay. So what they do is they work with large brands that you have in mind, you know, Chevron and Toyota and all of these guys, and they deploy to them solutions to manage the life cycle of that car that they're leasing. Okay. And every company is different, every version of the product is different. And all of that. And they do, they do deployment, they do professional services, they customize it, they test it, they do all of that. Now they approached us saying now that they understood what we're doing, they want to build all the assets of what does it mean to test a leasing system? And once they have that, they could reuse it on different brands, different infrastructures, and different product versions. So you're completely right. I think it is the future of how do you build more value on top of Thunders. It's not something we will do because we are not experts of every business line and every industry, but the experts can use us to do that.

All right, so as I mentioned, test testers tend to be very skeptical. I'm sure developers and engineers seem to be pretty skeptical. How do you approach someone like, do you have like a, a go to elevator pitch you give someone to say what Thunders does to get ROI on what they're they would be investing in with this technology?

Absolutely. I actually start with the pain and the roi. So what I tell them is with Thunders, you can ship twice as fast. Okay. So I focus on that pace of innovation and everyone is trying to innovate faster. So ship twice as fast, cover 10 times more with the same resources. Okay. So think quality test coverage and discover bugs much sooner. So these are the three that I keep on repeating that my team repeats. And that's what we want our customers to understand, basically.

Awesome. All right, Karib, before we go, is there one piece of actual advice you can give to someone to help them with their AI testing efforts? And what's the best way to find or contact you at Thunders?

So absolutely. So the easiest way to contact us is on the website Thunders AI. You can have a two week free trial. So you don't have to trust me. You can go test it fully online. You can also see it in action without creating an account. You can just enter the URL of a web app, your web app or your website, and you will see AI in 40 seconds. It will discover your app, create your first test case, and you can immediately run it with our different Personas, which is a pretty strong wow effect. My advice to people getting into AI is really defining why they want AI. Okay? They have to have super clear definition of success in the industry. 95% of pilots failed with AI. Okay? There was an MIT study that says 95% of pilots fail. The reason they fail is that you don't define well what you're trying to get. So my advice is don't get into AI before you know why you're doing it, and then get into AI quickly, because otherwise testers that use AI will replace you.

All right, this sounds really awesome. So if you want to see how Thunders AI will work in your own pipelines, we'll have a link down below. Highly recommend you check it out and let us know your thoughts.