El timo de las apps hechas en 3 horas con IA: lo que pasa de verdad cuando el vibe coding llega a producción

La velocidad no es el problema. La ausencia de cimientos, sí

El vibe coding tiene una promesa muy concreta: describes lo que quieres, la IA escribe el código, tú tienes una app funcional antes de que se enfríe el café. Y esa promesa se cumple. El problema es lo que viene después.

Cuando le pides a Claude o a ChatGPT que genere una funcionalidad, la IA responde al prompt que tienes delante. No al sistema completo. No a los prompts anteriores. No a los usuarios que van a la app en producción. Responde a la frase que escribiste hace diez segundos.

El resultado, si vas prompt a prompt sin un esquema previo de arquitectura, es código espagueti: módulos que se solapan, lógica duplicada, dependencias implícitas que nadie documentó porque nadie las diseñó. Funciona en local. Pasa los tests manuales que tú mismo haces. Y en el momento en que llega tráfico real, empieza a romperse de formas que no anticipaste porque nunca pensaste en esas formas.

He visto esto de primera mano. Apps construidas en tres horas, lanzadas con orgullo, que se caen en producción porque no aguantan concurrencia. Porque no hay rate limiting. Porque la idempotencia, la propiedad que garantiza que ejecutar una operación dos veces produce el mismo resultado que ejecutarla una, no existe en ningún sitio del código.

Y eso último no es un detalle técnico menor. Es el agujero que permite que un descuento se aplique en bucle hasta dejar una cuenta a cero. O peor, en negativo.

Los casos reales que los gurús no mencionan en sus hilos de Twitter

No hace falta especular. Hay nombres, hay empresas y hay incidentes documentados.

Matt Schlicht lanzó Moltbook, una red social para agentes de IA, construida íntegramente con vibe coding sin escribir una sola línea de código manualmente. El concepto era interesante. La ejecución, un desastre de seguridad. En días, investigadores de Wiz encontraron la base de datos de producción completamente expuesta: decenas de miles de correos y mensajes privados accesibles sin autenticación. El bug se parcheó tras el aviso, pero el daño reputacional ya estaba hecho.

Bob Starr lanzó Boomberg, un sitio que mostraba impuestos destinados a tecnológicas. Sin ser programador, usó herramientas de vibe coding para construirlo. Meses después descubrió una vulnerabilidad de inyección SQL que habría permitido leer o alterar los datos del sitio. Starr, que es project manager de profesión, lo calificó como "un punto ciego" en su aprendizaje. Un punto ciego que en otro contexto, con datos financieros o médicos de usuarios reales, habría sido una brecha grave.

Jer Crane, fundador de PocketOS, publicó en X que un agente de IA borró la base de datos de producción de su empresa. Sin copia de seguridad accesible. Sin rollback. Un incidente que en una empresa establecida con usuarios reales puede ser terminal.

Joe Procopio, emprendedor en serie con experiencia técnica, tuvo que retirar una app web creada con vibe coding para demos privadas después de recibir ataques de hackers. Ahora hace las demos desde su máquina local por Zoom. Un desarrollador veterano, con criterio técnico, construyendo una app vulnerable sin darse cuenta.

Max Segall, COO de Privy, creó EzRun para recompensar a su hijo con Ethereum al correr. Un colega revisó el código antes del lanzamiento y encontró un fallo crítico que habría permitido modificar cuentas de usuario. La revisión por pares evitó el desastre. Pero esa revisión fue manual, externa y por iniciativa propia. No fue parte del flujo de construcción.

Todos estos casos comparten algo: los creadores no actuaron con negligencia deliberada. Actuaron con desconocimiento. La IA generó código que parecía correcto, que funcionaba en local, que pasaba la inspección visual. Y nadie les dijo que "funciona" y "es seguro" son dos afirmaciones completamente distintas.

"El peligro no es que aficionados construyan software. Es cuando una app personal 'deriva' a software de negocio almacenando datos compartidos sin que el creador lo note.", Gabriel Bernadett-Shapiro, científico de IA en SentinelOne

La escala del problema no es anecdótica

Estos casos podrían parecer excepciones. No lo son.

Investigadores de Red Access analizaron apps públicas construidas con herramientas populares de vibe coding y encontraron aproximadamente 5.000 sin autenticación. De esas, alrededor de 2.000 filtraban datos sensibles: información médica, financiera, documentos estratégicos y registros de conversaciones de chatbots.

Cinco mil apps. Dos mil con datos reales expuestos. Eso no es un problema de un fundador descuidado. Es un problema sistémico que crece en proporción directa a la velocidad con que el vibe coding baja el umbral de entrada al desarrollo.

Jack Cable, CEO de Corridor, lo resume con precisión: el vibe coding es apto para prototipos o rastreadores de fitness sin datos sensibles. No para registros financieros o médicos. No para cualquier cosa que almacene datos de terceros en internet. El criterio no es si la app funciona. Es qué pasa cuando alguien con malas intenciones encuentra el endpoint equivocado.

Los fallos técnicos concretos que nadie te explica antes de empezar

Vamos a lo específico. Porque el problema no es abstracto: son patrones concretos que aparecen una y otra vez en apps construidas sin arquitectura previa.

Código espagueti sin contexto global

Cuando construyes prompt a prompt, cada respuesta de la IA es óptima para ese prompt. Pero la IA no mantiene una visión global del sistema. El resultado es código que funciona localmente pero que tiene dependencias implícitas, lógica duplicada y módulos que se contradicen entre sí. Dos semanas después de escribirlo, ni tú mismo entiendes qué hace qué. Escalar eso o añadir una feature nueva se convierte en una operación de arqueología.

