Advanced Web Testing with Playwright and AI [Testμ 2026]

What Makes Playwright Fast?

Playwright manipulates the browser through fast debug protocols rather than the WebDriver protocol Selenium uses. He describes it as going in through the back door, and it is why the benchmarks put it ahead on raw interaction speed.

It also works against browser projects rather than the branded browsers. You test Chromium, Firefox and WebKit, the three core projects that sit under Chrome, Edge and Safari, and Playwright pins and manages those versions for you.

That removes a specific class of failure: a driver executable falling out of sync, or an overnight browser update wiping out CI. Browser channels let you reach installed Chrome and Edge when you need them, though full Safari and mainline Firefox stay out of reach.

The built-ins matter too: automatic waiting, a code generator, UI mode, and API testing alongside UI testing. His own habit is to stage data through APIs for setup and cleanup, then drive the workflow through the UI.

On language bindings he is blunt. Node is the native one and gives you the Playwright test framework itself. The Python, Java and .NET packages give you Playwright as an engine that you plug into pytest, JUnit or MSTest, which is not the same thing.

Browsers, Contexts, Pages

The architecture section is the one worth reading twice, because it explains the speed claim rather than asserting it.

In Selenium practice, every test gets its own WebDriver session. Launching it costs three to ten seconds locally and longer remotely, teardown costs more, and multiplying that by a thousand tests buys you nothing but mechanics.

Playwright runs one browser instance per worker, and several tests share it. That sounds like a violation of test independence until you see the second half: every test gets its own browser context, a protected session inside the instance carrying its own state, storage and cookies, much like an incognito window.

Setup and teardown per test therefore drop from seconds to milliseconds, and parallel tests in separate contexts stay safe.

Inside a context you get one or more pages. Most tests need one, but a click that opens a new tab can be handled by spinning up another page, which is the limitation Cypress historically could not clear because it could only ever hold one tab.

Selenium, Cypress, Playwright

He is careful not to turn the comparison into a war, and notes that Cycle Labs still runs Selenium alongside Playwright for some work.

• Selenium - the kingpin that started open-source web testing, with multiple contributors, all the branded browsers and multiple language bindings. Its limit is that it is a tool rather than a framework, so you build everything around it yourself.
• Cypress - the first to take developer experience seriously and make web testing enjoyable, at the cost of living inside the confines of a browser and being JavaScript only.
• Playwright - the developer experience of one with the reach of the other, plus the optimisations above, and in his reading the best equipped of the three for the AI era.

The AI Stack Defined

Before touching the tooling he defines the vocabulary, on the grounds that rule, context, skill and agent have blurred together in common use.

• Coding agent - the orchestrator, pulling model, rules, sub-agents and tools together into an end-to-end result.
• Model - the thinking piece, and stateless. You put in a prompt and get out an answer, which is why models are good at answering questions and not at remembering your project.
• Rules - standing instructions in the system prompt, meant to be unconditional. A rule says you will always do this, and the agent takes it seriously.
• Sub-agent - a spawned worker with its own context window, tools and directives. You give it a persona or a goal, it is dispatched, and it comes back.
• Skill - narrower and more targeted, a packaged prompt for a specific task with well-defined bounds, running inside the context window it was called from rather than being dispatched.
• MCP - an open standard for connecting agents to external servers, which is how deterministic tools get made visible and callable to a non-deterministic agent.
• CLI - another way of calling a deterministic process, local, fast, text-based, and documented by man pages the agent can read.

MCP or CLI?

Playwright ships both, which invites the question of which to reach for.

His split is about where the work runs. For local development on your own laptop the CLI is usually the better tool, because it is local and quick and the agent is already good at calling command-line programs.

For an agentic workflow that is distributed, MCP is the answer, because you need a network protocol to command things across machines.

Plan, Generate, Heal

The process has three steps, and Playwright’s own tooling guides you towards them.

