Expert Insights

Q1: Are we heading toward a world where AI writes and maintains its own test suites – and is that a good or a terrifying idea?

Yes, we’re heading there, and it’s both a good and a terrifying idea. As a QA automation architect who has watched this industry evolve from brittle record-and-playback scripts to complex test automation frameworks, I see this as the era of ‘autonomous testing’. We are entering an era of “autonomous testing”, but the reality on the ground is nuanced. Here is how I see this.

The good:

1. Reduced flakiness – AI can eliminate the tedious maintenance cycle of updating broken element selectors and fixing timeout issues.
2. Instant shift-left – the moment a developer opens a pull request, AI can generate a corresponding integration test suite and send it for review.
3. Extended test coverage – AI can generate a significant amount of user journeys that a human would never have the time or the resources to create.
4. Elevating human QA – engineers can shift from writing repetitive boilerplate code to designing high-level test strategies and exploring complex edge case scenarios.

The bad:

1. Echo chamber of errors – if AI writes the application code and AI writes the test suite, they can share the same logical blind spots.
2. Black box problem – debugging a failed test written by an AI framework can be a nightmare if the execution path and assertions lack clear, human-readable intent.
3. Regression of skills – if junior engineers rely entirely on AI to generate tests, they will lose the critical thinking skills required to understand how software breaks.
4. Hallucinated assertions – so far AI is notorious for hallucinating green lights. It might assert that a feature works perfectly well simply because the user interface is rendered, completely missing silent backend data corruption.

So, in my opinion we are not heading toward a world without QA engineers – we are heading toward a world where QA engineers manage AI testing agents. The future is a hybrid model where AI handles the execution and some script maintenance, while humans retain absolute veto power over test strategy, risk assessment, and final quality gates. Execution is being automated while strategy is being elevated. QA engineers who survive this shift will stop being “script writers” and become “risk architects”.

Q2: What does “quality assurance” even mean when the system you’re shipping is an AI agent making autonomous decisions?

Quality Assurance shifts from verifying predetermined paths to defining safe boundaries. You can no longer test for expected “outputs” because the agent is non-deterministic and decides its own path (an autonomous agent is essentially a series of linked probabilistic decisions). Instead, you must switch to the risk management approach and test for acceptable “behaviours”.

Q3: How should the role of a QA engineer evolve as AI handles more of the mechanical testing work?

QA engineer’s role evolves from a technical scribe to a quality strategist and system architect. You are no longer paid to find bugs – you are paid to prevent architectural risks and design the guardrails that keep both code and AI agents in check.

One emerging pattern: the ‘overseer of the judge.’ Agents are increasingly graded by other AI models (LLM-as-a-Judge). QA can own the golden datasets for evaluation to ensure these automated judges are scoring the agent accurately and unbiasedly. QA engineers must aggressively test the agent’s constraints. You are no longer checking if a button works – you are checking if the agent refuses to bypass security, hallucinate data, or execute unauthorized transactions when provoked.

Q4: How do you think about accountability and liability when an AI feature makes a wrong call that causes real harm?

If a bridge collapses, you don’t blame the concrete – you investigate the blueprints, the tests that were executed, and the maintenance logs. I think about AI accountability the same way.

You must prove you ran rigorous regression testing, adversarial red-teaming, and bias evaluation prior to release. If a company can show documentation that they tested a decent amount of edge cases, set up guardrails, and maintained a continuous evaluation pipeline, the liability shifts from “negligence” to “inherent system limitation”.

Here is a high-level overview of where the blame ultimately lands:

1. Model providers (Anthropic, OpenAI, etc.) – can be liable only if the model bypasses its core alignment safety filters (for example: teaching someone how to build a bomb despite built-in restrictions) or if they silently change a model’s weights in production, causing downstream consumer systems to break.
2. Software engineering teams – can be liable if they failed to implement adequate deterministic guardrails (for example: allowing an LLM-driven chatbot to directly execute SQL write commands against a database without a hardcoded validation layer).
3. Executive leadership – can be liable if they rushed a product to market to beat competitors, consciously overriding QA red flags and risk assessments regarding the system’s error rates.

In the autonomous age, QA changes from a technical function to a legal and ethical protection layer. Our job is to prove that the business exercised due diligence before unleashing autonomous agents on the public.

Q5: What would a dedicated “AI QA” function look like inside an engineering org – separate team, embedded, or something else?

