Playwright With AI: How to Automate Tests Without Shipping AI Slop with Andrew Knight

Speaker A: Hey, what if the code your team shipped stopped being the thing you actually review? What if markdown was the new programming, um, language and the AI coding agent was just the new compiler? And this is not a hot take from someone on the sidelines. And this is not some verdict tool hype. This is actually a director of engineering, shipping the biggest release quarter of his career with the team of just six. Hey, I'm Joe, and in this episode of the Test Guild Automation podcast, today, I'm joined by Andrew Knight, better known by most view as Automation Panda. Andy is a senior director of Product and engineering at AH Cycle Labs, and he just released a brand new LinkedIn learning course on playwright with AI. He's one of the few people I know who could talk about test strategy, engineering, leadership, and actually work in code in the same breath. So in this episode, Andy breaks down exactly how Playwright evolved from a web testing tool into an AI automation platform. We also get into the MCP server, the Planner generator, and Healer agents, and why the new CLI and skills approach might save you a fortune and tokens. He also shares, uh, how his team uses Spec Kit to make testing strategy into a product once, so it, uh, never has to be argued about again. He also explains how he spots AI slop from his own reports and what he does about it. And then he says something I think is going to make a lot of testers uncomfortable. He tells me code quality may not matter the way you think it does anymore. I pushed back. He didn't blink. So stick around for that part because whether you agree or not, this is a conversation your team is definitely going to have in the next six months. You want to miss it, check it out. Hey, Andy. Welcome back to the Guild.

Speaker B: Hey, thanks for inviting me back, Joe. Good to see you.

Speaker A: Good to see you, man. It's been a while. I mean, the first solo episode we did, I think, was in 2019, but then we did an episode with you and your boss, I think, in 2023. But it's still been a while. M. So just great to have you back on the show.

Speaker B: Thank you. Thank you. Always a pleasure.

Speaker A: So, I'm almost up, uh, on episode 600. This might be 600. It might be a few before 600, which is crazy. And I met you when you were a young panda, and I think when you're a young panda, you're really into Python. But I've been seeing you blowing up everywhere, all your different talks at different places, but I don't see anything around Python. So a little bit maybe backstory of where you are now, where you were.

Speaker B: Sure, yeah, sure. So I consider myself a polyglot. I still love Python. I'm still very active in the community, still go to Python events, but I mean with AI these days you can program in any language that you want. I find that much of my work tends to actually be in the node stack these days. I've been doing a lot of typescript. Now granted, I am a manager now, so I'm not coding as much as the regular engineers, but when I do projects it's almost always some kind of node based application. On my team we do node, we do go, we do some Java. So there's a little bit in there. Um, a big portion of my team's backend is written in Scala and we're trying to get out of that because it's kind of scary. It's not good. But yeah. So fun fact. Even when I was like super, super doing Python stuff that was kind of a public face, I was still working at a company where day to day I was doing c.net, python was more of like the passion projects. And so people would ask me all the time like, hey, so tell me how you use Python at work? And I'm like, I don't. And they'd look at me like, what do you mean? I was like no, seriously, I don't, I work on a, @a.net shop. But so it goes.

Speaker A: All right, very cool. So you did mention you're more of a manager now. But you know, uh, we're going to dive into this lady just released a course on playwright on LinkedIn. How do you keep yourself up to speed then? Because it seems like you're really still in the technical weed still. But how are you able to balance that between being a manager and still being technical?

