──────────────────────────────────────── If you are building a SaaS product or any reasonably large web application, automated tests are essential. They protect the paths you have already defined and catch regressions on known flows. The limitation is everything else. Complex products always contain edge cases, unusual sequences, and broken states that no one planned for. Exploratory testing exists to surface those unknowns. Traditionally this work had to stay with a person. The value came from human curiosity and the ability to notice something unexpected. That approach is slow and expensive. Playwright CLI combined with an AI coding agent changes the economics. You can now run structured exploration for hours while you continue working on other tasks. ──────────────────────────────────────── ▶ What the Agent Does The agent follows a mission you define: • Opens the application • Moves through the areas you specify • Observes the current state of the page • Records what it finds • Stops only when it hits a hard blocker You review the findings afterward and decide what deserves attention. ──────────────────────────────────────── ▶ Setup: One Rules File Create a file called `steps.md`. This becomes the mission brief. It should contain: • How to use Playwright CLI • Start URL and environment • Scope: which areas or flows to explore and which to skip • Credentials or test data (or where to find them) • Rules for what to report and what to ignore • Output location for findings (`report.md`) Example rules: What to report: • Functional problems (buttons that do nothing, wrong redirects, forms that fail to submit) • Broken UI that blocks use • Incorrect or missing copy on critical paths • JavaScript errors that prevent actions • Failed network requests on important APIs • Accessibility blockers • Dead ends (404s, infinite spinners, errors with no recovery) What to ignore: • Third-party analytics or tracking failures

──────────────────────────────────────── AI coding agents can use Playwright CLI to control a real browser. This opens up useful workflows beyond simple code generation. Two practical cases stand out: exploring UI flows for ui test generation, and extracting content from sites that block basic bots and AI crawlers. ──────────────────────────────────────── ► Why a Real Browser Might be Needed 1. Some websites actively detect and block automated access. Simple HTTP requests or headless scrapers get stopped. 2. UI testing An agent that drives a real browser through Playwright CLI can interact with the page more like a person would. It can open pages, click, fill forms, wait for content, and read what actually appears on screen. This makes it useful for both testing work and for scraping or data collection on protected sites. ──────────────────────────────────────── ► A Practical Workflow ↳ Step 1. Explore with Playwright CLI Give the agent a clear task. Include: • Starting URL • What the agent should do on the page • What information or outcome matters • Any credentials or data it should use The agent then uses Playwright CLI to walk through the flow: • Open the page • Take snapshots of the current state • Click, fill, and navigate as needed • Capture relevant details along the way The agent records what it finds in a structured document. ↳ Step 2. Review the exploration document • Pages visited and the sequence of actions • Elements and locators that worked • Important text, fields, or state changes • Anything that blocked progress (login walls, captchas, missing data, anti-bot measures) ↳ Step 3. Do something with that extracted knowledge - Extract the scrapped data - Generate UI tests or workflows

🟢 𝐖𝐡𝐚𝐭 𝐏𝐥𝐚𝐲𝐰𝐫𝐢𝐠𝐡𝐭 𝐂𝐋𝐈 𝐀𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐈𝐬 Playwright CLI is a command-line tool for controlling a browser that is mostly used to generate UI tests, scrap data or build workflows. 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. ──────────────────────────────────────── 🟢 𝐖𝐡𝐚𝐭 𝐑𝐮𝐧𝐬 𝐖𝐡𝐞𝐧 𝐘𝐨𝐮 𝐨𝐫 𝐚𝐧 𝐀𝐈 𝐀𝐠𝐞𝐧𝐭 𝐓𝐲𝐩𝐞 𝐚 𝐂𝐨𝐦𝐦𝐚𝐧𝐝 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.

──────────────────────────────────────── For a long time, browser automation tools were designed for humans to write UI Automated Tests, Scrapping and sometimes some other automation workflows. An engineer would write the code, read the errors, decide the next step, and repeat. But now, AI coding agents can now handle many of those steps directly. Engineers shift toward directing the agent, reviewing results, and setting constraints. ──────────────────────────────────────── ▶ Playwright MCP Playwright MCP was one of the earlier tools that let AI agents interact with a browser. It allowed an agent to open pages, click elements, take snapshots, and perform basic browser tasks. Common uses included: • Inspecting page structure • Gathering element information • Debugging UI behavior • Reading console and network activity The flow was straightforward. The engineer gave the agent a task, and the agent used Playwright MCP to control the browser. ──────────────────────────────────────── ▶ Context Cost of Playwright MCP (old way) Playwright MCP works by loading a full page snapshot (HTML and related data) into the agent’s context after interactions. It also includes tool metadata. This can consume a noticeable portion of the available context window in a single use. As context fills up, agents become more likely to lose track of earlier instructions or make mistakes. The agent’s context functions as working memory. It holds the conversation, instructions, code, and any data the agent needs to stay coherent. Filling it with large page snapshots reduces room for everything else. ──────────────────────────────────────── ▶ Playwright CLI (new way) Playwright CLI takes a lighter approach. It gives the agent a command-line interface it can call like any other terminal tool. The agent runs small commands and receives focused results. Full page data is loaded only when the agent explicitly requests it. This keeps context usage lower. The agent decides what information it needs instead of receiving large snapshots by default.