El código vibe es código legacy

• La vibe coding es una forma de escribir código rápidamente siguiendo la intuición con ayuda de la IA, y al final deja código que no se entiende, es decir, código legacy
• El código legacy es código que nadie entiende, lo que genera deuda técnica y problemas de mantenimiento, además de aumentar la probabilidad de errores al agregar nuevas funciones
• La vibe coding puede ser una forma rápida de desarrollar prototipos o proyectos de corto plazo, pero no es adecuada para proyectos que deban mantenerse a largo plazo
• Cuando una persona no especialista hace vibe coding en un proyecto grande, existe un riesgo comparable a darle una tarjeta de crédito a un niño
• Incluso en 2025, al desarrollar con IA sigue siendo importante mantener la cautela y la comprensión del código

---

¿Qué es la vibe coding?

• Andrej Karpathy definió el término "vibe coding" como una forma de programar en la que la IA escribe el código y la persona usuaria presta tan poca atención que casi se olvida de que el código existe
• Este enfoque se diferencia del desarrollo de software tradicional porque permite obtener resultados sin entender en absoluto el funcionamiento interno del código generado

El problema del código legacy y la deuda técnica

• El código que nadie entiende ya es código legacy
• Este tipo de código requiere mucho tiempo de mantenimiento y hace que los problemas aumenten mucho más cuando aparecen bugs o se intentan agregar nuevas funciones
• Se enfatiza que la esencia de programar no es producir mucho código, sino construir una teoría conceptual

Vibe coding y prototipado

• La vibe coding ofrece una entrada rápida y desarrollo ágil para crear prototipos o proyectos desechables
• Si no hace falta mantenimiento posterior, no conocer el interior del código no representa una carga tan grande
• Por eso puede acelerar mucho el desarrollo y resulta muy adecuada para experimentar con ideas nuevas

El espectro de comprensión en la vibe coding

• La vibe coding funciona de modo que, cuanto menor es la comprensión que tiene la persona desarrolladora sobre el código, más fuerte es el vibe
• Básicamente, mientras más claramente entienda una persona de ingeniería los requisitos, menos vibe coding habrá
• Si alguien que no programa pide código sin saber la diferencia entre la web y una app nativa, ni cómo se almacenan los datos, normalmente se produce mucha más vibe coding

Vibe coding a gran escala por parte de no especialistas: se parece a una tarjeta de crédito

• Que una persona no especialista intente crear y mantener un proyecto grande con vibe coding se parece a darle una tarjeta de crédito a un niño sin explicarle el concepto
• Al principio puede parecer que todo es fácil, pero después llegan enormes costos de mantenimiento y muchos problemas
• Al final, cuando llega la "factura", si no se tiene la capacidad de resolver los problemas, la situación puede empeorar aún más

Desarrollo serio en la era de la IA en 2025

• Andrej Karpathy enfatiza que, al desarrollar con IA, es indispensable mantener prudencia, cuidado y una actitud de aprendizaje continuo sobre el código existente
• Es importante defenderse de la confianza exagerada de la IA y conservar el criterio humano para distinguir entre buen código y mal código
• No hay que simplemente dejárselo todo a la IA; es indispensable leer y entender el código personalmente

Uso de herramientas de IA en Val Town

• Val Town automatiza la escritura, ejecución, verificación y mejora iterativa del código mediante un asistente de IA llamado Townie
• Townie es una herramienta adecuada para la vibe coding y puede usarse con libertad o bajo control estricto según el caso de uso
• La forma de desarrollar con IA está evolucionando muy rápido, y la importancia de una base teórica en el desarrollo de software complejo seguirá vigente

Advertencia sobre la vibe coding indiscriminada por parte de no especialistas

• No es una buena idea que personas no programadoras gasten miles de dólares en hacer vibe coding para una idea de app enorme
• En última instancia, siempre hace falta el ojo humano para leer y analizar directamente el interior del código, y suele ser más efectivo rediseñar bien desde cero que intentar arreglar código legacy incomprensible

Conclusión y consejo

• Al construir software complejo, la base teórica es clave
• Aunque la forma de programar cambia rápidamente con el avance de la IA, la experiencia del desarrollador humano sigue siendo importante
• Si una persona no especialista intenta crear una app a gran escala con IA, al final puede ser mejor leer todo el código y volver a construirlo