Speaker B: Great question. It's tough, right? I think it really starts with a, a true passion for the technical side. I still love to code. I think these new AI tools are heckin phenomenal. It is the best time ever to be a builder. And uh, that desire is within me. It's not something that I have co, opted, it's not something that I pretend. It has been within me, you know, since ninth grade in high school when I first picked up a TI83 plus and started program. And that sucker, right, that spark has never gone out. And uh, now that I'm a manager, it's not my day to day job to be in the middle of code to be grinding like that. And so I need to find ways to keep myself Sharp. And so whether that's doing code reviews with my team, whether that's picking up some smaller tickets on the side that, that I can easily crush, that's not in any critical paths, not blocking anybody, or whether that's side projects on my own. Right. For example, I just built a new small little web app. It's, it's called if you go to autopandamotive.com it's a spin on automationpanda.com autopandamotive.com I made a little static site to show people my cars because as you know Joe, I've got some classic Volkswagens. I also have a cool Mercedes now that I've been working on. And so I wanted a quick convenient way to show people here are my cars, here are some cool pictures and here are their stories. So I built uh, uh, a node JS based app. It uses Astro for the, for the static site generator. It's all server side render too, which is really nice. And I use JS Deliver for the cdn so all my photos are sent through for free. The only money the site is hosted on GitHub pages. The only thing I paid for was the $10 a year for the domain name. Just hook it all up. And so I used that project specifically to learn the Superpowers, uh, toolkit Superpowers, the AI skill set to help you brainstorm and develop through a process. And I found it to be really helpful because like I'm, I would not identify as a web developer. Like I'm not good about twiddling CSS and making it look good. But what I could do with Superpowers is I could have it like kind of build out different designs and show me and I could pick do you like A, B or C. Right. And so doing all these fun kinds of projects on the side also help me keep my skills sharp even when my day to day is people management.

Speaker A: Love it. So you know, you think with AI, uh, you'd have less to do, you wouldn't be learning as much. But it sounds like almost um, you're using AI to empower yourself to learn more, to do uh, a web from scratch.

Speaker B: Yeah. There is this fallacy that AI is going to reduce the amount of time we have to work or reduce the effort we have to work. On the contrary, like what I have found is that it is a force multiplier. But when you do use it right, it really takes a lot of focus, it takes a lot of mental energy and capacity such that by the end of the day you End up being more mentally tired than you were before. And it's because there's so much more detail that's flying. There's almost an art to deciding what you don't have to worry about and what you do. And because it all comes so fast and it's not just you, everyone else on your team is doing it too. And so you're now moving at a much faster pace. You're not walking down the sidewalk anymore, you're driving down the freeway. Do you look at every single little tree? Maybe not, but you look for the signs. Right? It's that kind of shifted mentality. And so you need to be more alert, more engaged, more focused.

Speaker A: All right, So I don't mean to keep hopping on this. I'm just curious. Being a manager now though, how do you know what's really being produced by your people that report to you? I don't know if that makes sense. Like, how do you know, like thinking still being involved or someone's just not phoning it in as, like, how do you know what's quality or real or what people are really doing nowadays?

Speaker B: Yeah, uh, that's a people problem.

Speaker A: Yeah.

Speaker B: Because some people are still highly engaged, using their full mind and thinking through the problems and using AI where it's appropriate. But there's other people that just put it into Claude and push AI slop. Right. It's. Sometimes I'm able to deduce myself when something doesn't seem quite right and you push on it a bit. Sometimes you rely on other people you trust to kind of give a once over and be like this. Didn't something seems wrong about this? What do you think? Sometimes you got to double check yourself. Being a manager, I do have the powers to be able to push back and be like, this ain't it. This is not good enough. You need to try harder in these ways. And not in a punitive sense, but in a coaching, uh, sense. Thankfully, I will say that pretty much everyone on my team, I have a team of five reports. They're all pretty good. Like, they're not fresh out of college. They're all more senior level folks. They are. And they're all driven to do the right things too. So it's not like I have a problem person that I need to keep smacking upside the head to be like, no, think for yourself. But what I'm finding is that the, the tolerance for AI slop is very low. And so if you try to sling that, you build a culture of try. If you build a culture where you don't like AI slop, right? Then it can be self correcting to catch when it leaks out. And it happens because sometimes it's not malicious, it's not lazy, it's just like, oh shoot, I didn't look into this one area of the spec that I was gener and next thing you know it went off the rails and hey, maybe you got to check that before you, before it wrecks you, that kind of thing.

Speaker A: Yep, for sure. So once again as a manager, is your team getting more done with AI that you don't, that you could reduce headcount or is it like you said, it just gives you more stuff you have to do.

