Vibe coding es programar describiéndole a una IA lo que quieres y aceptando el código que genera sin leerlo: si al probarlo funciona, sigues. Sirve para prototipos rápidos y herramientas personales. El riesgo aparece cuando ese código llega a usuarios reales sin que nadie lo haya revisado ni probado de verdad.
Una pregunta de la app. Elige una respuesta.
El agente responde «Listo, ya funciona». ¿Qué lo respalda mejor?
Sonar seguro no es evidencia. Un modelo puede afirmar algo falso con total calma.
Editar muestra que cambió algo. Para saber si está bien, falta comprobarlo.
Es un resultado que puedes ver y repetir. Los tests que pasan respaldan lo que prueban, no toda la app.
El término se popularizó a comienzos de 2025 con un post de Andrej Karpathy, investigador de IA. La idea: le hablas a un agente de código, aceptas todos los cambios, y si aparece un error le pegas el mensaje y le pides que lo arregle. No lees el código; juzgas por cómo se ve y se comporta la app.
No todo lo que se programa con IA es vibe coding. Si le pides un cambio con un prompt claro, lees lo que hizo y corres los tests, estás programando con ayuda. La diferencia no está en la herramienta, sino en si alguien entiende y revisa lo que entra.
Para cosas que se pueden tirar o que sólo usas tú: una página para calcular cuánto pone cada uno en el asado, un script que renombra las fotos del viaje por fecha, una maqueta para mostrarle una idea a un cliente antes de invertir semanas. Ahí lo que importa es la velocidad, y si algo falla, el daño es chico.
También abrió la puerta a gente que no programa: alguien de ventas o de diseño puede armar la herramienta que necesita sin esperar al equipo técnico. Eso es valioso, mientras la herramienta no maneje datos de otros ni dinero.
Antes de arrancar, tres preguntas. ¿Lo va a usar alguien más que tú? ¿Toca datos de otras personas, como mails, contraseñas o fotos? ¿Mueve dinero? Si las tres son «no», adelante: es el terreno del vibe coding (igual, con datos de prueba y todo guardado en git). Con un solo «sí», alguien que sepa tiene que leer el código y probar qué pasa cuando falla.
Un script que ordena tus fotos en tu compu: tres «no». Una app donde tus amigos cargan sus datos y pagan su parte del viaje: tres «sí». Lo que cambia es quién paga si falla.
El código funciona en la demo y falla en el borde: el formulario acepta un monto negativo, o la búsqueda se cae con un apellido con tilde. Nadie lo vio porque nadie lo leyó. Otros errores típicos: una clave de API pegada en el código que ve el navegador, o una librería que el modelo inventó y que alguien podría publicar con ese nombre para colar código malicioso.
El otro problema llega con el tiempo. Después de cincuenta pedidos, el proyecto es un montón de parches que nadie entiende, y cada arreglo rompe otra cosa. En ese punto, el agente tampoco tiene claro cómo está armado.
Empieza con algo sólo para ti, con datos inventados y sin mover dinero: por ejemplo, una página que reparte un gasto entre amigos. Antes de pedirla, define una prueba concreta: «12 entre 4 tiene que dar 3». Y prueba también qué pasa con cero personas.
Usa un agente de código y pídele primero un plan corto (modo plan): mira si coincide con tu idea. Después avanza de a un cambio y prueba el resultado. Si repites reglas en cada pedido, déjalas en un CLAUDE.md o un AGENTS.md. Para aprender, pídele que te muestre en el código cómo funciona una parte; su explicación también puede equivocarse.
Puedes mantener la velocidad y sumar controles baratos. Pídele al agente que escriba tests para lo que importa (que un monto negativo se rechace) y que los corra; mira tú la salida, no su resumen. Trabaja en pasos chicos y guarda cada uno en git, así puedes volver atrás si algo se rompe.
Antes de aceptar, revisa el diff aunque sea por encima: qué archivos tocó y si hay algo que no pediste. Y no le des acceso a la base de datos real ni a claves de producción mientras experimentas. Si el prototipo gusta y va a tener usuarios, ese es el momento de leerlo entero.
Para armar un prototipo, no. Para saber si lo que hizo la IA está bien, lo básico sí. No hace falta escribir cada línea, pero sí ver qué cambió en el diff, saber dónde no va una clave de API y darte cuenta si los tests prueban lo que importa. Esa es la diferencia entre vibecodear a ciegas y dirigir a un agente.