[servent2616]

La comparación de que es como darle una tarjeta de crédito a un niño
es una comparación apropiada.
O también podría compararse con darle un cuchillo a un niño.

[actofvalor]

Si aparece una IA para generar código que además agregue comentarios y dibuje diagramas de flujo del código, sería de cierta ayuda.

[draupnir]

Es una opinión con la que coincido bastante. De hecho, ya me ha tocado vivirlo un poco…
Y también me da curiosidad ver cómo irá cambiando esta parte según evolucione el rendimiento de los modelos.

[optionzero]

Es tan cierto que no pude evitar asentir. La gente que no sabe de código dice "wow" cuando hace vibe coding, pero la gente que sí sabe de código dice "¿por qué? así".

[qscwdv531]

El estado de los comentarios es lamentable.

[kgun9]

Entonces, ¿eso significa que no se puede conducir un automóvil jamás hasta entender por completo toda su estructura interna?

[onetoday]

Construir un auto sin entender su estructura interna = vibe coding

[hackerst]

Se puede usar. Pero no se puede crear.

[sinbumu]

Creer que es un problema de método y tecnología, y que en vez de usar IA hay que hacer código orgánico a mano, es como la gente que dice que la verdad está en usar un ábaco en lugar de una calculadora científica o escribir todo a mano en vez de usar funciones de Excel.

[elbanic]

Es una analogía equivocada. Una calculadora de ingeniería, al igual que una calculadora común o Excel, entrega resultados exactos según los valores de entrada. Si la IA simplemente devolviera exactamente el resultado que el usuario previó, no sería una tecnología tan distinta de tantas otras nuevas tecnologías que han aparecido hasta ahora. Esa es también la razón por la que, con el tiempo, aumentan las preocupaciones sobre la seguridad y las alucinaciones. Es decir, no se puede controlar la IA generativa. Hay que entender las limitaciones actuales de los LLM y usarlos en los lugares adecuados.

[tensun]

Actualmente, el vibe coding está apenas en su etapa inicial, y creo que el próximo año o el siguiente se convertirá en una metodología de desarrollo madura. Así como devops se vuelve aidevops, pienso que también surgirá aiagile o vibeagile.

[GN⁺]

Opinión de Hacker News

