Data di pubblicazione: 10 novembre 2026
Policybazaar è una delle principali piattaforme assicurative dell'India, con oltre 97 milioni di clienti registrati. Circa l'80% dei suoi clienti visita il sito web ogni mese. La sua società madre, PB Fintech, ha lanciato di recente Pensionbazaar, una piattaforma di pianificazione pensionistica end-to-end, che è un brand di Paisabazaar Marketing & Consulting Private Limited.
Entrambi i team utilizzano già agenti di programmazione, che scrivono il codice rapidamente, ma non possono vedere cosa fa quel codice in un browser. Gli agenti spesso utilizzavano pattern web obsoleti e non avevano modo di verificare se una schermata veniva visualizzata correttamente, quindi gli ingegneri dovevano comunque verificare tutto manualmente.
Per risolvere questo problema, entrambe le aziende hanno combinato due strumenti nel loro Agentic Workflow: Modern Web Guidance per insegnare ai modelli gli standard web moderni e Chrome DevTools per agenti per fornire a questi agenti un browser headless in tempo reale per ispezionare e verificare il loro lavoro.
Ecco l'impatto:
92%
Meno sforzo di controllo manuale su circa 30 pagine di destinazione di Policybazaar
>90%
Tempi di sviluppo e test più rapidi per le nuove pagine di Pensionbazaar, da circa quattro giorni a poche ore
>90%
Meno bug dell'interfaccia utente segnalati per le nuove schermate di Pensionbazaar
La sfida: codice veloce, verifica lenta
Policybazaar e Pensionbazaar hanno riscontrato due diversi colli di bottiglia che i flussi di lavoro di programmazione AI standard non sono riusciti a ottimizzare a livello di produzione.
Pensionbazaar: nuove schermate con lunghi cicli di QA
Pensionbazaar aveva bisogno di decine di nuove schermate complesse, come il calcolatore del punteggio di libertà pensionistica in più passaggi, le proiezioni personalizzabili delle spese di investimento e i report automatici sui consigli. Il team li ha creati con agenti di programmazione e il server MCP di Figma, ma due problemi hanno prolungato i cicli di QA.
Innanzitutto, gli agenti programmavano al buio. Un modello di base potrebbe generare codice, ma non potrebbe vedere l'interfaccia visualizzata, confrontare gli stili calcolati con le specifiche di progettazione, rilevare variazioni del layout o leggere una struttura a cascata di rete. Di conseguenza, problemi correlati come l'interfaccia utente tagliata e gli spostamenti del layout sono arrivati fino al QA manuale.
In secondo luogo, il codice generato era bloccato nel passato. Senza conoscere la moderna piattaforma web, gli agenti hanno fatto ricorso a soluzioni alternative obsolete, scrivendo modali JavaScript pesanti anziché utilizzare l'elemento <dialog> integrato, aggiungendo polyfill non necessari e tralasciando suggerimenti per le prestazioni come fetchpriority.
Policybazaar: 30 pagine di destinazione e un controllo manuale
Il team di Policybazaar responsabile delle assicurazioni sulla vita gestisce circa 30 pagine di destinazione per diversi prodotti assicurativi e ogni pagina può avere varianti per diverse campagne di marketing. Insieme, ricevono da 200.000 a 300.000 visitatori al giorno e ogni pagina riceve aggiornamenti mensili di progettazione e logica di business. Il team deve mantenere elevati i punteggi di Core Web Vitals e assicurarsi che ogni variante rimanga accessibile e venga visualizzata correttamente su schermi di ogni dimensione.
Prima dell'automazione, un ingegnere controllava ogni pagina manualmente:
- Esegui PageSpeed Insights per raccogliere dati utente reali.
- Valuta i punteggi e i consigli di Core Web Vitals.
- Esamina la build di sviluppo o di gestione temporanea, diagnostica i problemi alla base dei punteggi e applica le correzioni del codice dell'applicazione.
Il processo era lento, ripetitivo e non scalabile. Questo approccio lasciava spazio a ottimizzazioni mancate, copertura dei controlli incoerente, regressioni delle prestazioni non rilevate e ritardi nelle release.
Prima di modificare il flusso di lavoro, i team hanno fissato tre obiettivi: ridurre di oltre l'80% il tempo dedicato dagli sviluppatori ai controlli delle prestazioni, rendendo al contempo continua la copertura dei controlli, abbreviare i tempi di risposta del QA con report verificati e ridurre i bug dell'UI generati perché una schermata non corrispondeva ai relativi wireframe.
La soluzione: un ciclo di verifica del codice
Pensionbazaar ha colmato il divario tra la scrittura del codice e il suo controllo. L'agente scrive il codice, avvia un'istanza del browser pulita, controlla la pagina in modo programmatico per verificare la parità visiva, la rottura del layout, gli errori della console e le prestazioni e risolve i problemi rilevati con un intervento umano minimo. L'agente ottiene il design da Figma MCP, in modo da poter confrontare la pagina visualizzata con l'intenzione dei designer.
Il seguente video mostra questo loop in azione. L'agente legge i design di Figma per una nuova schermata, li implementa e poi utilizza Chrome DevTools per agenti per ispezionare la pagina visualizzata e correggere le differenze che trova.
Passaggio 1: basa l'agente su standard web moderni
Il team di Pensionbazaar voleva che il codice generato seguisse le best practice del web moderno, utilizzasse le funzionalità della piattaforma attuale e funzionasse comunque nei browser meno recenti. Controllare manualmente è noioso e gli agenti non sono sempre aggiornati sulla piattaforma. Modern Web Guidance risolve questo problema. Si tratta di una skill dell'agente, scritta e gestita da esperti web di Chrome e della community web, che copre oltre 200 casi d'uso. Indirizza gli agent verso le API della piattaforma web moderna e verso le best practice di prestazioni e accessibilità che si adattano al tuo target Baseline. Se non imposti un target, il valore predefinito è Baseline Widely Available.
Dopo aver estratto il contesto dai file Figma, l'agente utilizza Modern Web Guidance durante la scrittura del codice. Per Pensionbazaar, questo ha cambiato il codice in tre modi:
- Gli elementi nativi hanno sostituito le soluzioni alternative JavaScript. L'agente ha utilizzato l'elemento
<dialog>integrato e l'API Popover per i modali dei dettagli del piano, nonché CSS Grid e Flexbox per le schede di riepilogo finanziario. - L'agente ha aggiunto suggerimenti sulle prestazioni che i modelli di base di solito tralasciano.
Questi includevano
fetchpriority="high"sulle immagini LCP principali,loading="lazy"sulle schede dei piani below the fold e un budget di esecuzione basato sul tempo conscheduler.yield()per proteggere l'Interaction to Next Paint (INP). - Le funzionalità moderne non hanno compromesso i browser meno recenti. Pensionbazaar supporta le versioni precedenti del browser, che definisce in Browserslist. L'agente ha utilizzato funzionalità come la pseudo-classe CSS
:user-invalideautoComplete="one-time-code"nel campo della password monouso (OTP). I browser meno recenti li ignorano e la funzionalità di base continua a funzionare.
I modelli di base non erano molto lontani. Per quanto riguarda le prestazioni, il team ha riscontrato che erano allineati per circa il 70% alle best practice. Il report dell'agente ha elencato 12 regole di Modern Web Guidance che hanno colmato il divario rimanente. Quattro esempi:
| Area | Il divario del modello di base | La regola Modern Web Guidance |
|---|---|---|
| Caricamento dell'immagine | Combinazioni allucinate in conflitto, come l'abbinamento di fetchpriority="high" con loading="lazy". |
Vieta esplicitamente di combinarli e limita le immagini ad alta priorità a una o due per pagina. |
| Stabilità del layout | content-visibility: auto suggerito per le prestazioni, ma contain-intrinsic-size omesso. |
Richiede l'accoppiamento delle due proprietà per evitare variazioni di layout significative durante il rendering dei contenuti. |
| Yielding del thread principale | Utilizzato scheduler.yield() in modo generico senza un pattern di scadenza. |
Applica una scadenza rigorosa basata sul tempo (performance.now() + 50) per proteggere l'Interaction to Next Paint (INP). |
| Memorizzazione nella cache del service worker | Non hai tenuto conto degli invii di moduli offline. | Avvisa l'agente che i service worker non possono memorizzare nella cache in modo nativo le richieste non GET. |
Per Pensionbazaar, la nostra priorità era creare un codice di qualità fin dal primo giorno per evitare il debito tecnico in un secondo momento. Modern Web Guidance ha guidato il nostro agente di programmazione nell'adozione di standard web moderni e best practice per le prestazioni, rispettando al contempo i nostri target di compatibilità con i browser specifici. In questo modo, le nostre revisioni del codice frontend sono diventate molto più semplici e veloci, migliorando in ultima analisi i tempi di sviluppo.
Aman Soni, Engineering Manager, Policybazaar
Passaggio 2: fornisci un browser all'agente
Chrome DevTools per agenti è un insieme di strumenti, tra cui un server MCP, una CLI e competenze degli agenti, che offre agli agenti di programmazione l'accesso in tempo reale ai dati di debug di runtime, come i log della console, il traffico di rete, l'albero di accessibilità e altre funzionalità di DevTools.
Il team ha installato Chrome DevTools per agenti come plug-in nel proprio agente di programmazione, Claude Code:
# 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
Il team voleva che ogni test venisse eseguito in un'istanza del browser pulita, in modo che le estensioni di Chrome installate non potessero influire sui risultati e non potessero trapelare dati personali o sensibili. Per ottenerlo, aggiungi
--isolated all'array args
nella configurazione del server MCP:
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
Se i test richiedono una sessione del browser esistente con accesso eseguito, utilizza --autoConnect.
Passaggio 3: consenti all'agente di controllare e correggere il proprio lavoro
Il team di ingegneria elenca i controlli nelle istruzioni dell'agente, come prompt o come skill dell'agente. A livello generale, l'agente esegue le seguenti operazioni:
- Ispeziona l'albero DOM e il CSS calcolato e li confronta con il design Figma.
- Ridimensiona la pagina in base alle aree visibili dei dispositivi mobili per testare la reattività.
- Registra le tracce delle prestazioni per trovare i frame dell'animazione lunghi (LoAF) causati da script, risorse che bloccano il rendering e altri problemi di prestazioni.
- Riscrive il codice per correggere le discrepanze di progettazione, i problemi di prestazioni e le eccezioni della console prima che un ingegnere lo esamini.
La tabella seguente mostra quali strumenti di Chrome DevTools per agenti supportano ogni controllo:
| Assegno | Strumenti |
|---|---|
| Testa la reattività su diverse aree visibili | resize_page ridimensiona la finestra della pagina in base a dimensioni esplicite. emulate emula ambienti di dispositivi specifici. take_screenshot acquisisce il risultato. |
| Confronta il DOM e il CSS calcolato con il design di Figma | take_snapshot restituisce un'istantanea di testo della pagina in base all'albero di accessibilità. get_css_styles legge le regole CSS applicate. evaluate_script esegue una funzione JavaScript all'interno della pagina. |
| Trova problemi relativi a LoAF, risorse che bloccano il rendering e Core Web Vitals | click e drag emulano le interazioni. performance_start_trace e performance_stop_trace registrano una traccia di rendimento. performance_analyze_insight restituisce una diagnostica dettagliata per gli insight nella traccia. list_network_requests e get_network_request mostrano l'attività di rete. lighthouse_audit controlla le aree non relative alle prestazioni, come la SEO e l'accessibilità. |
Quando l'agente rileva un problema, ad esempio un testo tagliato su schermi di piccole dimensioni, un flex wrap interrotto o un'immagine non ottimizzata che causa una variazione del layout, esegue un breve ciclo di correzione:
- Chrome DevTools per agenti acquisisce l'errore esatto.
- L'agente analizza i dati e riscrive il CSS o il JavaScript problematico.
- L'agente ricarica la pagina per confermare la correzione.
In una schermata, l'agente ha eseguito il rendering della pagina e ha rilevato che il layout, la spaziatura e il gradiente dell'intestazione non corrispondevano al design. Ha corretto i file .scss pertinenti. Ha anche interagito con la pagina, ad esempio espandendo le sezioni a fisarmonica per verificare che i loro stati aperti corrispondessero ai design.
Passaggio 4: consegna al team di QA un report verificato
Al termine della verifica, l'agente fornisce il codice pronto per la produzione insieme a un report di audit per il team di QA. Il report include:
- Un confronto visivo con il design di Figma che evidenzia le differenze dei pixel, creato a partire da screenshot, snapshot DOM e stili calcolati.
- Screenshot della pagina visualizzata con schermi di dimensioni diverse.
- Core Web Vitals e diagnostica delle prestazioni di
performance_start_traceeperformance_analyze_insight, come Speed Index e Total Blocking Time (TBT). - Punteggi Lighthouse per SEO, best practice e accessibilità da
lighthouse_audit. - Controlli di superamento o mancato superamento per le interazioni, come la compressione di righe e pulsanti di attivazione/disattivazione, oltre a errori della console e modifiche dello stato dell'applicazione, come la modifica di righe, l'eliminazione di righe e gli stati vuoti.
Adotta lo stesso approccio per 30 pagine di campagna
Sulla sua piattaforma principale, Policybazaar ha sostituito le esecuzioni manuali di PageSpeed Insights con controlli eseguiti tramite Chrome DevTools per agenti in Kiro. Prima che una pagina della campagna venga pubblicata, un ingegnere attiva un controllo dell'URL di gestione temporanea per dispositivi mobili e computer. L'agente esegue controlli delle prestazioni e di Lighthouse, mentre Chrome DevTools per agenti estrae automaticamente i dati sul campo reali del Chrome User Experience Report (CrUX) insieme ai dati di laboratorio. Questo ha sostituito completamente il passaggio di PageSpeed Insights.
L'agente segnala quindi i punteggi di rendimento, i colli di bottiglia rilevati e un elenco di miglioramenti prioritari che un ingegnere deve correggere. In un audit pre-release, ha segnalato chiamate API non critiche che venivano attivate una dopo l'altra durante il caricamento della pagina e competevano con il lavoro di rendering critico. Il team ha risolto il problema prima che la pagina venisse pubblicata.
Ora l'agente completa 12 audit delle prestazioni nel tempo necessario a un ingegnere per completarne uno. Si tratta di una riduzione del 92% del lavoro manuale.
Le prestazioni web sono importanti per mantenere una buona esperienza utente, ma il controllo manuale, la valutazione dei waterfall e delle tracce su decine di pagine di destinazione erano noiosi e rappresentavano un importante collo di bottiglia. Chrome DevTools per agenti ha trasformato questo processo e ridotto del 92% il tempo di controllo delle prestazioni dei nostri ingegneri, lasciando loro spazio per concentrarsi su attività più complesse.
Aman Soni, Engineering Manager, Policybazaar
Impatto
Modern Web Guidance e Chrome DevTools per agenti hanno trasformato i test del frontend di Policybazaar e Pensionbazaar da un processo manuale e reattivo a uno automatizzato e proattivo. La seguente tabella mette a confronto i flussi di lavoro prima e dopo la modifica:
| Area | Prima: revisione manuale e modelli di base | Dopo: Modern Web Guidance e Chrome DevTools per agenti |
|---|---|---|
| Attività di controllo del rendimento (Policybazaar) | Un ingegnere ha eseguito PageSpeed Insights, ha esaminato i Core Web Vitals e ha applicato manualmente le correzioni per ciascuna delle circa 30 pagine di destinazione. | 92% di sforzo manuale in meno. L'agente completa 12 audit nel tempo necessario a un ingegnere per completarne uno. |
| Copertura dell'audit (Policybazaar) | La copertura del controllo tra le varianti della campagna non era coerente. | Copertura del 100% dei test sul rendimento per le pagine delle campagne. |
| Nuovo turnaround dello schermo (Pensionbazaar) | Pochi giorni dal codice alla schermata di verifica. | Poche ore, con un aumento della velocità di oltre il 90%. |
| Bug di parità di progettazione (Pensionbazaar) | UI tagliata e variazioni del layout hanno raggiunto il QA manuale. | I bug della UI sono diminuiti di oltre il 90%. |
La riduzione del 92% ha superato l'obiettivo del team di oltre l'80%. Le regressioni della pagina di destinazione vengono rilevate prima di raggiungere la gestione temporanea o il controllo qualità. Su Pensionbazaar, il codice arriva già controllato con screenshot per diverse aree visibili, il che riduce il viavai tra progettazione, ingegneria e QA.
Punti chiave per il tuo team
- Basare l'agente su indicazioni autorevoli. Le indicazioni selezionate, come Modern Web Guidance, tengono gli agenti lontani da pattern obsoleti e mantengono il codice entro i target di Baseline.
- Non consentire a un agente di contrassegnare un'attività di frontend come completata finché non ha controllato la pagina visualizzata. Chrome DevTools per agenti consente all'agente di ispezionare il layout, le aree visibili e le tracce delle prestazioni in un browser reale.
- Fornisci al loop criteri di uscita chiari. Imposta limiti di passaggi e condizioni esplicite di superamento e fallimento in modo che l'agente non entri in loop e non sprechi token.
- Inizia con pagine ad alta frequenza basate su modelli. I workflow a ciclo chiuso sono più efficaci quando la velocità di risposta è fondamentale.
- Esegui i controlli in un browser pulito. Utilizza
--isolatedin modo che le estensioni e i dati memorizzati nella cache non influiscano sui risultati o non espongano dati personali.