Los 10 errores principales que comete la IA en el desarrollo web

Philip Walton

Publicado el 11 de noviembre de 2026

Esta semana, lanzamos la versión 1.0 de Modern Web Guidance, un conjunto de habilidades que incorporan experiencia en plataformas web, prácticas recomendadas y datos de compatibilidad con navegadores directamente en tus agentes de programación. Nuestro objetivo con Modern Web Guidance es ayudar a los desarrolladores que usan agentes de IA para programar a aprovechar al máximo la potencia y las capacidades de la plataforma web moderna y, en última instancia, mejorar las experiencias web de los usuarios.

Desde que presentamos nuestra versión preliminar anticipada de Modern Web Guidance en mayo, los agentes de programación han mejorado cada vez más y se han lanzado muchos modelos de frontera nuevos y sorprendentes. Una de las preguntas que más escuchamos es: ¿estos nuevos modelos de frontera ya no siguen las prácticas recomendadas para el desarrollo web?

Lamentablemente, la respuesta es "no", y lo sabemos porque lo probamos.

Cada guía de Modern Web Guidance define un conjunto de expectativas que deben cumplirse si se siguieron correctamente las prácticas recomendadas de la guía. Luego, nuestro paquete de evaluación prueba esas guías dándole la misma instrucción a un agente que se ejecuta con Modern Web Guidance instalado (el agente guiado) y a otro que se ejecuta sin Modern Web Guidance instalado (el agente no guiado). El resultado de ambas ejecuciones se compara con las expectativas definidas en la guía.

Cuando comparas las tasas de aprobación guiadas y no guiadas, puedes ver que los modelos de IA, incluso los modelos de frontera más recientes, no siguen de forma confiable las prácticas recomendadas de desarrollo web moderno por sí solos.

En promedio, los agentes de programación sin orientación aprueban solo alrededor del 50% de las verificaciones de nuestro paquete de evaluación, en comparación con alrededor del 90% cuando se usa Modern Web Guidance.

Puedes consultar nuestro panel de evaluación para ver la lista completa de las verificaciones específicas que ejecutamos para cada guía y la puntuación de cada modelo en ellas.

Sin embargo, para obtener una descripción general de alto nivel, en esta publicación se abordan 10 de las áreas más problemáticas en las que vemos que los modelos de IA se equivocan de forma constante, en disciplinas clave que los desarrolladores web tienen más probabilidades de encontrar en su trabajo diario, como la accesibilidad, la experiencia del usuario, el rendimiento y la seguridad.

1. Accesibilidad: Enfoque del teclado y administración de inert

Para las personas que navegan con un teclado o un lector de pantalla, el orden de enfoque predecible es lo que hace que las IU interactivas sean utilizables. Sin ella, el enfoque puede desviarse hacia contenido oculto en segundo plano o quedar atrapado en decenas de tabulaciones adicionales.

El enfoque y la administración de inert son algunas de las brechas de accesibilidad más grandes en nuestras evaluaciones y una de las áreas que más mejora con Modern Web Guidance. Estos son los errores más comunes:

• No mover el enfoque a las vistas recién abiertas y olvidar restablecerlo al elemento activador cuando se navega hacia atrás
• Confiar en trampas de pestañas de JavaScript manuales y aria-modal="true" en modales personalizados, en lugar de usar un modal <dialog> o marcar el contenido en segundo plano inert.
• Exponer cada elemento de una barra de herramientas o una cuadrícula direccional como una tabulación independiente en lugar de usar una sola tabulación con tabindex itinerante
• Crear contornos de :focus-visible personalizados que no tengan una relación de contraste de 3:1 con los fondos adyacentes

2. Accesibilidad: Compatibilidad con movimiento reducido

El movimiento inesperado de la página y las animaciones a gran escala no solo distraen, sino que, para los usuarios con trastornos vestibulares o sensibilidad al movimiento, pueden provocar mareos, náuseas o dolores de cabeza.

