Sitio bonito, seguridad de papel: el riesgo del vibe coding sin criterio

Imagina la escena. Alguien abre su laptop para mostrarte el sistema que acaba de construir. La interfaz es bonita, los gráficos se deslizan y el botón tiene una animación muy cuidada. Ya hay hasta una página de planes. Tú preguntas:

— ¡Qué bonito sitio! ¿Qué tecnología usaste?

— Claude Code.

La respuesta llega con ese entusiasmo de quien acaba de descubrir el fuego. Y lo entiendo. Convertir una idea en algo que funciona da una satisfacción enorme. Ver que eso ocurre con ayuda de la IA puede hacerte sentir que una puerta, antes cerrada, por fin se abrió.

Pero la conversación continúa. ¿Dónde se guardan los datos? ¿Quién puede acceder a ellos? ¿Cómo se almacena una contraseña? ¿Qué impide que un cliente consulte la información de otro?

Silencio.

Quiero hablar de ese espacio entre «logré hacerlo» y «estoy preparado para entregarlo». En 2026, esta situación ha aparecido en las conversaciones y los proyectos a los que doy soporte. Es una percepción basada en mi experiencia, no una estadística sobre todas las personas que usan IA.

«Claude Code» todavía deja muchas preguntas sin responder

La documentación de Anthropic presenta Claude Code como una herramienta de programación con IA capaz de leer proyectos, editar archivos y ejecutar comandos. Por lo tanto, decir que lo utilizaste cuenta una parte del proceso de construcción. Todavía falta explicar el sistema que produjiste. Fuente: Anthropic.

Es más o menos como preguntar de qué material está construida una casa y escuchar: «Usé un destornillador eléctrico excelente». Una gran herramienta. Ahora conversemos sobre la estructura.

Puedes haber creado una aplicación en PHP con Laravel, una interfaz en React, un servicio en Python o una página estática. Puedes usar una base de datos propia, un servicio administrado o ni siquiera necesitar almacenar datos. Cada decisión implica responsabilidades diferentes.

Nadie necesita memorizar una sopa de siglas para merecer un lugar en este campo. Pero, al ofrecer un producto a clientes, necesita poder explicar qué hace, dónde está la información y quién se encarga de su mantenimiento. Si todavía no puedes hacerlo, es un tema que debes aprender y revisar antes de la entrega.

La etiqueta vibe coder abarca experiencias muy diferentes. Aquí, mi crítica es concreta: entregar un sistema que maneja datos reales sin comprender ni verificar los controles que deberían protegerlos.

Cuando admin123 se convierte en credencial de administrador

Últimamente, al dar soporte a empresas, departamentos e instituciones, me encontré con una situación cuya lógica se puede resumir así:

si contraseña == "admin123":
    el usuario es administrador

Este fragmento es una representación simplificada del problema que relaté, no una reproducción de un sistema identificable. El punto era precisamente ese: la comparación con una contraseña fija funcionaba como la única validación para determinar quién era administrador.

Es fácil imaginar la presentación. La persona escribe la contraseña, se abre el panel y aparecen los botones. Todo parece funcionar. Solo que la prueba demostró que la puerta se abre con esa combinación. Todavía falta demostrar quién recibió la llave y qué puertas debería poder abrir esa persona.

Las credenciales incrustadas en el código tienen una clasificación conocida: CWE-798, en el catálogo de MITRE. Si una contraseña secreta está en el código enviado al navegador, quien recibe ese código puede recuperarla. Si está únicamente en el servidor, sigue siendo una credencial fija que requiere un tratamiento adecuado. Fuente: MITRE.

Cambiar admin123 por una frase larguísima, llena de símbolos, puede dejar intacta la lógica equivocada. La revisión debe abarcar la identidad del usuario, la asignación de privilegios y las operaciones protegidas. Poner una contraseña más larga en el mismo arreglo improvisado no lo convierte en arquitectura.

Guardar una contraseña exige algo más que un candadito en pantalla

Cuando alguien dice que «las contraseñas necesitan cifrado», conviene precisar el término. Para las contraseñas de inicio de sesión, la recomendación habitual es usar un hash específico para contraseñas, como Argon2id, con una configuración adecuada. El objetivo es comprobar la contraseña sin guardar su texto original para recuperarlo después. Fuente: OWASP.

Las directrices del NIST añaden salt y un factor de costo a este proceso: elementos que dificultan los intentos de adivinación cuando alguien obtiene los hashes. Eso no vuelve invencible una contraseña débil. HTTPS protege la comunicación; almacenar la contraseña de forma adecuada es otra responsabilidad. Fuente: NIST.

Para quienes están empezando, mi sugerencia es recurrir a los mecanismos de autenticación de frameworks y servicios consolidados, entendiendo su configuración. Inventar una protección porque «la IA dijo que es seguro» genera una deuda que quizá solo descubras cuando alguien venga a cobrarla.

