What are the risks of AI-generated test code?

AI assistants make it cheap to produce test code. The risk is that producing tests and producing confidence are different things. I group the risks like this.

1. Tests that don’t really test anything

Generated tests often check that a response is 200, that an element is visible, or that a value is “not null”. They pass, increase coverage numbers and catch very little.

// Looks thorough, asserts almost nothing about the business rule
test('applies discount', async ({ page }) => {
  await page.goto('/cart');
  await page.getByRole('button', { name: 'Apply coupon' }).click();
  await expect(page.locator('.total')).toBeVisible();
});

A useful test asserts the expected total for a given coupon and cart. I check generated tests by breaking the behaviour (or running a mutation testing tool such as PIT or Stryker on unit-level tests) and confirming the test fails.

2. The oracle problem

If you ask a model to “write tests for this function” and give it only the implementation, it infers expected results from the code. Any bug in the code becomes the expected behaviour, now locked in by a passing test. Expected results must come from requirements, specifications or domain experts, not from the implementation under test.

3. Hallucinated and outdated APIs

Models can produce methods that don’t exist, options from older library versions (for example the pre-Selenium-4 WebDriverWait(driver, 10) constructor), or mix up frameworks (Cypress syntax in a Playwright test). These usually fail at compile time, which is the lucky case. The worse case is a misused API that compiles and silently does something else.

4. Convention drift and maintenance cost

Generated code tends to ignore your framework’s helpers, page objects and data builders, and re-implements them inline. Volume grows fast: hundreds of near-duplicate tests that each need updating when the UI changes. Generated UI tests also frequently include fixed sleeps or brittle locators, adding flakiness.

5. Security and compliance

• Pasting proprietary code, credentials or production data into unapproved tools.
• Generated code that disables TLS verification or logs tokens “to make it work”.
• Licensing and provenance questions, which your company’s policy should cover.

6. Skills and ownership

If a team stops understanding its own tests, nobody can debug them when they fail at 2 a.m. before a release.

Mitigations

• Same review bar as human code, with a reviewer who understands the feature.
• Requirements-first prompts: generate scenarios from acceptance criteria, review them, then generate code.
• Prove tests can fail: mutation testing, or deliberately breaking the feature or the test data.
• Guardrails in CI: linters and custom rules (ban Thread.sleep, waitForTimeout, .only), type checking, flakiness tracking.
• Coverage of risk, not lines: track which requirements and risks are covered.
• Clear policy on approved tools and data.

What interviewers look for

• The oracle problem, stated explicitly; it is the deepest risk.
• Concrete mitigations, especially verifying tests can fail.
• A balanced view: AI assistance is useful, with controls.