Let me start with something I don't see many senior engineers admit publicly.

I am still learning Playwright. Not "polishing my advanced knowledge" learning. Actually learning it — working through concepts, getting stuck, figuring things out. And I have been using AI heavily to do that.

I manage a 20+ member QA team. I have been doing this work for over seven years. And there are things about the tools we are moving toward that I do not fully know yet. I am figuring them out alongside my team, not ahead of them.

I am writing this because most of the content I read about AI in QA is written from a position of authority. Someone who has already figured it out, explaining it back to you. I am not in that position. I am in the middle of it. And I think that perspective is worth something.

Why I was skeptical

When AI tools started becoming part of the conversation in software testing, my honest reaction was to wait. Seven years in QA teaches you to be careful about things that get called "the future." I have watched tools get adopted with enormous enthusiasm and then quietly shelved. I did not want to get caught chasing something that would not last.

So for a while I observed. I read what other people were saying. I did not rush to form an opinion.

What eventually changed my mind was not a conference talk or an article. It was a specific, ordinary moment at my desk where I was stuck on a Playwright concept I could not make sense of from the documentation, and I asked an AI assistant to explain it differently. And it did. Clearly. In a way that actually landed.

That was it. Not a dramatic transformation. Just a quiet realization that this thing could actually help me learn.

What it actually looks like in practice

I am in the middle of transitioning our team from manual testing to Playwright automation. That is the direction we are heading as a team, and I am responsible for keeping that momentum going. What I want to be honest about is that my role in this transition right now is mostly motivation and guidance. I am encouraging people to pick it up, pointing them toward resources, keeping the energy positive.

I am not the person teaching Playwright on the whiteboard. I am learning it myself.

When I get stuck — on async behavior, on a locator strategy that is not working the way I expect, on understanding why a particular test is flaky — AI is the first place I go. Not because it always gets it right. But because it explains things in plain language, it does not judge the question, and I can ask the same thing five different ways until the explanation finally clicks.

I think a lot of people are using it exactly this way. Late at night when you cannot sleep and you are turning a concept over in your head. In between meetings when you have ten minutes and a question you are slightly embarrassed to ask a colleague. When you need to understand something properly before you can explain it to someone else.

That last one matters to me. I spend a lot of time motivating my team to push through the discomfort of learning something new. I want to be able to have real conversations with them about what they are running into. AI helps me close that gap faster — between what I know and what I need to know to be useful to the people around me.

The thing I think about more than the tools

Here is where I want to say something that is not really about AI at all.

My team has fears about where this is going. Some of them have asked me, carefully, whether automation and AI tools mean fewer QA engineers are needed. Whether learning all this new technology is just accelerating their own obsolescence.

I do not think that fear is irrational. The industry is changing. Some companies are reducing headcount. When you watch a tool generate test cases in seconds, it is natural to wonder where that leaves the person who used to spend hours writing them.

What I believe — and what I keep coming back to — is that the engineers who will be fine are the ones who stay curious. Not the ones who already know everything, but the ones who keep asking questions and are not too proud to learn in public.

I include myself in that. I am a senior engineer who is still learning the tools my team is adopting. I ask AI to explain things to me that I probably should have already mastered. I am figuring this out as I go, the same as everyone else.

I think that is okay. I think it might even be the point.

What I want to keep

The part of QA that AI does not touch — or at least has not touched yet in any way that worries me — is the part that lives in context and history. Knowing how a specific system actually breaks. Understanding the gap between what a state contract says an EVV integration should do and what it does at the boundaries. Recognizing a pattern of failures across releases because you were there for all of them.

That knowledge is slow to build and hard to transfer. It is not in any documentation. It lives in the people who have been paying attention for years.

I think about that when I think about where QA engineering is heading. The tools will keep changing. The underlying skill — actually understanding what a system is doing and why it matters when it goes wrong — that feels durable to me.

At least I hope it is. I have built seven years of it.

Sakif Yeaser is a Senior Software Engineer in QA at Therap (BD) Ltd., where he co-leads a 20+ member QA engineering team working on a US healthcare platform. He is currently learning Playwright. He uses AI a lot.