Playwright Test AI Agents – Setup and First Steps in VS Code

Three Ways to Add AI to Playwright Workflows

There are currently at least three ways to plug AI into Playwright workflows:

• Playwright CLI – simple, token efficient browser control from the command line.
• Playwright MCP – a richer toolset exposed to AI agents via the Model Context Protocol.
• Playwright Test Agents – custom AI agents embedded in your test workflow (our focus here).

The CLI gives you quick, direct automation, while MCP opens up a broader ecosystem of tools for agents to use. Both are useful and worth exploring in more detail, but this post is really about the third option.

If you are already using VS Code + Playwright Test + GitHub Copilot Chat, Playwright Test Agents are easy to set up and where things get very interesting fast.

Why Playwright Test Agents?

Unlike the CLI or raw MCP integration, Playwright Test Agents are designed specifically for testing workflows.

They sit on top of:

• Playwright Test
• VS Code’s Copilot agent chat experience
• A bundled MCP toolset

This gives you something closer to a guided, semi-autonomous testing assistant rather than a general-purpose AI tool.

The key idea is simple: instead of writing tests directly, you collaborate with agents that plan, generate, and refine them.

Setting Things Up

First, you will need a Playwright Test project in VS Code, and to be signed in to your GitHub Copilot account.

Make sure you are logged in to your GitHub account in VS Code

Use the command palette (Ctrl+Shift+P) to install Playwright Test

Finally, in the terminal initialise the Playwright agents for VS Code:

npx playwright init-agents --loop=vscode

That is it for setup.

The --loop=vscode flag tells the setup process that you will use the agents with VS Code. Other loop options include “claude“, “codex“, “copilot“(CLI), and “opencode” if you prefer CLI agent tooling.

What Gets Added?

1. Bundled MCP Server Configuration

Playwright Test includes a bundled MCP server that provides a broader toolset than the basic browser automation built into VS Code.

Unlike the Playwright CLI approach, which is minimal and token efficient, MCP tools return richer context and feed more information back into the agent loop. Also, unlike the standalone Playwright MCP server, the bundled server includes tools specifically for test planning, creation, and execution.

Together, that means:

• More informed decisions
• Better reasoning
• Higher token usage

It is a trade-off, but usually a worthwhile one for test creation.

2. Seed File

You also get a seed test file.

It is worth spending time shaping this, especially if you are adding agents to an existing project that already uses custom fixtures and setup. It is also worth noting that the file has a valid test file name – it will be discovered and run as part of a normal test run if executed with

npx playwright test

unless you exclude it in the playwright.config.ts file.

3. Custom Agents

Playwright defines a set of purpose-built agents:

• Planner – explores your app and creates a test plan
• Generator – turns plans into executable tests
• Healer – fixes failing tests

These are defined via simple agent.md files, so you can customise them or create your own.

Custom agent definitions added

Take a look at one you’ll see it’s like a film director giving an actor (the AI) stage directions and general instructions on how to play the role they have been assigned.

The Agent Workflow

Rather than writing tests from scratch, the recommended flow looks like this:

1. Generate a test plan
2. Review and refine the plan
3. Generate tests from that plan
4. Run tests and fix failures automatically

Step 1 – Generate a Test Plan

Start by selecting the Planner agent in the chat panel and asking it to explore your application.

The agent will:

• Launch a browser via MCP tools
• Navigate your application
• Inspect UI structure and content
• Build a plan covering user flows and scenarios

It does this through an “agentic loop” where the running agent proposes an action, you approve it, the tool runs, and the output feeds back into context before the agent continues.

The loop continues until the agent concludes the task is complete—or you notice something has gone awry and step in to help. It’s collaborative rather than fully automatic process,with the agent pausing to ask you to review its planned tool use and the output that will be fed back to the agent.

As you become more confident with the output of the AI through continual refinement of your prompts and the custom agent definitions you can “loosen the reins” allowing the agent to act more autonomously, while still being mindful of the risks posed by unsupervised and unrestricted AI use.

• https://code.visualstudio.com/docs/agents/concepts/trust-and-safety
• https://code.visualstudio.com/docs/agents/security

Step 2 – Review the Plan

The generated plan is saved into a specs folder.

At this point, treat it like any other test artefact:

• Check coverage
• Remove noise
• Refocus on business-critical flows