• Es una historia sobre un amigo no desarrollador. El año pasado lanzó un SaaS programándolo él mismo y empezó a generar ingresos casi sin marketing, solo con boca a boca e inbound. Usó Replit y Supabase para desarrollarlo y, considerando que la app se fue volviendo cada vez más compleja a medida que recibía feedback de clientes, me parece realmente impresionante. Según yo, ya había dos proveedores establecidos en ese mercado, y como mi amigo ofrecía un producto más moderno con una tarifa mensual mucho más barata, parece que no quedaron nada contentos con eso (los productos existentes eran todos software de escritorio para Windows). Entonces contrataron a un hacker para atacar el SaaS de mi amigo, y estos hackers atacaron sin pedir dinero. Por desgracia, como mi amigo programó rápido y sin experiencia, había muchas vulnerabilidades. Primero, la lista de usuarios estaba expuesta en el código del frontend, así que el hacker terminó enviando correos a todos los clientes. Segundo, el hacker consiguió las claves de Stripe y procesó reembolsos para todos los clientes. Tercero, el hacker sigue intentando ataques XSS y a veces todavía aparecen etiquetas como <script>alert()</script> en algunos campos. Mi conclusión es que, cuando alguien sin experiencia hace vibe coding, la deuda técnica se acumula de inmediato. Pero al mismo tiempo, es sorprendente que esta persona haya demostrado en solo unos meses que había un producto con potencial de negocio, sin experiencia en ingeniería. Ahora está contratando desarrolladores para reforzarlo. Demostró una posibilidad de negocio razonable invirtiendo solo unos cientos de dólares en un código flojo y vulnerable, así que al final creo que el proceso sí valió la pena

  • Me parece que asumir que fueron los competidores es más bien una forma de evadir responsabilidad. En realidad, es más probable que un escáner automatizado de vulnerabilidades haya detectado el sitio y, como era tan endeble, algún hacker entró a curiosear o hacer travesuras. Quienes suelen ver este tipo de tráfico de exploits en servicios conectados a internet lo saben bien

  • Esto es moralmente equivalente a construir una casa sin experiencia en ingeniería y que luego alguien llegue, le dé una patada y la derrumbe. El problema no es el vibe coding en sí, sino la falta de conocimiento necesario para tomar decisiones importantes. Este tipo de problema incluso puede terminar en responsabilidades legales

  • Si ya había proveedores establecidos en el mercado, ¿de verdad hacía falta un MVP así para demostrar viabilidad? En esencia, si lo ofreces más barato, no hace falta probar si la gente se cambiaría del proveedor actual. La lección que aprendió tu amigo es que algunos clientes sí pagarán al principio (sin datos de retención), pero al final tendrá que contratar gente para construir un producto real, y cuando eso pase también perderá competitividad en precio. Cuando llegue el momento de invertir de verdad en marketing, va a tener mucho en qué pensar. Al final se vuelve a confirmar lo de siempre: las ideas por sí solas no valen nada; lo que importa es la capacidad de ejecución

  • El problema de fondo en esta industria es que tu amigo puede seguir operando el negocio sin prácticamente ninguna responsabilidad. Si el software estuviera regulado con el mismo rigor que otras ramas de la ingeniería, un desarrollador o una empresa tendrían que asumir responsabilidad legal por filtrar información de clientes

  • Aunque el negocio en sí haya quedado validado, para el cliente puede haber sido una pérdida y no una ganancia. Está pagando por usar algo mientras expone datos importantes en un entorno inseguro, y ni siquiera está claro si el producto funciona correctamente. Ahora dices que va a contratar desarrolladores para arreglarlo, pero no será tan fácil como parece. Estoy a favor de usar IA como material de aprendizaje, herramienta de productividad o apoyo educativo, pero cuando no hay una persona en medio, el resultado puede ser terrible

• Antes ya pasó muchas veces que personas no desarrolladoras o desarrolladores junior creaban y distribuían aplicaciones fácilmente con Microsoft Access, Excel y similares. También entonces hubo límites, problemas de escalabilidad y pesadillas de mantenimiento, pero al mismo tiempo esa tendencia empujó a los desarrolladores profesionales a crear mejores soluciones. Pasó lo mismo con la masificación de la PC: los desarrolladores de mainframe se horrorizaban al ver el código “desastroso” del mundo PC

• Llevo casi más de treinta años trabajando como ingeniero de software y he leído todos los comentarios de esta publicación. Y aun así, creo que casi todos los argumentos que critican el vibe coding aplican igual a prácticamente todas las bases de código “escritas por humanos” que he visto durante mi carrera (aunque claro, hay excepciones)

  • No entiendo por qué sería malo hacer un prototipo pensado para desecharse. Es la etapa más importante al iniciar un negocio. Lo mismo pasa con el código legacy. De hecho, es muy probable que la mayoría del código que realmente genera ingresos ya sea considerado legacy a ojos de los desarrolladores dentro de esa organización

  • Como chiste, se dice que en cuanto algo se mergea a trunk, ya pasa a ser código legacy

  • Estoy algo de acuerdo, pero el problema del vibe coding es que permite abordar las cosas a la fuerza, sin investigar bien, sin estudiar la estructura del codebase existente ni cuál es realmente la solución necesaria. Apenas ayer, un colega que no domina Rust creó una función nueva con vibe coding y, aunque por fuera “funciona”, en realidad es un desastre total (I/O síncrono dentro de un contexto async de tokio, locks, implementación propia de canales, etc.). Ya existían abstracciones async seguras y aun así creó unas nuevas y mal hechas. Si hubiera investigado por su cuenta o pedido ayuda primero, podría haber tomado ejemplos del código existente

