![Aman Soni](https://web.dev/images/authors/amansoni.jpeg) Aman Soni [LinkedIn](https://www.linkedin.com/in/amansoni211) [Homepage](https://www.policybazaar.com/) ![Swetha Gopalakrishnan](https://web.dev/images/authors/swethagopalakrishnan.jpg) Swetha Gopalakrishnan [X](https://twitter.com/swetha_go) [LinkedIn](https://www.linkedin.com/in/swetha-gopalakrishnan-5ba92936)

<br />


Published: November 10, 2026

<br />

[Policybazaar](https://www.policybazaar.com/) is one of India's leading
insurance platforms, with more than 97 million registered customers. About 80%
of its customers visit the website every month. Its parent company, PB Fintech,
recently launched [Pensionbazaar](https://www.pensionbazaar.com/), an
end-to-end retirement planning platform, which is a brand under Paisabazaar
Marketing \& Consulting Private Limited.

Both teams already use coding agents, which write code quickly, but can't see
what that code does in a browser. Agents often reached for outdated web
patterns, and had no way to check whether a screen rendered correctly, so
engineers still had to verify everything by hand.

To solve this, both companies combined two tools into their agentic workflow:
[Modern Web Guidance](https://developer.chrome.com/docs/modern-web-guidance.md.txt) to teach models modern web
standards, and [Chrome DevTools for agents](https://developer.chrome.com/docs/devtools/agents) to give
those agents a live, headless browser to inspect and verify their work.

Here's the impact:
92%

Less manual auditing effort across about 30 Policybazaar landing pages
\>90%

Faster development and testing turnaround for new Pensionbazaar pages, from about four days to a few hours
\>90%

Fewer UI bugs raised against new Pensionbazaar screens

## The challenge: Fast code, slow verification

Policybazaar and Pensionbazaar ran into two different bottlenecks which the
standard AI coding workflows couldn't optimize at production level.

### Pensionbazaar: New screens with long QA cycles

Pensionbazaar needed dozens of new, complex screens, such as the multi-step
Retirement Freedom Score calculator, customizable investment expense
projections, and automated recommendation reports. The team built them with
coding agents and the Figma MCP server, but two problems kept QA cycles long.

First, the agents were coding in the dark. A base model could generate code, but
it couldn't see the rendered interface, compare computed styles with the design
specs, detect layout shifts, or read a network waterfall. So related issues like
clipped UI and layout shifts made it all the way to manual QA.

Second, the generated code was stuck in the past. Without awareness of the
modern web platform, the agents fell back on outdated workarounds, writing heavy
JavaScript modals instead of using the built-in `<dialog>` element, adding
unnecessary polyfills, and leaving out performance hints like `fetchpriority`.

### Policybazaar: 30 landing pages and a manual audit

Policybazaar's life insurance team runs about 30 landing pages for different
insurance products, and each page can have variations for different marketing
campaigns. Together, they receive 200,000 to 300,000 visitors a day, and every
page gets monthly design and business-logic updates. The team has to keep
[Core Web Vitals](https://web.dev/articles/vitals) scores high and make sure
every variant stays accessible and renders correctly on every screen size.

Before automation, an engineer audited each page by hand:

1. Run PageSpeed Insights to gather real-world user data.
2. Evaluate the Core Web Vitals scores and recommendations.
3. Inspect the development or staging build, diagnose the problems behind the scores, and apply code fixes.

The process was slow, repetitive, and didn't scale. It left room for missed
optimizations, inconsistent audit coverage, undetected performance regressions,
and delayed releases.

Before changing their workflow, the teams set three goals: cut developer time
spent on performance audits by more than 80% while making audit coverage
continuous, shorten QA turnaround with verified reports, and reduce UI bugs
raised because a screen didn't match its wireframes.

## The solution: A code-to-verify loop

Pensionbazaar closed the gap between writing code and checking it. The agent
writes the code, starts a clean browser instance, audits the page
programmatically for visual parity, layout breakage, console errors and
performance, and fixes the issues it finds with minimal human intervention.
Their agent gets the design from Figma MCP, so it can compare the rendered page
with what the designers intended.
![A flowchart with five stages from top to bottom. First, a Figma
wireframe, read with the Figma MCP server. Second, code generation,
where a coding agent is guided by Modern Web Guidance. Third,
automated audits in an isolated browser launched with Chrome
DevTools for agents: a viewport and visual layout audit, a console
error and exception audit, and an automated performance audit.
Fourth, verification, where an autonomous feedback and
self-correction loop applies changes based on the audit findings,
compares the result with the original Figma wireframe, and loops
back to the audits when needed. Fifth, the resulting final verified
code, including an automated QA report with screenshots.](https://developer.chrome.com/static/blog/policybazaar-agentic-audit/images/code-to-verify-flow.png) Pensionbazaar's code-to-verify loop. The agent repeats the audits and corrections until the page matches the design, then automatically verified code with a QA report.

The following video shows this loop in action. The agent reads the Figma
designs for a new screen, implements it, and then uses Chrome DevTools for
agents to inspect the rendered page and fix the differences it finds.
The Pensionbazaar coding agent implements a screen from Figma designs, then uses Chrome DevTools for agents to verify and fix it.

### Step 1: Ground the agent in modern web standards

The Pensionbazaar team wanted the generated code to follow modern web best
practices, use current platform features, and still work in older browsers.
That's tedious to check by hand, and agents aren't always up to date with the
platform. [Modern Web Guidance](https://developer.chrome.com/docs/modern-web-guidance.md.txt) solves this problem.
It's an agent skill, written and maintained by web experts from Chrome and the
web community, that covers more than 200 use cases. It steers agents toward
modern web platform APIs and toward performance and accessibility best practices
that fit your Baseline target. If you don't set a target, it defaults to
[Baseline Widely Available](https://developer.chrome.com/docs/modern-web-guidance/get-started.md.txt#baseline).

> [!TIP]
> **Tip:** To install Modern Web Guidance in your coding agent, run `npx modern-web-guidance@latest install`. For more options, see [Get started with Modern Web Guidance](https://developer.chrome.com/docs/modern-web-guidance/get-started.md.txt).

After the agent pulls context from the Figma files, it uses Modern Web Guidance
as it writes code. For Pensionbazaar, this changed the code in three ways:

- **Native elements replaced JavaScript workarounds.** The agent used the built-in `<dialog>` element and the [Popover API](https://developer.mozilla.org/docs/Web/API/Popover_API/Using) for plan detail modals, and CSS Grid and Flexbox for financial summary cards.
- **The agent added performance hints that base models usually leave out.** These included `fetchpriority="high"` on hero LCP images, `loading="lazy"` on below-the-fold plan cards, and a time-based execution budget with [`scheduler.yield()`](https://developer.chrome.com/blog/use-scheduler-yield.md.txt) to protect Interaction to Next Paint (INP).
- **Modern features didn't break older browsers.** Pensionbazaar supports older browser versions, which it defines in [Browserslist](https://browsersl.ist/). The agent used features like the `:user-invalid` CSS pseudo-class and `autoComplete="one-time-code"` on the one-time password (OTP) field. Older browsers ignore them, and core functionality keeps working.

The base models weren't far off. For performance, the team found them about 70%
aligned with best practices. The agent's own report listed 12 Modern Web
Guidance rules that closed the remaining gap. Four examples:

| Area | The base model gap | The Modern Web Guidance rule |
|---|---|---|
| **Image loading** | Hallucinated conflicting combinations, like pairing `fetchpriority="high"` with `loading="lazy"`. | Explicitly prohibits combining them, and caps high-priority images to one or two per page. |
| **Layout stability** | Suggested `content-visibility: auto` for performance, but omitted `contain-intrinsic-size`. | Requires pairing the two properties to prevent severe layout shifts when content renders. |
| **Main-thread yielding** | Used `scheduler.yield()` generically without a deadline pattern. | Enforces a strict time-based deadline (`performance.now() + 50`) to protect Interaction to Next Paint (INP). |
| **Service Worker caching** | Didn't account for offline form submissions. | Warns the agent that Service Workers cannot natively cache non-GET requests. |

> For Pensionbazaar, our priority was building quality code from day one to
> avoid technical debt later. Modern Web Guidance steered our coding agent to
> adopt modern web standards and performance best practices while respecting our
> specific browser compatibility targets. This made our frontend code reviews
> substantially easier and faster, ultimately improving our development
> turnaround time.
> Aman Soni, Engineering Manager, Policybazaar

### Step 2: Give the agent a browser

[Chrome DevTools for agents](https://developer.chrome.com/docs/devtools/agents) is a set of tools, including
an MCP server, a CLI, and agent skills, that gives coding agents real-time
access to runtime debugging data, such as console logs, network traffic, the
accessibility tree, and
[other DevTools capabilities](https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md).

The team installed Chrome DevTools for agents as a plugin in their coding agent,
Claude Code:

```bash
# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp

# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins
```

The team wanted every test to run in a clean browser instance, so installed
Chrome extensions can't affect the results and personal or sensitive data can't
leak. To get that, add
[`--isolated`](https://developer.chrome.com/docs/devtools/agents/get-started/configuration.md.txt) to the `args`
array in the MCP server configuration:

```json
{
  "args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
```

If your tests need an existing signed-in browser session instead, use
[`--autoConnect`](https://developer.chrome.com/docs/devtools/agents/use-cases/auto-connect.md.txt).

### Step 3: Let the agent check and fix its own work

The engineering team lists the checks in the agent's instructions, either as a
prompt or as an agent skill. At a high level, the agent does the following:

- Inspects the DOM tree and computed CSS and compares them with the Figma design.
- Resizes the page to mobile viewports to test responsiveness.
- Records performance traces to find long animation frames (LoAF) caused by scripts, render-blocking resources, and other performance issues.
- Rewrites code to fix design mismatches, performance issues, and console exceptions before an engineer reviews it.

The following table shows which Chrome DevTools for agents tools support each
check:

| Check | Tools |
|---|---|
| Test responsiveness across viewports | `resize_page` resizes the page's window to explicit dimensions. `emulate` emulates specific device environments. `take_screenshot` captures the result. |
| Compare the DOM and computed CSS with the Figma design | `take_snapshot` returns a text snapshot of the page based on the accessibility tree. `get_css_styles` reads applied CSS rules. `evaluate_script` runs a JavaScript function inside the page. |
| Find LoAF, render-blocking resources, and Core Web Vitals issues | `click` and `drag` emulate interactions. `performance_start_trace` and `performance_stop_trace` record a performance trace. `performance_analyze_insight` returns detailed diagnostics for the insights in the trace. `list_network_requests` and `get_network_request` show network activity. `lighthouse_audit` audits non-performance areas like SEO and accessibility. |

> [!TIP]
> **Tip:** The tools an agent calls depend on its task, so this list isn't complete. For every available tool, see the [Chrome DevTools for agents tool reference](https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md).

When the agent finds a problem, such as text cut off on small screens, a broken
flex wrap, or an unoptimized image that causes a layout shift, it runs a short
correction loop:

1. Chrome DevTools for agents captures the exact error.
2. The agent analyzes the data and rewrites the problematic CSS or JavaScript.
3. The agent reloads the page to confirm the fix.

On one screen, the agent rendered the page and found that the header layout,
spacing, and gradient didn't match the design. It fixed the relevant `.scss`
files. It also interacted with the page, such as expanding accordions to check
that their open states matched the designs.

### Step 4: Hand QA a verified report

When verification is done, the agent delivers production-ready code along with
an audit report for the QA team. The report includes:

- A visual comparison with the Figma design that highlights pixel differences, built from screenshots, DOM snapshots, and computed styles.
- Screenshots of the rendered page at different screen sizes.
- Core Web Vitals and performance diagnostics from `performance_start_trace` and `performance_analyze_insight`, such as Speed Index and Total Blocking Time (TBT).
- Lighthouse scores for SEO, best practices, and accessibility from `lighthouse_audit`.
- Pass or fail checks for interactions, such as collapsing rows and toggles, plus console errors and application state changes, such as editing rows, deleting rows, and empty states.

![A QA report for the customer financial details page that shows the
Figma design, the implementation, and a pixel diff side by side,
with 98.7% and 97.1% of pixels matching.](https://developer.chrome.com/static/blog/policybazaar-agentic-audit/images/figma-visual-comparison.jpg) Agent-generated visual comparison between the rendered page (captured with Chrome DevTools for agents) and Figma mock design specs, highlighting differences by pixel. ![A Lighthouse report table for the production build. Mobile and
desktop scores are 90 and 93 for performance, 91 for
accessibility, 100 for best practices, and 92 for SEO. Metrics
include a Largest Contentful Paint of 2.1 seconds on mobile and
0.5 seconds on desktop, 0 milliseconds of Total Blocking Time, and
a Cumulative Layout Shift of 0.006 on mobile and 0.001 on
desktop.](https://developer.chrome.com/static/blog/policybazaar-agentic-audit/images/lighthouse-cwv-scores.png) Lighthouse and Core Web Vitals scores on mobile and desktop.

## Bring the same approach to 30 campaign pages

On its main platform, Policybazaar replaced manual PageSpeed Insights runs with
audits run through Chrome DevTools for agents in Kiro. Before a campaign page
goes live, an engineer triggers an audit against the staging URL for mobile and
desktop. The agent runs performance and Lighthouse audits, and Chrome DevTools
for agents automatically pulls real-world Chrome User Experience Report (CrUX)
field data alongside the lab data. That replaced the PageSpeed Insights step
entirely.

The agent then reports the performance scores, the bottlenecks it found, and a
prioritized list of improvements for an engineer to fix. In one pre-release
audit, it flagged non-critical API calls that fired one after another during
page load and competed with critical rendering work. The team fixed the issue
before the page went live.

The agent now completes 12 performance audits in the time an engineer needs to
finish one. That's a 92% reduction in manual effort.
Kiro uses Chrome DevTools for agents to run Lighthouse audits and performance traces on a Policybazaar landing page, then lists the performance issues it finds. Web performance is important for us to maintain a good user experience, but
> manually auditing, evaluating waterfalls and traces across dozens of landing
> pages was tedious and a major bottleneck. Chrome DevTools for agents
> transformed this process and reduced our engineers' performance auditing time
> by 92%, leaving room for them to focus on more complex tasks.
> Aman Soni, Engineering Manager, Policybazaar

## Impact

Modern Web Guidance and Chrome DevTools for agents turned frontend testing at
Policybazaar and Pensionbazaar from a manual, reactive process into an
automated, proactive one. The following table compares the workflows before and
after the change:

| Area | Before: manual review and base models | After: Modern Web Guidance and Chrome DevTools for agents |
|---|---|---|
| Performance auditing effort (Policybazaar) | An engineer ran PageSpeed Insights, reviewed Core Web Vitals, and applied fixes by hand for each of about 30 landing pages. | 92% less manual effort. The agent completes 12 audits in the time an engineer needed for one. |
| Audit coverage (Policybazaar) | Audit coverage across campaign variants was inconsistent. | 100% performance test coverage for campaign pages. |
| New screen turnaround (Pensionbazaar) | A few days from code to verified screen. | A few hours, more than 90% faster. |
| Design parity bugs (Pensionbazaar) | Clipped UI and layout shifts reached manual QA. | More than 90% fewer UI bugs were raised. |

The 92% reduction beat the team's goal of more than 80%. Landing page
regressions get caught before they reach staging or QA. On Pensionbazaar, code
arrives already audited with screenshots for several viewports, which cut down
the back-and-forth between design, engineering, and QA.

## Takeaways for your team

- **Ground your agent in authoritative guidance.** Curated guidance like Modern Web Guidance keeps agents away from obsolete patterns and keeps your code within your [Baseline targets](https://web.dev/articles/how-to-choose-your-baseline-target).
- **Don't let an agent mark a frontend task done until it has checked the
  rendered page.** Chrome DevTools for agents lets the agent inspect layout, viewports, and performance traces in a real browser.
- **Give the loop clear exit criteria.** Set step limits and explicit pass and fail conditions so the agent doesn't loop and waste tokens.
- **Start with high-frequency, template-driven pages.** Closed-loop workflows pay off most where turnaround speed matters.
- **Run audits in a clean browser.** Use `--isolated` so extensions and cached data don't affect results or expose personal data.

## Resources

- [Modern Web Guidance](https://developer.chrome.com/docs/modern-web-guidance.md.txt)
- [Modern Web Guidance source repository](https://github.com/GoogleChrome/modern-web-guidance-src/tree/main)
- [Chrome DevTools for agents documentation](https://developer.chrome.com/docs/devtools/agents)
- [Chrome DevTools for agents on GitHub](https://github.com/ChromeDevTools/chrome-devtools-mcp)