Speaker B: It gives us more stuff we have to do. Yeah. I, the way I look at it is that I have an expectation that people are going to work full time jobs, right. You know, order of magnitude 40 hours a week. Right. I expect people to be optimally performing for the time that they're on company time. And so with AI, that means that everybody should be able to get a whole lot more done. Right. I've had managers in the past who have said things like, well, I don't care how uh, much time you spend to get done your stuff, if you can get everything done you need a week and 20 hours a week, so be it. I don't quite have that view. I think that was more old school. It's a bit flippant to be like uh, manage your time. But if you take that perspective it's like then our company and team are never going to advance because everybody else is using these tools and moving a whole lot faster too. Right. So it's not that we're going to reduce the hours we work or that we're going to reduce the headcount. I see this as a optimization opportunity the likes of which Joe, I don't think you and I have ever seen in our working careers is wild. You know this, this coming quarter at uh, at uh, my team like, like my company's small, we got 30 people. Ish. So my, my team of six, which includes me, we are the entirety of product and engineering. Right. We own both of those functions. This Q3 of 2026, we are going to have the biggest releases in terms of the number of features we're pushing out that I have ever witnessed at this company. I've been there full time for three years now. I, three days from now is my three year anniversary as a full timer. But I'd been working with this company going Back to like 2018, right. This is the biggest sets of releases we've ever had and it's thanks to A, the team being awesome, but B, being super powered and supercharged by AI coding tools, we're able to get done so much more.

Speaker A: Love it. How do you know then that shipping, that velocity, these big features, that it is actually actual quality? So I assume it's not a team of testers, it's developers. How do you then build in that mindset? Like, okay, yeah, we're able to create this code faster, but how are we verifying it?

Speaker B: Excellent question. All the traditional ways also baked into AI. That's the short answer. Uh, what I really like with the state of AI coding tools right now, it's not just that Claude is going to poop out a bunch of code, but when you have the right like skills and process in place. When I say skills, I'm not talking about like the human people skills we have, but like the, the AI coding agent skills MD files, right? If you pull in something like uh, spec kit, for example, or I mentioned superpowers before as well. Right. I. We use both of those on the team for different purposes, but particularly let's focus on Speckit for an example. Right now, when you do your thinking and your product management pieces for first and then moving on to your engineering design in conjunction with the tool like that, it catches a lot of the extra things for you, right? Things like, oh, you should be automating your tests, right? Automate them together at the same time with the code that you're writing. Things like, hey, have you thought about things like accessibility? Have you thought about things like putting this in a pipeline? Right? It's the, it's leveraging the AI to think of all these extra cases that when you as the human are almost entirely focused on just the behaviors you're trying to develop, there's a bunch of these extra technical concerns you should also be thinking of too. We used to promote people to be senior and staff and principal level engineers because they were the ones who thought about the things nobody else did. Now the AI is catching and thinking about it for us too, right? And as we're refining the designs and the specifications using a tool like that too, because you start with that before you do your code, which we should have been doing before, but that was too much work. Now we have tools to help, right? But when you're doing that all of a sudden, like the AI is able to catch these kinds of problematic issues and raise them to you to be like, hey, have you thought of this hey, you know, these two things don't quite align, right? How would you like to proceed? Option A, B or C, right? And then through all of that, you're basically building better quality into the product from the beginning. And you know when you have all your specs written, you can go to say, okay, let's implement the code. One thread can go implement the product code, the other thread can go implement all the tests, unit integration end to end. And so you can have that together and so you can review the spec, review the code, review the test, get it running, make sure it's good, and then boom, then you're protected. Moving into the future, that's how you can really, it's really the only way you would keep up. Because if you're trying to push, push product code to the speed of AI, you can't have another separate test team trying to do N plus one, Sprint Automation or something. Not going to happen.

Speaker A: So if you have an avalanche of code, you must have an avalanche of tests. How do you know what tests really are really needed then? Because you can't have. I know you did a session on risk based basically no longer pyramids, but more skyscrapers. Is there a certain approach where you make sure the tests are generated rather than just a bunch of tests just to generate for AI's sake of really testing?

Speaker B: Oh, that's a great question. If you just let raw AI go to the hilt, you're going to get a lot of good tests, but you're going to get some that perhaps aren't worth it. And when I say not worth, it's not that they're like a bad test, but it's like you have X amount of hours in the day to run your test. X amount of dollars to pay for the compute read resources. Do you really need to check that the button is yellow? That kind of stuff? So part of it is still human review. Right. What we're finding is that people are spending more time doing reviews and less time like doing the hands on coding, which is fair because you're writing spec, the code just happens as a side effect. And then, you know, you have to use your human intellect to actually review and make sure the things are good. The other thing that's really nice. And again, this is why I've become a huge proponent of Spectrum in development and of using these kinds of skills and building out the process. As you see M, you can codify the guidance that you want for your testing along with your projects. Right? Because if, like I said, you could ask Claude to do Something and it'll just go puke on the screen.

