We've come a long way from the early days of Vibe coding, LLMs and MCPs. Today, we're stitching them together into Agents, autonomous systems that don't just assist, they act. And in the testing world, I've seen these agents do some remarkable things: spinning up test automation frameworks from scratch, generating self-healing scripts, embedding quality gates directly into CI/CD pipelines.

It's exciting. It's fast. And it's exactly where we need to pause and think.

The Agentic Testing Landscape in 2026

When I first saw Agentic AI entering the test case creation space, I kept my eyes wide open. As someone who's spent over a decade building QA practices from the ground up from Colombo to Amsterdam to Melbourne, I've learned to be both an optimist and a sceptic when it comes to new tooling.

Here's what the agentic workflow looks like today:

• Atlassian MCPs connect to your Jira, pulling user stories and acceptance criteria

• Figma MCPs access design files and UI specifications

• Confluence MCPs surface technical documentation, architecture diagrams, and API contracts

• Playwright or Cypress MCPs take the generated test cases and automate them end-to-end

Feed the agent a well-written requirement, complete with acceptance criteria, design references, underlying API details, architecture context, data models, and integration touchpoints, and it will produce a set of test cases in minutes. Connect a Playwright MCP, and the automation is done too.

Impressive? Absolutely.

But here's the question nobody's asking loudly enough:

Speed ≠ Quality

Will agentic AI fast-track test case creation? Yes, without a doubt.

Will it accelerate delivery cycles? Yes.

But will it reduce defect leakages? That's where it gets complicated.

I've heard the argument: "If we do frequent releases, bugs can be fixed in the next release." And sure, technically that's true. But let me ask you this.

Do we really want our customers to tell us how buggy the system is?

Do we want them frustrated, leaving bad reviews, losing trust in our product?

A fast pipeline that ships bugs faster is not a quality pipeline. It's a liability pipeline.

"Think Like a QA"

I say this to everyone I work with, and I'll say it here: test case designing yes, I deliberately use the word designing over writing because it is a craft.

There is so much that goes into creating a quality test case. You go through the requirements inside and out. You ask questions from the BA or Product Owner questions that sometimes make them pause and realise,

"Wait, there's more to this requirement than we thought."

You study the design files. You trace the data flow through APIs. You think about what happens when things go wrong, not just when they go right.

Just as UI/UX engineers design interfaces to deliver the best user experience, a QA designs test cases to safeguard that experience.

An AI agent can generate test cases from inputs. But it doesn't wrestle with the requirement. It doesn't have that nagging feeling that something's missing. It doesn't ask the awkward question in a refinement session that uncovers a gap no one else noticed.

The Exploratory Testing Opportunity

Here's the thing, I'm an advocate for using AI tools to make our lives easier. I'm not anti-AI. Far from it!

But once AI covers the bulk of the functional testing for a requirement, that creates a golden opportunity. It frees up the QA to do the most meaningful work: Exploratory testing for instance.

And this is where humans shine.

Consider this scenario:

An agent generates 40 test cases for a healthcare patient registration form. It covers field validations, mandatory fields, API response handling, error messages all the expected paths. Everything passes. Green across the board.

But a human QA, spending time living in that feature, notices something the agent never would: when a patient's Medicare number is entered with a trailing space (copied from an email), the system silently accepts it but fails downstream during a claims submission. Three steps later, in a completely different module. No error. No warning. Just a rejected claim that the patient discovers weeks later.

That's the kind of defect that an AI agent misses because it tests in isolation. A QA who thinks like a user, who follows the thread beyond the boundary of a single story, catches it.

The Danger of Prompt-and-Go

Here's my concern: if a QA just picks up a story, fires off a prompt to an agent, and lets it do all the testing, that QA never actually engages with the requirement. They never study the designs. They never think like a technical QA.

And that has a real downstream impact. The quality of the final delivery drops. Not because the AI did a bad job within its scope, but because nobody did the job that sits outside the AI's scope.

The thinking. The questioning. The connecting of dots across stories, sprints, and systems.

Introducing QX Notes! Let Your QA Spend Time on the Story

Here's something practical I want to propose.

Add a section to your Jira stories called "QX Notes."

This is where the QA after spending time understanding the requirement, the design, the technical context, captures their insights, observations, edge cases they've identified, areas of risk and writes it in a plain language.

Think of it as the QA's design brief for the story.

Two things happen when you do this:

1. AI agents get better inputs. When the agent reads the story to generate test cases, the QX Notes section gives it the domain context, edge-case thinking, and risk areas that acceptance criteria alone don't cover. Better inputs, better test cases.

2. The QA is empowered to do meaningful exploratory testing. Because they've already engaged deeply with the story, they know exactly where to probe, where the gaps are, where the real risks live.

Introducing QX Engineers!

QX stands for Quality Experience.

And a Quality Experience Engineer or QX Engineer is what I believe the modern QA role is evolving into.

A QX Engineer isn't just someone who writes test cases or maintains automation scripts. They are someone who:

• Thinks like a QA - bringing the quality mindset to every conversation, every requirement, every design review

• Asks the right questions - the ones that make BAs rethink, developers reconsider, and product owners add detail

• Champions quality culture - not as a gate at the end of the pipeline, but as a thread woven through the entire delivery process

• Leverages AI as a tool, not a crutch - using agents to handle the repetitive work while focusing their expertise on what truly matters

The future of QA isn't about being replaced by AI. It's about evolving into QX Engineers who bring the human judgment, domain expertise, and quality culture that no agent can replicate.

The Bottom Line

Agentic AI is a game-changer for test case generation. I won't pretend otherwise. But it's a tool. And like any tool, its value depends entirely on the hands that wield it.

Let your QA spend time on the story. Let them think, question, and design. Capture that thinking in QX Notes so both humans and AI benefit from it. And start thinking of your QA team not as testers, but as Quality Experience Engineers,the people who ensure your product doesn't just work, but works well for the people who use it.

Because at the end of the day, your customers don't care how fast you shipped. They care how good it is.

I'm a Quality Practice Leader based in Melbourne, Australia, with over 10 years of experience building QA practices across banking, healthcare, and edtech. From Sri Lanka to the Netherlands to Australia. I write about test strategy, quality culture, and the evolving role of QA in the age of AI and beyond.

Connect on LinkedIn, lets have a chat about it!