Publicado: 10 de noviembre de 2026
Policybazaar es una de las plataformas de seguros líderes de la India, con más de 97 millones de clientes registrados. Alrededor del 80% de sus clientes visitan el sitio web cada mes. Su empresa matriz, PB Fintech, lanzó recientemente Pensionbazaar, una plataforma de planificación de jubilación integral, que es una marca de Paisabazaar Marketing & Consulting Private Limited.
Ambos equipos ya usan agentes de programación, que escriben código con rapidez, pero no pueden ver lo que hace ese código en un navegador. Los agentes solían recurrir a patrones web obsoletos y no tenían forma de comprobar si una pantalla se renderizaba correctamente, por lo que los ingenieros aún tenían que verificar todo de forma manual.
Para resolver este problema, ambas empresas combinaron dos herramientas en su flujo de trabajo de agentes: Modern Web Guidance para enseñarles a los modelos los estándares web modernos y las Herramientas para desarrolladores de Chrome para agentes para darles a esos agentes un navegador sin interfaz gráfica en vivo para inspeccionar y verificar su trabajo.
Este es el impacto:
92%
Menos esfuerzo de auditoría manual en unas 30 páginas de destino de Policybazaar
>90%
Desarrollo y pruebas más rápidos para las nuevas páginas de Pensionbazaar, de alrededor de cuatro días a unas pocas horas
>90%
Se informaron menos errores de la IU en las nuevas pantallas de Pensionbazaar.
El desafío: Código rápido, verificación lenta
Policybazaar y Pensionbazaar se encontraron con dos cuellos de botella diferentes que los flujos de trabajo de programación de IA estándar no pudieron optimizar a nivel de producción.
Pensionbazaar: Pantallas nuevas con ciclos de QA largos
Pensionbazaar necesitaba decenas de pantallas nuevas y complejas, como la calculadora de varios pasos Retirement Freedom Score, las proyecciones de gastos de inversión personalizables y los informes de recomendaciones automatizados. El equipo las creó con agentes de programación y el servidor de MCP de Figma, pero dos problemas hicieron que los ciclos de QA fueran largos.
Primero, los agentes programaban a ciegas. Un modelo base podría generar código, pero no podría ver la interfaz renderizada, comparar los estilos calculados con las especificaciones de diseño, detectar cambios en el diseño ni leer una cascada de red. Por lo tanto, los problemas relacionados, como la IU recortada y los cambios de diseño, llegaron hasta el control de calidad manual.
En segundo lugar, el código generado estaba estancado en el pasado. Sin conocimiento de la
plataforma web moderna, los agentes recurrieron a soluciones alternativas obsoletas, escribieron modales de JavaScript
pesados en lugar de usar el elemento <dialog> integrado, agregaron
polyfills innecesarios y omitieron sugerencias de rendimiento como fetchpriority.
Policybazaar: 30 páginas de destino y una auditoría manual
El equipo de seguros de vida de Policybazaar administra alrededor de 30 páginas de destino para diferentes productos de seguros, y cada página puede tener variaciones para diferentes campañas de marketing. En conjunto, reciben entre 200,000 y 300,000 visitantes por día, y cada página recibe actualizaciones mensuales de diseño y lógica empresarial. El equipo debe mantener altas las puntuaciones de las métricas web esenciales y asegurarse de que cada variante siga siendo accesible y se renderice correctamente en todos los tamaños de pantalla.
Antes de la automatización, un ingeniero auditaba cada página de forma manual:
- Ejecuta PageSpeed Insights para recopilar datos de usuarios reales.
- Evalúa las puntuaciones y recomendaciones de Core Web Vitals.
- Inspecciona la compilación de desarrollo o de etapa de pruebas, diagnostica los problemas detrás de las puntuaciones y aplica correcciones de código.
El proceso era lento, repetitivo y no se podía escalar. Esto dejaba margen para optimizaciones omitidas, cobertura de auditoría inconsistente, regresiones de rendimiento no detectadas y lanzamientos retrasados.
Antes de cambiar su flujo de trabajo, los equipos establecieron tres objetivos: reducir el tiempo que los desarrolladores dedican a las auditorías de rendimiento en más de un 80% y, al mismo tiempo, hacer que la cobertura de la auditoría sea continua, acortar el tiempo de respuesta del control de calidad con informes verificados y reducir los errores de la IU que se producen porque una pantalla no coincide con sus esquemas de página.
La solución: Un bucle de código para verificar
Pensionbazaar cerró la brecha entre escribir código y verificarlo. El agente escribe el código, inicia una instancia de navegador limpia, audita la página de manera programática para verificar la paridad visual, la rotura del diseño, los errores de la consola y el rendimiento, y corrige los problemas que encuentra con una intervención humana mínima. Su agente obtiene el diseño de Figma MCP, por lo que puede comparar la página renderizada con lo que pretendían los diseñadores.
En el siguiente video, se muestra este bucle en acción. El agente lee los diseños de Figma para una pantalla nueva, la implementa y, luego, usa las Herramientas para desarrolladores de Chrome para agentes con el objetivo de inspeccionar la página renderizada y corregir las diferencias que encuentra.
Paso 1: Fundamenta el agente en los estándares web modernos
El equipo de Pensionbazaar quería que el código generado siguiera las prácticas recomendadas de la Web moderna, usara las funciones actuales de la plataforma y, al mismo tiempo, funcionara en navegadores más antiguos. Es tedioso verificarlo de forma manual, y los agentes no siempre están actualizados con la plataforma. Modern Web Guidance resuelve este problema. Es una habilidad de agente, escrita y mantenida por expertos web de Chrome y la comunidad web, que abarca más de 200 casos de uso. Orienta a los agentes hacia las APIs de plataformas web modernas y hacia las prácticas recomendadas de rendimiento y accesibilidad que se ajustan a tu objetivo de Baseline. Si no estableces un objetivo, se establece de forma predeterminada en Baseline Widely Available.
Después de que el agente extrae el contexto de los archivos de Figma, usa Modern Web Guidance mientras escribe el código. En el caso de Pensionbazaar, esto cambió el código de tres maneras:
- Los elementos nativos reemplazaron las soluciones alternativas de JavaScript. El agente usó el
elemento
<dialog>integrado y la API de Popover para los modales de detalles del plan, y CSS Grid y Flexbox para las tarjetas de resumen financiero. - El agente agregó sugerencias de rendimiento que los modelos base suelen omitir.
Esto incluyó
fetchpriority="high"en las imágenes de LCP principales,loading="lazy"en las tarjetas de planes que se encuentran en la mitad inferior de la página y un presupuesto de ejecución basado en el tiempo conscheduler.yield()para proteger la interacción con la siguiente pintura (INP). - Las funciones modernas no dañaron los navegadores más antiguos. Pensionbazaar admite
versiones anteriores de navegadores, que define en
Browserslist. El agente usó funciones como la pseudoclase CSS
:user-invalidyautoComplete="one-time-code"en el campo de contraseña de un solo uso (OTP). Los navegadores más antiguos las ignoran, y la funcionalidad principal sigue funcionando.
Los modelos base no estaban muy lejos. En cuanto al rendimiento, el equipo descubrió que estaban alineados en un 70% con las prácticas recomendadas. El propio informe del agente enumeró 12 reglas de Modern Web Guidance que cerraron la brecha restante. Cuatro ejemplos:
| Área | La brecha del modelo base | La regla de Modern Web Guidance |
|---|---|---|
| Carga de imágenes | Combinaciones contradictorias alucinadas, como vincular fetchpriority="high" con loading="lazy". |
Prohíbe explícitamente combinarlas y limita las imágenes de alta prioridad a una o dos por página. |
| Estabilidad del diseño | Se sugirió content-visibility: auto para mejorar el rendimiento, pero se omitió contain-intrinsic-size. |
Requiere vincular las dos propiedades para evitar cambios de diseño graves cuando se renderiza el contenido. |
| Ceder el subproceso principal | Se usó scheduler.yield() de forma genérica sin un patrón de fecha límite. |
Aplica un plazo estricto basado en el tiempo (performance.now() + 50) para proteger la métrica Interaction to Next Paint (INP). |
| Almacenamiento en caché de service workers | No se tuvieron en cuenta los envíos de formularios sin conexión. | Advierte al agente que los service workers no pueden almacenar en caché de forma nativa las solicitudes que no sean GET. |
Para Pensionbazaar, nuestra prioridad era crear código de calidad desde el primer día para evitar la deuda técnica más adelante. Modern Web Guidance guió a nuestro agente de programación para que adoptara estándares web modernos y prácticas recomendadas de rendimiento, a la vez que respetaba nuestros objetivos específicos de compatibilidad con navegadores. Esto hizo que nuestras revisiones de código de frontend fueran mucho más fáciles y rápidas, lo que, en última instancia, mejoró nuestro tiempo de respuesta de desarrollo.
Aman Soni, gerente de Ingeniería de Policybazaar
Paso 2: Dale un navegador al agente
Las Herramientas para desarrolladores de Chrome para agentes son un conjunto de herramientas, incluidos un servidor de MCP, una CLI y habilidades de agentes, que les brindan a los agentes de programación acceso en tiempo real a los datos de depuración del entorno de ejecución, como los registros de la consola, el tráfico de red, el árbol de accesibilidad y otras funciones de las Herramientas para desarrolladores.
El equipo instaló las Herramientas para desarrolladores de Chrome para agentes como un complemento en su agente de programación, 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
El equipo quería que cada prueba se ejecutara en una instancia limpia del navegador, de modo que las extensiones de Chrome instaladas no pudieran afectar los resultados y no se filtraran datos personales o sensibles. Para obtenerlo, agrega
--isolated al array args
en la configuración del servidor de MCP:
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
Si tus pruebas necesitan una sesión de navegador existente con acceso, usa
--autoConnect.
Paso 3: Permite que el agente verifique y corrija su propio trabajo
El equipo de ingeniería enumera las verificaciones en las instrucciones del agente, ya sea como una instrucción o como una habilidad del agente. En un nivel alto, el agente hace lo siguiente:
- Inspecciona el árbol del DOM y el CSS calculado, y los compara con el diseño de Figma.
- Cambia el tamaño de la página a los viewports para dispositivos móviles para probar la responsividad.
- Registra seguimientos de rendimiento para encontrar fotogramas de animación largos (LoAF) causados por secuencias de comandos, recursos que bloquean la renderización y otros problemas de rendimiento.
- Vuelve a escribir el código para corregir las discrepancias de diseño, los problemas de rendimiento y las excepciones de la consola antes de que un ingeniero lo revise.
En la siguiente tabla, se muestra qué herramientas de Herramientas para desarrolladores de Chrome para agentes admiten cada verificación:
| Cheque | Herramientas |
|---|---|
| Prueba la responsividad en diferentes viewports | resize_page cambia el tamaño de la ventana de la página a dimensiones explícitas. emulate emula entornos de dispositivos específicos. take_screenshot captura el resultado. |
| Compara el DOM y el CSS calculado con el diseño de Figma | take_snapshot devuelve una instantánea de texto de la página según el árbol de accesibilidad. get_css_styles lee las reglas de CSS aplicadas. evaluate_script ejecuta una función de JavaScript dentro de la página. |
| Encuentra problemas de LoAF, recursos que bloquean el renderizado y Core Web Vitals | click y drag emulan interacciones. performance_start_trace y performance_stop_trace graban un registro de rendimiento. performance_analyze_insight devuelve diagnósticos detallados para las estadísticas del seguimiento. list_network_requests y get_network_request muestran la actividad de red. lighthouse_audit audita áreas que no son de rendimiento, como el SEO y la accesibilidad. |
Cuando el agente encuentra un problema, como texto cortado en pantallas pequeñas, un ajuste flexible roto o una imagen no optimizada que causa un cambio de diseño, ejecuta un bucle de corrección corto:
- Las Herramientas para desarrolladores de Chrome para agentes capturan el error exacto.
- El agente analiza los datos y vuelve a escribir el CSS o JavaScript problemático.
- El agente vuelve a cargar la página para confirmar la corrección.
En una pantalla, el agente renderizó la página y descubrió que el diseño del encabezado,
el espaciado y el gradiente no coincidían con el diseño. Se corrigieron los archivos .scss pertinentes. También interactuó con la página, por ejemplo, expandiendo los acordeones para verificar que sus estados abiertos coincidieran con los diseños.
Paso 4: Entrega un informe verificado al equipo de QA
Cuando se completa la verificación, el agente entrega el código listo para producción junto con un informe de auditoría para el equipo de QA. El informe incluye la siguiente información:
- Una comparación visual con el diseño de Figma que destaca las diferencias de píxeles, creada a partir de capturas de pantalla, instantáneas del DOM y estilos calculados.
- Capturas de pantalla de la página renderizada en diferentes tamaños de pantalla
- Diagnósticos de rendimiento y de Core Web Vitals de
performance_start_traceyperformance_analyze_insight, como Speed Index y Total Blocking Time (TBT). - Puntuaciones de Lighthouse para SEO, prácticas recomendadas y accesibilidad de
lighthouse_audit. - Verificaciones de aprobación o falla para interacciones, como contraer filas y activar o desactivar opciones, además de errores de la consola y cambios de estado de la aplicación, como editar filas, borrar filas y estados vacíos.
Aplica el mismo enfoque a 30 páginas de campañas
En su plataforma principal, Policybazaar reemplazó las ejecuciones manuales de PageSpeed Insights por auditorías ejecutadas a través de las Herramientas para desarrolladores de Chrome para agentes en Kiro. Antes de que se publique una página de campaña, un ingeniero activa una auditoría en la URL de etapa de pruebas para dispositivos móviles y computadoras de escritorio. El agente ejecuta auditorías de rendimiento y de Lighthouse, y las Herramientas para desarrolladores de Chrome para agentes extraen automáticamente los datos de campo del Informe sobre la experiencia del usuario en Chrome (CrUX) del mundo real junto con los datos de laboratorio. Eso reemplazó por completo el paso de PageSpeed Insights.
Luego, el agente informa las puntuaciones de rendimiento, los cuellos de botella que encontró y una lista priorizada de mejoras para que un ingeniero las corrija. En una auditoría previa al lanzamiento, se marcaron las llamadas a la API no esenciales que se activaban una tras otra durante la carga de la página y competían con el trabajo de renderización esencial. El equipo solucionó el problema antes de que se publicara la página.
Ahora, el agente completa 12 auditorías de rendimiento en el tiempo que un ingeniero necesita para terminar una. Eso representa una reducción del 92% en el esfuerzo manual.
El rendimiento web es importante para que mantengamos una buena experiencia del usuario, pero auditar y evaluar de forma manual las cascadas y los seguimientos en decenas de páginas de destino era tedioso y un cuello de botella importante. Las Herramientas para desarrolladores de Chrome para agentes transformaron este proceso y redujeron el tiempo de auditoría de rendimiento de nuestros ingenieros en un 92%, lo que les dejó tiempo para enfocarse en tareas más complejas.
Aman Soni, gerente de Ingeniería de Policybazaar
Impacto
Modern Web Guidance y las Herramientas para desarrolladores de Chrome para agentes convirtieron las pruebas de frontend en Policybazaar y Pensionbazaar de un proceso manual y reactivo en uno automatizado y proactivo. En la siguiente tabla, se comparan los flujos de trabajo antes y después del cambio:
| Área | Antes: Revisión manual y modelos base | Después: Modern Web Guidance y Herramientas para desarrolladores de Chrome para agentes |
|---|---|---|
| Esfuerzo de auditoría de rendimiento (Policybazaar) | Un ingeniero ejecutó PageSpeed Insights, revisó las Core Web Vitals y aplicó correcciones de forma manual para cada una de las aproximadamente 30 páginas de destino. | Un 92% menos de esfuerzo manual El agente completa 12 auditorías en el tiempo que un ingeniero necesitaba para una. |
| Cobertura de auditoría (Policybazaar) | La cobertura de la auditoría en las variantes de la campaña no fue coherente. | Cobertura del 100% de las pruebas de rendimiento para las páginas de campañas |
| Nuevo tiempo de respuesta de la pantalla (Pensionbazaar) | Unos días desde el código hasta la pantalla verificada. | Unas pocas horas, más de un 90% más rápido. |
| Errores de paridad de diseño (Pensionbazaar) | La IU recortada y los cambios de diseño llegaron al control de calidad manual. | Se generaron más de un 90% menos de errores de IU. |
La reducción del 92% superó el objetivo del equipo de más del 80%. Las regresiones de la página de destino se detectan antes de que lleguen a la etapa de pruebas o de control de calidad. En Pensionbazaar, el código llega ya auditado con capturas de pantalla para varios viewports, lo que reduce el ida y vuelta entre el diseño, la ingeniería y el control de calidad.
Conclusiones para tu equipo
- Fundamenta tu agente en orientación autorizada. La orientación seleccionada, como Modern Web Guidance, mantiene a los agentes alejados de los patrones obsoletos y mantiene tu código dentro de tus objetivos de Baseline.
- No permitas que un agente marque una tarea de frontend como completada hasta que haya verificado la página renderizada. Las Herramientas para desarrolladores de Chrome para agentes permiten que el agente inspeccione el diseño, los viewports y los seguimientos de rendimiento en un navegador real.
- Proporciona criterios de salida claros para el bucle. Establece límites de pasos y condiciones explícitas de aprobación y reprobación para que el agente no entre en un bucle y desperdicie tokens.
- Comienza con páginas de alta frecuencia basadas en plantillas. Los flujos de trabajo de ciclo cerrado son más rentables cuando la velocidad es importante.
- Ejecuta auditorías en un navegador limpio. Usa
--isolatedpara que las extensiones y los datos almacenados en caché no afecten los resultados ni expongan datos personales.