Why AI‑Generated Frontends Need More Than Screenshots: A Playwright Acceptance Checklist

AI‑generated front‑end code can look correct in a static screenshot but may miss essential product state‑machine behavior such as login status, permission errors, network failures, saving states, validation messages, mobile keyboard handling, long‑text overflow, and dark‑mode contrast. A screenshot is only a first impression; before delivery the key user flows must be exercised in a real browser.

When a screenshot is not enough

Static landing page / hero section – partially sufficient; combine screenshot with mobile breakpoint check. Verify main copy, CTA, image ratios and that nothing overlaps on mobile.

Forms, login, checkout, settings pages – not sufficient; run Playwright MCP for real interaction. Verify input, validation, submit and reproducible error messages.

Backend list, filter, bulk actions – not sufficient; use Playwright Test for regression. Verify sorting, filtering, pagination, empty state and permission‑based UI.

AI‑reconstructed UI from a screenshot – not sufficient; combine screenshot comparison with browser interaction to ensure consistency across sizes and that key buttons are truly clickable.

PR modifies existing interaction – not sufficient; let AI generate acceptance paths then manually review. Require trace, screenshot or test report as evidence.

Tool / method suitability

Screenshot review – best for first‑screen visual hierarchy and copy prominence; not suitable for verifying clickability, API success or error states. Produces screenshots and design notes.

Playwright MCP – best for exploratory real‑browser actions (click, fill, observe state); not suitable for long‑term stable regression or high‑privilege login without supervision. Produces operation logs, screenshots, trace/video and issue description.

Playwright Test / CLI – best for persisting critical paths as repeatable tests for CI or PR gating; not suitable for one‑off exploration of unknown interactions. Produces test files, HTML report and trace.

Manual review – best for assessing business boundaries, risk, visual quality and merge decision; not suitable for mechanical repetitive clicking of every page. Produces merge comments and fix requests.

Scenario 1: Multi‑screen UI verification

When AI recreates a page from a screenshot, checking only the desktop view can miss mobile overflow and buttons that only look clickable. Require three pieces of evidence from the AI:

Desktop (1440 px), tablet (1024 px) and mobile (390 px) breakpoint screenshots.

At least one click or fill on each primary button, input, menu and modal.

If the page originates from a design mock, note which parts are faithfully reproduced and which are adapted to the component library.

Example prompt (preserved in pre block):

请用 Playwright 打开本地页面，分别检查 1440、1024、390 宽度。
不要只截图。请点击主 CTA、打开菜单、填写一个输入框、触发一次错误状态。
最后给我：3 张截图、发现的问题列表、你实际操作过的控件清单。

Scenario 2: Forms and settings – verify failure paths

Form pages are often delivered as a “successful‑path demo”. Real users encounter many failure states. The article lists six questions to ask during front‑end acceptance:

Can empty fields be submitted?

Is error feedback shown next to the field or only in the console?

Does the save button allow repeated clicks while saving?

Does the button recover after an API failure?

Is there clear success feedback after submission?

Does the state persist after a page refresh?

Playwright MCP can temporarily mock network requests; Playwright Test can turn those interactions into stable test cases. The key is to give the AI a clear acceptance goal: treat success and failure paths equally.

Scenario 3: Backend lists and filters – verify data states

AI can align cards, tables and filters visually but may ignore data‑state handling. Checklist for list pages:

Data present – verify column widths, sorting, amount/date format, action button enablement.

No data – verify empty‑state copy guides the user.

Loading – verify skeleton or loading indicator does not break layout.

Search no results – verify a clear way to clear filters.

Pagination / infinite scroll – verify page navigation, back navigation and state after refresh.

Permission insufficient – verify UI elements are hidden, disabled or show appropriate prompts.

Scenario 4: Login and high‑privilege pages – narrow permissions

Running browser‑based acceptance can unintentionally operate already‑logged‑in sessions. OpenAI’s computer‑use safety guidance advises narrowing the task scope for any operation that touches accounts, credentials, payments or private data. The three rules for Playwright acceptance are:

Use test accounts, not production accounts.

Restrict domain, environment and task; prevent the agent from freely browsing the backend.

For destructive actions (delete, payment, bulk ops), stop at the confirmation page and do not auto‑confirm.

