Introduction

When I use AI coding tools like Claude, Codex, Cursor, or similar agents, one of the most frustrating problems is this:

The AI can read the code, but it often fails to understand what is actually happening in the browser.

This becomes painful during frontend work. The AI says “fixed,” but the UI is still broken. It says “tested,” but it never opened the page. It changes CSS blindly. It misses console errors. It ignores failed API requests. It fixes desktop layout but breaks mobile. Sometimes it just guesses.

This is not only an AI problem. It is a workflow problem.

The correct solution is not to keep saying:

“Claude, please check the browser.”

or:

“Codex, analyze this screenshot.”

The better solution is:

Give the AI browser evidence.

That means screenshots, console logs, network failures, viewport data, accessibility reports, Lighthouse reports, waterfall data, and bug recordings.

This tutorial explains the complete workflow I recommend for vibe coding, browser debugging, screenshot work, frontend verification, and AI-assisted development.

1. The Real Problem

The main problem is simple:

Claude/Codex can read files, but may not actually see the rendered browser.

When working on a web application, the source code is only half the truth. The browser shows the real truth.

A frontend bug may come from:

CSS cascade
Responsive breakpoint
JavaScript runtime error
Failed API call
Missing environment variable
Wrong route
Broken image path
Authentication failure
Hydration issue
Layout shift
Slow-loading resource
Blocked script
Wrong z-index
Modal overlay issue
Mobile viewport problem

The AI may inspect the source code and assume everything is fine. But the browser may show a completely different story.

That is why AI coding agents often fail in UI work.

2. Problems We Identified

Problem 1: AI cannot reliably access your browser

Your browser may be open on your laptop, but Claude/Codex may be running in:

A cloud workspace
A sandbox
A container
A remote coding environment
A browser session without your login

So even if you say:

Check localhost:3000
Code language: CSS (css)

the agent may not actually be able to access it.

This is very common with local apps.

Problem 2: Localhost is not always visible to the AI

Your app may run at:

http://localhost:3000
http://127.0.0.1:3000
http://localhost:5173
http://localhost:4321
Code language: JavaScript (javascript)

But if the AI agent is not running in the same machine or container, it cannot open that URL.

This is why the agent may say:

I cannot access the page.

or worse:

I checked it.

when it actually did not.

Problem 3: Screenshots alone are useful but incomplete

A screenshot helps the AI see visual issues, but it does not show the full technical context.

A screenshot cannot show:

Console errors
Network failures
API response status
DOM state
CSS computed styles
Missing JavaScript bundles
CORS errors
Authentication redirects
Slow-loading resources
User action sequence

So screenshots are good, but not enough.

Problem 4: AI agents sometimes pretend verification happened

This is one of the biggest issues.

An AI agent may say:

Done
Tested
Verified
Looks good

But it may have only inspected source files.

For frontend work, that is not enough.

A real verification should include at least:

Open the page in a browser
Check screenshot
Check console errors
Check failed network requests
Check desktop/tablet/mobile layout
Confirm the issue is fixed
Code language: JavaScript (javascript)

Without browser evidence, “done” is weak.

Problem 5: Public pages and private pages need different workflows

There are two categories of pages.

Public pages

Example:

A website page available on the internet
A landing page
A blog page
A product page
A hospital listing page
A marketing page

These can be tested using online tools like WebPageTest, PageSpeed Insights, GTmetrix, DebugBear, Lighthouse, and similar tools.

Private/local pages

Example:

localhost app
Admin dashboard
Logged-in user area
Keycloak-protected page
Internal staging app
Patient dashboard
Private CRM
Developer preview
Code language: PHP (php)

These cannot always be tested by public tools.

For private/local pages, you need browser automation or a browser extension.

3. The Core Idea: Browser Evidence, Not Browser Guessing

The best workflow is:

Do not ask AI to guess from code.
Give AI real browser evidence.
Code language: JavaScript (javascript)

Browser evidence includes:

Screenshot
Screen recording
Console logs
Network logs
Failed requests
Viewport size
Device/browser metadata
Lighthouse report
Accessibility report
Waterfall report
Filmstrip report
DOM/CSS inspection

