"Vibe coding" empezó como un chiste de un investigador de IA a principios de 2025 y terminó siendo la puerta de entrada de miles de personas no técnicas al software. El término es nuevo; el cambio de fondo es serio: escribir código dejó de ser el cuello de botella. Saber qué construir, sí.
En corto
- Qué es: construir software describiendo en lenguaje natural lo que querés, mientras una IA escribe el código, y aceptando el resultado sin revisar cada línea.
- De dónde viene: lo acuñó Andrej Karpathy en febrero de 2025 para describir un estilo de trabajo donde "te entregás a las vibras" y te olvidás de que el código existe.
- Para quién funciona mejor: proyectos nuevos, chicos y de bajo riesgo. Un prototipo, una herramienta interna, tu primera app.
- El dato incómodo: un ensayo controlado de 2025 midió que desarrolladores experimentados tardaron 19% más en tareas reales sobre código que ya conocían cuando usaron asistentes de IA. Y creían haber sido 20% más rápidos.
- Conclusión práctica: la IA acelera muchísimo lo que no sabés hacer y bastante menos lo que ya dominás. La sensación de velocidad no es un buen instrumento de medición.
- Lo que decide el resultado no es la herramienta: es descomponer, especificar, verificar y controlar el alcance.
Lo que vas a leer
Qué es y qué no es
Vibe coding es construir software describiendo lo que querés en lenguaje natural y dejando que una IA escriba el código, sin revisar cada línea de lo que produce. El término lo acuñó Andrej Karpathy a principios de 2025 medio en broma, para describir un modo de trabajo en el que uno "se olvida de que el código existe".
Lo que no es: magia, y tampoco "no aprender nada". El código lo escribe la IA, pero las decisiones importantes siguen siendo tuyas: qué problema resolvés, para quién, qué es lo mínimo que vale la pena construir, cómo sabés si funciona. Los que fracasan no fracasan por el código: fracasan por pedirle a la IA cosas que ni ellos tienen claras.
El dato incómodo sobre productividad
Conviene decirlo antes que el entusiasmo: la evidencia sobre cuánto acelera la IA al programar es más mezclada de lo que sugiere el discurso público.
En 2025, un ensayo controlado siguió a 16 desarrolladores open source con experiencia trabajando sobre repositorios que conocían bien, en 246 tareas reales, con y sin asistentes de IA. El resultado fue el opuesto al esperado: tardaron 19% más con las herramientas de IA. Lo más interesante viene después: esos mismos desarrolladores estimaron que la IA los había hecho 20% más rápidos.
Más lentos en tareas reales sobre código que ya conocían. Y creyeron haber sido 20% más rápidos. Casi 40 puntos de diferencia entre lo que pasó y lo que sintieron que pasó.
Antes de sacar la conclusión equivocada: eso no significa que la IA no sirva para construir. Significa que la ventaja depende del contexto. Expertos, en código maduro que dominan, con estándares altos: poca o ninguna ganancia. Principiante en proyecto nuevo, donde la alternativa era no poder hacerlo: la ganancia es infinita, porque el punto de comparación es cero.
La lección transferible es otra, y vale para cualquiera: la sensación de velocidad no mide la velocidad. Si vas a construir con IA, medí el resultado (¿funciona?, ¿alguien lo usa?), no la impresión de estar avanzando rápido.
Las cuatro habilidades del constructor sin código
01 Descomponer
Convertir "quiero una app de reservas" en piezas chicas y ordenadas que se puedan construir de a una y probar por separado. Si le pedís todo junto, obtenés algo grande que no funciona y no sabés por dónde empezar a arreglar.
02 Especificar
Describir comportamiento con precisión. La diferencia entre "que se vea lindo" y "el botón queda deshabilitado hasta que el email sea válido, y si el email ya existe muestro este mensaje". La IA construye exactamente lo que le describís, incluida tu vaguedad.
03 Verificar
Probar lo construido como lo usaría una persona real, encontrar el caso que rompe y pedir el arreglo. Es la habilidad más descuidada: mucha gente acepta lo que la IA devuelve porque se ve bien, sin probar ni una sola vez el camino del error.
04 Controlar el alcance
Resistir la tentación de agregar funciones y llegar a algo que funcione de punta a punta. Con IA la tentación es mucho peor que antes, porque agregar parece gratis. No lo es: cada función nueva es superficie que puede romperse.
Plan de primer producto en 4 semanas
- Semana 1: Elegí un problema tuyo, real y chico. Escribí en una página qué hace la versión mínima y, sobre todo, qué no hace. Si no podés describirlo en una página, todavía no lo entendés.
- Semana 2: Construí el esqueleto. Feo pero funcionando de punta a punta. Un camino completo que ande vale más que cinco pantallas lindas que no se conectan.
- Semana 3: Usalo vos todos los días. Anotá lo que molesta. Arreglá eso y nada más. Acá es donde la mayoría se pone a agregar funciones en vez de arreglar: no lo hagas.
- Semana 4: Dáselo a tres personas. No les expliques cómo se usa: mirá dónde se traban. Esa lista de tropiezos es tu producto de verdad.
Dónde se rompe
- El muro de la semana 2. Algo se rompe, la IA propone un arreglo que rompe otra cosa, y como no entendés el código no sabés ni qué preguntar. Es el punto exacto donde la mayoría abandona, y donde tener alguien que mire tu pantalla y te explique qué está pasando separa a los que terminan de los que no.
- La seguridad. Claves pegadas en el código, bases de datos abiertas, formularios sin validación. La IA no te avisa, porque le pediste que funcione y funciona. Si tu proyecto va a tocar datos de otras personas, esto deja de ser opcional.
- La deuda que no ves. Aceptar todo sin entender nada produce un sistema que crece hasta que nadie, ni vos ni la IA, puede modificarlo sin romperlo.
- Confundir prototipo con producto. Que funcione en tu máquina para vos no es lo mismo que funcione para cien personas a la vez.
Cuándo sí y cuándo no conviene
| Contexto | ¿Vibe coding? | Por qué |
|---|---|---|
| Prototipo para validar una idea | Sí, ideal | Velocidad importa, el riesgo de error es bajo |
| Herramienta interna para vos o tu equipo | Sí | Usuarios conocidos y tolerantes, datos acotados |
| Tu primer producto como no programador | Sí, con acompañamiento | La alternativa era no construir nada |
| Algo que maneje pagos o datos sensibles | No sin revisión | El costo de un error deja de ser tu tiempo |
| Modificar un sistema grande que ya funciona | Con cuidado | Es justo el escenario donde se midió la pérdida de velocidad |
Probalo en una clase real
10 minutos gratis con un profesor AI que te acompaña cuando algo se rompe y no sabés ni qué preguntar. Por voz, sin tarjeta.
Probá una clase gratis¿Qué es el vibe coding?
Es construir software describiendo en lenguaje natural lo que querés mientras una IA escribe el código, sin revisar cada línea. El término lo acuñó Andrej Karpathy en febrero de 2025 para describir un modo de trabajo en el que uno se olvida de que el código existe. Funciona mejor en proyectos nuevos, chicos y de bajo riesgo: prototipos, herramientas internas, un primer producto.
¿Se puede crear una app sin saber programar?
Hoy sí, y de hecho es el caso de uso donde más rinde la IA: cuando la alternativa era no construir nada, cualquier avance es infinito. Lo que sigue siendo tuyo son las decisiones: qué problema resolvés, para quién, qué es lo mínimo que vale la pena, y cómo verificás que funciona. Las cuatro habilidades que hacen la diferencia son descomponer, especificar, verificar y controlar el alcance.
¿La IA hace más rápido a los programadores?
Depende del contexto, y menos de lo que se cree. Un ensayo controlado de 2025 con 16 desarrolladores experimentados en 246 tareas reales sobre repositorios que ya conocían encontró que tardaron 19% más usando asistentes de IA, aunque estimaron haber sido 20% más rápidos. En proyectos nuevos y para quien no sabe programar el efecto es el opuesto. La lección general: la sensación de velocidad no mide la velocidad.
¿Qué riesgos tiene programar con IA sin entender el código?
Cuatro principales: problemas de seguridad que la IA no te advierte (claves en el código, bases de datos abiertas, formularios sin validación); deuda técnica que crece hasta que nadie puede modificar el sistema sin romperlo; confundir un prototipo que anda en tu máquina con un producto que soporta usuarios reales; y quedarte trabado cuando algo se rompe y no sabés ni qué preguntar. Si el proyecto toca datos de otras personas o pagos, hace falta revisión.
¿Cuánto lleva construir un primer producto con IA?
Cuatro semanas alcanzan para algo real si el alcance es honesto: semana 1 definir el problema en una página, semana 2 construir el esqueleto feo pero funcionando de punta a punta, semana 3 usarlo vos todos los días y arreglar solo lo que molesta, semana 4 dárselo a tres personas y mirar dónde se traban. El error clásico es usar la semana 3 para agregar funciones en vez de arreglar.
¿Por qué la mayoría abandona en la mitad?
Por el muro de la semana 2: algo se rompe, la IA propone un arreglo que rompe otra cosa, y sin entender el código no se sabe ni qué preguntar. No es un problema de capacidad sino de acompañamiento: es exactamente el momento donde tener a alguien que vea tu pantalla, entienda el error y te lo explique separa a los que terminan de los que no.
Fuentes
- METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Ensayo controlado aleatorizado con 16 desarrolladores y 246 tareas. metr.org
- Karpathy, A. (febrero de 2025). Publicación original donde se acuña el término "vibe coding".
- Kosmyna, N. et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt. MIT Media Lab. arxiv.org
Seguí leyendo
Cómo aprender IA desde cero en 2026: una ruta sin humo › Cuánto se tarda en aprender una habilidad › Qué es un profesor AI y en qué se diferencia de un chatbot ›Publicado por el equipo de Maestre · Los creadores de Cineastas del Futuro: más de 17.000 alumnos formados. Escribimos sobre lo que probamos enseñando.