La difusión del término vibe coding

Andrej Karpathy, científico informático eslovaco-canadiense con una destacada trayectoria en inteligencia artificial (IA), particularmente como exdirector de IA en Tesla y cofundador de OpenAI, acuñó el término «vibe coding» en febrero de 2025. Su amplia experiencia en aprendizaje profundo y visión por computadora, incluido su puesto como principal instructor del primer curso de aprendizaje profundo de Stanford, CS 231n, lo posiciona como una voz respetada en la comunidad de IA.

El 2 de febrero de 2025, Karpathy publicó en X/Twitter sobre un nuevo enfoque al que llamó «vibe coding», en el que los desarrolladores «se dejan llevar por completo por las vibras, aceptan los exponenciales y se olvidan de que el código siquiera existe». No fue simplemente otra opinión polémica de un líder tecnológico; fue la cristalización de algo que muchos desarrolladores ya estaban experimentando, pero que aún no tenía nombre.

Karpathy explicó su flujo de trabajo: usar comandos de voz con SuperWhisper para minimizar el uso del teclado, hacer solicitudes sencillas como ajustes de la interfaz de usuario, aceptar habitualmente todos los cambios sugeridos sin examinar las diferencias y, al encontrar errores, simplemente copiarlos y pegarlos de vuelta en la IA. Reconoció que este enfoque hizo que el código creciera «más allá de lo que [él] normalmente podía comprender» y que, a veces, corregir errores consistía en «buscar soluciones alternativas o hacer cambios aparentemente aleatorios hasta que los problemas desaparecieran».

¿Qué es el vibe coding?

El vibe coding es un enfoque deliberadamente informal del desarrollo de software en el que los desarrolladores (incluso quienes no tienen formación, educación ni experiencia formal) usan asistentes de IA para escribir código con muy poca supervisión o comprensión de lo que se está generando. En lugar de revisar cuidadosamente cada cambio, quienes practican vibe coding confían en el resultado de la IA, aceptan todas las modificaciones sugeridas y tratan los mensajes de error como información para devolverle a la IA, en vez de problemas que deben depurar personalmente. Esto no es algo intrínsecamente malo. Es excelente que se escriba más código y que el proceso sea más accesible para personas con menos conocimientos técnicos.

El código en sí pasa casi a un segundo plano; lo que importa es que la aplicación parezca funcionar. Es programar por «vibras» en lugar de comprender, priorizando la velocidad y la iteración por encima de prácticas tradicionales de ingeniería de software, como la revisión del código, las pruebas y mantener un modelo mental de tu base de código. En su forma más extrema, el vibe coding consiste en crear aplicaciones sin poder explicar cómo funciona la mayor parte del código, porque no lo escribiste ni realmente lo leíste.

Está en todas partes

La propagación viral del «vibe coding» ocurrió a la velocidad de internet. En cuestión de horas, Amjad Masad, CEO de Replit, respondió y señaló que aproximadamente el 75 % de la base de usuarios de Replit ya programaba sin escribir código por su cuenta. Esto sugería que Karpathy no había inventado una práctica nueva, sino que le había puesto nombre a algo que ya estaba muy extendido.

Para el 12 de febrero, un hilo de X de @rileybrown_ai que compartía «15 reglas del vibe coding» había recibido más de 10.000 Me gusta. La comunidad tecnológica se lanzó de lleno, creando memes, artículos de opinión y comentarios polémicos a toda velocidad. Un usuario de X, @IterIntellectus, creó un meme de Rick Rubin con audífonos sobre el vibe coding que recibió más de 3.000 Me gusta. Así, Rick Rubin se convirtió en el «rostro» no oficial del vibe coding, una elección adecuada, dada su legendaria manera intuitiva y basada en las vibras de producir música.