Los modelos de IA suelen recordar que deben verificar prefers-reduced-motion cuando agregan transiciones de CSS estándar o animaciones de fotogramas clave. Sin embargo, cuando usan funciones más nuevas, como el desplazamiento fluido, las transiciones de vistas o las animaciones controladas por el desplazamiento, suelen olvidarse de la reducción de movimiento o cometen errores cuando la implementan:

• Establecer scroll-behavior:smooth de forma global y sin condiciones en el elemento raíz
• Usa animaciones de CSS basadas en el desplazamiento sin una verificación de movimiento reducido.
• Quitar las duraciones de transition en los elementos del carrusel para habilitar el movimiento reducido durante el desplazamiento, pero olvidar quitar también las propiedades de transformación, lo que hace que los elementos cambien de tamaño mientras se desplazan.
• Aplicar un restablecimiento general de la duración de 0.01ms en *, *::before y *::after cuando el movimiento reducido está activo, lo que también elimina todas las transiciones esenciales sin movimiento (necesarias para comunicar los cambios de estado de la IU).
• Habilitar las transiciones de vistas entre documentos de forma incondicional y anular las animaciones de ::view-transition-* cuando el movimiento reducido está activo, en lugar de solo restringir la regla @view-transition detrás de una verificación de movimiento reducido.

3. Accesibilidad: Validación de formularios, sugerencias de formato y estados de autocompletado

Los formularios son un pilar de la mayoría de los recorridos críticos de los usuarios en la Web. Un pequeño problema en un formulario de confirmación de compra puede tener un gran impacto en los resultados finales de una empresa.

Cuando se crean formularios, los modelos de IA aciertan en muchos de los aspectos básicos. Sin embargo, suelen fallar en detalles pequeños, pero fundamentales, como los errores de validación, la ubicación adecuada de los marcadores de posición y las sugerencias de formato, y la integración correcta con los administradores de contraseñas y las funciones de autocompletado:

• Volver a implementar :user-invalid de CSS con la validación personalizada de blur de JavaScript, que suele marcar los campos required sin modificar en cuanto los usuarios los pasan con la tecla Tab.
• Permitir que aria-invalid se desincronice con errores visibles, ya sea configurando aria-invalid="true" de forma prematura en blur o aplicando diseño a :user-invalid en CSS sin sincronizar aria-invalid en JavaScript.
• Confiar en el texto de placeholder que desaparece para mostrar los formatos obligatorios (como MM/YY en una entrada de vencimiento de tarjeta) en lugar de renderizar una sugerencia persistente vinculada con aria-describedby.
• Colocar sugerencias de formato y reglas de contraseñas debajo del <input> (en lugar de arriba), donde pueden quedar ocultas por los teclados de dispositivos móviles y las ventanas emergentes de autocompletar justo cuando el usuario necesita leerlas.
• Destacar las entradas de :autofill cambiando solo el color del borde en lugar de vincular el color con un indicador que no sea de color y que no cambie el diseño (como un box-shadow insertado)

4. Experiencia del usuario: Gestos de deslizamiento y táctiles

Los agentes son buenos para implementar gestos táctiles con JavaScript imperativo y escribir su propia lógica de física personalizada. Estas implementaciones funcionan; sin embargo, las interacciones táctiles con tecnología de JavaScript rara vez se sienten tan fluidas como los usuarios esperan de sus contrapartes de aplicaciones nativas.

Muchas de estas interacciones se pueden implementar con CSS y APIs de desplazamiento nativas, lo que permite que el navegador ejecute la física de gestos fuera del subproceso principal. Sin embargo, en nuestras evaluaciones, los modelos de IA suelen pasar por alto estas características:

• Implementar gestos de deslizar para descartar o deslizar para revelar con objetos de escucha pointermove o touchmove en lugar de usar el ajuste de desplazamiento de CSS
• Omitir overscroll-behavior-x:none en las interfaces de deslizamiento de pestañas, lo que puede activar accidentalmente una navegación hacia atrás o hacia adelante del navegador durante un deslizamiento excesivo.
• Controlar los efectos de progreso del deslizamiento en el subproceso principal en las devoluciones de llamada de JavaScript en lugar de usar animaciones controladas por el desplazamiento
• No se admite correctamente el enfoque del teclado en los paneles de acción de deslizamiento basados en el desplazamiento.