Once the AI has this evidence, it can reason better.

Instead of saying:

Fix the UI.

you say:

Here is the screenshot.
Here are the console errors.
Here are failed API requests.
Here is the mobile viewport.
Here is the Lighthouse report.
Now find the exact frontend issue and fix it.
Code language: JavaScript (javascript)

This changes the quality of the result.

4. Best Overall Workflow

The full workflow depends on the type of page.

For local/private development

Use:

Python + Playwright + Chromium

This generates browser evidence from your local app.

For public websites

Use:

WebPageTest
PageSpeed Insights
GTmetrix
DebugBear
Lighthouse

These tools create public/shareable reports.

For quick one-click bug reports

Use:

Jam.dev Chrome extension
BrowserStack Bug Capture
Bird Eats Bug-style tools
Code language: CSS (css)

These capture screenshot/video plus console/network logs.

For accessibility

Use:

WAVE
axe DevTools
Lighthouse Accessibility

For visual regression

Use:

Percy
BrowserStack visual testing
Playwright screenshots

5. Recommended Stack for Vibe Coding

My recommended practical stack is:

1. Python Playwright + Chromium
   For local/private automated browser checks.

2. Jam.dev extension
   For one-click bug reports with screenshot/video + console/network logs.

3. WebPageTest
   For public page loading, waterfall, screenshot, and filmstrip reports.

4. PageSpeed Insights / Lighthouse
   For performance, SEO, accessibility, and best-practice audits.

5. WAVE or axe DevTools
   For accessibility testing.

6. CLAUDE.md / CODEX.md browser verification rules
   To stop the AI from pretending it tested the browser.
Code language: JavaScript (javascript)

This gives the best balance of:

Low cost
Practical evidence
Local development support
Public website support
Claude/Codex compatibility
Repeatable workflow
Less hallucination
Code language: PHP (php)

6. Solution 1: Python + Playwright + Chromium

This is the best free local solution.

Playwright can control Chromium, Firefox, and WebKit. For vibe coding, I recommend Chromium first because it is fast, stable, and close to Chrome behavior.

What this solves

It can check:

Page loads or not
Desktop screenshot
Tablet screenshot
Mobile screenshot
Console errors
JavaScript runtime errors
Failed API/network requests
Responsive layout
Basic visual evidence

Cost

Playwright: Free
Chromium through Playwright: Free
Python script: Free
AI usage: depends on your Claude/Codex/Cursor plan

Install

pip install playwright
playwright install chromium

Create a browser check script

Create this file:

tools/browser_check.py

Add this code:

from playwright.sync_api import sync_playwright
from pathlib import Path

URL = "http://127.0.0.1:3000"

VIEWPORTS = {
    "desktop": {"width": 1440, "height": 900},
    "tablet": {"width": 768, "height": 1024},
    "mobile": {"width": 390, "height": 844},
}

output_dir = Path("browser-report")
output_dir.mkdir(exist_ok=True)

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)

    for name, viewport in VIEWPORTS.items():
        print(f"Checking {name} viewport...")

        page = browser.new_page(
            viewport=viewport,
            is_mobile=(name == "mobile")
        )

        console_errors = []
        failed_requests = []

        page.on(
            "console",
            lambda msg: console_errors.append(msg.text)
            if msg.type == "error"
            else None
        )

        page.on(
            "pageerror",
            lambda error: console_errors.append(str(error))
        )

        page.on(
            "requestfailed",
            lambda request: failed_requests.append(request.url)
        )

        page.goto(URL, wait_until="networkidle")

        screenshot_path = output_dir / f"{name}.png"
        page.screenshot(path=str(screenshot_path), full_page=True)

        report_path = output_dir / f"{name}-report.txt"

        with open(report_path, "w", encoding="utf-8") as f:
            f.write(f"URL: {URL}\n")
            f.write(f"Viewport: {viewport}\n\n")

            f.write("Console Errors:\n")
            if console_errors:
                for error in console_errors:
                    f.write(f"- {error}\n")
            else:
                f.write("No console errors found.\n")

            f.write("\nFailed Requests:\n")
            if failed_requests:
                for request in failed_requests:
                    f.write(f"- {request}\n")
            else:
                f.write("No failed requests found.\n")

        page.close()

    browser.close()

