──────────────────────────────────────── 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.

──────────────────────────────────────── Open Cursor, Copilot, or whatever AI tool fits the workflow. Type: "add pagination to the users endpoint." The agent responds. It looks like real code. Imports are there. Structure looks familiar. But on closer look: • Hardcoded values that should come from config • Wrong file location • No reuse of existing helpers • Naming conventions ignored • And when it runs... it fails ──────────────────────────────────────── 🧠 Why the Agent Guesses Wrong Think of the agent like a new hire. Smart. Fast. Capable. But they have never opened this repo before. ➤ They do not know how files are named ➤ They do not know which patterns the team already uses ➤ They do not know what “done” means in this project The instruction was simply: "add pagination to the users endpoint." So the agent searches and infers. Every assumption is a guess. Every guess is a chance to be wrong. This is an onboarding problem. And onboarding needs clear documentation. ──────────────────────────────────────── 📝 What a Real Task Spec Looks Like In the AI coding agents world, that documentation is often called a task spec. A task spec is not just a longer prompt. It is a precise set of constraints that leaves very little room to guess. Weak prompt: ``` add pagination to the users endpoint ``` Good task spec: ``` Add cursor-based pagination to the users list endpoint. Before making any changes, inspect existing list endpoints in /src/api/routes/ and follow the same handler structure, naming, and error handling patterns. Task: - Add pagination query params (limit, cursor) to GET /users - Reuse existing pagination helpers if present; do not duplicate logic - Place changes in the appropriate existing route file - Do not hardcode limits or bypass existing auth middleware - Do not create new files unless no existing file fits - Do not modify unrelated routes - Do not guess. Work only from concrete code in the repository. If expected behavior is unclear from existing handlers or tests, stop and report the ambiguity

In Part 2 I covered CLI tools. They work well. But when it comes to reviewing code quality, IDE agents are generally the better fit. ──────────────────────────────────────── ► CLI agents give you output on a screen. A wall of text. ► IDE agents show changes line by line, directly inside your actual files. In agentic IDEs, you can accept or reject each change individually. One chunk at a time. When something goes wrong, you see exactly what changed and where. You can ask the AI to explain the change while looking at the real code. This makes it much easier to stay in control and actually understand what the agent is doing. ──────────────────────────────────────── 🔹 How Agentic IDEs Work You use them like any other IDE, but they also have a special chat window where you can give the AI tasks. There are quite a few agentic IDEs available. Most of them are forks of VS Code. Some of the common ones: • Cursor • Kiro • Windsurf • VS Code with Copilot Right now, Cursor is the strongest option. It has two exclusive models (Composer 2.5 and Cursor Grok 4.5) that deliver strong coding performance at a fraction of the cost of larger models like Opus or the top GPT models. Cursor also has a smooth interface, relatively few bugs (looking at you, Copilot), and many small quality-of-life features that add up and make daily work noticeably easier. ──────────────────────────────────────── ⚡ Why Third-Party Coding Agents Are Better Most people default to Claude Code or ChatGPT with Codex. That comes with a big downside: these are proprietary tools that only give you access to a limited set of models. • Claude Code → Anthropic models only • ChatGPT with Codex → OpenAI models only (Note: There are plugins that can bypass this, but they usually require extra setup and ongoing management.) When you use a third-party AI coding agent like Cursor, you get access to models from both Anthropic and OpenAI in one place, plus open-source models and Cursor’s own exclusive models.