• Todo código se vuelve legacy en algún momento. Viéndolo desde mi experiencia revisando infinidad de scripts de producción y código de servicios que escribí cuando era junior, y también los que escribieron otros juniors con los que trabajé, esta visión absolutista me parece excesiva. Este problema se repite en la mayoría de las organizaciones. Entiendo escribir artículos criticando la calidad del código generado con LLM, pero cualquiera que haya pasado su carrera arreglando, extendiendo o refactorizando sistemas hechos por otros conoce bien esta realidad. Mientras el mundo de la ingeniería de software no incorpore estándares estrictos de consistencia, certificación, responsabilidad y consecuencias reales como en la ingeniería mecánica, esta discusión tiene poco sentido. La industria moderna de TI está basada en una filosofía completamente opuesta: ‘agile’, “hazlo rápido y no pasa nada si se rompe”. Se lanza rápido, con poco diseño, con frecuencia, y si algo sale mal se revierte; si hay una caída, se asume como “cosas que pasan”. El software es tratado como si fuera un juguete. Quizá el 1% presume que lo hace bien, pero la mayoría no

  • Todo lo que dices es cierto, y sumaría además que el código al final no es una ciencia. El criterio de lo que es código “correcto” siempre depende del contexto. El código no es más que una herramienta para alcanzar un objetivo

• Está pasando algo interesante ahora mismo. Gente que no entiende bien la ingeniería, y hasta cierto punto también gente que sí sabe pero no lo explica bien, está difundiendo una narrativa equivocada en internet. Ahora dicen que los desarrolladores junior son 10 veces más productivos y que hasta los PM están desplegando código por su cuenta. Pero si uno cierra los ojos un segundo e imagina el código que sale de ese contexto, es 100% código legacy y código desechable. El fondo del asunto no es que la IA o un PM puedan sacar código directo desde Figma, ni que un junior se la pase lanzando prompts. La razón real de la brecha entre expectativas y realidad es que ya no se distinguen correctamente términos y conceptos que originalmente se definieron durante años de discusión.
  Un prototipo lean y un prototipo desechable ni siquiera son lo mismo (ni hablar de un MVP). Un MVP solo puede construirse después de validar con éxito un prototipo lean. Y un producto es otra cosa distinta de un MVP.
  Las herramientas de vibe coding son excelentes para crear prototipos desechables rápido, mientras que un IDE con LLM integrado es más adecuado para crear un producto real. En esta etapa, solo los ingenieros de verdad están en nivel de programar prototipos lean con prompts de LLM; el resto solo produce software simple que funciona con código desechable

  • Cuando dices “un producto es distinto de un MVP”, me dan ganas de decírselo a casi todas las empresas donde he trabajado. Hoy en día abundan directorios y ejecutivos C-level con la actitud de “saquen lo que sea antes de que termine el trimestre”, así que los desarrolladores hacen un MVP y enseguida los mandan al siguiente proyecto. Independientemente de si hubo vibe coding o no, la realidad es que si parece tener muchas funciones, los indicadores de negocio suben aunque la calidad real sea mala. De hecho, no son tantos los entornos donde un ingeniero de verdad (que ahora parece ser como le llaman a “desarrollador”) lidere el prototipado. Tal vez se ve en juegos o en algunas empresas tech. La mayoría está enfocada únicamente en producir MVPs. El vibe coding solo acelera esa fábrica de MVPs, y la calidad se sacrifica en la misma proporción

  • En los últimos 10 años se ha hecho mucho más visible en la industria la tendencia a mezclar “definiciones de términos” sin sustancia. Estas palabras venían cargadas de contexto construido a lo largo de muchísimos libros, discusiones y años de debate. Cuando un desarrollador experimentado usaba una palabra, llevaba dentro toda esa experiencia y ese contexto. Pero los recién llegados “copian” los términos superficialmente, sin ese trasfondo ni una definición clara, y los usan así nada más. Como resultado, nadie entiende ya qué significaba originalmente cada término ni por qué era la palabra adecuada para esa situación. Por ejemplo, "'agile', 'technical debt', 'DevOps', y el más reciente ‘vibe coding'", etc. En HN también apareció una publicación sobre semantic drift. Es algo bastante común en la industria del software.
    Como ejemplo técnico, en JavaScript muchas veces se usan mezclados 'object', 'JSON', 'dictionary' y 'hashmap'. Originalmente significan cosas distintas, pero para muchos desarrolladores JS todo termina siendo simplemente ‘object’. Es como si toda la resolución lingüística y conceptual quedara aplastada en un solo “píxel”

  • Antes los desarrolladores hablaban de que cada quien tenía una “actitud” distinta frente al código. Pero ahora el agotamiento de los desarrolladores por no entender el código se ha disparado muchísimo. Antes, cuando eso pasaba, el ingeniero intervenía para arreglar de forma útil lo que estaba roto y el arquitecto reducía la complejidad. Ahora, en la era de los LLM, se está vertiendo 100 veces más código, pero justo los ingenieros y arquitectos están completamente excluidos de ese flujo. Esa es la situación que estamos viviendo en carne propia.
    Si alguien inventa una forma de probar y resolver este problema (un servidor MCP para TDD, un servidor MCP para DDD o cualquier workflow/arquitectura), ahí hay potencial para una startup multimillonaria. Hace muchísima falta una herramienta que aumente drásticamente y escale la eficiencia del code review

  • Creo que primero hay que definir mejor qué es “software que funciona”. Por ejemplo, las UI hechas por LLM se ven todas iguales y suelen estar sutilmente mal o esconder errores. Basta una sola prueba con usuarios para que los problemas salten a la vista. Además, la UI generativa ya parece estar obsesionada solo con seguir tendencias, sin crear nada realmente nuevo

  • ¿Has visto cómo se escribe el código interno en las grandes empresas? No es muy distinto del vibe coding. De hecho, si ajustas un LLM para que pase pentests, al menos intenta hacer algo. Las grandes empresas ni siquiera muestran interés

