AI coding agents in 2026 can write UI and API tests very fast, with minimal direction. But there are 3 problems. Let's look at what they are and how to fix or avoid them. ──────────────────────────────────────── 🔴 𝟏. 𝐓𝐞𝐬𝐭 𝐝𝐞𝐬𝐢𝐠𝐧 𝐝𝐨𝐞𝐬𝐧'𝐭 𝐦𝐚𝐭𝐜𝐡 𝐭𝐡𝐞 𝐟𝐫𝐚𝐦𝐞𝐰𝐨𝐫𝐤 Before writing a single line of code, an agent scans your framework for a pattern to "learn" how to write the tests. If the framework itself is inconsistent (a few ways to structure a page object, different assertion styles, mixed naming conventions), the agent won't see one "right way" to write code. It will end up doing one of two things: - Picks whichever example it happened to see most recently and copies that - Decides there is no standard and invents its own The long-term fix: Make the framework itself consistent. This isn't really an AI problem. It's a framework hygiene problem that AI just makes visible faster than a human reviewer would. - One way to structure a test. - One way to name things. - One place patterns live. The short-term fix (while the framework catches up): Write the design you actually want into `AGENTS.md`, or a standalone design doc. Feed it to the agent at the start of the task. Then use that same doc again after the task is done, as a second pass, to verify the output actually matches the design. ──────────────────────────────────────── 🔴 𝟐. 𝐓𝐞𝐬𝐭𝐬 𝐝𝐨𝐧'𝐭 𝐮𝐬𝐞 𝐝𝐞𝐭𝐞𝐫𝐦𝐢𝐧𝐢𝐬𝐭𝐢𝐜 𝐥𝐨𝐜𝐚𝐭𝐨𝐫𝐬 A strange but common AI agent habit: instead of picking one reliable locator, the agent picks a few and writes code that loops through them to see which one exists or loads on the page. - `locator1 or locator2 or locator3`, "just in case" - Fallback chains that quietly hide which locator the test actually relies on This makes a test non-deterministic before it has even run once. You don't know what it's actually checking against. Fix: State the rule explicitly. Only 1 locator per element. No fallback chains. If the agent can't find a stable locator, that's a signal to fix the app's markup or test IDs.

You cannot be in two places at once. But your AI agent can. Learn how to use AI agents with Playwright CLI to do exploratory testing, while you are working in parallel on something more fun. ──────────────────────────────────────── 🧠 𝐖𝐡𝐚𝐭 𝐝𝐨𝐞𝐬 𝐡𝐮𝐦𝐚𝐧 𝐞𝐱𝐩𝐥𝐨𝐫𝐚𝐭𝐨𝐫𝐲 𝐭𝐞𝐬𝐭𝐢𝐧𝐠 𝐥𝐨𝐨𝐤 𝐥𝐢𝐤𝐞? A tester: ∙ Thinks about what to try next ∙ Clicks, observes, and takes notes ∙ Stops when something blocks them ∙ Hands findings to the team Playwright CLI + AI coding agent can do the same. Completely autonomously. And you can set it up and configure it in 30 minutes, then send it to work for hours. ⚙️ 𝐇𝐞𝐫𝐞 𝐢𝐬 𝐭𝐡𝐞 𝐬𝐞𝐭𝐮𝐩: You need to create only 1 file `𝐬𝐭𝐞𝐩𝐬.𝐦𝐝` that defines the mission and the rules for the agent: - How to use Playwright CLI - Start URL (and environment) - Scope. What area or flow to explore: - What area of the application should be covered and what should ignored. - Credentials or test data (or where to find them) - Rules. What to look for and what to ignore - Where to write the report with all findings: `𝐫𝐞𝐩𝐨𝐫𝐭.𝐦𝐝` 📌 𝐑𝐮𝐥𝐞𝐬 𝐒𝐞𝐜𝐭𝐢𝐨𝐧 𝐁𝐫𝐞𝐚𝐤𝐝𝐨𝐰𝐧 in `𝐬𝐭𝐞𝐩𝐬.𝐦𝐝` ──────────────────────── What to look for (report these): ⤷ Functional bugs. Button does nothing, wrong redirect, form does not submit ⤷ Broken UI. Missing elements, layout breaks, overlapping content ⤷ Wrong or missing copy on critical paths (checkout, login, errors) ⤷ JavaScript errors that break user actions ⤷ Failed network requests on critical APIs (auth, payment, save) ⤷ Accessibility blockers. ⤷ Dead ends. 404, infinite spinner, error with no recovery What to ignore: ⤷ Third-party analytics / tracking failures (Google Analytics, etc.) ⤷ Benign console warnings (deprecated API in a vendor script) ⤷ Cosmetic-only issues (misalignments, font weight on footer) ⤷ Cookie banner / GDPR UI unless it blocks the flow under test ──────────────────────── After you are done with the `𝐬𝐭𝐞𝐩𝐬.𝐦𝐝`, just point the AI agent to the file and let it loose. The agent will read the file and create an empty `𝐫𝐞𝐩𝐨𝐫𝐭.𝐦𝐝` to fill as it goes.