Scenario 5: From one‑off acceptance to long‑term regression

Do not try to automate the entire site at once. Start with three high‑impact paths (login, settings, payment/submit). Write a human‑readable acceptance plan for each, run Playwright MCP for exploratory evidence, then solidify the most stable path into a Playwright Test. Store the plan in specs/, the generated test in tests/, and configure execution in playwright.config.ts. Sample folder layout:

specs/
  checkout-flow.md        # Human‑readable acceptance plan
tests/
  checkout-flow.spec.ts   # AI‑generated test after manual review
playwright.config.ts      # Browser, trace, screenshot, retry strategy

After the three stable paths are in place, let the AI fix locators or add edge‑case tests based on failure records.

7‑day trial plan

Day 1: Pick the three most critical pages (login, settings, payment/submit).

Day 2: Write a readable acceptance plan covering success, failure, mobile and data boundaries.

Day 3: Run Playwright MCP for exploratory acceptance, collect problems and evidence.

Day 4: Convert the most stable path into a Playwright Test, reusing existing test style.

Day 5: Hook the test into a local pre‑PR command (no CI yet).

Day 6: Intentionally break a button, a validation rule, and a mobile layout to confirm the test or manual review catches them.

Day 7: Retrospect which checks are worth keeping, which are too slow or brittle, and keep only the reliable ones.

12‑item AI front‑end acceptance checklist

Page purpose – AI can explain what user task the page fulfills.

First‑screen information – Main info not occluded at 1500 px, 1024 px, 390 px.

Key buttons – Primary CTA, back, cancel, save, delete are truly clickable.

Input validation – Empty, illegal and overly long values show visible feedback.

Success path – Submission shows clear success state and persists after refresh.

Failure path – Network failure, permission denial, API error have recovery mechanisms.

Loading / empty state – Loading, empty list, no‑result all provide next‑step hints.

Mobile – No horizontal overflow, bottom actions not hidden, no hover‑only interactions.

Accessibility – Major controls have identifiable names; keyboard Tab order works.

Data boundaries – Amounts, dates, long Chinese/English, zero or abnormal values do not break layout.

Permission boundaries – Test account, test environment, high‑risk actions require confirmation.

Acceptance evidence – At least one of: screenshot, trace, video, HTML report, or test output is retained.

Copy‑paste acceptance prompt

完成前端改动后，请不要只汇报实现了什么。

请用 Playwright 或浏览器工具完成以下验收：
1. 打开改动页面，检查桌面 1440px、平板 1024px、手机 390px。
2. 操作主路径：点击主按钮、填写关键表单、提交一次成功路径。
3. 操作失败路径：空字段、非法字段、接口失败或权限不足，至少覆盖一个。
4. 检查 loading、空状态、长文本和移动端溢出。
5. 输出验收证据：截图路径、trace/report 路径、测试命令和结果。
6. 明确列出未验证项，不要把未跑过的路径写成通过。

Final recommendation

Playwright should be used to add verifiable evidence, not to reduce visibility. Visual design, information hierarchy and business boundaries still require human judgment, but the habit of accepting a page based on a single screenshot must be stopped, especially for forms, admin panels, permission‑restricted pages and payment flows.

Suggested division of labor:

AI: implements UI, enumerates acceptance paths, drives the browser, generates initial tests.

Playwright: records clicks, inputs, breakpoints, network traffic, trace and reports as evidence.

Human: decides business risk, visual quality and whether the changes can be merged.

References

Playwright MCP Introduction [1] – https://playwright.dev/mcp/introduction

Microsoft playwright-mcp README [2] – https://github.com/microsoft/playwright-mcp/blob/main/README.md

Playwright MCP v0.0.76 release [3] – https://github.com/microsoft/playwright-mcp/releases/tag/v0.0.76

Playwright Test Agents docs [4] – https://playwright.dev/docs/test-agents

Playwright Intro docs [5] – https://playwright.dev/docs/intro

GitHub Copilot E2E test cookbook [6] – https://docs.github.com/en/copilot/tutorials/copilot-cookbook/testing-code/create-end-to-end-tests

OpenAI Codex frontend designs [7] – https://developers.openai.com/codex/use-cases/frontend-designs

OpenAI Codex computer use safety [8] – https://developers.openai.com/codex/app/computer-use#safety-guidance