• En realidad, todo código es legacy. Así que no hay nada especialmente nuevo en que el vibe coding produzca código rápido y en gran cantidad. Al final, incluso el “código escrito por mi propia mano” que nadie entiende termina siendo igual de desastroso. Todo código es una carga desde la perspectiva del mantenimiento. Las librerías solo pueden aliviar parte del problema, pero cuando cambian mucho o sus interfaces se quedan anticuadas, se convierten en un legacy todavía peor.
  Cuanto más tiempo lleva alguien programando, más tiende a concluir que la verdadera respuesta es hacer menos: reducir en general la necesidad misma. Toda complejidad termina convirtiéndose en “un problema que mi yo del futuro no va a recordar”. Y la verdad es que los requisitos también cambian a cada rato, e incluso los requisitos dados por expertos pueden estar equivocados (y ese “experto” podrías ser tú mismo)

  • No estoy de acuerdo con la idea de que “todo código es legacy”. Algunas cosas son pequeñas y el desarrollador todavía las tiene enteras en la cabeza, así que el código sigue siendo completamente “en tiempo real”. La definición práctica de legacy es código enorme que ya no tiene ningún dueño actual dentro de la organización. El código hecho con vibe coding cumple ambas condiciones desde el momento en que se genera

  • Legacy significa que ya no quedan stakeholders y por eso mantenerlo y entender su contexto se vuelve difícil

  • Ojalá pudiéramos resolver los problemas con la menor cantidad de código posible. La clave es lograr que el código no tenga que ser mi problema. Lo importante es cuánto “filtra” una abstracción, y las abstracciones que están generando los LLM ahora mismo son bastante malas. No está claro cuánto mejorarán en el futuro.
    Me gustaría invertir en herramientas que hagan más divertido, fácil y barato entender el código. Mi amigo Glen tiene un proyecto que puede servir de referencia: https://glench.github.io/fuzzyset.js/ui/
    Como dice Geoffrey Litt, los LLM pueden ser mucho más útiles para crear visualizaciones temporales, depuradores y otras herramientas que nos ayuden a entender nuestro código

  • Todo código conlleva riesgo, pero no todo código es legacy. El código hecho con vibe coding se siente legacy desde el principio porque nace sin contexto ni dueño

  • Como respuesta a la idea de que todo código es legacy: cuando en un proyecto que entiendo profundamente puedo detectar de inmediato la causa de un bug y visualizar en mi cabeza cómo implementar una nueva función, eso no es legacy