Y tampoco vale pedirle al agente «agrega seguridad», recibir una respuesta tranquilizadora y dar por terminada la revisión. Alguien capaz de explicar qué cambió y verificar si realmente protege la operación debe comprobar el resultado.

El navegador no puede repartir las credenciales

La autenticación verifica la identidad. La autorización decide qué puede hacer esa identidad. OWASP recomienda verificar los permisos en cada solicitud, en una capa confiable, como un servidor, una puerta de enlace o una función serverless. La decisión no debe depender únicamente de verificaciones en el navegador. Fuente: OWASP.

Ocultar el botón «Eliminar cliente» ayuda a organizar la interfaz. La operación de eliminación también debe rechazar a quien no tenga permiso. Del mismo modo, iniciar sesión en tu propia cuenta no debería darte acceso a los registros de todos los demás clientes.

Piensa en un club: presentar una credencial en la recepción no autoriza automáticamente a abrir la caja, entrar al archivo y llevarse el televisor. Cada acceso tiene una regla.

En la presentación comercial, todos suelen seguir el recorrido esperado: entrar, registrar, guardar. Una revisión responsable también pregunta qué sucede cuando alguien intenta una acción que debería ser rechazada. Ahí, la belleza del panel deja de responder a la pregunta.

El archivo .env no adquirió poderes mágicos

Otro escenario merece atención: alguien aprende que debe guardar la configuración en un archivo .env, lo hace y considera resuelto el asunto. Solo que el despliegue quedó configurado de una forma que permite al servidor entregar ese archivo por internet.

El nombre del archivo no crea una barrera de acceso. Si contiene credenciales y se puede descargar, la organización de las carpetas no evitó la exposición.

La documentación de Laravel incluye una advertencia concreta: servir la aplicación desde la raíz del proyecto puede exponer configuraciones sensibles. La recomendación es dirigir el servidor a la estructura pública correcta. La misma guía recomienda desactivar el modo de depuración en producción. Fuente: Laravel.

Existe además otra situación: el archivo está protegido, pero un secreto termina incorporado al JavaScript que recibe el navegador. En Vite, por ejemplo, las variables con el prefijo VITE_ se exponen al código del cliente durante el build. La documentación advierte que no deben contener información sensible. Fuente: Vite.

Son dos caminos diferentes hacia una exposición. En ambos, necesitamos entender qué se está publicando. «Está en el .env» es el comienzo de la investigación, no una garantía de seguridad.

Tener o no tener un backend propio no resuelve la discusión

También debemos ser justos con la arquitectura. Una API puede existir sin interfaz visual. Un sitio estático puede cumplir perfectamente su función. Una aplicación puede usar servicios administrados para la autenticación y los datos sin mantener un backend propio.

Supabase, por ejemplo, documenta el acceso desde el frontend con una clave publicable, RLS —reglas que restringen el acceso a las filas de la base de datos— y políticas adecuadas. En cambio, las claves secretas y service_role, que pueden eludir esas restricciones, deben permanecer fuera del frontend. Fuente: Supabase.

Por lo tanto, encontrar una clave publicable en el navegador no demuestra, por sí solo, que exista una filtración. Y contratar un servicio conocido tampoco demuestra que sus permisos estén configurados correctamente.

La pregunta útil es muy directa: ¿dónde se aplica la regla de acceso y qué demuestra que funciona? Es posible responder con una arquitectura sencilla. Lo que no se puede hacer es sustituir la respuesta por «el agente lo armó así».

La confianza también debe pasar por una revisión

La investigación ayuda a observar este comportamiento con cuidado. En un estudio publicado en ACM CCS en 2023, 47 participantes resolvieron cinco tareas de programación relacionadas con la seguridad. El grupo asistido por IA produjo soluciones inseguras con mayor frecuencia en cuatro tareas y mostró más confianza en la seguridad del resultado. Estudio de Perry y colegas.

Fue un experimento controlado con un modelo antiguo, codex-davinci-002. No mide el Claude Code actual ni la proporción de aplicaciones inseguras en 2026.

Hay un contrapunto: otro estudio, presentado en USENIX Security en 2023, evaluó a 58 estudiantes en una tarea en C y encontró un impacto pequeño en la seguridad dentro de ese contexto. La herramienta, la tarea y la forma de uso importan. Estudio de Sandoval y colegas.

Mi interpretación es que debemos tratar la confianza como una hipótesis hasta tener evidencia. Terminar una conversación con la IA sintiéndote seguro no equivale a haber verificado el sistema.

La propia documentación de Claude Code atribuye al usuario la responsabilidad de revisar la seguridad del código y de los comandos propuestos. Las protecciones para operar el agente y la seguridad de la aplicación resultante son asuntos distintos. Fuente: Anthropic.

Cuando llegan los clientes, el juego cambia de escala