A siloed, traditional ‘separate team’ sitting at the end of a deployment pipeline doesn’t work here. Since AI systems operate at the intersection of data, code, infrastructure, and probabilistic models, a guild model is a better fit. In this structure, you have a highly specialized, centralized AI testing platform team, while embedded QA specialists reside directly inside product squads.

By the centralized AI testing platform team I mean a core engineering team focused entirely on infrastructure and tooling. They do not test individual features. Instead, they build and maintain the internal testing ecosystem that the rest of the company consumes. Their mandate can be:

1. Build and maintain the LLM-as-a-Judge infrastructure and automated prompt evaluation pipelines.
2. Manage the company’s golden datasets for tests and regression benchmarks.
3. Construct realistic deterministic sandboxes and API mocks where autonomous agents can run wild safely during testing.
4. Provide observability tooling to track model drift, latency, token costs, and safety violations in production.

As for the embedded AI QA engineers – they are specialized quality engineers residing directly inside cross-functional product squads (together with frontend developers, backend developers, and data scientists). Their sphere of influence can be:

1. Own the intent specifications and test personas for the specific features their squad is building.
2. Conduct adversarial red-teaming and prompt-injection testing against new feature prototypes.
3. Curate the evaluation datasets specific to their product domain (for example: ensuring a billing agent has specific billing edge-case test data).
4. Review production logs to catch state decay and micro-hallucinations unique to their feature’s users.

To make this work, leadership must treat AI QA as a peer to Data Science and MLOps, not an afterthought. The function’s success should be measured not by “bugs found”, but by system guardrail reliability, evaluation dataset coverage, and time-to-market safety.

Q6: If you were advising a QA team just starting to test AI features for the first time, what’s the first thing you’d tell them?

The very first thing I would tell them is: “Step forward from deterministic testing – you are no longer verifying exact outputs, you are evaluating a spectrum of acceptable behaviours”.

In traditional QA, software is predictable. If you input A, you must get B. If you get C, it is a bug. AI entirely shatters this paradigm. Because AI models are probabilistic, the exact same input can yield different answers. You must evaluate the guardrails, confidence scores, and semantic meaning rather than doing string assertions.

Q7: What does “technical debt” mean in the context of AI evaluation infrastructure – and how do you avoid accumulating it?

In AI evaluation infrastructure, technical debt is the long-term architectural cost you incur when you build quick, brittle validation setups instead of scalable, rigorous testing systems.

In traditional QA, technical debt usually looks like messy code or flaky end-to-end tests. In AI evaluation, it is far more dangerous because it directly compromises your ability to trust whether your model is getting better or worse. Here are several examples:

1. Frozen dataset – using the same small, hand-crafted prompt dataset for months. The model can optimize for these specific prompts, masking real-world failures and regressions.
2. Brittle assertions – using rigid code to parse fluid AI outputs. When the model subtly updates its phrasing, hundreds of tests break, leading to alert fatigue.
3. Lack of evaluation versioning – failing to tie evaluation scores to specific prompt versions, model weights, and hyper-parameters you lose the ability to reproduce or audit past results.
4. Unmonitored evaluation LLMs – using an external LLM as your automated judge without tracking its API costs, prompt changes, or internal version updates. In such a case your judge is mutating silently.
5. Tooling fragmentation – allowing individual developers to build their own custom evaluation scripts. This creates disconnected silos instead of a unified, enterprise-wide evaluation pipeline. This problem was actual even before the AI era, so using tools like Cucumber (for example: https://github.com/Marketionist/playwright-cucumber-steps) with standardized and reusable step definitions that are easily readable both for human and for AI can be worth looking at.

To keep AI evaluation infrastructure clean, scalable, and reliable, I would suggest to implement these strategies as early as possible:

1. Version everything – store your test datasets as a code in Git or any other version control system.
2. Automate dataset growth – build pipelines that automatically clean, anonymise, and inject real user production failures back into your test suites.
3. Maintain diversity – segment your datasets by intent, complexity, and safety guardrails rather than bundling them into one giant pool.
4. Abstract the judge – if you use an LLM-as-a-judge, self host the evaluation model or lock down the exact API version to prevent silent evaluation drift.
5. Separate environments – keep your application code completely independent of your prompt engineering and model selection.
6. Manage prompts via registry – use a prompt registry tool so updates can be version controlled, tested, and deployed without changing application source code.
7. Profile your tests – as automated AI evaluation consumes a lot of resources, track token spend and execution duration for every test run.
8. Implement tiered testing – do not run a bunch of LLM evals on every single code commit. Run cheap, deterministic checks on commit, and save heavy LLM-as-a-judge evaluations for nightly builds or trigger them on demand.