IA en el desarrollo web: cómo trabajar con asistentes de código sin perder calidad

Hace un par de semanas, alguien que estaba montando su propia tienda online me enseñó una web que había levantado en una tarde con un asistente de IA. Tenía buena pinta: cabecera, catálogo, carrito y hasta un formulario de contacto. Al abrir las herramientas del navegador aparecieron los matices: imágenes de tres megas, botones que eran div con un clic encima, un formulario que solo validaba en el navegador y una clave de API visible en el código. Nada de eso se veía en la demo. Todo eso importa el día que la web tiene clientes de verdad.

En el estudio usamos asistentes de código a diario y nos encantan. Escriben rápido, conocen casi cualquier librería y se ocupan con gusto de lo tedioso. Lo que hemos aprendido es que la velocidad es la parte fácil. La calidad sale de cómo se encarga el trabajo, de cómo se revisa y de qué pruebas tiene que pasar antes de publicarse. Esta guía cuenta ese flujo, paso a paso, para que puedas aplicarlo tanto si programas como si diriges un proyecto web y quieres saber qué preguntar.

01Qué hacen bien los asistentes de código (y qué les falta)

Conviene empezar separando dos tipos de herramienta, porque se usan de forma distinta.

Los asistentes en el editor, como GitHub Copilot o Cursor, sugieren la siguiente línea, completan funciones o editan un archivo a partir de una instrucción. Son como un compañero sentado al lado que teclea muy rápido. Los agentes de código, como Claude Code, trabajan sobre el repositorio entero: leen varios archivos, proponen un plan, ejecutan comandos, lanzan las pruebas y entregan un conjunto de cambios. Se parecen más a encargarle una tarea completa a alguien del equipo.

En los dos casos brillan en lo mismo:

• →Maquetar componentes con patrones conocidos: una tarjeta, un acordeón, una tabla con paginación.
• →Escribir pruebas a partir de una función que ya existe, y casos límite que a una persona se le pasarían.
• →Traducir código entre versiones o frameworks, por ejemplo de clases a componentes funcionales.
• →Explicar código ajeno, algo que ayuda muchísimo cuando heredas un proyecto.
• →Redactar documentación, mensajes de commit y scripts de automatización.

Lo que les falta no es habilidad técnica, sino contexto. El asistente no sabe que tus clientes son en su mayoría personas mayores que navegan con el móvil, que la marca pide una animación contenida, que el formulario manda datos de salud o que el servidor del cliente tiene una versión concreta de PHP. Tampoco sabe qué es «suficientemente bueno» para tu proyecto. Ese criterio lo pone el equipo, y de él depende casi todo lo que viene después. Hablamos de esta idea con más calma en la guía sobre dirección creativa en la era de la IA, y en desarrollo se aplica igual.

02Especificar antes de pedir: el encargo decide el resultado

La diferencia entre un asistente que acierta y uno que inventa suele estar en la primera instrucción. «Hazme un formulario de contacto» da un formulario. «Hazme el formulario de contacto de esta web, con estos campos, estas reglas y este comportamiento» da tu formulario.

En nuestros proyectos, antes de abrir el asistente escribimos una especificación corta para cada pieza. No hace falta un documento largo; media página bien pensada rinde muchísimo más que diez intercambios de corrección. Un ejemplo real, simplificado:

Componente: formulario de solicitud de presupuesto
Stack: Next.js (App Router), TypeScript, server actions, sin librerías de formularios nuevas
Campos: nombre (obligatorio), email (obligatorio, validar formato), teléfono (opcional),
  tipo de proyecto (select: marca, web, espacio, otro), mensaje (obligatorio, 20-2000 caracteres)
Validación: en cliente para ayudar y en servidor siempre; mensajes de error junto al campo
Accesibilidad: label visible en cada campo, errores anunciados con aria-live, foco al primer error
Antispam: campo trampa oculto + límite de envíos por IP; nada de captcha visual
Privacidad: casilla de aceptación sin marcar, enlace a la política; no guardar IP más de 30 días
Éxito: mensaje en la misma página con el siguiente paso («te respondemos en 24 h laborables»)
Fuera de alcance: subida de archivos
Criterio de terminado: pasa las pruebas, sin errores de axe, funciona sin JavaScript

Fíjate en lo que hace esa especificación: fija el stack para que el asistente no instale lo primero que se le ocurra, separa lo obligatorio de lo opcional, marca la accesibilidad y la privacidad como requisitos y define cuándo está terminado. También dice qué no hay que hacer, algo que ahorra muchas sorpresas.

Darle contexto permanente al asistente

Casi todos los asistentes admiten un archivo de instrucciones en el repositorio que leen en cada tarea: convenciones de nombres, estructura de carpetas, comandos para lanzar pruebas, librerías permitidas. Merece la pena dedicarle una hora al principio del proyecto. Es la forma de que el asistente escriba «como lo escribiría el equipo» en vez de como lo escribiría un desconocido con prisa. En ese archivo nosotros incluimos también el tono de los textos de interfaz y los tokens de diseño, para que un botón nuevo nazca ya con el espaciado y el color correctos.