En Oombe, trabajo con integraciones de marketplaces. En los proyectos vinculados a la gestión pública, trabajo con servicios digitales destinados a personas reales. Esa experiencia hace que, al mirar una pantalla de registro, también piense en quienes dependerán de ella después de la demostración.

En un escenario de falla, un comerciante podría perder acceso a una operación importante. La información de un ciudadano podría quedar expuesta. Un equipo podría quedarse sin saber qué ocurrió ni cómo recuperar el servicio. Son ejemplos de consecuencias posibles, no relatos de incidentes en esos proyectos.

Quien está empezando quizá vea un formulario con cinco campos. Para quien lo completa, ahí pueden estar su nombre, teléfono, dirección e información que no debería circular por todas partes.

En Brasil, el artículo 46 de la LGPD establece medidas técnicas y administrativas para proteger los datos personales y dispone que se observen desde la concepción del producto o servicio. El tamaño de la operación exige evaluar el contexto; no autoriza a ignorar la protección. Fuente: LGPD.

La ANPD incluso ofrece una guía para agentes de tratamiento de pequeño tamaño, con orientaciones sobre control de acceso, copias de seguridad y actualización de sistemas. Hay caminos accesibles para empezar con responsabilidad. Fuente: ANPD.

Por eso me preocupa tanto escuchar «lo voy a publicar y después veo la seguridad». Cuando llegue ese «después», alguien ya puede haber confiado su información al producto.

Lo que pediría antes del primer cliente

Empezaría por una conversación concreta, acompañada de demostraciones. ¿La persona que hizo el sistema puede responder estas preguntas?

• ¿Qué se construyó? ¿Qué componentes existen, dónde se ejecutan y quién se encargará de mantenerlos?
• ¿Qué datos son necesarios? ¿Para qué se recopilan, dónde se guardan y quién puede acceder a ellos?
• ¿Cómo se limita el acceso? ¿Una cuenta común puede hacer algo reservado al administrador? ¿Un cliente puede acceder a los datos de otro?
• ¿Dónde están los secretos? ¿Qué es público por diseño y qué debe permanecer protegido, incluida la configuración del alojamiento?
• ¿Cómo se detectará y corregirá una falla? ¿Hay responsables, registros útiles y un procedimiento conocido para recuperar el servicio?

Estas preguntas son un punto de partida para la revisión, no un certificado. El nivel de verificación debe corresponder a lo que hace la aplicación y al impacto de una falla.

Mi recomendación para empezar es reducir el alcance. Haz un prototipo con datos ficticios, entiende una funcionalidad a la vez y pide una revisión antes de poner en juego información de terceros. Durante la validación, demuestra también que las operaciones prohibidas se rechazan. OWASP recomienda pruebas para la lógica de autorización. Referencia.

Si faltan conocimientos, incorpora a alguien con experiencia en esa etapa. Eso puede significar una revisión puntual, una colaboración o más tiempo de estudio. Buscar ayuda forma parte de hacerse cargo del proyecto.

Para quien contrata, vale la misma lógica: pide explicaciones y evidencias proporcionales al servicio. Un proveedor serio debe poder hablar de sus limitaciones sin responder a cada pregunta con un «confía en mí».

La cometa es hermosa. El escudo tiene que resistir

Cuando comenté sobre estos sistemas bonitos y frágiles, usé una imagen que todavía me parece perfecta: el Capitán América decide cambiar su escudo por una cometa de papel de seda. La cometa es maravillosa. Colorida, bien diseñada, ideal para la foto.

Hasta que alguien necesita usarla como escudo.

Así veo un panel muy cuidado que se apoya en permisos improvisados. El aspecto visual merece elogios. Pero la confianza del cliente también exige una estructura capaz de sostener lo prometido.

Si llegaste a la programación a través de la IA, te doy la bienvenida. Pregunta, experimenta y aprovecha esta puerta abierta. No necesitas avergonzarte de lo que todavía no sabes; necesitas reconocer cuándo ese desconocimiento exige estudiar o pedir ayuda antes de comprometerte con una entrega.

Y quienes llevan años programando también deben revisar su propio trabajo. Los años de carrera no eliminan los errores, así como una herramienta poderosa no elimina la necesidad de criterio.

Quiero ver a más personas creando soluciones útiles. También quiero que puedan explicar lo que construyeron, recibir una crítica técnica y cuidar de quienes van a usarlo.

La próxima vez que alguien me muestre un proyecto, seguiré empezando con un elogio sincero:

Qué bonito sitio. Ahora muéstrame cómo estás protegiendo a quienes van a usarlo.

---

Artículo de opinión técnica, basado en experiencia personal y en las fuentes primarias enlazadas a lo largo del texto. Documentación consultada el 22 de octubre de 2026. Los ejemplos se simplificaron para explicar los riesgos, sin identificar a clientes o instituciones.