5. Experiencia del usuario: Diálogos, ventanas emergentes y transiciones de la capa superior

En nuestras evaluaciones, los modelos suelen recurrir a soluciones alternativas imperativas de JavaScript cuando animan, descartan o contienen el desplazamiento alrededor de diálogos modales y ventanas emergentes.

En lugar de depender de las funciones modernas de HTML y CSS creadas para las superposiciones de la capa superior, los agentes suelen crear manualmente máquinas de estado de entrada y salida, hooks de historial y bloqueos de desplazamiento del cuerpo que son más difíciles de mantener y propensos a errores sutiles de la IU.

Cuando estas interacciones se realizan correctamente, pueden transformar una experiencia que se siente frágil en una experiencia refinada en la que los usuarios confían. Estos son los errores más comunes que vemos:

• Crear superposiciones de position:fixed personalizadas con controladores manuales de clics fuera de la superposición para el cierre rápido, en lugar de usar solo popover
• Crear animaciones de entrada y salida activando o desactivando las clases de transición de CSS y coordinando con los objetos de escucha requestAnimationFrame() y transitionend (con resguardos de setTimeout()), en lugar de hacerlo en CSS puro con @starting-style y transition-behavior
• Bloquear el desplazamiento de la página detrás de un modal abierto configurando overflow:hidden en <html> en lugar de usar un elemento <dialog> para contener el sobredesplazamiento
• Se agregaron objetos de escucha popstate para detectar gestos de retroceso de Android y cerrar modales abiertos, en lugar de usar la funcionalidad nativa de cierre con el botón Atrás de un elemento modal <dialog>.

6. Experiencia del usuario: Modo oscuro y controles adaptables al tema

Los usuarios habilitan el modo oscuro para reducir la fatiga visual y el resplandor, por lo que un destello blanco brillante en la carga de la página, los controles de formulario sin tema o un botón de activación que se desincroniza con la preferencia del SO perjudican de inmediato la experiencia.

Un botón de activación del modo oscuro puede parecer sencillo, pero los modelos sin guía en nuestras evaluaciones suelen pasar por alto detalles clave de la plataforma que se necesitan para que el cambio de tema y los controles de formularios nativos funcionen correctamente:

• Falta <meta name="color-scheme" content="light dark"> en <head>, lo que hace que los usuarios del modo oscuro vean un destello de lienzo blanco mientras se cargan las hojas de estilo externas.
• Aplicar diseño a temas oscuros o componentes con superficie oscura con colores personalizados sin configurar color-scheme, lo que deja las barras de desplazamiento nativas y los controles de formulario bloqueados en el modo claro
• Pasar por alto la función light-dark() de CSS cuando se definen tokens de color adaptables al tema que siguen automáticamente el color-scheme activo.
• Proporcionar solo un botón de activación binario de modo claro o modo oscuro que establezca una anulación explícita en localStorage sin opción para volver al valor predeterminado del SO
• Olvidar agregar un objeto de escucha de eventos storage, lo que deja otras pestañas abiertas sin sincronizar cuando el usuario cambia de tema.

7. Rendimiento: Capacidad de respuesta y fluidez del entorno de ejecución

Los usuarios pasan la mayor parte del tiempo en una página web después de que termina de cargarse, por lo que las interacciones lentas y las transiciones inestables pueden perjudicar la experiencia del usuario tanto como una carga inicial lenta.

En nuestras evaluaciones, los modelos suelen seguir las prácticas recomendadas clásicas de tiempo de carga que se promocionaron en herramientas como Lighthouse durante años, y suelen saber cómo descargar bucles pesados obvios en un Web Worker. En lo que constantemente tienen dificultades es en la capacidad de respuesta del subproceso principal, que es esencial para optimizar la INP: aislar el trabajo de diseño, programar tareas por prioridad y aprovechar las nuevas funciones de HTML y CSS que realizan el trabajo de renderización fuera del subproceso principal.