• Plan - gather what to test. Skills and tools explore the app, read the specs, and produce test plans as markdown files.
• Generate - turn those plans into executable spec files with real Playwright calls.
• Heal - fix what breaks, whether a locator the first generation got wrong or a change you made to the app on purpose.

He maps it onto the BDD cycle he came up in: discovery is plan, formulation is generate, automation is heal.

The caution he attaches to the third step is the one to carry away. A test that starts failing may have caught a real bug rather than fallen behind an intended change, so review the failure before you let anything heal it. Healing a genuine regression makes the test agree with the defect.

Context Engineering

This is where he answers the opening complaint directly. The people who got useless tests one-shotted a prompt and skipped the workflow.

Prompt engineering still matters, but it does not scale, because a software project carries far more context than you can paste in every time you want a change.

Context engineering puts that information where the agent can reach it: tech stack, architecture including diagrams it can read, coding standards, favoured design patterns, quality and testing standards, and the domain knowledge that app exploration will never recover on its own.

His own example is supply chain and warehouse systems, where an agent poking at the UI gets only so far without being told how the underlying enterprise system works. Product behaviour from your ticketing system belongs there too, since user stories and acceptance criteria are already the shape test cases derive from.

Spec-Driven Development

The step above context engineering turns that pile of information into a directed process, with the specification as the core artifact rather than a document nobody reads.

His argument for why this works starts from what people actually buy. Nobody cares which language you wrote it in or what your coverage number was. They care that they can log in, check a balance and make a transfer.

Those behaviours are human-centred, so they get described in plain language, and plain language is now something tooling can act on. Write the behaviour into a markdown specification and the agent can implement against it.

The consequence he draws is the one that reframes the job: product code and test code both come out of the same source as outcomes rather than as separate efforts. He has been making the BDD version of this argument for years, and his read is that AI is what finally made it practical without a human policing the process.

Turning Practices Into Rules

Anything you would otherwise have to remember can become a rule, and this section is the most directly copyable part of the workshop.

• Work step by step - small bite-sized features rather than big-bang prompts. It feels slower and it keeps care and quality in the loop as you go.
• Write three-part user stories - as somebody, I want something, so that I get an outcome. It fixes the persona, the behaviour and the reason in one line.
• Keep acceptance criteria in Gherkin - given, when, then forces arrange, act, assert, which keeps every check verifiable, independent and atomic.
• Demand test IDs - a rule that every testable element gets a data-testid attribute means you never again test a page with an atrocious DOM, because the agent inserts them as it builds.
• Require page objects and fixtures - left alone, generation produces raw calls inline. A rule pointing at Playwright’s own page object documentation, plus fixtures for clean teardown, means you never make a second pass.
• Generate tests with product code - the rule he calls the kingpin. If development and testing come from the same spec, the tests should never be a separate prompt.

He extends the point to everything teams defer under pressure. On a startup runway, test automation, accessibility and security are the concerns that get pushed to later and never arrive. Written as rules, they carry through every generation almost for free.

Three-Way Programming

Pair programming becomes three-way: a developer, a tester and AI building together.

It looks like two people on one task, but nothing waits on a pull request thrown over a wall. Corrections happen in the moment and everyone learns in the same session.

His related claim is that both writing specs and reviewing output are open to everyone on the team, which is what turns quality into a shared activity rather than a blame allocation after the fact.

He also makes a prediction about the role. With automated tests baked into developer workflows, testers move towards exploratory work and product insight, and over time the title splits towards either developer or product depending on which half of the job someone prefers.

CI Is a Production System

He repeats this line deliberately, because most teams treat CI as somewhere tests get parked after they work locally.

CI is where results become visible and where the people who consume them are, so it earns the standards you would give any production system: reliable pipelines, reliable tests, parallelism, known dependencies.

Practically that means caching node modules and Playwright browsers and using pre-built images, because feedback on a pull request has to arrive in minutes. A test pipeline measured in hours stops being a safety net and becomes a bottleneck.