Speaker A: Right?

Speaker B: But you say, hey, Claude, don't worry so much about like testing visuals or stuff. Thanks, Pandy. I'll keep that in mind for next time. Save it as a skill. It's in there. It's baked in every single time. So that way, you know, like, like, for another example, I. My wife runs a dance studio. I think I've mentioned this before. DIA Dance Studio in Durham, if you happen to be in my area. Right. North Carolina. She's wonderful. She's awesome. It's great. She has had to cobble together a bunch of different SaaS solutions to run the operations of her studio. Everything from like scheduling classes to soliciting payments, right? And she's like, hey, Andy, can you use those AI superpowers to build me an app so that I don't have to pay hundreds of dollars a year for this? And I'm like, actually, yes, I can. Before the answer was yes, but it's not worth AI. Now it's yes, I can. And so like, I've set up a project for a web app that I'm building for her that I work nights and weekends when I have a chance. It's. We're only just getting started here, but one of the things I did is I set it up with spec kit. And, uh, you better believe it in the project constitution. I was very meticulous about the testing strategy I was going to enact for this, right? We're going to have, you know, thorough test coverage, unit integration, end to end level. We're going to use playwright as the end to end solution, right? We're going to make sure that we're not duplicating tests at different layers. I mean, I had a whole spell, um, out markdown for all the kinds of things, like, you know, writing your acceptance criteria in gherkin and stuff, you know, so you know me, I'm picky about that, right? But it's like all of these things you can specify once and then it's baked in so that you. There's a much less risk of you constantly having to check every single pull request that it did it right, you know, versus like you have a, uh, college intern, you tell them to him or her to do something, okay? Then they fix it in that pr. The next PR same issue comes back third PR same. And then you're like, why did I hire this person? Right? Those kinds of issues go away when you bake it into your context and your skills. So it's just Part of the whole system, right? And so then you're perpetually finding new issues and eventually those run out. And then you can finally focus on the behaviors you're trying to build and not all the technical details that should just be taken care of for you.

Speaker A: So Andy, it sounds like you're using AI for a lot of things, but as you mentioned, how about costs? I know I've been seeing a lot of companies talking about token cost. Have you been seeing that? Is there a way, uh, a best practice that you found that maybe, hey, maybe you don't need AI for this. Or if we do AI for this, maybe have the context smaller than what you're using.

Speaker B: So thankfully for my personal projects, the $20, $25 a month subscriptions to cursor and Claude have been good enough, right? I'll pay that out of pocket. You know, I've got my automation, I got the business expense for my own personal stuff, right? Like, like my wife even has a Claude account that she pays for through her dance studio because think about it, she's got to write rental agreements and all the paperwork and stuff. I remember one day she texted me, Joe, uh, it was the most amazing day. I was at lunch, pizza with my friends and she said, Andy, I hit my clawed limit. So she had to wait like two or three hours for the reset or something. But I'm just like, dang, like my non tech program, like she's doing a dance studio and she's hitting her quad limit, right? But like we've been okay with like the, the 20amonth, like another monthly bill, right? We, business expense, the studio, whatever. On my team, thankfully we haven't had any runaway costs yet. We have a. Almost everyone on my team uses Claude code. I'm the one person who still uses Cursor because I'm weird and different, right? But like on, on the team and I have both of them, Claude and Cursor, like there we have like more than half the company has an account and certain people, we have a team account. So it's all together. Some people are okay with the standard subscription, which is like 20 bucks a month or something. Our power users, for example, my team, many of them are on the premium, which gives you the increased limits, the increased speed because literally they've got like three cloud terminals grinding code on different things at any given time, right? They've got it synced on their app where they're sending prompts while they're grocery shopping and stuff. It's wild. So it's like the costs are roughly expected. There haven't been any overage costs that we've incurred so far. But I mean there have been times where certain people have hit certain limits and be like, ah, ah, shoot, I gotta stop for a bit in those cases, like, okay, if it happens three times, bump you up. Right. So it's been manageable.

Speaker A: Nice.

Speaker B: I fear when all the subsidies run out and companies start charging what it actually costs, then that could be tough. But we're not there yet, so we're going to get as much progress as we can.