Sin control de concurrencia ni idempotencia

Una app que funciona cuando la usas tú solo no está preparada para 200 usuarios simultáneos. Sin rate limiting, sin gestión de estados concurrentes, sin operaciones idempotentes, el sistema produce resultados imposibles bajo carga real.

La idempotencia es el ejemplo más caro. Si una operación de descuento no está protegida contra ejecuciones múltiples simultáneas, dos usuarios haciendo clic al mismo tiempo pueden desencadenar aplicaciones dobles. Cien usuarios en un flash sale pueden vaciar el inventario y seguir procesando pedidos. Un ecommerce puede aplicar un descuento del 100% en bucle hasta que alguien lo para manualmente. He visto exactamente esto.

API keys y secretos hardcodeados

La IA genera código funcional. Si no le preguntas por seguridad, no te la da. El resultado más frecuente: credenciales de servicios externos, Stripe, AWS, APIs de terceros, escritas directamente en el código fuente. Subes el repositorio a GitHub, alguien lo encuentra con una búsqueda básica, y en veinte minutos tienes tus credenciales siendo usadas por alguien que no eres tú. Las variables de entorno existen precisamente para esto. La IA las usa si se las pides. Si no se las pides, no las usa.

Cero control de acceso

Sin roles de usuario, sin scopes de permisos, sin separación entre lo que puede hacer un usuario normal y lo que puede hacer un administrador. En muchas apps de vibe coding, cualquier usuario autenticado, o incluso no autenticado, puede acceder a endpoints que deberían estar restringidos. No por malicia del creador. Por omisión. Porque nadie diseñó el modelo de permisos antes de escribir el primer prompt.

La falsa seguridad de las herramientas

Las herramientas de desarrollo con IA tienen revisiones de seguridad. Pero son manuales o requieren configuración avanzada. Claude Code tiene /security-review, pero hay que pedirlo explícitamente. Codex Security funciona con flujos de control de versiones, lo que excluye al creador casual que no usa Git de forma estructurada.

Modelos como GPT-5.5-Cyber pueden detectar vulnerabilidades que incluso desarrolladores experimentados pasan por alto. Pero el usuario puede ignorar las advertencias, no entenderlas o simplemente no haberlas solicitado. La IA ayuda si se le pregunta. No sustituye el criterio de alguien que sabe qué preguntar.

El creador del término ya no cree en el hype

Andrej Karpathy acuñó el término "vibe coding". Y hace poco declaró que los agentes de IA para desarrollo son net unhelpful en su estado actual. El creador del concepto desmontando la hype de su propio concepto.

Eso no significa que la IA para código no sirva. Significa que la narrativa de "construye una app en un finde sin saber programar y lánzala a producción" tiene un coste que no aparece en el hilo de Twitter que la vende.

El coste es técnico: deuda acumulada que eventualmente hay que pagar, normalmente en el peor momento. El coste es económico: iterar sin plan consume recursos computacionales a una velocidad que se hace insostenible. El coste es de seguridad: datos de usuarios expuestos, credenciales robadas, sistemas caídos.

Los desarrolladores que usan estas herramientas con revisión real, arquitectura previa y criterio técnico sacan resultados genuinamente útiles. Si quieres entender cómo se hace eso bien, vibe coding sin pegarte un tiro en el pie cubre exactamente eso. El problema no es la IA. Es presentar la ausencia de ingeniería como una característica en vez de como un riesgo.

Lo que Bernadett-Shapiro llama el momento de la deriva

Gabriel Bernadett-Shapiro, científico de IA en SentinelOne, identifica el patrón más peligroso con precisión quirúrgica: no es el aficionado que construye una app para uso personal. Es el momento en que esa app "deriva" hacia uso de negocio sin que el creador lo note.

Empieza como un rastreador personal. Luego lo comparte con el equipo. Luego almacena datos de clientes. Luego procesa pagos. En cada paso, el estándar de seguridad que se necesita sube. Pero la arquitectura de la app sigue siendo la del rastreador personal de día uno.

Ese es el agujero real. No la app de juguete en local. Es la app de juguete que acaba almacenando información médica de cien pacientes porque "funcionaba bien y la empezamos a para todo".

La principal preocupación no es el código con errores. Es la falta de autenticación al mover una app local a la nube. Opciones de configuración mal entendidas que dejan datos sensibles expuestos. Similar, en palabras de Bernadett-Shapiro, a dejar una caja de secretos en la acera.

Qué separa una app útil de una bomba de relojería

La distinción no es si usas IA o no. Es si tienes arquitectura antes del primer prompt.

Arquitectura no significa semanas de documentación. Significa decidir antes de escribir código: qué datos maneja la app, quién puede acceder a qué, cómo se autentican los usuarios, cómo se gestionan los errores, qué pasa cuando dos usuarios hacen la misma operación al mismo tiempo.

Con esas respuestas claras, la IA es una herramienta de implementación brutalmente eficiente. Sin ellas, es una máquina de generar deuda técnica con buena presentación visual.

Una app en tres horas sin cimientos no es un MVP. Es una deuda técnica con fecha de vencimiento desconocida. Y cuando vence, normalmente lo hace con los datos de tus usuarios en medio.

Si el tema de la seguridad en sistemas con IA te interesa más allá del vibe coding, RAG no es magia: la bomba de seguridad y compliance que nadie te contó cubre otro flanco igual de ignorado y igual de caro cuando explota.