Locally the same discipline applies: run tests continually as features are built, and let agents work out which tests a code change actually touches before running everything.

The Five-Step Playbook

For scaling a suite he gives five steps in order, and the order is the advice.

• Run in parallel - the highest-impact change available, which requires tests independent enough not to collide. Playwright parallelises across workers by default.
• Implement proper waiting - hard sleeps destroy runtime and flakiness destroys trust in the result. Playwright builds waiting into the calls rather than leaving it to you.
• Use performant infrastructure - powerful enough CI machines, scaled-up hardware and scaled-out execution grids.
• Write atomic tests - each one independent, focused on a single behaviour, short and to the point.
• Arrange efficiently - he has seen tests spend ten minutes building data they never use. Inject data through APIs rather than traversing the UI to create it.

The Live Build

The demo runs against Buggy Board, his own open-source app, opened in Cursor on a fresh branch. Playwright goes in from scratch, gets configured to Chromium only, and then the CLI and skills are installed.

Planning is where the interesting part happens. Asked for test plans, the agent reads the specs folder and also explores the running app headlessly, logging in and clicking around, which takes roughly five minutes.

What came back was a plan per feature plus a readme, thirteen plans in total, on the order of a hundred tests if all were generated.

His comment on reading them is the most useful thing in the demo. Humans plan the happy path; the generated plans were full of the negative cases people skip, like whitespace trimming and what an error message reveals for security reasons.

He is equally clear that it over-produces. Some suggestions are not worth automating, the favicon plan among them, and he treats the output as something to think against rather than accept.

Taking his own step-by-step advice, he generated from one plan rather than all thirteen. The result was 13 login tests, all passing, arranged with page objects and fixtures without being asked, because the rules were already in the project.

For scale, his comparison is his own past. As an SDET before AI, three to five genuinely bulletproof tests was a good day. This took five to ten minutes.

Q & A Session

He took questions throughout rather than saving them, and answered several more as the workshop closed.

• Is the generated test checking business behaviour or just clicking the UI?

  Andrew Knight: That is exactly what context engineering and spec-driven development are for. If your specs define the business value and desired behaviour, and generation accounts for them, you have grounds to believe the tests check something meaningful. Without that, you are trusting a click trace. He adds elsewhere that human review is not optional here, and that the way to treat the AI is as an ambitious intern who wants to impress you.

• Where does AI genuinely improve Playwright beyond generating boilerplate?

  Andrew Knight: Exploration. Because Playwright actually opens the app and moves through it, the agent captures real locators from the running page rather than guessing and retrying. It could read them from the source, but you do not always have the project code, and a locator captured from a live page is right the first time. Skills add the guidance layer on top, and both can be extended with your own.

• How do you make AI-generated tests deterministic enough for enterprise CI/CD?

  Andrew Knight: Generation will never be deterministic in the sense of producing identical code each time, and he pushes back on wanting that. Put a team of testers on the same Playwright project and they will not write identical code on Monday, Tuesday and Wednesday either. What matters is whether the right things are being done, not whether the same things are produced, and with skills, context and a followed process he considers it enterprise ready.

• What are the biggest challenges with Playwright in a large production project?

  Andrew Knight: Less about Playwright than about practice. Generated code without page objects and fixtures becomes unmaintainable as the project grows, so the answer is to follow the process, use the established patterns and the skills, run the plan-generate-heal workflow, and move up to spec-driven development as the suite gets bigger.

• We use WebdriverIO. Is migrating to Playwright with AI a good idea?

  Andrew Knight: Yes, translation between tools, frameworks and languages is one of the things AI does well, and it will beat doing it by hand even if the result is imperfect. His caution is to be clear why you are migrating. If the tests themselves are bad, porting bad tests to a new tool gets you bad tests in a new tool. Moving to Playwright is not a magic wand, so make sure you are solving the problem you actually have.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.