El 13 de febrero, Business Insider publicó «El próximo acto de Silicon Valley: llevar el “vibe coding” al mundo», con lo que dio lugar a la primera cobertura importante del concepto en los medios tecnológicos. The New York Times siguió el 27 de febrero con el artículo de Kevin Roose «¿No sabes programar? Con la IA, basta con tener una idea».

El 24 de febrero, Gitpod publicó «El “vibe coding” es una revolución para las personas creativas y optimistas», donde lo describía como «un símbolo de optimismo y una nueva ola» y contaba que había creado calcomanías físicas de «vibe coding» para la AI Engineering Summit.

Quizás el indicador más revelador de su aceptación general: para el 1 de marzo, Merriam-Webster había agregado «vibe coding» como término de jerga y lo había definido como «escribir código de computadora de manera algo descuidada, con ayuda de la IA». De un tuit al diccionario en menos de un mes. Eso no es solo viralidad; es un fenómeno cultural.

Garry Tan, CEO de Y Combinator, informó que el 25 % de las startups de su cohorte de invierno de 2025 tenía bases de código generadas en más de un 95 % por IA. Esto sugería que no se trataba solo de gente experimentando: se estaban creando empresas enteras de esta manera.

Pero a medida que crecía el entusiasmo, también aumentaban las historias de advertencia. A mediados de febrero, el usuario de X @Brycicle77 volvió a compartir una publicación de Reddit en la que alguien lamentaba que su «proyecto creado por completo con Cursor y Claude» se hubiera vuelto inmanejable: «Más de 30 archivos de Python, código desorganizado, bucles duplicados... Claude sigue olvidándose de las importaciones». El pie de foto decía con ironía: «El vibe coding y sus consecuencias».

Pero ¿de verdad las vibras pueden programar?

No de forma segura.

Aquí es donde las vibras chocan con la realidad. Mientras los desarrolladores aceptaban con entusiasmo todos los cambios y copiaban y pegaban mensajes de error, graves vulnerabilidades de seguridad se acumulaban en bases de código de producción.

En un caso muy conocido documentado por investigadores de seguridad, un desarrollador usó IA para crear la estructura inicial de una aplicación SaaS, pero expuso sin saberlo su clave de API de OpenAI en el código del lado del cliente. Los atacantes encontraron la clave filtrada en cuestión de minutos, y el desarrollador «tuvo que negociar con OpenAI para que le perdonaran la factura». Las vibras salieron caras.

Varios proyectos creados con vibe coding tuvieron fallas en sus flujos de autenticación. En una revisión se descubrió que el código de autenticación generado por IA enviaba claves de API de OpenAI por la red en texto sin cifrar, visibles para cualquier usuario mediante las herramientas para desarrolladores.

Un incidente especialmente preocupante involucró un juego web generado por IA que se volvió viral y que también tenía una grave vulnerabilidad de Cross-Site Scripting (XSS), lo que puso en riesgo a miles de usuarios. El desarrollador había creado la aplicación con vibe coding usando ChatGPT y confió en su resultado. Los investigadores de seguridad advierten que los copilotos de IA pueden introducir fallas de inyección SQL, vulnerabilidades XSS y filtraciones de datos si se acepta el código a ciegas.

Una persona que practicaba vibe coding aceptó código recomendado por la IA para un complemento de una comunidad que tenía una falla de sanitización de entradas. Más adelante, esta permitió un ataque XSS almacenado en su sitio, un patrón similar al de las «vulnerabilidades encontradas en complementos de WordPress con poco mantenimiento».

Y no se trataba solo de proyectos individuales. El 18 de marzo de 2025, se descubrió una vulnerabilidad de «puerta trasera en el archivo de reglas» que afectaba a GitHub Copilot y Cursor, dos de las herramientas más populares para practicar vibe coding. Era una vulnerabilidad sistémica en la infraestructura que hacía posible esta práctica.

El patrón quedó claro: el vibe coding acelera notablemente el desarrollo, pero también acelera la introducción de vulnerabilidades de seguridad. Una investigación de Wiz descubrió que una de cada cinco organizaciones que desarrollan en plataformas de vibe coding se expone inadvertidamente a riesgos debido a errores de configuración comunes.

