Cada vez más gente construye su web o su app con IA: le describes lo que quieres a Claude Code, Lovable o Cursor, y en horas tienes algo funcionando. A esto se le llama vibe coding.
El problema no es que la IA no sepa programar. El problema es publicar eso sin que nadie lo revise de verdad. En octubre de 2025, la empresa de seguridad Escape.tech escaneó 5.600 aplicaciones vibe-coded públicas y encontró más de 2.000 vulnerabilidades de alto impacto, más de 400 secretos expuestos (claves de API, tokens de acceso) y 175 casos de datos personales visibles, incluidos historiales médicos y números de cuenta bancaria.
Ese es el trabajo que hace un QA: no escribir el código, sino comprobar que lo que ya existe funciona y no expone nada que no debería. Esta es la checklist que seguimos en 17lab antes de publicar cualquier página nueva, aplicada a una web hecha con IA.
Vulnerabilidades de alto impacto encontradas en 5.600 aplicaciones vibe-coded públicas, con datos personales y credenciales expuestas en cientos de casos.
Escape.tech, "The State of Security of Vibe Coded Apps" (octubre 2025)
Por qué el código hecho con IA necesita más revisión, no menos
Es tentador pensar que si la IA escribe el código, la IA también se encarga de que esté bien. No es así, y hay datos que lo confirman más allá de la seguridad.
GitClear analizó 153 millones de líneas de código en su informe de 2026 sobre calidad de código con asistencia de IA: en los repositorios con uso intensivo de herramientas de IA, el "code churn" (código que se reescribe o se borra poco después de haberse creado) se ha duplicado aproximadamente frente a los niveles previos. Es la señal de que se genera más código del que realmente se termina revisando y afinando.
A esto se suma otro dato de GitGuardian: en su informe "State of Secrets Sprawl 2026" (marzo de 2026), los commits asistidos por IA filtran secretos (claves, contraseñas) en el 3,2% de los casos, frente al 1,5% en commits solo humanos. Más del doble.
Nada de esto significa que construir con IA sea mala idea. Significa que el paso que antes hacía un compañero revisando el código, ahora tienes que hacerlo tú, con otra mirada: la de alguien que prueba el resultado, no la de alguien que lo escribió.
Checklist de funcionalidad: los flujos que hay que probar a mano
Antes de mirar nada técnico, prueba la web como la va a usar alguien real. La IA prueba lo que le pides explícitamente, no lo que das por hecho.
- El flujo completo de principio a fin. Regístrate, inicia sesión, rellena el formulario, paga si hay pago. No lo hagas a medias: termina cada flujo tal y como lo haría un cliente.
- Los formularios con datos raros. Un campo de email sin arroba, un nombre con tilde o ñ, un número de teléfono con espacios. Si el formulario no avisa del error con un mensaje claro, es un fallo.
- Los campos vacíos y los límites. Envía el formulario sin rellenar nada, o con un texto larguísimo en un campo pensado para pocas palabras.
- Cerrar sesión y volver a entrar. Comprueba que la sesión se mantiene o se cierra donde toca, y que no puedes acceder a una página privada después de haber cerrado sesión pulsando "atrás" en el navegador.
- Los enlaces rotos. Revisa cada botón y cada enlace del menú, no solo los que usaste tú al construir la web.
En dos páginas de contenido de pago de nuestro propio sitio encontramos que el contenido gated solo tenía un overlay visual encima, pero el HTML completo se enviaba igual al navegador. Cualquiera podía ver el contenido pagado con "Ver código fuente", sin haber pagado ni iniciado sesión. La IA había construido el overlay perfecto, pero nadie había probado a mirar el código fuente antes de nosotros.
Seguridad: lo que un QA revisa que la IA no te dice
Aquí es donde más duele publicar sin testear, y donde los datos de Escape.tech y GitGuardian son más claros: secretos expuestos y datos accesibles sin permiso son los fallos más repetidos en aplicaciones hechas con IA.
No hace falta ser desarrollador para hacer estas tres comprobaciones:
| Qué comprobar | Cómo hacerlo sin saber programar |
|---|---|
| Contenido de pago visible sin pagar | Clic derecho → "Ver código fuente" en la página, antes de iniciar sesión. Busca el texto del contenido pagado. |
| Claves o contraseñas expuestas | En ese mismo código fuente, busca palabras como "key", "secret" o "password" seguidas de un valor real, no una referencia. |
| Acceso a datos de otro usuario | Con dos cuentas de prueba, comprueba que cambiar un número o un identificador en la URL no te lleva a los datos de la otra cuenta. |
Si construyes con Claude Code o una herramienta similar, pide explícitamente que revise estos tres puntos antes de publicar. La diferencia entre pedir "hazme una web de reservas" y pedir "hazme una web de reservas y verifica que ningún usuario puede ver ni editar las reservas de otro" es, muchas veces, la diferencia entre estar en la estadística de Escape.tech o no estarlo.
Cómo probar en móvil de verdad (no solo el build)
Un build o una vista previa en el ordenador no reproduce cómo se ve la web en una pantalla pequeña. Ejecutar el proyecto y que no dé errores solo confirma que el código compila, no que el diseño funcione.
Un usuario nos reportó que varios artículos eran ilegibles en móvil. El build no había mostrado ningún error: el problema era que una tabla sin contenedor con scroll horizontal se cortaba de forma invisible, porque el body del sitio oculta cualquier desbordamiento. En el ordenador no se notaba nada raro. Solo se veía abriendo la página en un móvil real, a un ancho de pantalla de verdad.
- Abre la web en un móvil real, no solo en el inspector de dispositivos del navegador (que ayuda, pero no sustituye a un dispositivo real con conexión real).
- Prueba a 375-430px de ancho, el rango de las pantallas más pequeñas. Si algo se ve bien en un iPhone grande pero mal en uno pequeño, lo vas a perder igual.
- Revisa cualquier tabla, bloque de código o elemento ancho. Si no tiene scroll horizontal propio, puede cortar contenido sin avisar o desbordar toda la página.
- Comprueba los botones con el pulgar, no con el ratón. Un botón que funciona bien con un clic preciso puede ser demasiado pequeño para pulsarlo con el dedo.
Antes de pulsar publicar
- Confías en que "si compila, funciona"
- Solo probaste en tu propio ordenador
- Nadie miró el código fuente ni las URLs
- Descubres los fallos cuando los reporta un usuario
- Probaste cada flujo de principio a fin
- Revisaste móvil en un dispositivo real
- Verificaste código fuente, claves y permisos
- Los fallos los encuentras tú, antes que nadie más
Nada de esto convierte una tarde de vibe coding en un proceso de QA profesional completo. Pero sí es la diferencia entre publicar a ciegas y publicar habiendo mirado, al menos una vez, con los ojos de alguien que busca lo que puede fallar.
Si te ha pasado por la cabeza aprender esto en profundidad, así es exactamente como piensa un QA profesional cuando recibe una funcionalidad nueva para revisar, sea de un compañero o de una IA.
Preguntas frecuentes
¿Necesito saber programar para testear mi web hecha con IA?
No. La mayoría de las pruebas de esta checklist (funcionalidad, formularios, móvil, casos límite) se hacen usando la web como cualquier usuario, sin tocar código. Solo la parte de seguridad se beneficia de conocimientos técnicos básicos, y aun así puedes pedirle a la propia IA que revise puntos concretos como credenciales expuestas o reglas de acceso a la base de datos.
¿Qué es el vibe coding y por qué necesita más QA, no menos?
Vibe coding es construir una aplicación describiéndole a una IA lo que quieres en lenguaje natural, sin escribir el código a mano. El riesgo no es que la IA escriba mal una función suelta, es que nadie revisa el conjunto: la IA no sabe qué flujos son críticos para tu negocio ni qué datos son sensibles. Eso lo decide un humano con criterio de QA.
¿Cómo pruebo la seguridad de mi web si no soy desarrollador?
Empieza por lo básico y accionable: comprueba que el contenido de pago no es visible viendo el código fuente de la página antes de iniciar sesión, que ninguna clave secreta aparece en ese código fuente, y que un usuario sin permisos no puede acceder a datos de otro simplemente cambiando la URL. Estas tres pruebas manuales detectan buena parte de los fallos más comunes.
¿Es suficiente con revisar la web en el ordenador?
No. Un build o una vista previa en el navegador del ordenador no reproduce cómo se comporta el CSS en una pantalla de móvil real. Hay fallos que solo aparecen a 375-430px de ancho, como contenido cortado sin scroll o tablas ilegibles. Hay que abrir la web en un móvil de verdad o en el inspector de dispositivos del navegador antes de publicar.
¿Cuánto tiempo debería dedicar a testear antes de publicar?
Para una web pequeña con formularios y pagos, entre 1 y 3 horas de pruebas manuales siguiendo un checklist como este ya detecta la mayoría de los problemas graves. No es tiempo perdido: es mucho menos que el tiempo que cuesta arreglar una fuga de datos después de publicar.
¿Dónde aprendo a hacer estas pruebas paso a paso?
El curso De cero a web profesional con Claude Code de 17lab enseña a construir una web completa (dominio, base de datos, login y pagos) con el mismo criterio de revisión que se explica aquí. Si además quieres aprender testing como disciplina completa, el curso QA desde cero cubre casos de prueba, bugs y las técnicas que hay detrás de este checklist.
¿Quieres entrar al sector?
Aprende QA desde cero, con formación práctica y orientada al mercado español.