Por ejemplo, a menudo vemos que los agentes hacen lo siguiente:

• Crear colas de setTimeout() personalizadas para el trabajo en segundo plano o de baja prioridad en lugar de priorizar las tareas visibles para el usuario con scheduler.postTask() o aprovechar la continuación de tareas con scheduler.yield() cuando el navegador lo admita.
• Crear diseños complejos (como cuadrículas de datos densas) sin aplicar content-visibility:auto ni contain-intrinsic-size, lo que significa que las actualizaciones después de las interacciones del usuario activan un reflujo de página completa
• Ocultar las vistas de SPA inactivas con display:none (o eliminarlas) en lugar de usar content-visibility:hidden (vinculado con inert). Lo primero destruye el estado de renderización almacenado en caché, por lo que volver a cambiar activa el diseño y la pintura completos.
• Se detienen las animaciones <canvas> fuera de la pantalla y los bucles en segundo plano con devoluciones de llamada de Intersection Observer en lugar de vincular content-visibility:auto con el evento contentvisibilityautostatechange (cuando está disponible), lo que hace que se pierda el margen de renderización previa del navegador antes de que los elementos se desplacen a la vista.
• Crear sugerencias de IU de affordance de desplazamiento con objetos de escucha de eventos scroll que fuerzan cálculos de diseño continuos, en lugar de usar consultas de estado de desplazamiento de CSS cuando están disponibles (con resguardos de Intersection Observer)

8. Rendimiento: Cambios de diseño y parpadeo visual

Los cambios de diseño inesperados interrumpen el enfoque del lector y pueden hacer que los usuarios hagan clic en botones inesperados, a veces con consecuencias irreversibles.

Los modelos agregan de forma confiable los atributos width y height a los elementos <img> estándar para protegerse contra los cambios de diseño, pero se pierden de forma constante otras fuentes comunes de cambios de diseño y destellos previos a la pintura de los elementos <video>, los intercambios de fuentes web, las barras de herramientas de los navegadores para dispositivos móviles y los experimentos del cliente, todo lo cual puede afectar el CLS.

• Omitir los atributos explícitos width y height en los elementos <video> (de modo que los reproductores descargados se establezcan de forma predeterminada en 300×150 y cambien el diseño una vez que se carguen los metadatos) o aplicar diseño a los elementos de wrapper de medios en lugar de establecer aspect-ratio y object-fit directamente en los elementos de medios.
• Se vincularon fuentes web con fuentes de resguardo del sistema sin font-size-adjust, lo que hace que los párrafos y los encabezados se ajusten de forma visible cuando se intercambian las fuentes web.
• Dimensionar las secciones destacadas y los diseños de pantalla completa con unidades vh estáticas en lugar de unidades de viewport dinámicas o pequeñas (dvh, svh), lo que hace que el contenido salte a medida que las barras de herramientas del navegador para dispositivos móviles se expanden y se contraen.
• Ocultar contenido con fragmentos antiparpadeo heredados de opacity:0 o visibility:hidden y tiempos de espera de varios segundos para las pruebas A/B del cliente (lo que retrasa el LCP y deja elementos invisibles en los que se puede hacer clic), en lugar de usar secuencias de comandos con blocking="render" cuando estén disponibles
• Se activaron transiciones de vistas entre documentos antes de que se analizara el lenguaje de marcado crítico de la mitad superior de la página, en lugar de retener la primera renderización con rel="expect" y blocking="render", lo que provocó que los elementos analizados a medias aparecieran en medio de la transición.

9. Seguridad: Defensas contra XSS del DOM y limpieza de HTML

Una sola falla de secuencia de comandos entre sitios (XSS) permite que un atacante ejecute código arbitrario en los navegadores de tus usuarios, robe datos de sesión o realice acciones en su nombre. Por eso son tan importantes las defensas aplicadas por el navegador, como la limpieza segura de HTML, los tipos de confianza y las CSP estrictas.