Como lo expresó un analista de seguridad: «La IA no detectó verificaciones de autorización críticas que una persona habría identificado». Se refería a un sistema de autenticación que funcionaba durante las pruebas, pero carecía de una verificación crítica de roles, lo que provocó un error que permitía explotar privilegios de administrador.

¿El problema de fondo? Cuando no entiendes el código que implementas, no puedes evaluar sus implicaciones de seguridad. Las vibras pueden ser impecables, pero no hay ningún modelo de amenazas.

Hacer que el vibe coding sea accesible

A pesar de las preocupaciones de seguridad, aquí está ocurriendo algo realmente revolucionario: la programación se está volviendo accesible para quienes antes no podían participar.

Durante años, hemos hablado de las plataformas «low-code» y «no-code» como las grandes democratizadoras del desarrollo de software. Pero a menudo tenían limitaciones: plantillas rígidas, funciones restringidas y un límite para lo que se podía crear. El vibe coding, en cambio, ofrece algo más cercano a todo el poder de la programación mediante el lenguaje natural.

La programación por voz —usar la voz en vez del teclado— ha ganado mucho terreno junto con el vibe coding, impulsada por los avances en tecnología de reconocimiento de voz, como Whisper de OpenAI. Esta convergencia es especialmente poderosa para la accesibilidad.

La evolución de las herramientas de programación por voz muestra un progreso constante durante 2024. En marzo de 2024, Aqua Voice (una startup de Y Combinator) demostró el creciente interés por la programación por voz al lanzar un editor de texto controlado por voz que afirmaba tener «7 veces menos errores que el dictado de macOS». Herramientas como Serenade, un motor de voz a código de código abierto que permite escribir código usando el lenguaje natural y se integra con editores como VS Code, alcanzaron un alto nivel de madurez.

En la conferencia CSUN Assistive Technology Conference 2025, una sesión sobre IA para programar mostró cómo las herramientas de programación por voz permiten que programadores con discapacidades motoras participen más plenamente en el desarrollo de software. Una persona que participó demostró cómo usar Serenade con GPT-4 para crear una aplicación web únicamente con la voz.

Esto es sumamente importante. La programación ha sido durante mucho tiempo una actividad increíblemente física: horas de tecleo, control motor preciso y navegación por atajos de teclado complejos. Las interfaces de voz combinadas con la asistencia de IA abren las puertas a personas con lesiones por esfuerzo repetitivo, discapacidades motoras u otras afecciones que dificultan o imposibilitan la programación tradicional.

Pero la accesibilidad va más allá de las capacidades físicas. También incluye la accesibilidad cognitiva: poder expresar lo que quieres sin necesidad de conocer la sintaxis, las bibliotecas ni los patrones. Para alguien que comprende a fondo el área de su problema, pero carece de conocimientos de programación, el vibe coding ofrece un puente.

El desafío para quienes diseñan productos y hacen investigación de UX es descubrir cómo lograr que estas interfaces sean seguras y eficaces para usuarios sin conocimientos técnicos. Power Platform Copilot de Microsoft permite crear aplicaciones mediante lenguaje natural. Además, los administradores pueden definir lo que Copilot tiene permitido hacer, para garantizar que los desarrolladores ciudadanos no expongan datos confidenciales sin saberlo.

Salesforce presentó un copiloto de IA que ayuda a los administradores a crear flujos de automatización con instrucciones de texto. Por ejemplo, un administrador de Salesforce puede escribir «Cuando se cree un cliente potencial de alto valor, asígnalo a un representante de ventas sénior y envía una alerta por correo electrónico», y la IA generará un Flow que implementa esa funcionalidad.

Estas plataformas se enfrentan a una pregunta fundamental: ¿cómo dar a usuarios sin conocimientos técnicos el poder de crear software y, al mismo tiempo, protegerlos de peligros que no saben que existen?

