Que funcione no significa que esté bien hecho: la trampa del vibe coding

Llevo meses, por no decir años, leyendo sobre si la IA nos va a quitar el trabajo a los programadores. Cada semana aparece un artículo nuevo con una opinión radicalmente optimista o catastrofista, y la realidad, como casi siempre, está en algún punto intermedio. Estos días he leído dos artículos que representan bastante bien las dos caras de esta moneda, y me han dado ganas de escribir lo que pienso al respecto.

La inundación de software "adecuado"

El primer artículo, The Great Flood of Adequate Software, habla de lo que el autor llama "la inundación": la idea de que estamos entrando en una era donde cualquier persona puede construir herramientas de software en una tarde. Lo compara con el "horizonte cerámico" en arqueología, cuando los humanos descubrieron la cerámica y de repente todo el mundo hacía vasijas. El software está viviendo ese momento. Herramientas que antes necesitaban un equipo de 20 personas durante meses, ahora las construye una persona en un día con ayuda de una IA.

Y es verdad. Lo estoy viendo. Repo2Text, convertidores de formatos, automatizaciones de flujos de trabajo... pequeñas utilidades que resuelven problemas muy específicos, construidas en horas, publicadas como shareware. El modelo SaaS de cobrar 8,99€/mes por un editor de texto empieza a no tener sentido cuando generar algo equivalente cuesta una tarde y un café.

El lado oscuro: cuando el código funciona pero no está bien hecho

El segundo artículo tiene que ver con Moltbook. Para quien no lo conozca: Moltbook es una red social creada exclusivamente para agentes de IA. Algo así como Reddit, pero donde los que publican, comentan y votan no son personas sino bots autónomos. Fue creada a finales de enero de 2026 por Matt Schlicht mediante vibe coding y en cuestión de días se hizo viral: más de 1,5 millones de agentes registrados y más de un millón de visitantes humanos curiosos por ver qué hacían los bots entre ellos.

Hasta aquí, la historia parece fascinante. Pero el análisis de seguridad que publicó Wiz cuenta la otra cara. Schlicht presumía de haber construido Moltbook entera sin escribir una sola línea de código manualmente. El problema es que unos investigadores de seguridad descubrieron que la base de datos Supabase estaba completamente expuesta. La clave de API estaba en el JavaScript del frontend, algo que en Supabase es normal por diseño y no supone un riesgo si tienes configurado Row Level Security (RLS). Pero no lo tenían. Sin RLS, esa clave que debería ser inofensiva daba acceso total de lectura y escritura a toda la base de datos sin autenticación. El resultado: 1,5 millones de tokens de autenticación de agentes expuestos, más de 35.000 direcciones de email accesibles, mensajes privados al descubierto y la posibilidad de modificar cualquier contenido de la plataforma.

Lo peor no es que pasara. Lo peor es que el código funcionaba. La plataforma estaba online, los agentes publicaban, los usuarios se registraban. Todo iba bien... hasta que alguien miró por debajo del capó.

Y no fue solo un equipo el que lo descubrió. Tanto Wiz como el investigador Jameson O'Reilly encontraron la misma vulnerabilidad de forma independiente, simplemente navegando por la plataforma como usuarios normales. Cuando algo tan grave lo encuentran dos equipos por separado sin ni siquiera buscar activamente, el problema es bastante obvio.

No sabes lo que no sabes

Hay una frase clásica que aplica perfectamente aquí: no sabes lo que no sabes. Y la IA tampoco.

A menos que le especifiques exactamente qué quieres que haga, qué quieres que no haga, y por qué motivos, la IA te va a devolver una respuesta plausible. No necesariamente correcta, ni óptima, ni segura. Plausible. Algo que tiene buena pinta, que compila, que devuelve lo que esperas en un test rápido. Pero que puede esconder problemas graves que ni tú ni la IA habéis contemplado, simplemente porque nadie se lo ha preguntado.

Lo vivo en primera persona constantemente. Me encuentro con código generado por IA que es directamente para tirar a la basura. Le tengo que explicar cómo quiero que lo haga, cómo quiero que no lo haga, por qué motivos, qué patrones debe seguir, qué malas prácticas debe evitar... y aun así, necesito varias iteraciones para llegar a algo aceptable. Y eso que yo sé qué preguntar. Sé detectar cuándo lo que me devuelve tiene problemas porque llevo más de 15 años en esto. El que no tiene esa experiencia, ¿cómo va a saber que el código que le ha generado la IA tiene una inyección SQL, una caché mal configurada o un endpoint expuesto?

Esa es la trampa del vibe coding: si no sabes lo suficiente para cuestionar lo que genera la IA, no vas a saber que hay un problema hasta que explote.