Speaker A: Absolutely. So, yeah. How do you know that you're not losing company domain knowledge this way? Like over relying on the AI where before maybe you would need. Is it just like you're just now a person that manages MD files and as long as you have those, doesn't really matter about being a domain expert. Well,

Speaker B: I have a few thoughts on that. I can't, I don't want to speak to like more entry or intermediate level folks because that's a whole question mark problem. Uh, right. But for more senior and experienced dev folks who, like you and me, we've been through the trenches, we fought battles, we've had to learn things the hard way. Right. Those lessons learned, that experience, that domain knowledge doesn't go away or get invalidated, I feel like it truly gets accentuated by AI. I know, like we're three years into this AI revolution and the coding assistants have only been really good for about a year. I don't feel like I've lost anything in terms of my knowledge or understanding, but rather I've gained because like, I feel like there's so much more that I can do now and I don't have the hesitations I used to have. Right. You know, like I mentioned this, this web app for my wife's dance studio. I could have figured that out like five years ago, but that would have been a, um, major project. I would have had to get some books and really dedicate a lot of time and learn some things. Right. Because it's like, I can figure this out, but that's not my day to day. I'm not a web developer now. It's just like, yeah, Speckit and React on the front end, Express on the back end, SQLite for now. And then at night I'm like, here's version 0.1, honey. What do you think so far? Wow. Make this like this. Okay. You got it. Great girl. Right? And so like, I understand principles of good software development, I understand web application architecture, I understand good testing practices, and so Like, I can bake all of that into a system, set it and forget it, and then just new features, right? So I don't feel like I'm losing domain knowledge or expertise in that of anything. I'm simply codifying it and I can refer back to it if I happen to, you know, need to check my notes.

Speaker A: Right.

Speaker B: I would also posit this. Do we ever open assembler code and read it today? Right? Do we, after we compile something, you know, do we crack open that, that executable, read the assembler code and be like, aha, I see what it's doing? No, we literally blindly trust what comes out of compiler. Right. That wasn't always the case 40 years ago, right. People would still be going into assembler, trying to eke out little efficiencies, but now it's like, no, no way. Right. I see these AI coding tools as the new compiler. I see markdown as the new programming language. Right. And if you start to think about it like that, does it really matter at the code level what is generated or that it works and it works well enough?

Speaker A: Oh, that's controversial because people like code quality, especially with testers. They care about the things we grew up on. Atomic tests, uh, page objects, shoot, automation, like a product. What language I use. Like, who cares now? But is that the wrong way to go? Like, if it's working, it's doing what I need, it's doing in a way that's fast enough. What do I care about what it looks like?

Speaker B: Isn't that what business always cared about anyway? See, wasn't that always the business perspective?

Speaker A: That was always the case, but we were so caught up in, I think, the, the development aspects of the, like, the mechanics of it, rather than, like you said, the business that we should probably always focusing on. I don't know.

Speaker B: Yeah. So business people never cared about the tech details because they were like, push features, make money. We as technical people cared about the tech details because we were humans actively working in those spaces. And so we had to make it good for ourselves to use.

Speaker A: Right.

Speaker B: If we've taken away that and we're no longer working at the level of the code, much like we were no longer working at the level of assembler. If we're now working at the level of spec, we're working at the level of skills, we're working the level of markdown, because Markdown is magic. How much should we care about code quality? We should care about efficiency, right? How fast does it run? We should care about bugs, security, vulnerabilities Right. But at the end of the day, is it worth waging holy wars on your company's formatting standards? Right. Maybe this doesn't matter as much now. I know you said this is very controversial. Yes, I'm, um. Today, where the puck is highly controversial. Where the puck is going, I think in 10 years, absolutely, this would be a no brainer. Like. But we're still early in this revolution, we're still early in this transition. And so. And the fact is the AI capabilities and the AI wisdom is not evenly dispersed amongst us as a whole technical community. Right. There are, there are still people working in places who, whose companies do not let them touch these tools.

Speaker A: That's true.

Speaker B: Who haven't had as much exposure. They've heard about the wonders of cursor, but they've never actually cursed at it.

Speaker A: Right.