Y esta vez, es algo personal

Hay otra dimensión del vibe coding que merece atención: la personalización.

El desarrollo de software tradicional se ha orientado a crear aplicaciones para otras personas, ya sea software empresarial, aplicaciones para consumidores o herramientas de código abierto. Pero ¿y si la manera más rápida de obtener una experiencia personalizada fuera crearla tú, en el momento y mediante una conversación?

Karpathy contó que creó un juego de «Batalla naval» y una aplicación de «lector de texto LLM» en aproximadamente una hora cada uno, dando todas las instrucciones por voz. No eran productos pensados para distribuirse; eran herramientas personales, creadas para su propio uso y adaptadas a sus preferencias.

Esto apunta a un futuro en el que el software se parecerá más a cocinar que a comprar comida preparada. En lugar de elegir de un menú de aplicaciones existentes e intentar adaptarlas a tus necesidades con ajustes y opciones de personalización, tal vez solo tengas que describir lo que quieres y hacer que lo creen para ti.

Ya vemos indicios de esto con la última generación de modelos de IA. Gemini, de Google, está experimentando con el uso de tu historial de búsqueda para personalizar las respuestas. Los modelos entienden cada vez mejor el contexto, recuerdan qué te importa y se adaptan a tus necesidades específicas.

Pero aquí es donde las cosas se ponen interesantes y algo complicadas: a veces, los LLM generan código incorrecto o desactualizado para usar las API asociadas con esos modelos. No se trata de que los modelos conozcan sus propios pesos o su arquitectura; ese sería otro tipo de problema. Es algo más simple y frustrante: modelos como ChatGPT se entrenan con enormes conjuntos de datos que incluyen documentación hasta una fecha de corte determinada. Si su API o SDK cambia después de esa fecha, el modelo no lo sabrá, a menos que se lo ajuste explícitamente más adelante.

Lo he vivido en carne propia. Cuando he intentado usar ChatGPT para escribir código para la propia API de OpenAI, a menudo he recibido sintaxis desactualizada o métodos obsoletos. En el foro para desarrolladores de OpenAI, en noviembre de 2024, un usuario se quejó: "GPT-4 genera constantemente código desactualizado para su propia API en Node.js. Incluso cuando le doy un enlace a la documentación más reciente, lo ignora y devuelve el mismo código de siempre".

La ironía es evidente: las empresas de IA se apresuran a hacer que programar sea más accesible mediante interfaces conversacionales, pero sus propios modelos tienen dificultades para mantenerse al día con sus API, que evolucionan rápidamente. Un usuario señaló que ChatGPT seguía mostrando ejemplos con una versión anterior de la biblioteca openai para Node, con callbacks o nombres de parámetros antiguos, o que usaba endpoints obsoletos, como Completions.create, en lugar del más reciente ChatCompletion.create.

Curiosamente, Claude (de Anthropic) suele generar mejor código para la API de OpenAI que el propio ChatGPT. Quizás se deba a que el entrenamiento de Claude incluyó fuentes más diversas y no dio tanto peso a la documentación antigua de OpenAI.

Esto pone de relieve un desafío fundamental en el intento de los modelos por personalizarse y adaptarse: siempre trabajan con información algo desactualizada. Aunque los límites de conocimiento han mejorado considerablemente (pasaron de más de 18 meses a unos seis u ocho meses), este desfase sigue creando importantes puntos ciegos al generar código para frameworks y API que evolucionan rápidamente.

Al final, solo nos tenemos los unos a los otros

Ampliemos un poco la perspectiva.

Cuando ChatGPT apareció por primera vez, a fines de 2022, la gente no podía creer que la IA pudiera programar. La idea de describir un programa en inglés y obtener código funcional parecía ciencia ficción. Ahora, menos de tres años después, debatimos si es sensato crear aplicaciones enteras a partir de una "vibra", apenas leyendo el código.