• Creo que la época de “ver el código matemáticamente” ya terminó. En software lo bastante grande y conectado con el mundo real, no se puede garantizar que sea perfectamente verdadero como una prueba matemática. Los sistemas reales son productos de ingeniería que dependen de garantías formales, diseño basado en experiencia, pruebas experimentales, know-how y criterios de rendimiento.
  Esa tendencia se va a extender incluso hasta los scripts más pequeños. La mayoría del software ni siquiera necesita estar demostrado matemáticamente. Solo tiene que cumplir su propósito. Respeto completamente el oficio de programar, pero creo que ya es momento de soltar esa parte.
  En resumen, el futuro ofrece dos opciones:

• un programa de 100,000 líneas y 50,000 pruebas que garantiza todos los requisitos pero que casi nadie puede leer, con un costo total de 50,000 dólares (costo de tokens de API)

• uno diseñado por humanos, de 30,000 líneas, 3,000 pruebas, abstracciones elegantes, que cumple los mismos requisitos, con un costo total de 300,000 dólares (salarios de desarrolladores)
  Si yo fuera consumidor de software, sin interés en los detalles internos y fijándome solo en el precio, elegiría sin dudar el que cuesta 6 veces menos

  • Hay que pensar en qué pasa cuando se requiere un cambio por una nueva exigencia externa. En esos casos, si ese software es clave para el negocio, no te queda otra que cambiar de proveedor de inmediato. Por eso el mantenimiento y el soporte siempre importan, tanto en B2B como en B2C. El software siempre tiene que poder adaptarse al cambio

  • De ahí sale el chiste de: “Este código lo entendimos yo y Copilot. Ahora ya solo lo entiende Copilot”

  • Respecto a “no se puede demostrar matemáticamente que un sistema suficientemente grande y conectado al mundo real sea correcto”, la gente que trabaja en verificación formal podría disentir con mucha fuerza... o quizá estar de acuerdo por dentro

  • Entre esos dos escenarios, habría que preguntar cuál sale más barato y más rápido cuando toca actualizar versiones. Hoy por hoy creo que el modelo con desarrolladores humanos sigue siendo más barato, pero del futuro no estoy seguro

  • La verdad es que casi nunca he visto ninguna de esas dos opciones en la vida real

• Quizá la etapa final de evolución sea un lenguaje de programación completamente orientado a máquinas, que los humanos ni siquiera necesiten leer. ¿Por qué un LLM tendría que convertir algo a Python o Swift, lenguajes fáciles para personas, si al final lo único necesario es un resultado ejecutable? Entonces incluso la idea de mantenimiento dejaría de tener sentido. Todavía no estamos ahí, pero siento que eventualmente vamos hacia eso

  • El buen software siempre está en mantenimiento. Las nuevas exigencias nunca dejan de aparecer, así que creer que puedes lanzar una función una vez y terminar para siempre ya es un chiste. Por eso importan el código, las pruebas y la documentación hechos pensando en cambios futuros. Si los LLM se ponen a producir en masa código de caja negra y sin sentido, eso sí da miedo. Pensar que el LLM va a llegar a programar a nivel humano y que a nadie le va a importar ya entra en el terreno de la ciencia ficción. Programar es solo una parte de todo el proceso de crear software realmente útil

  • ¿No es básicamente eso ya el lenguaje de máquina? Los LLM están optimizados para interfaces legibles por humanos, por eso generan JSON y casi nunca BSON

  • Cuesta ver qué problema se supone que esto resolvería. Los problemas que crearía sí están clarísimos

  • Se siente como una especie de “teléfono descompuesto”: el LLM aprende código escrito para humanos, lo vuelve a generar, y luego lo ejecutamos para obtener el comportamiento deseado. A veces pienso si no sería mejor generar directamente la acción

  • Si hablamos de lenguajes difíciles de leer para humanos, Malbolge sería el ejemplo clásico. De hecho, el primer programa "Hello World" también fue generado mediante un algoritmo genético

• Soy el autor original. Me entusiasma conversar sobre esto con ustedes

• El término ‘vibe coding’ es demasiado perfecto. Se parece a cómo ‘cloud computing’ terminó expandiéndose muchísimo. Originalmente significaba levantar instancias EC2 de forma elástica y apagarlas al terminar el trabajo, pero la metáfora era tan intuitiva que hasta Gmail pasó a llamarse “la nube”.