Los modelos rara vez abordan estos problemas de seguridad de forma proactiva. Por ejemplo, en todas las tareas de nuestro conjunto de evaluación completo, los modelos no agregaron una política de seguridad del contenido (CSP) ni un encabezado de aislamiento de origen cruzado sin una instrucción explícita.

Incluso cuando las instrucciones solicitan seguridad directamente, los modelos sin guía siguen fallando en más de la mitad de nuestras verificaciones de seguridad, lo que genera resguardos personalizados frágiles o políticas incompletas. Esto se nota claramente cuando se defiende contra la XSS del DOM:

• Escribir limpiadores de listas de entidades permitidas de DOMParser personalizados, ya sea como un resguardo de setHTML() o dentro de una política de Trusted Types, en lugar de usar una biblioteca verificada como DOMPurify cuando no está disponible la limpieza nativa
• Empaquetar DOMPurify de forma inmediata en cada carga de página en lugar de usar setHTML() nativo cuando sea compatible y cargar DOMPurify de forma diferida solo como resguardo
• Registrar políticas de tipos de confianza de transferencia de (input) => input permisivas que perjudican la aplicación de medidas por incumplimiento de receptores
• Vincular Trusted Types en páginas estáticas con CSP de script-src 'self' de lista de entidades permitidas de host en lugar de bloquear las secuencias de comandos intercaladas con hashes SHA-256
• Omitir 'strict-dynamic' y 'report-sample' cuando se configuran políticas de seguridad del contenido de script-src basadas en nonce

10. Seguridad: Acceso con llave de acceso, reautenticación y ciclo de vida de las credenciales

Las llaves de acceso mejoran la seguridad de los usuarios y las conversiones de acceso para las empresas, pero implementarlas (incluso con la ayuda de agentes) es un desafío.

WebAuthn tiene APIs específicas de serialización, detección de capacidades y señalización que los modelos no guiados omiten casi por completo en nuestras evaluaciones. Si le pides a un modelo de IA que agregue el acceso con llaves de acceso, la administración o la reautenticación de nivel superior, suele escribir ayudantes de codificación de bytes manuales, omitir las verificaciones de capacidades en la IU de administración o dejar las credenciales sin sincronizar con los administradores de contraseñas:

• Crear manualmente asistentes de conversión de Base64URL atob() y btoa(), ya sea como la ruta principal o como código estándar de resguardo redundante, en lugar de depender de métodos de serialización integrados como parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() y credential.toJSON()
• Omitir PublicKeyCredential.signalUnknownCredential() durante el acceso cuando el servidor informa un ID de credencial desconocido, lo que deja llaves de acceso borradas o revocadas en los administradores de contraseñas de los usuarios.
• Se omitirá PublicKeyCredential.getClientCapabilities() antes de renderizar la IU de creación y administración de llaves de acceso.
• Omitir un AbortController y un AbortSignal cuando se inician solicitudes de reautenticación con llave de acceso de nivel superior
• Pasar la opción mediation:"immediate" de prueba de origen en lugar de uiMode:"immediate" para los cuadros de inicio de sesión optimizados.

Cierra estas brechas

Estas 10 áreas están lejos de ser una lista exhaustiva, y esperamos que las brechas de conocimiento específicas cambien con el tiempo. Los modelos se pondrán al día y la plataforma web seguirá evolucionando.

La buena noticia es que la Guía de la Web moderna aborda todas estas brechas y seguirá evolucionando junto con la plataforma.

Para comenzar a usar Modern Web Guidance, ejecuta el siguiente comando o búscalo en el mercado de complementos de tu agente:

npx modern-web-guidance@latest install

¿Has visto que los modelos se equivoquen en otras tareas de desarrollo web? Queremos conocer tu opinión. Abre un problema en el repositorio de GitHub de Modern Web Guidance o ayúdanos a cerrar esas brechas para otros desarrolladores contribuyendo al proyecto.