La velocidad de esta transformación es realmente desconcertante. Y es fácil enfocarse en los riesgos: las vulnerabilidades de seguridad, la deuda técnica y las pesadillas de mantenimiento. Estas preocupaciones son reales y serias.

Pero aquí también está ocurriendo algo que vale la pena celebrar: cada vez más personas están creando cosas.

Garry Tan, CEO de Y Combinator, elogió la programación por vibra porque permite que los equipos pequeños logren más. Dijo que las herramientas de programación con IA permiten que "10 ingenieros hagan el trabajo de 100". Artistas, diseñadores y expertos en sus campos que nunca habrían aprendido a programar de forma tradicional ahora crean software funcional. Las personas con discapacidades, a quienes se les impedía programar, están encontrando nuevas oportunidades.

Sí, algunos de estos proyectos tendrán errores. Sí, algunos tendrán problemas de seguridad. Sí, a veces el código será un desastre. Pero ¿sabes qué? Lo mismo ocurrió con los primeros días de la web, las aplicaciones móviles y cada nueva ola de desarrollo de software. Aprendimos. Desarrollamos mejores prácticas. Creamos mejores herramientas.

El consenso que empezaba a surgir era que la programación por vibra "se siente como un truco... pero, cuando pasas de los proyectos de juguete, la realidad te golpea fuerte". Probablemente sea una perspectiva saludable. La programación por vibra encontró su lugar: creación rápida de prototipos, herramientas personales, proyectos de fin de semana y exploración. Para sistemas de producción que manejan datos sensibles o funciones críticas, necesitamos más rigor.

Desarrolladores y expertos en seguridad están estableciendo buenas prácticas para el código generado por IA, como tratar a la IA como a un desarrollador junior cuyo código debe revisarse, ejecutar análisis estáticos y linters, usar herramientas como DCAIF de Snyk para corregir vulnerabilidades automáticamente y pedirle explícitamente a la IA que tenga en cuenta los requisitos de seguridad antes de programar.

Namanyay Goel publicó "El movimiento de 'programación por vibra' de Karpathy es perjudicial" el 27 de marzo, y calificó la confianza ciega en la generación de código como un "colapso fundamental de la responsabilidad de ingeniería". Tiene razón. Pero también reconoció que los copilotos de IA son herramientas poderosas cuando se usan de forma responsable.

Es probable que el futuro del desarrollo de software implique una colaboración entre desarrolladores humanos y herramientas de IA. La programación por vibra representa una etapa inicial y algo caótica de esta colaboración. Es desordenada. Es emocionante. A veces, es imprudente. Está permitiendo que las personas creen cosas que antes no habrían podido crear.

Simon Willison aclaró oportunamente que "no toda programación asistida por IA es programación por vibra" y distinguió el uso habitual de herramientas como Copilot del enfoque extremo de Karpathy de "confiar en la IA". Hay todo un espectro, y probablemente la mayoría nos ubicaremos en algún punto intermedio: usaremos la IA para acelerar nuestro trabajo, sin dejar de comprenderlo y supervisarlo.

Quizás la verdadera lección de la programación por vibra no tenga que ver con el código. Se trata de experimentar, reducir las barreras y darles permiso a las personas para probar cosas, aunque no las entiendan por completo. Así es como las personas siempre han aprendido a programar: copiando ejemplos, mediante ensayo y error, rompiendo cosas y arreglándolas.

La IA simplemente acelera el ciclo.

Así que programa por vibra, pero quizás mantén un ojo abierto. Lee al menos algunos de los diffs. Ejecuta esos escáneres de seguridad. Haz preguntas. Aprende. Y cuando tu proyecto creado por vibra inevitablemente tenga problemas, recuerda: de todos modos, la depuración es donde realmente se aprende.

Al final, solo nos tenemos los unos a los otros. Humanos e IA, creados por y para los humanos, tratando de resolver esto juntos.