03Revisar como si lo hubiera escrito alguien nuevo

La regla que más calidad nos ha dado es sencilla: todo lo que genera un asistente se revisa como el código de una persona que acaba de incorporarse al equipo. Con cariño, con atención y línea a línea. El asistente es rapidísimo y muy capaz, pero no conoce la historia del proyecto ni asume la responsabilidad de lo que publica. Esa responsabilidad es nuestra.

En la práctica, eso significa trabajar con cambios pequeños. Un diff de cuarenta líneas se revisa de verdad; uno de cuatrocientas se aprueba con un vistazo. Le pedimos al asistente tareas acotadas, una por rama, y revisamos cada conjunto de cambios antes de mezclarlo.

Qué miramos en cada revisión

1. 01¿Hace lo que pedía la especificación, y solo eso? Los asistentes tienden a «mejorar» cosas que nadie pidió: renombrar variables, reorganizar un archivo, añadir una dependencia.
2. 02¿Las dependencias nuevas son necesarias y existen de verdad? De vez en cuando un modelo propone un paquete con un nombre plausible que no es el que crees, o una versión antigua. Comprobamos cada paquete en el registro oficial.
3. 03¿Se usan las APIs de la versión que tenemos instalada? Los frameworks cambian rápido y el asistente puede recordar una versión anterior. Contrastamos con la documentación de la versión del proyecto.
4. 04¿Dónde se valida cada dato? La validación en el navegador es una cortesía; la de verdad va en el servidor.
5. 05¿Hay secretos en el código? Claves, tokens o contraseñas van en variables de entorno, nunca en el repositorio.
6. 06¿El HTML es semántico? Botones que son button, enlaces que son a, encabezados en orden. Si quieres repasar por qué importa tanto, lo explicamos en HTML semántico.
7. 07¿Se entiende dentro de seis meses? Si para entender una función hay que leerla tres veces, se simplifica ahora.

04Las pruebas que protegen la calidad

La revisión humana capta lo que tiene que ver con criterio. Las pruebas automáticas captan lo repetible, y tienen una virtud enorme cuando trabajas con IA: no se cansan. Un asistente puede cambiar diez archivos en un minuto, y una batería de pruebas comprueba en otro minuto que nada se ha roto.

Nuestra base mínima para cualquier web, con o sin IA, tiene cuatro capas.

Aquí el asistente es un aliado estupendo: escribir pruebas es justo el tipo de tarea larga y metódica que hace bien. Lo que hacemos es escribir nosotros los casos importantes en lenguaje natural («si el email no tiene arroba, el formulario muestra el error junto al campo y no se envía») y dejar que el asistente los convierta en código. Después leemos las pruebas con atención, porque una prueba que siempre pasa no protege nada.

Accesibilidad: lo automático y lo que hay que mirar

Las herramientas automáticas como axe detectan una parte de los problemas de accesibilidad: contrastes insuficientes, imágenes sin texto alternativo, campos sin etiqueta. El resto exige probar con el teclado y con un lector de pantalla. Como referencia, las WCAG 2.2 piden un contraste mínimo de 4,5:1 para texto normal y un área táctil mínima de 24×24 píxeles CSS para los objetivos de clic. Un asistente cumple estas cifras si se las pides; si no se las pides, a veces sí y a veces no. Por eso van en la especificación y en las pruebas, y por eso alguien recorre cada formulario con el tabulador antes de publicar.

Rendimiento: medir con los mismos umbrales siempre

El código generado tiende a ser generoso: una librería entera para formatear una fecha, imágenes sin dimensiones, scripts de terceros cargados en la cabecera. Fijamos los umbrales de las Core Web Vitals que publica web.dev como criterio de terminado: LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. Si un cambio empeora alguno, se revisa antes de mezclarlo. La guía de JavaScript y rendimiento tiene más detalle sobre cómo aligerar lo que llega al navegador.

05Seguridad y privacidad cuando programas con IA

Hay dos conversaciones distintas aquí: la seguridad del código que se genera y la privacidad de lo que le cuentas al asistente.

En la primera, lo que funciona es tratar el código generado con la misma lista que usarías para cualquier proyecto. La referencia más extendida es el OWASP Top 10, que recoge los fallos más habituales en aplicaciones web: control de acceso roto, inyecciones, configuraciones inseguras, componentes vulnerables. Nosotros pedimos al asistente que justifique cómo trata cada entrada del usuario, activamos el análisis automático de dependencias del repositorio y revisamos a mano cualquier cambio que toque autenticación, pagos o datos personales. Para esos tres territorios la norma es que una persona escribe o reescribe el código con calma, aunque el asistente haya hecho el primer borrador.

En la segunda, conviene saber qué hace cada herramienta con lo que le envías. Las versiones de empresa de la mayoría de asistentes permiten desactivar el uso de tu código para entrenar modelos y fijan plazos de retención. Revisamos esas opciones al empezar un proyecto, y con clientes que manejan información sensible lo dejamos por escrito. Las claves y los datos reales de clientes se quedan fuera de las conversaciones con el asistente; para probar usamos datos ficticios.