In practice, plans are often surprisingly thorough and occasionally over-enthusiastic, so a tidy-up goes a long way.

Step 3 – Generate Tests

Switch to the Generator agent and ask it to create tests from the plan.

You can use the generated plan, provide your own plan, or describe a scenario directly in the prompt.

The generator will produce Playwright Test code aligned with your seed file and project structure.

Results are often good, but not perfect.

// spec: specs/edgewords-cart-basic-plan.md
// seed: e2e/seed.spec.ts

import { test, expect } from '@playwright/test';

test.describe('Cart Core Flows', () => {
  test('Search for Cap, add to cart, and verify in cart', async ({ page }) => {
    // 1. Open home page in a fresh state.
    await page.goto('https://www.edgewordstraining.co.uk/demo-site/');

    // expect: Search box is visible and enabled
    await expect(page.getByRole('searchbox', { name: 'Search for:' })).toBeVisible();

    // expect: Cart starts empty for this independent scenario
    await expect(page.getByRole('link', { name: '£0.00 0 items ' })).toBeVisible();

    // 2. Enter Cap in the search box and submit.
    await page.getByRole('searchbox', { name: 'Search for:' }).fill('Cap');
    await page.getByRole('searchbox', { name: 'Search for:' }).press('Enter');

    // expect: User is taken to relevant result/product page for Cap
    await expect(page.getByRole('heading', { name: 'Cap' })).toBeVisible();

    // 3. Click Add to cart for Cap from search result/product context.
    await page.getByRole('button', { name: 'Add to cart' }).click();

    // expect: Success confirmation is shown
    await expect(page.getByRole('alert')).toContainText('"Cap" has been added to your cart');

    // expect: Cart count increments to 1
    await expect(page.getByRole('link', { name: '£16.00 1 item ' })).toBeVisible();

    // 4. Open main Cart page.
    await page.goto('https://www.edgewordstraining.co.uk/demo-site/cart/');

    // expect: Cap appears as a cart line item with quantity 1
    await expect(page.getByRole('link', { name: 'Cap' }).first()).toBeVisible();
    await expect(page.getByRole('spinbutton', { name: 'Product quantity' })).toHaveValue('1');

    // expect: No unexpected extra products are present (only one product row)
    await expect(page.getByRole('button', { name: /Remove .* from cart/ })).toHaveCount(1);
  });
});

You may still see:

• Slightly odd locator choices
• Fragile navigation steps
• “Creative” interaction patterns

For the most part the above code looks OK – except Step 4 navigates directly to the cart page via an address change. I prefer to “do what the user does” when writing my tests – i.e. I’d click the Cart link in the navigation:

There is a subtle issue that took some time to debug the first time I encountered it:

The Edgewords WooCommerce demo site (and WordPress platform on which WooCommerce is built) often use “curly quotes”, which Claude models currently normalises to “straight quotes”. This can break assertions and locators that use them.

However, the proof of the pudding is in the eating, so let’s go ahead and run the test as is.

This is another common issue with the AI generated tests: locators are not checked for uniqueness i.e. a given locator should only match one element on the page—if a locator matches more than one element then a “strict mode violation” error is thrown when the test attempts to perform an action (such as a click) using that locator.

We could certainly fix these issues ourselves (and in the case of the style issue of navigating using page.goto() will have to), but we can also ask our AI assistant to do the honours…

Step 4 – Run and Fix Tests

When a test fails, hand it to the Healer agent.

It can:

• Replay failing steps
• Inspect the current UI
• Identify equivalent elements or flows
• Suggest and apply fixes (depending on approval settings)
• Re-run the test

It effectively performs an automated debug -> fix -> retry loop.

This works particularly well for:

• Locator issues
• Timing/synchronisation problems
• Minor UI structure changes

Less so for:

• Fundamental logic errors
• Incorrect test assumptions
• Errors stemming from the chosen AI model itself (e.g. the “curly quotes” Claude issue)

…but even then, it often gives you a strong starting point.

Note the change of model to GPT 5.3 Codex: it has no problems with “Curly Quotes”.

One last follow up prompt I have found useful is:

Wrapping Up

Playwright Test Agents do not replace writing tests. They change where your effort goes:

• Less time scaffolding
• More time reviewing
• More time refining

And perhaps, most importantly, they keep you in the loop rather than taking you out of it.

If you’re interested in learning more take a look at our AI and Playwright Test course.