Speaker B: You know, and so like, especially in big enterprise, my company, Target supply chain, guess what, Guess who, Right? You know, we just had a customer advisory board and almost half of them say, yeah, my company won't let me use these. And I'm like, oh my gosh. Right? And you're like, but it's 2026. It's like we're still only three years into the revolution. Oh, uh, we still got a long way to go. And so I think the fact that what I said right there is still controversial is because not enough people have gone through and it hasn't been accepted as standard enough yet. And to be fair, you know, the AI coding assistant tools are now just good enough that we can have that conversation, but they're not good enough yet that it's universally accepted. That's still going to take more time too. I do believe we will get there. I believe it's inevitable because look at compilers, right? Right. It's the, the AI building technology is too good. It is too. That's why we're building data centers around the world. Like, it's too good. And anybody who has touched it and known it had been supercharged by it knows, right? It's. There's no going back. There's no going back.

Speaker A: So like I said, controversial. Even testers that I use it sometimes, we have a different point of view. But what I thought is interesting, a lot of people said, oh, courses are dead now. Thought, being a thought leader is dead. But I noticed you, this was the whole show about this. But you released a new, a new course on LinkedIn about playwright with it. Like, and it's pretty extensive. Like, why couldn't it just be like open cursor Write me a test. Like, what type of skills? Why did you devote so much time to play, right, with AI if people think AI is going to replace them, um, or to teach them everything without putting the effort in, I guess.

Speaker B: Yep, yep. So what we as humans have to learn now are lessons, tools and techniques at a higher level, right? We. It's less important to know how to write the most perfect X path. It's more important to know how to leverage these tools and technologies as part of your quality strategy. Right? Because that part's not going away. Remember, software is ultimately for people, right? There's no world in which software is going to be in a hermetically sealed bubble, never operated by people at all. We build applications to solve our problems. We still live. We are endowed with souls, right? That doesn't go away. And so, okay, maybe I don't need to worry about, like I said, little minute details in the code, but I still need to worry about risk mitigation, quality management, building a project that is sustainable. Right. That doesn't go away. And that's more what I wanted to focus on in my new LinkedIn learning course, which is, I forget the exact title because it stretches off the page, but it's basically Playwright with AI.

Speaker A: You know, agents, context and test automation patterns. Smart web testing scripts with Playwright and AI. Amazing.

Speaker B: Um, yes, yes. So what I cover in that course is how you can use Playwright with AI coding agents leveraging the vast amount of AI tooling that Playwright has offered. What Playwright's strategy has been like. Originally they were meant to be a web testing tool, arguably competing against Cypress and Selenium. In the days before AI, their whole pitch was smarter, faster, stronger, better, whatever the daft punk stuff is. And they were, execution wise, the fastest. They had, in my opinion, the best developer experience.

Speaker A: Getting controversial, probably not anymore, but you know, so that a few years ago,

Speaker B: probably, yeah, but like it was meant to be something that was easy for developers and testers alike to pick up a run and get going. And that's. I fell in love with it. I'm like, this is, this is great. I love this, right? Then when the AI, uh, revolution came, Playwright wasn't trying to build their own models or anything, right? They weren't trying to build a whole platform around it. What they realized is, hey, let's make Playwright extensible. Let's make it usable by AI coding agents, right? Well, how do we do that? Well, they started with like an MCP server, right? Hey, you can have an MCP server that exposes all of the web interactions the Playwright does. So now if you have say, Claude or cursor, you can direct it to open a browser and explore and learn and do stuff. I mean it became the ultimate RPA tool. If you think about, ah, robotic process automation, all you need is a coding agent plus Playwright mcp. I mean the things you could do are amazing. Get this, you could make it explore your app, exercise the instructions of your user manual to verify that your user manual instructions are good and then provide suggestions. Or you could have it go, you know, clip by clip through your app and capture screenshots to make sure your user manual screenshots are up to date. That has nothing to do with like traditional test automation, but it's the kind of thing you can do now with Playwright and AI just like, oh, this is beyond testing. This is pure automation of my tasks. Wow, right? So they did that, then they added a whole bunch of agents or sub agents. Right? There's basically three. Three Biggins, Planner, Generator, Healer, Planner. Hey, let me suck in any specs you have, any information you have, any context or hey, maybe I can kick open a browser and explore your app and I'll come up with the, the reasoning behind like test plans that you should, or tests, uh, that you should be writing. Right? And so it'll generate test plans as markdown and you can review them and you know, you can whack some tests, you can tell it to refine, but it's like, it speeds up your test development process because now it's like, oh, here's a plan I can use. Generator turns those plans into actual playwright test scripts. Okay, you know what? Now let's do how goes through all of that. And then finally Healer is you've been running, um, them and something broke, something changed in your app. Your locator was flaky. Let's figure that out. Read the trace log of errors and then implement the change, run it and make sure it all works together. Planner, Generator, Healer very much mirror the BDD process of discovery, formulation, automation. Of course I eat this up. I'm just like, ah, this is genius.