print("Done. Check the browser-report folder.")
Code language: PHP (php)

Run it

python tools/browser_check.py

It will create:

browser-report/
  desktop.png
  desktop-report.txt
  tablet.png
  tablet-report.txt
  mobile.png
  mobile-report.txt

Now you have evidence.

7. How to Give This Report to Claude/Codex

After generating the report, tell Claude or Codex:

I ran browser verification using Python Playwright + Chromium.

Check the browser-report folder:
- desktop.png
- tablet.png
- mobile.png
- desktop-report.txt
- tablet-report.txt
- mobile-report.txt

Analyze the screenshots, console errors, failed network requests, and responsive layout.

Find the exact frontend/component/CSS/API issue.
Fix the code.
Then explain:
1. What was wrong
2. Which files were changed
3. How the fix was verified
4. Whether any browser issue still remains

Do not say done unless browser verification passes.
Code language: JavaScript (javascript)

This is much better than:

Please check my browser.

Because now the AI has actual proof.

8. Headless vs Visible Chromium

Playwright can run Chromium in two modes.

Headless mode

This runs silently in the background.

browser = p.chromium.launch(headless=True)
Code language: PHP (php)

Best for:

Automated testing
CI pipeline
Fast screenshot generation
Routine checks

Visible mode

This opens the browser window.

browser = p.chromium.launch(headless=False)
Code language: PHP (php)

Best for:

Watching the browser
Debugging interactions
Seeing dropdowns/modals
Manual verification

You can slow down browser actions like this:

browser = p.chromium.launch(headless=False, slow_mo=500)
Code language: PHP (php)

This is useful when you want to watch what is happening.

9. Solution 2: Browser Extensions for One-Click Bug Reports

For quick bug reporting, browser extensions may be easier than scripts.

The ideal extension workflow is:

Open page
Click extension
Record issue or take screenshot
Capture console/network logs
Generate shareable report link
Give report link to Claude/Codex
Code language: JavaScript (javascript)

Best option: Jam.dev

Jam.dev is one of the best tools for this workflow.

It can capture:

Screenshot
Screen recording
Console logs
Network logs
Browser metadata
Device metadata
User actions
Annotations
Shareable report link

Best for:

Frontend bugs
UI issues
JavaScript errors
Hard-to-reproduce problems
QA notes
Claude/Codex debugging context

Example workflow:

1. Open your local/staging/public page.
2. Click Jam extension.
3. Start recording or take screenshot.
4. Reproduce the issue.
5. Stop recording.
6. Copy the Jam report link.
7. Paste it into Claude/Codex.
8. Ask the AI to analyze screenshot/video, console logs, network logs, and user actions.
Code language: JavaScript (javascript)

Prompt:

Analyze this Jam bug report.

Focus on:
1. Screenshot/video issue
2. Console errors
3. Network failures
4. User actions
5. Browser/device metadata
6. Exact frontend component/CSS/API issue
7. Specific code changes needed

Do not give generic advice.
Convert the evidence into exact implementation fixes.
Code language: JavaScript (javascript)

Cost

Jam has a free plan with limits. Paid plans are useful if you need more recordings, team features, or heavier usage.

For personal vibe coding, start with the free plan.

10. Solution 3: BrowserStack Bug Capture / Bird Eats Bug

BrowserStack Bug Capture is another strong option.

It can capture:

Screen recording
Console logs
Network logs
Click events
Key events
System details
Technical bug report

Best for:

QA workflows
Bug reproduction
Frontend debugging
Team reporting
Sharing evidence with developers or AI coding tools
Code language: JavaScript (javascript)

Use it when you want a more QA-style bug report.

11. Solution 4: WebPageTest for Public Pages

For public websites, WebPageTest is extremely useful.

It can provide:

Shareable report
Screenshot
Filmstrip
Waterfall
Performance metrics
Request details
Loading timeline
Lighthouse-style report in some workflows

Best for:

Slow public pages
Large images
Render-blocking CSS/JS
Third-party scripts
Blank page during loading
LCP problems
Network waterfall analysis
Code language: PHP (php)

Use it for:

Landing pages
Blog pages
Public hospital pages
Public doctor listing pages
Marketing websites
SEO pages
Country landing pages
Procedure pages
Code language: PHP (php)

Limitation

WebPageTest usually cannot test:

localhost
private staging
logged-in dashboards
Keycloak-protected pages
internal admin pages
Code language: PHP (php)

For those, use Playwright or a browser extension.

12. Solution 5: PageSpeed Insights and Lighthouse

PageSpeed Insights and Lighthouse are best for:

Performance
SEO
Accessibility
Best practices
Progressive web app checks
Core Web Vitals
Mobile quality

Lighthouse can run from:

Chrome DevTools
Command line
Node module
PageSpeed Insights
Browser extension
Code language: JavaScript (javascript)

Use it when you want to know:

Is the page slow?
Is the SEO basic setup correct?
Are images too large?
Is JavaScript blocking rendering?
Are accessibility basics broken?
Is mobile performance weak?

Limitation

Lighthouse is not enough for detailed UI debugging.

It will not fully understand:

Card spacing is ugly
Header design is weak
Button should align right
Dropdown looks broken
Modal overlay is wrong

For those, use screenshots and AI review.

13. Solution 6: GTmetrix and DebugBear

GTmetrix and DebugBear are good for public website performance reports.

They are useful for:

Performance score
Page size
Waterfall
Large assets
Core Web Vitals
Recommendations
Shareable report
Client-friendly explanations

Use these when you want a cleaner report to share with:

Claude
Codex
Client
Developer
SEO team
Designer

Limitation

Free tiers may have limits.

They are mostly useful for public pages, not private/local pages.

14. Solution 7: WAVE and axe DevTools for Accessibility

Accessibility needs separate attention.

Use WAVE or axe DevTools when you want to check:

Missing alt text
Low color contrast
Missing labels
ARIA issues
Heading hierarchy
Keyboard navigation
Form accessibility
Button/link accessibility
Semantic HTML problems

WAVE

Good for visual accessibility feedback directly inside the browser.

Useful for:

Public pages
Local pages
Password-protected pages
Dynamic pages
Sensitive pages
Code language: PHP (php)

axe DevTools

Good for developers who want automated accessibility checks inside the browser.

Use it before saying a frontend page is ready.

15. Solution 8: Percy and Visual Regression Testing

Percy is for visual regression testing.

It captures screenshots and compares them against a baseline.

Best for:

Detecting visual changes
Preventing accidental UI breakage
Reviewing frontend changes
Team QA workflows
Release checks

Use Percy later when your project becomes bigger.

For your current vibe coding workflow, it is not the first tool I would start with.

Start with:

Playwright screenshots
Jam reports
WebPageTest reports

Then add Percy if visual regression becomes important.

16. Cost Summary

Here is the practical cost map.

My advice:

Do not start with expensive tools.
Start with free browser evidence workflows.
Code language: JavaScript (javascript)

17. Best Tool by Situation

18. Add Browser Verification Rules to Every Project

This is very important.

Create or update one of these files in your project root:

CLAUDE.md
CODEX.md
AGENTS.md
.cursor/rules

Add this:

# Browser Verification Rule

For any UI, layout, frontend, responsive, CSS, JavaScript, or browser-related task:

1. Do not rely only on source-code reading.
2. Run browser verification using Playwright, Chromium, Jam, or available browser tools.
3. Check desktop, tablet, and mobile screenshots.
4. Check console errors.
5. Check failed network requests.
6. Inspect DOM/CSS if layout is broken.
7. Do not say "done" unless browser verification was actually performed.
8. If browser access is unavailable, clearly say browser verification was not possible.
9. Mention exactly what was tested.
10. Mention any remaining unverified area.
Code language: PHP (php)

This rule is gold.

Without this, the AI may pretend the browser was checked.

19. Standard Prompt for Claude/Codex

Use this prompt for UI tasks:

You must verify the UI in a real browser, not only by reading code.