El matiz que falta en el debate

Cuando hablamos de si la IA sustituye a los programadores, estamos metiendo en el mismo saco cosas muy distintas.

Para tareas de frontend donde estamos hablando de HTML y CSS, de cambiar colores, ajustar layouts, maquetar componentes... sí, la IA lo hace cada vez mejor. Son cosas que se testean de forma muy visual, donde el resultado correcto es evidente: o se ve bien o no se ve bien. No implican problemas de seguridad ni de rendimiento (siempre que hablemos de frontend puro, no de meter llamadas a APIs de base de datos en el cliente, que es exactamente lo que pasó con Moltbook). En ese terreno, la IA sustituye más que ayuda, y quien solo hacía eso debería estar aprendiendo cosas más complejas.

Pero para backend la cosa cambia radicalmente. Que un código funcione no significa que esté bien hecho. Un endpoint puede devolver los datos correctos y a la vez tener una inyección SQL esperando a ser explotada. Un sistema de caché puede funcionar perfectamente hasta que recibes tráfico real y descubres que cada petición invalida la caché entera. Una consulta a base de datos puede devolver resultados correctos y ser un desastre de rendimiento con datos reales.

Son cosas que la IA no detecta por sí sola porque no entiende el contexto completo: el entorno de producción, las posibles amenazas, los patrones de tráfico, la arquitectura global del sistema. La IA genera código que resuelve el problema inmediato, pero las malas prácticas de seguridad, rendimiento y escalabilidad requieren experiencia y criterio humano para detectarlas.

De programadores a arquitectos

La IA no nos sustituye. Nos obliga a pensar de otra forma y a trabajar de otra forma. Los programadores estamos pasando a ser más arquitectos, más directores de orquesta. La IA amplifica y potencia lo que ya sabemos hacer bien, pero necesita a alguien al volante que sepa hacia dónde ir.

Esto es especialmente relevante donde la calidad de lo que se entrega importa, donde hay que dar la cara ante un cliente y asumir una responsabilidad. Si subes cosas a producción que provocan caídas, problemas de rendimiento, vulnerabilidades de seguridad o funcionalidades que fallan, la culpa no es de la IA. La culpa es de la persona o de la empresa que está utilizando la inteligencia artificial sin los controles de calidad necesarios. Si no tienes un estándar mínimo en la entrega de tu producto o servicio, el problema eres tú.

Y esto tiene implicaciones muy reales: si un cliente te denuncia por una brecha de seguridad, te denuncia a ti como empresa. No puedes denunciar a ChatGPT, ni a Claude, ni a Copilot. La responsabilidad es tuya. La IA es una herramienta, y como toda herramienta, la responsabilidad de lo que haces con ella recae en quien la usa.

Dónde encaja la IA en el trabajo de backend

Para mí, después de más de una década trabajando en desarrollo de software y en concreto con Drupal, la IA es un ayudante brutal. Me ahorra tiempo en tareas repetitivas, me genera scaffolding, me ayuda a explorar soluciones. Pero siempre reviso lo que genera. Siempre.

¿Para un MVP interno en un entorno controlado? Puede tener sentido usar código generado por IA con una revisión ligera. ¿Para un SaaS en producción con usuarios reales y gente malintencionada intentando entrar? Publicar código generado por IA sin revisión, sin saber si tiene problemas de seguridad o de rendimiento, es una irresponsabilidad.

El caso de Moltbook no es una anécdota. Es un ejemplo de hacia dónde estamos tendiendo. Hay gente que no entiende que no te puedes fiar del código que ha generado la IA. Que funcione no significa que esté bien. Y esa diferencia entre "funciona" y "está bien hecho" es exactamente donde seguimos siendo necesarios los que llevamos años peleándonos con backends, con cachés, con seguridad, con rendimiento bajo carga.

El futuro que veo

El software "adecuado" va a inundar el mercado, sí. Vamos a tener miles de herramientas pequeñas que hacen una cosa de forma aceptable. Y para muchos casos de uso, será suficiente.

Pero los proyectos que manejan datos reales de usuarios, que necesitan escalar, que están expuestos a internet, que tienen requisitos de seguridad y cumplimiento normativo... esos van a seguir necesitando profesionales que entiendan lo que hay por debajo. La IA no nos quita el trabajo a los que hacemos backend complejo. Nos cambia el rol. Nos hace más productivos, nos obliga a ser mejores arquitectos, pero el criterio, la experiencia y la capacidad de distinguir entre código que funciona y código que está bien hecho siguen siendo nuestros.

La inundación viene. Pero no todo el mundo sabe nadar.