Speaker A: Right?

Speaker B: So they did that. So not only do you have the mcp, but you also have these agents to guide, right? And so like you could go to just vanilla AI and be like, give me a playwright test. And it could poop out a script based on whatever it's sucked into its frontier model. But in terms of making sure that's actually a good test and that is actually a reliable test, that's where the MCP and the agents really come in because they help guide you, and they go through all the iterations and make sure that it's actually something worthwhile. And then finally the third thing did the MCP path. But then about half a year to a year ago, the whole world lit a buzz with Skills and cli, because that was going to be so much more efficient. Right? MCP is heavyweight, eats all the tokens. Let's do CLI with Skills. And so they did. They made a whole Playwright clique and they added a bunch of skills files that basically do the same things. And so now you can choose which way you want to go. So if you're a tester or developer just on your local laptop, you probably want to use CLI with Skills because of the token crunch is lower. If you're trying to embed Playwright into some agentic ecosystem and all this kind of stuff, you probably still want to use mcp. But it's like they gave all the tooling and said, you bring your own agent, we'll work with it. And now, boom. It's like, this is amazing, you know, so that's what the course really shows you, how to use all those tools, bring your own agent, and then make amazing things happen.

Speaker A: I highly recommend everyone check it out. We'll have a link for it down below, but I think it's like four hours long and I don't know how that works. Andy, I have a premium subscription to LinkedIn, but is it a paid. Is it. Who gets access to this?

Speaker B: Goodness. I'm not entirely sure the details. I think, like, I think you. There is payment that you have to give, but I think if you have like a LinkedIn Premium or if your company has like a LinkedIn Learning subscription, you can get in on that.

Speaker A: Nice.

Speaker B: I think I'm able to give some. Some like. Like discount or free links or something. I. I'll be honest, all the payment details, it's all LinkedIn.

Speaker A: Yeah, totally.

Speaker B: Yeah.

Speaker A: Cool.

Speaker B: They have an amazing process for soliciting instructors and running them through a program and everything. It's. It was an amazing experience developing the course with LinkedIn Learning A World class would recommend. If you're an instructor out there and they invite you, say yes.

Speaker A: All right, Andy, before we go, any actual piece of 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?

Speaker B: Sure. So best advice I can give to testers out there trying to get started with AI, just do it. Right. If you're not sure. Ask the AI how to help you through. Right? There's no barrier to entry. There's no reason to be stuck, right? Ask questions. Socratic method. Go ask your AI. Go ask people like me and Joe. Get involved in your local community. Now is the best time to get into software development and testing. Right? Um, I don't subscribe to doom and gloom. I don't think all of our jobs are going away. I see this as a true revolution on the scale of the Industrial revolution for what it's going to unlock for humanity. And we are on the front lines as the builders and it's going to be bumpy. There's going to be issues to solve along the way, but ultimately, like now is the opportunity. If you had any doubts, strike now while it's hot. So if you want to contact me, if you just Google Automation Panda, you will find me. My name is Andrew Knight. I am currently Senior Director of Product and Engineering at Cycle Labs. I am very active on LinkedIn. I used to be active on X. I'm still kind of out there. I just don't post as much. My website is automationpanda.com if you want to see cool things about cars, go to autopandamotive.com and you can find links

Speaker A: to all this awesomeness down below. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to test guild.com a599 and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm, um, Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers and across all our platforms and over 40,000 email subscribers who are at the forefront of automation testing and DevOps. If you haven't yet, join our vibrant community@, uh, testguild.com where you become part of our elite circle driving innovation, software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges. We're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve. With lutes and lyres the bards began their song A tune of knowledge A melody of cold through the air it spread like wildfire through the land Guiding tester showing us secrets to behold.