El riesgo oculto del vibe coding: código que funciona pero no es seguro

Bob Starr quedó encantado con la web que acababa de crear. "Boomberg", un sitio que mostraba cuánto dinero público estadounidense termina en manos de las grandes tecnológicas, salió a internet en cuanto la terminó. El detalle: Starr no la había programado, se la había dictado a un modelo de lenguaje describiendo lo que quería. No fue hasta meses después de publicarla cuando se dio cuenta de que arrastraba un riesgo de inyección SQL oculto, una puerta abierta que llevaba todo ese tiempo sin que nadie la viera.

El caso abre un reportaje de The Verge sobre los riesgos de seguridad de las apps creadas con vibe coding, y resume bien el problema de fondo: cuando el código lo escribe un modelo y quien lo publica no sabe leerlo, los fallos no desaparecen, solo se vuelven invisibles para su autor.

Qué es exactamente el vibe coding

El término describe una forma de programar en la que el usuario explica en lenguaje natural lo que quiere y deja que un modelo genere el código. Funciona razonablemente bien para prototipos y herramientas internas, y ha bajado tanto la barrera de entrada que cualquiera con una idea puede tener algo funcionando en una tarde. Ese es justamente su atractivo y su trampa.

El problema no es que el código generado sea malo por definición. Es que el modelo optimiza por "que funcione" y por "que se parezca a lo que pediste", no por "que sea seguro en producción". Un prototipo que arranca a la primera puede llevar dentro credenciales en texto plano, endpoints sin autenticar o consultas a base de datos construidas concatenando texto, el patrón clásico que abre la puerta a la inyección SQL.

Por qué importa más ahora

Hace dos años, publicar una app implicaba pasar por alguien que al menos sabía leer el código. Hoy ese filtro ha desaparecido para una parte creciente de proyectos. The Verge apunta a que el volumen de sitios y herramientas levantados así crece rápido, y con él la superficie de ataque: bases de datos expuestas, formularios sin validar y claves de API que acaban en repositorios públicos.

La diferencia con un bug normal es la asimetría de conocimiento. Quien escribe código a mano y mete un fallo tiene, al menos, la posibilidad de entenderlo cuando se lo señalan. Quien delegó todo en un modelo a menudo no sabe ni dónde mirar. El sitio funciona, se ve bien, y el agujero solo aparece cuando alguien lo explota o, con suerte, cuando un tercero avisa.

Para quién es útil esto

Para cualquiera que esté montando productos con asistentes de código, y muy en particular para quien lo hace sin formación técnica previa. No es un argumento para volver a programarlo todo a mano. Es un recordatorio de que generar código y publicarlo son dos decisiones distintas, y que la segunda exige un mínimo de revisión.

Hay medidas básicas que cubren la mayoría de estos casos: pedir explícitamente al modelo consultas parametrizadas en lugar de concatenadas, mover cualquier credencial a variables de entorno, no subir nunca claves al repositorio y pasar un escáner de seguridad antes de exponer nada a internet. Herramientas como Claude Code permiten pedir directamente una revisión de seguridad del propio código generado, algo que conviene convertir en paso obligatorio y no en extra opcional.

Nada de esto es nuevo para quien lleva años en desarrollo. Lo nuevo es la cantidad de gente que ahora publica software sin haber pasado por esa curva. El vibe coding no ha inventado la inyección SQL, lleva décadas en la lista de fallos más comunes, pero sí ha multiplicado el número de personas capaces de introducirla sin enterarse.

En ElephantPink lo vemos a diario: los asistentes de código son una herramienta extraordinaria para ir rápido, y la velocidad no está reñida con la seguridad siempre que se trate el código generado con la misma desconfianza que cualquier otro. La regla práctica es sencilla: si no entiendes lo que vas a publicar, al menos pide que alguien, o algo, lo revise antes.