Workflow:
1. Start the dev server if it is not running.
2. Open the app in browser using Playwright, Chromium, Jam evidence, or available browser tools.
3. Test these viewports:
   - Desktop: 1440x900
   - Tablet: 768x1024
   - Mobile: 390x844
4. Capture screenshots for each viewport.
5. Check browser console errors.
6. Check failed network requests.
7. Inspect the DOM and applied CSS for the broken UI section.
8. Identify the exact file/component/CSS causing the issue.
9. Fix the issue.
10. Re-run the browser check.
11. Show before/after explanation and mention what was verified.

Do not say the task is complete unless the browser was actually opened and verified.
If browser access is not available, clearly say so and provide the exact setup needed.
Code language: JavaScript (javascript)

20. Prompt for Screenshot-Based Debugging

When you only have a screenshot, use this:

Analyze this screenshot as a frontend/UI debugging task.

Please identify:
1. Visible UI problem
2. Likely frontend/component/CSS cause
3. Responsive layout risk
4. Accessibility concern if visible
5. Exact code areas to inspect
6. Suggested implementation fix
7. What browser evidence is still missing

Do not assume the issue is fixed without console/network/browser verification.
Code language: JavaScript (javascript)

21. Prompt for Jam.dev or Bug Capture Reports

Use this when you have a shareable bug report:

Analyze this browser bug report.

Focus on:
1. Screenshot/video evidence
2. User action sequence
3. Console errors
4. Network failures
5. Browser/device metadata
6. Failed API requests
7. Frontend route/component involved
8. Exact code changes needed

Convert the evidence into a precise implementation plan.
Do not give generic advice.
Code language: JavaScript (javascript)

22. Prompt for Public Website Audit Reports

Use this when you have WebPageTest, PageSpeed Insights, GTmetrix, or DebugBear reports:

Analyze these website audit reports.

Focus on:
1. Loading performance
2. Largest images/assets
3. Render-blocking CSS/JS
4. Third-party scripts
5. Core Web Vitals
6. SEO warnings
7. Accessibility warnings
8. Mobile issues
9. Exact frontend/build/content fixes required

Convert the findings into prioritized coding tasks:
- Critical
- High
- Medium
- Low

Avoid generic advice. Mention exact files, components, assets, or configuration areas to inspect.

23. Recommended Folder Structure

For every project, create:

tools/
  browser_check.py

browser-report/
  desktop.png
  desktop-report.txt
  tablet.png
  tablet-report.txt
  mobile.png
  mobile-report.txt

docs/
  browser-verification.md
  test-cases.md

In docs/browser-verification.md, document:

Local URL
Start command
Build command
Test command
Browser check command
Required viewports
Login/test user details
Pages to verify
Known limitations

Example:

# Browser Verification Guide

## Local URL

http://127.0.0.1:3000

## Start Command

npm run dev

## Build Command

npm run build

## Browser Check Command

python tools/browser_check.py

## Viewports

- Desktop: 1440x900
- Tablet: 768x1024
- Mobile: 390x844

## Required Checks

- Screenshot
- Console errors
- Failed network requests
- Mobile layout
- Header/menu
- Main CTA
- Forms
- Footer
Code language: PHP (php)

24. Security and Privacy Warning

This workflow can capture sensitive data.

Browser evidence may include:

API URLs
Headers
Console logs
Network requests
User details
Auth redirects
Error payloads
Session-related information
Private page content
Medical/customer data
Code language: JavaScript (javascript)

Be careful when recording:

Production admin pages
Patient data
Customer data
Payment pages
Private dashboards
Keycloak sessions
API tokens
Secrets
Internal tools
Code language: PHP (php)

Best practice:

Use staging/dev
Use test users
Blur sensitive fields
Delete old reports
Do not share bug report links publicly
Disable extensions when not needed
Avoid recording real customer/patient data
Code language: PHP (php)

This is especially important for healthcare, medical, hospital, doctor, fintech, and admin systems.

25. Common Mistakes to Avoid

Mistake 1: Asking AI to “check browser” without evidence

Bad:

Please check browser and fix.

Better:

Here are screenshots, console logs, failed requests, and viewport details. Analyze and fix.
Code language: JavaScript (javascript)

Mistake 2: Trusting “done” without proof

Do not accept:

Done
Fixed
Tested

Ask:

What browser was tested?
Which viewport?
Any console errors?
Any failed network requests?
Where is the screenshot?
Code language: JavaScript (javascript)

Mistake 3: Testing only desktop

Always test:

Desktop
Tablet
Mobile

Many UI bugs appear only on mobile.

Mistake 4: Using public tools for private pages

WebPageTest and PageSpeed Insights are good for public pages.

They usually cannot test:

localhost
private staging
logged-in pages
admin dashboards
Code language: PHP (php)

Use Playwright or browser extensions for those.

Mistake 5: Ignoring console errors

A page can look visually okay but still have broken JavaScript.

Always check console errors.

Mistake 6: Ignoring failed network requests

A page may load but silently fail APIs.

Always check failed requests.

26. Practical Daily Vibe Coding Workflow

Here is the workflow I recommend.

Step 1: Ask AI to implement

Build/fix the feature.
Follow existing project structure.
Do not mark done until browser verification passes.
Code language: PHP (php)

Step 2: Run the app

npm run dev

Step 3: Run browser verification

python tools/browser_check.py

Step 4: Review generated output

Check:

browser-report/desktop.png
browser-report/tablet.png
browser-report/mobile.png
browser-report/desktop-report.txt
browser-report/tablet-report.txt
browser-report/mobile-report.txt

Step 5: Give evidence back to AI

Analyze this browser-report folder and fix remaining issues.
Code language: JavaScript (javascript)

Step 6: Re-run verification

python tools/browser_check.py

Step 7: Accept only after evidence is clean

Accept when:

Screenshots look correct
No console errors
No failed requests
Mobile layout works
Desktop layout works
Tablet layout works
Code language: JavaScript (javascript)

27. Final Recommended Workflow by Page Type

Public marketing website

Use:

WebPageTest
PageSpeed Insights
Lighthouse
Jam screenshot if visual issue exists

Local development page

Use:

Python Playwright + Chromium

Logged-in dashboard

Use:

Jam extension
Playwright with login/session setup
BrowserStack Bug Capture if needed
Code language: JavaScript (javascript)

Accessibility testing

Use:

WAVE
axe DevTools
Lighthouse Accessibility

Performance optimization

Use:

WebPageTest
PageSpeed Insights
GTmetrix
DebugBear
Lighthouse

Visual regression

Use:

Playwright screenshots
Percy
BrowserStack visual testing

28. Final Tool Recommendation

If I had to choose only three tools, I would choose:

1. Python Playwright + Chromium
2. Jam.dev Chrome extension
3. PageSpeed Insights / Lighthouse

If I had to add two more:

4. WebPageTest
5. WAVE or axe DevTools

This gives almost everything needed for practical vibe coding.

29. Final Summary

The core problem is not that Claude or Codex are useless for frontend work.

The problem is that they often do not have enough browser evidence.

The winning approach is:

Do not ask AI to guess.
Give AI browser evidence.
Code language: PHP (php)

The best evidence includes:

Screenshots
Console logs
Network logs
Failed requests
Viewport details
Performance reports
Accessibility reports
User action recordings

The best free/local foundation is:

Python + Playwright + Chromium

The best one-click extension workflow is:

Jam.dev or BrowserStack Bug Capture
Code language: CSS (css)

The best public website audit workflow is:

WebPageTest + PageSpeed Insights + Lighthouse

The best accessibility workflow is:

WAVE + axe DevTools

The most important project rule is:

Never mark frontend work as done unless browser verification was actually performed.
Code language: JavaScript (javascript)

Once you follow this workflow, Claude/Codex become much more useful. They stop guessing from code and start fixing based on real browser evidence.

That is the difference between random vibe coding and professional AI-assisted frontend development.

Rajesh Kumar

I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I have worked at Cotocus. I share tech blog at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow , and SEO strategies at Wizbrand.

Do you want to learn Quantum Computing?

Please find my social handles as below;

Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at WIZBRAND

Rajesh Kumar DailyLogs