"Vibecoding" es el término que se usa hoy para describir algo que antes no tenía nombre propio: generar código a partir de prompts, sin revisar ni entender demasiado lo que se generó, confiando en que si compila y la demo anda, está bien. El término lo popularizó Andrej Karpathy a principios de 2025 y pegó rápido porque describe algo que ya estaba pasando hace rato, solo que ahora es mucho más accesible: cualquier persona, tenga o no formación técnica, puede pedirle a una IA que le arme una app, un sistema de turnos, un dashboard, o un formulario, y en minutos tener algo funcionando.
El problema no es la herramienta. El problema es no saber en qué terreno la estás pisando.
En Eje Z vemos las dos caras de esto todo el tiempo: usamos generación asistida por IA en nuestro propio flujo de trabajo, y también recibimos, cada vez con más frecuencia, proyectos de clientes que llegaron hasta un punto usando vibecoding y después necesitaron a alguien que entienda qué hay debajo del capó. Este artículo es la guía que nos gustaría que alguien le hubiera dado antes de que ese "andá armando algo con IA" se convirtiera en un problema.
Qué es vibecoding, en criollo
Vibecoding es programar por vibra (de ahí el “vibe”): le describís a una IA lo que querés, te tira código, lo pegás, anda (o parece que anda), y seguís para adelante sin pararte a entender por qué anda, qué pasa en los bordes, o qué decisiones técnicas se tomaron en el camino sin que vos las autorizaras.
No es lo mismo que "usar IA para programar". Un desarrollador que usa IA para escribir código revisa cada línea, entiende la arquitectura, y decide conscientemente qué entra y qué no, no está vibecodeando: está usando una herramienta de productividad, ni más ni menos que usar autocompletado avanzado. El vibecoding aparece cuando el que genera el código no tiene, o no ejercita, el criterio para evaluar lo que recibió.
Y acá está el matiz importante: esto no es un problema exclusivo de gente sin formación técnica. Programadores con experiencia también vibecodean cuando tienen apuro, cuando el proyecto no les importa lo suficiente como para revisarlo a fondo, o cuando confían de más en que la IA "ya debe haber pensado en los casos raros". El riesgo no depende de quién escribe el prompt, depende de qué tan crítico es el sistema que se está construyendo y de cuánta revisión real recibió antes de ponerse en producción.
Dónde el vibecoding funciona bien
Vale la pena decirlo con todas las letras, porque no se trata de demonizar la práctica: hay contextos donde vibecodear es exactamente lo que corresponde hacer.
- Prototipos y pruebas de concepto. Si querés validar si una idea tiene sentido antes de invertir tiempo real en construirla bien, un prototipo vibecodeado en una tarde te da la respuesta más rápido que cualquier otra cosa. Eso sí: ese prototipo es solo eso, un prototipo. Bajo ninguna circunstancia hay que confundirlo con un sistema listo para producción, ni ponerlo a manejar datos reales de tu negocio.
- Herramientas internas descartables. Un script para procesar un archivo una sola vez, una calculadora interna que usás vos y nadie más, un panel para ver datos que ya tenés en otro lado. Si se rompe, la pérdida es mínima y nadie más que vos se entera.
- MVPs para mostrarle algo a un inversor o a un cliente potencial, siempre y cuando quede clarísimo (para vos y para quien lo ve) que es una demo y no un sistema en producción.
En estos casos, la velocidad que da el vibecoding es una ventaja real. El error no es usarlo acá. El error es no darse cuenta cuándo el proyecto dejó de ser esto y se convirtió en otra cosa.
Un caso real: cuando la demo miente
Hace poco nos llegó un proyecto de un cliente con un rubro completamente distinto al software. Un estudio que necesitaba un sistema para organizar turnos y horarios de su equipo. Ya tenía algo armado: un artefacto HTML generado con IA, con una interfaz que se veía relativamente prolija, con botones, calendario, todo lo que uno esperaría ver.
El diagnóstico llevó cinco minutos: el sistema no tenía persistencia de datos real. Todo lo que cargabas (turnos, horarios, asignaciones) vivía únicamente en la memoria de esa sesión del navegador. Cerrabas la pestaña, o simplemente recargabas la página, y todo desaparecía. En la demo, delante del cliente, nunca se notaba: cargás datos, los mirás, se ven bien, cerrás la laptop satisfecho. El problema aparece recién cuando alguien del equipo lo abre al otro día y no encuentra nada de lo que se cargó ayer.
Esto es exactamente la trampa del vibecoding en su forma más común: el síntoma no se ve en la demo, se ve en el uso real, con el tiempo, cuando ya invertiste expectativa (y a veces plata) en que el sistema funcionaba. Una interfaz linda no dice nada sobre si los datos sobreviven un reinicio, si dos personas pueden usarlo al mismo tiempo sin pisarse, o si lo que se ve en pantalla es en verdad lo que hay guardado en algún lado.
Señales de alerta que cualquier no-programador puede chequear
No hace falta saber programar para hacerse estas preguntas antes de confiar un proceso real a un sistema vibecodeado. Son chequeos de sentido común, no de código:
- ¿Los datos sobreviven si cierro el navegador o se corta la luz? Cargá algo, cerrá todo, volvé a abrir. Si no está, no tenés un sistema, tenés una simulación.
- ¿Qué pasa si dos personas lo usan al mismo tiempo? Pedile a alguien que abra el mismo sistema en otra computadora mientras vos cargás datos. Si se pisan, se sobrescriben o se rompen, no está pensado para uso real en equipo.
- ¿Alguien de afuera puede ver o tocar datos que no debería? Si el sistema maneja información de clientes, de empleados, o cualquier dato sensible, preguntá específicamente quién más además de vos puede acceder, y cómo se controla eso.
- ¿Hay backups? Si el único lugar donde existen los datos es ese sistema, y ese sistema no tiene ningún tipo de respaldo, un solo error humano o técnico te puede borrar todo de una.
- ¿Qué pasa si lo uso de una forma que no probaron? Cargá un dato raro a propósito (una fecha inválida, un campo vacío, un texto muy largo). Un sistema bien armado te avisa con un error claro. Uno vibecodeado muchas veces simplemente se rompe en silencio, o peor, guarda el dato corrupto sin avisar.
Ninguna de estas preguntas requiere saber programar. Requieren animarse a desconfiar un poco de algo que se ve prolijo.
Vulnerabilidades comunes que aparecen en código vibecodeado
Acá sí entramos un poco más en terreno técnico, pero vale la pena entender los conceptos aunque no programes, porque son los puntos ciegos más frecuentes cuando el código se generó rápido y se revisó poco.
Secretos hardcodeados. Es común que el código generado incluya claves de API, contraseñas o tokens de acceso escritos directamente en el archivo, en texto plano, en lugar de guardarlos en variables de entorno o en un gestor de secretos. Si ese código después se sube a un repositorio público, o incluso a uno privado con más gente de la que debería tener acceso, esas credenciales quedan expuestas. Es uno de los errores más comunes y más fáciles de no notar, porque el sistema "funciona igual" tenga las credenciales hardcodeadas o no, el problema es invisible hasta que alguien no autorizado las encuentra.
Autenticación mal implementada. Sistemas generados rápido suelen tener controles de acceso más débiles de lo que parecen: contraseñas guardadas sin ningún tipo de protección adecuada, sesiones que no expiran nunca, o paneles de administración accesibles simplemente sabiendo la URL, sin ningún control real detrás. La interfaz puede mostrar un login prolijo y dar la sensación de seguridad, mientras que por debajo el control de quién puede entrar y a qué es prácticamente inexistente.
Falta de validación de datos. Cuando el código no revisa bien qué información puede ingresar un usuario, se abre la puerta a errores que van desde lo molesto (el sistema se rompe con un dato inesperado) hasta lo serio (alguien puede manipular la aplicación para acceder o modificar información que no debería, aprovechando justamente esa falta de control).
Permisos mal configurados. Es habitual ver sistemas donde cualquier usuario logueado puede, sin querer o a propósito, ver o editar datos de otros usuarios, simplemente porque nadie definió con claridad qué puede hacer cada rol dentro del sistema.
No profundizamos más en el detalle técnico de cada una de estas fallas a propósito: el objetivo de este artículo no es un manual de cómo explotarlas, sino ayudarte a reconocer que existen y que un sistema que "se ve terminado" puede tenerlas sin que se note a simple vista.
Cuándo conviene parar y llamar a alguien
Hay un punto de inflexión bastante claro, y no tiene que ver con cuánto código hay, sino con qué está en juego. Conviene frenar y pedir una revisión seria cuando el sistema empieza a tocar cualquiera de estos puntos:
- Maneja datos de clientes (contactos, historial de compras, información de contacto).
- Procesa pagos o cualquier dato financiero.
- Maneja información regulada (datos de salud, datos personales sensibles bajo la Ley 25.326, por ejemplo).
- Lo usa más de una persona a la vez, o más de una persona en distintos momentos, sobre los mismos datos.
- Un error o una caída te genera una pérdida real. Sea de plata, de tiempo del equipo, o de confianza de un cliente.
Si tu sistema cumple alguno de estos puntos, dejó de ser un experimento interno y empezó a ser infraestructura real de tu negocio. Y la infraestructura real de un negocio merece la misma pregunta que le hacemos a cualquier cliente antes de escribir la primera línea de código para ellos: ¿qué problema estamos resolviendo en verdad, y qué pasa si esto falla?
Eso dediagnosticar antes de construir, entender qué hay debajo de una demo que se ve bien es el trabajo que hacemos en el Sprint de Arquitectura para cada proyecto que llega a Eje Z, vibecodeado o no. La diferencia entre un sistema que sostiene un negocio y uno que un día simplemente deja de andar casi nunca está en qué tan lindo se ve. Está en las preguntas que nadie se hizo antes de darlo por terminado.
Si estás evaluando crear una app y no tenés claro por dónde empezar, hablemos.