Voy a empezar con una confesión que tal vez no esperan de alguien que lleva más de tres décadas en esto: el vibe coding me deslumbró. Lo probé en estas últimas semanas, cuando el término empezó a estar en todos lados, y la experiencia me sacudió de verdad. Ver cómo una idea descrita en lenguaje natural se convertía en algo que funcionaba, en minutos, sin escribir una línea a mano, me hizo sentir esa mezcla rara de entusiasmo y vértigo que no sentía hacía mucho. Por un rato me olvidé del código. Hablaba, probaba, corregía con otra frase, y la cosa avanzaba. Y sin embargo, casi en el mismo momento en que me maravillaba, una alarma se encendió en algún lado de mi cabeza. No una alarma de “esto no sirve” —porque sí sirve, y mucho—, sino una más incómoda: “esto, llevado a una empresa con equipos y sistemas en producción, se va a salir de control si no entendemos qué estamos haciendo”. Deslumbramiento y advertencia, el mismo día. De esa tensión quiero hablar acá, porque es la más honesta y la más interesante.
Qué es el vibe coding, en pocas palabras#
A principios de febrero, Andrej Karpathy —cofundador de OpenAI, ex líder de IA en Tesla, una de las voces que la industria escucha— publicó un mensaje breve que terminó nombrando algo que muchos ya estábamos sintiendo sin saber cómo llamarlo. Habló de “una nueva forma de programar” en la que uno “se entrega del todo a las vibras, abraza los exponenciales y se olvida de que el código siquiera existe”. La describió como una experiencia donde le pega los errores a la IA sin siquiera leerlos, acepta los cambios que propone, y deja que el sistema crezca aunque ya no entienda del todo cómo funciona por dentro. Y aclaró algo importante, que después muchos pasaron por alto: que esto le resultaba ideal para “proyectos desechables de fin de semana”.
El término prendió fuego. En cuestión de semanas pasó de un mensaje en una red social a estar en el New York Times, en Ars Technica, en The Observer, e incluso a aparecer listado en un diccionario como palabra de tendencia. Y prendió porque le puso nombre a un cambio real: los modelos de lenguaje orientados a programación llegaron a un punto en el que, para ciertas cosas, “mostrás, decís, corrés, copiás y pegás, y mayormente funciona”. Esa es la cita de Karpathy, y captura bien la sensación. El rol del que construye software se corre del teclado hacia la conversación.
Conviene marcar desde el principio una distinción que el propio campo ya está discutiendo. No todo desarrollo asistido por IA es vibe coding. Simon Willison, que es un entusiasta de estas herramientas y no un detractor, lo planteó con una claridad que ayuda mucho a ordenar la discusión: si la IA escribió cada línea de nuestro código pero lo revisamos, lo probamos y lo entendimos todo, eso no es vibe coding, es usar la IA como asistente de tipeo. El vibe coding, en su versión pura, implica justamente lo contrario: confiar en la IA para los detalles, aceptar sin revisar, iterar sobre el comportamiento y no sobre el código. La diferencia no es un capricho de definición. Es la diferencia entre dos prácticas que se parecen por fuera y son opuestas por dentro.
Por qué me deslumbró (y por qué eso importa)#
Quiero ser honesto sobre lo que sentí, porque creo que descartarlo sería deshonesto y también un error de análisis. Hay algo genuinamente nuevo acá. Durante años, la distancia entre tener una idea y tener algo funcionando fue enorme: había que conocer un lenguaje, un framework, configurar un entorno, entender mil detalles antes de ver el primer resultado. El vibe coding colapsa esa distancia de una manera que, cuando la experimentamos de primera mano, es difícil de no encontrar mágica. Pensamos algo, lo decimos, y aparece. Iteramos hablando. El cuello de botella deja de ser la sintaxis y pasa a ser la claridad de la idea.
Eso tiene un valor real, y no solo para no programadores. Para alguien con experiencia, el vibe coding es un acelerador brutal de exploración. Quiero probar si una idea tiene sentido, quiero ver una primera versión, quiero validar un enfoque antes de comprometerme: todo eso, que antes llevaba horas o días, ahora puede llevar minutos. La capacidad de prototipar a esa velocidad cambia cómo pensamos los problemas, porque baja tanto el costo de experimentar que nos animamos a probar caminos que antes ni considerábamos por pereza o por costo. En ese terreno —exploración, prototipos, prueba de conceptos, herramientas personales— el vibe coding no solo funciona: es una de las mejores cosas que le pasaron al desarrollo en mucho tiempo.
Y vale la pena decir esto fuerte, porque la reacción fácil de alguien de mi generación sería el desdén: “esto no es programar de verdad”. Es una reacción cómoda y, creo, equivocada. Es la misma reacción que tuvieron en su momento contra los lenguajes de alto nivel, contra los frameworks, contra todo lo que subió el nivel de abstracción y dejó que más gente construyera cosas. El desdén envejece mal. La pregunta interesante nunca es si una herramienta nueva “es programar de verdad”, sino qué habilita, qué riesgos trae y dónde conviene usarla. Y ahí es donde, el mismo día que me deslumbré, se me encendió la alarma.
El momento exacto en que se encendió la alarma#
Estaba en plena sesión de vibe coding, encantado, cuando me pregunté algo casi de reflejo, por costumbre de tantos años: “si esto que estoy haciendo lo tuviera que retomar otra persona la semana que viene, ¿podría?”. Y la respuesta, fría, fue que no. No porque el código estuviera mal, sino porque en ningún lado había quedado registrado qué le había pedido a la IA, en qué orden, con qué intención, qué descartamos y por qué, qué supuestos tomó ella por su cuenta. Todo eso vivía en una conversación efímera y en mi cabeza. El resultado existía; el camino para llegar a él, no. Y en software, muchas veces, el camino importa tanto como el destino.
Ese fue el momento. Me di cuenta de que el vibe coding, tal como lo estaba viviendo, no tenía versionado de especificaciones. Tenía versionado de código —el código está ahí, en el archivo— pero no tenía registro de las decisiones, de los requerimientos, de la intención que guió cada paso. Y eso, para un proyecto personal de fin de semana, es perfectamente aceptable. El propio Karpathy lo encuadró así. Pero mi cabeza no estaba pensando en un proyecto de fin de semana. Estaba pensando, inevitablemente, en empresas de software con equipos de varias personas, donde el código que escribimos hoy lo va a mantener otro dentro de seis meses, donde las decisiones tienen que poder explicarse, donde nadie trabaja solo. Y ahí la cosa cambia por completo.
El problema no es la IA, es lo que dejamos de versionar#
Durante décadas, la industria del software aprendió, a los golpes, a versionar el código. El control de versiones fue una de las grandes conquistas de nuestra disciplina: poder saber quién cambió qué, cuándo y por qué, poder volver atrás, poder trabajar muchas personas sobre la misma base sin pisarnos. Cuesta imaginar hoy un equipo serio que no versione su código. Es parte del aire que respiramos.
Pero el vibe coding introduce una pregunta que no teníamos del todo resuelta: ¿qué pasa con el versionado de la intención? Cuando yo escribía código a mano, la intención estaba, de alguna forma imperfecta, embebida en el código mismo y en los commits. Cuando le pido a una IA que genere ese código a partir de una conversación, la intención vive en otro lado: en los prompts, en el contexto que le di, en las correcciones que fui haciendo. Y eso, hoy, en la práctica del vibe coding puro, no se versiona. Se evapora cuando cierro la sesión. Lo que queda es el resultado, huérfano de su porqué.
Pensémoslo así. Si dentro de seis meses ese código falla, o hay que extenderlo, o cambia un requerimiento del negocio, el que lo tenga que tocar va a encontrarse con un código que nadie escribió en el sentido tradicional, generado a partir de una conversación que ya no existe, guiado por decisiones que no están documentadas. No va a poder reconstruir por qué se hizo así. Va a tener que, en el mejor de los casos, volver a entender todo desde cero, o peor, volver a vibe-codear encima, acumulando capas de decisiones sin registro sobre decisiones sin registro. Lo vi venir clarísimo en esa sesión, y me incomodó, porque era exactamente el tipo de deuda que tardamos años en aprender a evitar y que esta forma de trabajar reintroduce por una puerta nueva.
Lo que no se organiza, la IA lo completa sola#
Hay otra cosa que entendí casi al mismo tiempo, y que tiene que ver con cómo le hablamos a la IA. Cuando uno hace vibe coding, le da pedidos en lenguaje natural, muchas veces vagos, casi siempre incompletos. Y la IA, lejos de detenerse a preguntar, completa los huecos. Toma decisiones. Elige una estructura, una librería, un patrón, un enfoque. Lo hace con una seguridad que es convincente y, hay que decirlo, a menudo razonable. El problema es que esas decisiones quedan invisibles. Uno ve el resultado funcionando y asume que las decisiones de fondo fueron buenas, cuando en realidad nunca las revisó, ni siquiera supo que se habían tomado.
En un proyecto personal, da igual. Si funciona, funciona. Pero en un producto de software de empresa, esas decisiones invisibles son precisamente las que después se pagan caro. Una librería que no deberíamos haber sumado. Un patrón que contradice el resto del sistema. Una validación de seguridad que la IA no puso porque nadie se la pidió. Una lógica de negocio que la IA interpretó a su manera porque el pedido era ambiguo. Cada una de esas cosas, sola, parece menor. Juntas, y multiplicadas por la velocidad a la que el vibe coding genera, construyen un sistema que nadie diseñó del todo y que nadie entiende del todo.
Esto me conecta con algo que vengo pensando hace tiempo y que ya escribí en otro lado: si la IA tiende a completar los vacíos con supuestos, nuestra responsabilidad pasa a ser reducir esos vacíos. No alcanza con pedirle a la IA “hacé esto”; hay que organizar de antemano qué queremos que haga, con qué reglas, con qué límites. El vibe coding, en su forma pura, va exactamente en la dirección contraria: celebra el no organizar, el dejarse llevar, el no pensar demasiado en la estructura. Y eso, que es liberador para explorar, es peligroso para construir algo que va a durar y que otros van a mantener.
El verdadero punto de quiebre: el trabajo en equipo#
Si tuviera que señalar dónde el vibe coding pasa de “herramienta maravillosa” a “problema serio”, no dudaría: es cuando dejamos de ser una persona y pasamos a ser un equipo. Y acá hablo desde lo que conozco, desde haber estado en empresas de software con equipos de varias personas trabajando sobre los mismos sistemas. Porque una cosa es que yo vibe-codee mi prototipo, solo, entendiendo —o asumiendo que entiendo— lo que está pasando. Otra muy distinta es imaginar a cinco, diez, quince personas vibe-codeando en paralelo sobre el mismo producto, cada una con su conversación privada con la IA, cada una tomando decisiones que no quedan registradas, cada una generando código a una velocidad que nadie alcanza a revisar.
Pensemos qué significa eso en concreto. En un equipo, el código no es solo código: es un lenguaje común. Es la forma en que nos coordinamos, en que entendemos lo que hizo el otro, en que repartimos el trabajo sin chocarnos. Cuando alguien escribe código a mano, deja pistas: nombres, estructura, comentarios, commits, una lógica que otro puede seguir. Cuando ese código sale de conversaciones efímeras con una IA, multiplicadas por la cantidad de personas del equipo, esas pistas se diluyen. De repente tenemos un sistema construido por muchas manos a través de muchas conversaciones que nadie más vio, donde la coherencia que antes nos daba el lenguaje común del código empieza a resquebrajarse.
Y la velocidad, que en lo individual es una bendición, en lo colectivo se vuelve un agravante. Porque el cuello de botella del desarrollo nunca fue solamente escribir código. Fue entenderlo, coordinarlo, integrarlo, revisarlo, mantenerlo. El vibe coding acelera muchísimo la parte de escribir, pero no acelera —y en algunos casos empeora— la parte de entender y coordinar. Un equipo que produce diez veces más código del que puede revisar y comprender no es un equipo diez veces más productivo: es un equipo que está acumulando, diez veces más rápido, una deuda que va a pagar después. Lo dije una vez y lo sostengo: más código no es mejor software. Y más código generado sin registro, en equipo, es la receta más rápida que conozco para un caos difícil de gobernar.
Una preocupación aparte: los que recién empiezan#
Hay un costado de todo esto que me preocupa de una forma distinta, más a largo plazo, y tiene que ver con quienes están aprendiendo a programar ahora, en plena ola del vibe coding. Cuando yo aprendí, no había atajo: para que algo funcionara, había que entender por qué funcionaba. El error me obligaba a aprender. La fricción, que tantas veces maldije, era también la maestra. Cada bug que peleaba durante horas me dejaba un conocimiento que no se olvida. El que recién empieza hoy puede saltarse buena parte de esa fricción, y eso tiene una cara luminosa —puede construir cosas mucho antes, mantenerse motivado, ver resultados— pero también una sombra que no conviene ignorar.
Mi temor es que se confunda “lo logré” con “lo entiendo”. Que alguien junior, deslumbrado por la velocidad, acumule la sensación de competencia sin la competencia. Porque el día que el sistema falle de una manera que la IA no puede resolver sola —y ese día llega, siempre llega— el que no construyó los fundamentos va a quedar a la intemperie. No va a poder depurar lo que no entiende. No va a poder distinguir una buena sugerencia de la IA de una mala, porque para juzgar hace falta saber. La IA puede acelerar muchísimo a alguien que ya tiene criterio, pero a alguien que todavía no lo tiene puede darle una falsa autonomía que se derrumba en el primer problema serio.
No estoy diciendo que los que empiezan ahora no deban usar vibe coding. Sería ridículo e inútil pedir eso. Lo que digo es que, como industria y como personas que formamos equipos, tenemos una responsabilidad nueva: asegurarnos de que la herramienta no se coma el aprendizaje. Que vibe-codear sea una puerta de entrada al entendimiento, no un reemplazo de él. Que el junior que genera código con IA también sea empujado, con cariño pero con firmeza, a entender qué generó y por qué. Porque la abstracción siempre fue parte de la programación —nadie programa hoy en código de máquina— pero hay una diferencia entre apoyarnos en una abstracción que entendemos y delegar en una caja negra que no. La primera nos hace más productivos. La segunda nos vuelve frágiles.
Hay un dato de estas semanas que me dejó pensando. Se reportó que alrededor de una cuarta parte de las startups de un lote reciente de Y Combinator tenían bases de código generadas casi en su totalidad por IA. Es un número enorme, y a primera vista parece la prueba de que el vibe coding ya es el futuro del desarrollo profesional. Pero yo lo leo distinto, y la diferencia es crucial.
Una startup en etapa muy temprana es, en muchos sentidos, un prototipo gigante. Está buscando si su idea tiene sentido, está iterando rapidísimo, está dispuesta a tirar todo y empezar de nuevo si hace falta. En ese contexto, el vibe coding es ideal: la velocidad vale más que la mantenibilidad, porque tal vez ese código ni siquiera exista en seis meses. Pero esa lógica no se traslada automáticamente a una empresa de software establecida, con clientes que dependen del sistema, con código que tiene que vivir años, con equipos que tienen que coordinarse, con cumplimiento, con seguridad, con responsabilidad sobre lo que está en producción. Confundir “esto funciona para una startup de tres personas que prototipa” con “esto funciona para cualquier desarrollo de software profesional” es, me parece, uno de los errores de interpretación más peligrosos de este momento.
El propio Karpathy fue cuidadoso al encuadrarlo en proyectos desechables. Willison fue explícito al decir que vibe-codear hasta una base de código de producción es claramente una mala idea, y eso lo dice alguien que ama estas herramientas. El problema no es lo que dijeron los que pensaron el concepto. El problema es cómo el entusiasmo colectivo le borra los matices a las ideas. “Vibe coding” empezó siendo un nombre para una práctica específica y acotada, y en cuestión de semanas se está convirtiendo en una etiqueta para todo el desarrollo con IA, perdiendo justamente la advertencia que venía incluida en el paquete original.
Entonces, ¿qué hacemos? Ni prohibirlo ni rendirnos#
Quiero ser claro en algo, porque sería fácil leer todo esto como una condena, y no lo es: no estoy en contra del vibe coding. Lo usé, me cambió la forma de ver las cosas, y voy a seguir usándolo. Estoy en contra de usarlo sin entender dónde sirve y dónde se vuelve peligroso. Y creo que el camino no es ni prohibirlo en las empresas —sería absurdo, además de inútil, porque la gente lo va a usar igual— ni adoptarlo sin reglas, dejándonos llevar por las vibras hasta que un día nos demos cuenta de que tenemos un producto que nadie entiende.
Me parece que la clave está en separar los contextos con honestidad. Para explorar, prototipar, validar ideas, construir herramientas internas descartables o destrabar un experimento, el vibe coding es excelente, y restringirlo ahí sería matar su mejor virtud. Pero para el código que va a producción, que van a mantener otros, que tiene que durar y coordinarse en equipo, hace falta algo más. Hace falta recuperar, adaptadas a esta nueva forma de trabajar, las cosas que aprendimos a los golpes: versionar no solo el código sino la intención, registrar las especificaciones y las decisiones, organizar de antemano qué queremos que la IA construya en lugar de improvisarlo en una conversación, y revisar de verdad lo que se genera antes de aceptarlo. En cierto sentido, el desafío es traer disciplina a una práctica que nació, justamente, como la celebración de la falta de disciplina.
Y esto me lleva a una idea que me da vueltas y que dejo como debate abierto, porque no tengo la respuesta cerrada. Quizás lo que necesitamos no es elegir entre vibe coding y desarrollo riguroso, sino construir una forma nueva que tome la velocidad del primero y la disciplina del segundo. Una forma donde la conversación con la IA no se evapore, sino que quede versionada como un artefacto más del proyecto. Donde antes de vibe-codear algo serio, el equipo haya acordado y escrito qué quiere lograr, con qué reglas, con qué límites, de modo que la IA tenga contexto y no tenga que rellenar huecos con supuestos. Donde la revisión humana siga siendo innegociable para lo que va a producción. No sé todavía qué forma exacta va a tomar eso, ni qué herramientas lo van a soportar, pero intuyo que ahí está parte de hacia dónde tenemos que mirar.
Versionar la intención: una idea para dejar sobre la mesa#
Quiero detenerme un poco más en esa idea que mencioné antes, la del versionado de la intención, porque creo que ahí hay algo que vale la pena discutir en serio y que todavía nadie resolvió bien. Pensémoslo despacio. Hoy versionamos el código, que es el resultado. Pero en el vibe coding, el resultado se genera a partir de algo que no versionamos: la conversación, los prompts, el contexto, las decisiones que la IA tomó por nosotros. Es como si guardáramos la foto final pero tiráramos los negativos, el guión y las notas de dirección. Mientras el código lo escribíamos a mano, esa pérdida no dolía tanto, porque la intención quedaba más o menos impresa en el propio código. Cuando el código nace de una conversación efímera, la pérdida se vuelve grave.
¿Y si empezáramos a tratar la especificación —lo que queremos que el sistema haga, con qué reglas, con qué límites— como un artefacto de primera clase del proyecto, versionado junto al código, evolucionando con él? No hablo de volver a los documentos de requisitos eternos de hace veinte años, esos que nadie leía y que envejecían antes de terminarse. Hablo de algo más vivo: un registro conciso y mantenido de la intención, que sirva tanto para que un humano nuevo entienda el porqué como para darle a la IA el contexto que necesita para no rellenar huecos con supuestos. Si la IA va a construir a partir de lo que le decimos, entonces lo que le decimos merece el mismo cuidado que le damos al código. Merece versionarse, revisarse, discutirse en equipo.
Lo dejo planteado como debate, no como receta, porque honestamente no sé todavía qué forma va a tomar ni qué herramientas lo van a soportar. Tal vez surjan formatos nuevos para esto. Tal vez los repositorios incorporen la especificación y el contexto de IA como parte natural de lo que guardan. Tal vez aparezca una disciplina entera alrededor de cómo darle contexto estructurado a la IA en un equipo, igual que en su momento apareció toda una disciplina alrededor del control de versiones. Lo que sí intuyo es que las organizaciones que resuelvan bien este problema —cómo combinar la velocidad del vibe coding con un registro versionado de la intención— van a tener una ventaja real sobre las que sigan generando código a la velocidad de la luz sin saber, dentro de seis meses, por qué su sistema hace lo que hace. La velocidad sin memoria es deuda. La velocidad con memoria es productividad. La diferencia está, justamente, en lo que decidamos versionar.
El rol del que lidera, otra vez en el centro#
Si hay algo que esta sacudida me confirma, es que el rol de quien conduce equipos de tecnología se vuelve más importante, no menos. Cuando aparece una herramienta tan seductora y tan veloz, la tentación del equipo es lanzarse a usarla sin acuerdos, cada uno por su lado. Y el trabajo de liderar, en parte, es no apagar ese entusiasmo —sería un error matarlo— sino encauzarlo. Crear el espacio para que el equipo experimente con vibe coding donde tiene sentido, y al mismo tiempo establecer con claridad qué no aceptamos sin revisión, qué información sensible no se pega en una herramienta externa, cómo registramos las decisiones tomadas con ayuda de IA, qué nivel de comprensión exigimos del código que llega a producción.
No es control por el control mismo. Es la diferencia entre un equipo que usa una herramienta poderosa con criterio y uno que es usado por la herramienta. Y esa diferencia, en una empresa de software, se nota rápido: en la calidad de lo que se entrega, en cuánto cuesta mantenerlo, en cuántos incidentes aparecen, en si las personas todavía entienden el sistema que construyen o si pasaron a ser meros intermediarios entre el cliente y una IA que nadie supervisa de verdad. Liderar en esta época es, cada vez más, ayudar a la gente a distinguir entre la velocidad que suma y la velocidad que esconde problemas.
Lo que me queda dando vueltas#
Termino donde empecé, con esa tensión del primer día. El vibe coding me deslumbró y me asustó casi en el mismo momento, y con el tiempo entendí que esas dos reacciones no se contradicen: las dos son correctas. Es una de las cosas más entusiasmantes que vi en años, y también una de las que más fácil puede salirse de control si la llevamos a contextos para los que no fue pensada. La magia es real. El riesgo también. Y la madurez, como casi siempre, no está en quedarse con una sola de las dos verdades, sino en sostener las dos a la vez.
Me quedo con varias preguntas, más que con conclusiones, porque creo que este tema recién empieza y cualquier certeza hoy sería apresurada. ¿Cómo versionamos la intención y no solo el código? ¿Cómo trabajamos en equipo con vibe coding sin perder el lenguaje común que nos coordina? ¿Cómo aprovechamos su velocidad para explorar sin dejar que esa velocidad nos arrastre a producción? ¿Cómo enseñamos a los que recién empiezan a usar esta herramienta sin que confundan “funciona” con “está bien hecho”? No tengo todas las respuestas, y desconfío de quien diga que las tiene a tres semanas de que el término existe.
Lo que sí tengo es una convicción, formada en esa primera sesión donde el deslumbramiento y la alarma convivieron: el vibe coding no es el problema ni la solución. Es una herramienta nueva y potente que nos obliga, una vez más, a hacernos las preguntas de siempre con una urgencia nueva. Qué queremos construir, para qué, con qué cuidado, y quién se hace responsable cuando lo que generamos en una conversación de cinco minutos termina, sin que nos diéramos cuenta, sosteniendo algo que importa. Se los dejo para que lo piensen en su propio terreno: la próxima vez que una herramienta nos haga sentir que el trabajo se volvió mágicamente fácil, ¿esa facilidad está resolviendo el problema, o solo lo está corriendo unos meses hacia adelante, hacia el momento en que alguien —quizás nosotros mismos— tenga que entender lo que nadie se detuvo a entender?
Fuentes consultadas#
- Andrej Karpathy, publicación original sobre “vibe coding” en X, 2 de febrero de 2025.
- Benj Edwards, “Will the future of software development run on vibes?”, Ars Technica, 5 de marzo de 2025.
- Simon Willison, “Not all AI-assisted programming is vibe coding (but vibe coding rocks)”, 19 de marzo de 2025.
- Ivan Mehta, “A quarter of startups in YC’s current cohort have codebases that are almost entirely AI-generated”, TechCrunch, 6 de marzo de 2025.
- John Naughton, “Now you don’t even need code to be a programmer. But you do still need expertise”, The Observer, 16 de marzo de 2025.