Here is the full workflow that turns Playwright CLI + an AI coding agent into a system that can write UI tests for you. It works with Cursor, Claude Code, Codex, or any agent you have. ──────────────────────────────────────── 🟢 𝐓𝐡𝐞 𝐔𝐧𝐢𝐯𝐞𝐫𝐬𝐚𝐥 𝐖𝐨𝐫𝐤𝐟𝐥𝐨𝐰 ➤ Step 1. Explore the test case with Playwright CLI You give the agent a real test case with the steps and validations: ∙ What user flow to cover ∙ What URL to start from ∙ What success looks like ∙ What data or credentials to use (or where to find them in the repo) The agent uses Playwright CLI to walk through that flow in the browser: ∙ `open` the starting page ∙ `snapshot` to read what is on screen ∙ `click`, `fill`, and navigate step by step ∙ `snapshot` again after each meaningful action The Agent is exploring the app the same way a human tester would, but faster, and with structured output, a.k.a it generates a file with it's findings. ➤ Step 2. You review. When exploration finishes, the Agent should produce a short exploration document. Something you can read and review. It should include: ∙ Pages visited and the order of steps ∙ Locators or element refs that worked ∙ Form fields, buttons, and links involved ∙ Assertions the Agent observed (visible text, URL changes, success messages) ∙ Anything ambiguous or blocked (login wall, captcha, missing test data) 𝐘𝐨𝐮 𝐫𝐞𝐯𝐢𝐞𝐰 𝐭𝐡𝐢𝐬 𝐛𝐞𝐟𝐨𝐫𝐞 𝐚𝐧𝐲 𝐭𝐞𝐬𝐭 𝐜𝐨𝐝𝐞 𝐢𝐬 𝐰𝐫𝐢𝐭𝐭𝐞𝐧. ➤ Step 3. The Agent generates UI tests Now the agent writes code. It uses two inputs: 1. The exploration document from Step 2 2. Your existing test framework. Folder structure, page objects, fixtures, naming conventions, helper methods Playwright CLI does not replace your framework. It feeds facts into it. Same workflow whether you use Playwright Test, Selenium, Cypress, or something else. The exploration layer is shared. The test code layer is yours. ➤ Step 4. The Agent runs the tests. The agent runs the new test (or the relevant suite). If it passes —> done. If it fails —> the agent goes back to Playwright CLI:

──────────────────────────────────────── 🟢 𝐖𝐡𝐚𝐭 𝐑𝐮𝐧𝐬 𝐖𝐡𝐞𝐧 𝐘𝐨𝐮 𝐨𝐫 𝐚𝐧 𝐀𝐈 𝐀𝐠𝐞𝐧𝐭 𝐓𝐲𝐩𝐞 𝐚 𝐂𝐨𝐦𝐦𝐚𝐧𝐝 1. You or your AI agent type a command in the terminal. 2. Playwright CLI reads it and opens the browser. It can run in headed mode (you see the window) or headless (no UI). 3. After the browser opens and the page loads, Playwright CLI takes a snapshot of the page. The snapshot is a small `.md` file with page details, including locators. 4. You or the AI agent read the snapshot and decide what to do next. If it shows a Login button, you see its accessibility ID (often something like `e10` or `e12`). Then you run a command such as `playwright-cli click e10` to click it. That is the workflow in a nutshell: Step 1 — load the web page Step 2 — get a snapshot of it Step 3 — act on the snapshot information Playwright CLI does not replace Playwright, Selenium, or Cypress. It is a different tool that sits on top of them. ──────────────────────────────────────── 👁 𝐇𝐞𝐚𝐝𝐞𝐝 𝐯𝐬 𝐇𝐞𝐚𝐝𝐥𝐞𝐬𝐬 Playwright CLI can open browsers in two modes: headed and headless. Headed mode shows the browser on your screen. Use it when you set up the tool or when you need to see what happened. Headless mode runs without a window. It is faster for repeat runs, but harder to watch. Some failures only show up in one mode. If a command fails in headless, try headed once before you change the test. ──────────────────────────────────────── 📌 Want hands-on practice with the AI workflows for test automation? Join the AI AutoTest Live Workshop — live theory, practice, and real agent workflows for test automation. 👉 Click here to read more: https://www.skool.com/qa-automation-career-hub/welcome-to-qa-automation-roadmap-lab-start-here

In the last post I explained why Playwright CLI is a better fit than Playwright MCP for AI coding agents. So before we talk about workflows, debugging, or best practices, let's make the tool clear. - What is it? - How do you install it? - And how do you run one simple command against a real website? ──────────────────────────────────────── 🟢 𝐖𝐡𝐚𝐭 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭 𝐂𝐋𝐈 𝐀𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐈𝐬 Playwright CLI is a command-line tool for controlling a browser. You run commands in the terminal, and Playwright CLI can: ➜ Open a website ➜ Click buttons ➜ Fill inputs ➜ Press keys ➜ Take screenshots ➜ Read a page snapshot It was designed for AI coding agents. But it is not only for AI. You can use it yourself from the terminal to check that the browser opens, the page loads, and the command returns useful page information. ──────────────────────────────────────── 🧠 𝐇𝐨𝐰 𝐈𝐭 𝐅𝐢𝐭𝐬 𝐖𝐢𝐭𝐡 𝐀𝐈 𝐂𝐨𝐝𝐢𝐧𝐠 𝐀𝐠𝐞𝐧𝐭𝐬 The workflow is simple: 1. You ask the AI agent to inspect a page or debug a UI flow. 2. The agent runs Playwright CLI commands in the terminal. 3. Playwright CLI controls the browser. 4. The agent reads the result and decides what to do next. This does not replace Selenium, Cypress, or Playwright Test. It acts as a new layer on top of the testing frameworks. ──────────────────────────────────────── 🍎 𝐈𝐧𝐬𝐭𝐚𝐥𝐥 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭 𝐂𝐋𝐈 𝐎𝐧 𝐌𝐚𝐜 You need `Node.js` and `npm ` first. If you already have them, check in Terminal: ──────────────── > node -v ──────────────── > npm -v ──────────────── If those commands do not work, install Node.js LTS first: ──────────────── > brew install node ──────────────── Once `node` and `npm` work, install Playwright CLI: ──────────────── > npm install -g @playwright/cli@latest ──────────────── Then verify it: ──────────────── > playwright-cli --version ──────────────── You can also print the available commands: ──────────────── > playwright-cli --help ──────────────── Now go to the project where you want to use it: ──────────────── > cd your-project-folder