06Un ejemplo resuelto: de la petición al despliegue

Para que se vea entero, este es el recorrido de una tarea típica en un proyecto reciente: añadir un selector de idioma a la web de un hotel pequeño de la Costa del Sol que ya tenía versiones en español e inglés.

1. 01Especificación (15 minutos). Escribimos qué tenía que hacer el selector: mostrar el idioma actual, enlazar a la versión equivalente de la página en el otro idioma (no a la portada), mantener los parámetros de reserva en la URL y funcionar con teclado. Añadimos que el texto de cada opción fuera el nombre del idioma en su propio idioma, «English» y «Español».
2. 02Plan del asistente (5 minutos). Le pedimos al agente que leyera la estructura de rutas y propusiera un plan antes de tocar nada. Propuso un componente nuevo y un cambio en la cabecera. Le corregimos un punto: quería guardar la preferencia en una cookie, y para este caso no hacía falta.
3. 03Implementación (10 minutos). El agente escribió el componente, sus pruebas y el cambio en la cabecera. Lanzó las pruebas y pasaron.
4. 04Revisión humana (20 minutos). Encontramos dos cosas: el componente usaba un div con evento de clic en lugar de un enlace, y en las páginas de habitaciones el enlace equivalente apuntaba a un slug que no existía en inglés. Lo primero se corrigió en un minuto; lo segundo destapó que faltaba una tabla de correspondencias entre slugs, algo que ninguna herramienta podía saber.
5. 05Pruebas de calidad (10 minutos). Recorrido con teclado, prueba con VoiceOver en el móvil, auditoría con axe y medición del rendimiento en la página de una habitación. Todo dentro de umbrales.
6. 06Despliegue. Mezcla en la rama principal y despliegue automático, con la posibilidad de volver atrás en un paso si algo fallaba.

Una hora de trabajo, aproximadamente. Sin el asistente habría llevado algo más, sobre todo en la parte de pruebas. Pero lo interesante es dónde estuvo el valor: en la especificación y en la revisión, que es justo donde la herramienta necesitaba a alguien que conociera el proyecto.

07Cómo encaja la IA en un equipo de desarrollo web

Cuando todo esto funciona, el reparto del tiempo cambia de forma muy agradable. Se dedica menos a teclear lo previsible y más a lo que el cliente nota: pensar el flujo de una reserva, pulir una microinteracción, revisar textos, probar en dispositivos reales, hablar con las personas que van a usar la web. El asistente se convierte en un multiplicador del criterio del equipo.

Algunas costumbres que nos ayudan a mantener ese equilibrio:

• →Una persona responsable por cada cambio. Quien lo encarga lo revisa y lo firma.
• →Ramas cortas y frecuentes. Muchas mezclas pequeñas en vez de una gigante a final de semana.
• →Documentar las decisiones, no solo el código. Un párrafo explicando por qué se eligió una solución ayuda a la siguiente persona y al siguiente asistente.
• →Aprender del asistente sin delegar el aprendizaje. Cuando propone algo que no conocemos, lo estudiamos antes de aceptarlo. Así el equipo crece con la herramienta.
• →Probar herramientas nuevas en proyectos internos. Los proyectos de clientes se hacen con flujos que ya conocemos bien.

Clave: el asistente escribe el código; el equipo decide qué código merece existir. Esa división del trabajo es la que mantiene la calidad cuando todo va más rápido.

08Para quien encarga una web: qué preguntar al estudio

Si no programas pero vas a encargar una web, no necesitas saber qué asistente usa tu proveedor. Te resulta mucho más útil saber cómo trabaja con él. Estas preguntas dan una idea bastante clara:

• →¿Quién revisa cada cambio antes de publicarlo?
• →¿Qué pruebas automáticas tiene el proyecto y cuándo se ejecutan?
• →¿Con qué umbrales de accesibilidad y rendimiento se da una página por terminada?
• →¿Mis datos y los de mis clientes se comparten con alguna herramienta externa? ¿Con qué condiciones?
• →¿El código es mío y lo recibo en un repositorio al que tengo acceso?
• →¿Cómo se mantiene la web cuando cambian las versiones del framework?

Las respuestas buenas son concretas: nombres de herramientas, cifras, personas. Si quieres repasar qué conviene revisar antes de dar una web por publicada, la checklist de SEO técnico es un buen complemento a estas preguntas.

En SIMA programamos con IA cada día, siempre con una persona del estudio al mando de cada decisión, y lo contamos con naturalidad en cada propuesta. Si estás pensando en una web o en una aplicación y quieres que la velocidad de estas herramientas juegue a tu favor sin renunciar a una calidad que se nota, en desarrollo web y apps con IA explicamos cómo trabajamos. Y si prefieres contárnoslo directamente, escríbenos y lo hablamos con calma.