The QA engineer role when agents also write the tests

Stefan-Iulian Tesoi · 21 October 2026 · 6 min read

A QA engineer becomes the check that does not share the agent's assumptions. When one agent writes the code and its tests, both carry the same reading of the item, so the useful work sits around them: criteria fixed before the build, acceptance tests from an independent hand, and exploratory testing on the paths nobody wrote down.

That changes where the QA engineer role spends its week more than what it is for. Finding defects is still the job. Finding them by re-running a script written last quarter is not.

What is the QA engineer role for now?

Owning what correct means, independently of whoever built the change. A coding agent produces a change and the tests for it in one sitting, so the tests can only confirm the agent's own understanding. Someone has to stand outside that understanding, and it is the QA engineer.

In engineering team structure when agents write the code, QA is the role whose hours move from running manual test scripts to designing checks and acceptance testing per item. In practice that means owning the test strategy for coding agents: which checks run where, who writes each kind, and which tests an agent is not allowed to change.

Why are an agent's own tests not enough?

Because they come from the same reading of the item as the code. If the agent misunderstood the requirement, its tests encode the same misunderstanding and pass.

We have an example from this product. A change to the job queue added an attempt counter and compared it numerically. Its tests created jobs through the current data model, which fills in a default, so every job in the tests had a counter. Production held jobs written by the previous build, which had none, and a numeric comparison against a missing field fails every time. The change was live within 30 minutes of being merged, and from then on those jobs could never be claimed.

The test that catches it inserts a job in the old shape straight into the collection, past the model. Nobody writes that test from inside the change, because from inside the change there are no old rows. AI-generated tests are usually competent at what they test; the gap is what they never think to test. The mechanical check, running the new tests against the old code, is in AI-generated tests: what they prove and what they do not.

Tools that repair tests raise the same question one step later. Playwright's test agents, introduced in Playwright 1.56, are three agent definitions: a planner that explores the app and writes a Markdown test plan, a generator that turns the plan into tests, and a healer that reruns a failing test and patches it. The healer's documented output is "a passing test, or a skipped test if the healer believes that functionality is broken."

A skipped test is a decision about what correct means. On most dashboards it reads as green.

Whoever owns the test strategy decides whether a healer may skip, and who reads the list of what it skipped.

Moving QA to before the work starts

The most valuable hour a QA engineer spends now is on the item, before an agent picks it up. An agent tests what it is told about, so the edge cases have to be in the item rather than in a tester's head.

1. Make every criterion checkable. Each one names something to run and an outcome to observe, the standard set out in acceptance criteria an agent can verify.
2. Write the edge cases as criteria. Empty input, a duplicate, a record in the old shape, a user without permission. Four lines that cost a minute each.
3. Write the acceptance test, or at least its assertions, before the build. Keep it in a path the agent may read but not edit, enforced by a CODEOWNERS entry with required review or a CI check that fails when the agent's diff touches it.
4. Say which criteria need a person. A criterion nobody can automate is still a criterion. It needs a named checker, not silence.

This is QA in AI-assisted development at its most useful: the defect is removed from the specification before it is built, which is cheaper than finding it in a build that has already shipped.

Which testing still needs a person?

Exploratory testing, and acceptance of anything a customer will see. Exploration means learning the system while testing it, following what looks wrong rather than a script, and it finds the problems nobody specified: the label that misleads, the flow that works and makes no sense, the error message that blames the user.

The last row is a different question from the rest. A tester can confirm behaviour against the criteria; only the person who asked can say they were the right criteria, which is the subject of user acceptance testing when an agent built the feature.

Laimonade is built around the same split. A coding agent hands its work back to In Review with the commands it ran, their results, and the steps a person still needs to take, and the item's testers are notified. A coding agent cannot move its own work to Done.

What should a QA engineer stop doing?

Running scripted manual regression passes, and writing tests an agent can write as well. Behind most worried searches about QA testers and AI is replacement, and the part agents replace is exactly the scripted part.

• Repeating the release checklist by hand. Turn each step into a Playwright test, let the agent maintain it, and review the changes.
• Writing unit tests after a change lands. The agent writes those. Checking that they fail on the old code takes five minutes and is worth more.
• Re-running flaky tests until they pass. A healer does that now. Reading what it skipped is the new job.
• Being the last gate before release. By then the item has been built on whatever the criteria said. The first gate, at Ready, is where QA changes the outcome.

The definition of done when an agent wrote the code is where these choices become the team's rule rather than one tester's habit.

Frequently asked questions

Should QA write the acceptance criteria?

QA should edit them, not necessarily write them. The requester or product owner knows what the feature is for; QA knows what makes a criterion checkable and which edge cases are missing. The habit that pays is a QA pass on every item before it reaches Ready, so no criterion enters a build that nobody could test.

Can an agent do exploratory testing?

Partly. Playwright's planner agent explores an application and writes a test plan, and it finds broken flows quickly. It explores toward the request it was given, though, and reports what fails rather than what is confusing, slow or pointless. Use it to widen coverage, and keep a person on the session that asks whether the feature makes sense.

Do manual test cases still have a place?

Yes, for checks that cannot be automated: a payment with a real card, an email arriving in a real inbox, a layout on one specific device. Write each as steps with an observable result, attach it to the item, and retire it once it can be automated.