Dejar que la inteligencia artificial actúe y desarrolle aplicaciones complejas con tan sólo algunas instrucciones es un deseo de muchos que parecía hacerse realidad con los modelos de lenguaje más potentes. Pero detrás de lo aparente y fascinante de su acción surge el debate crítico.

El Nacimiento de una Tendencia Polémica

Imagina poder crear una aplicación completa simplemente describiendo lo que quieres en lenguaje natural, sin preocuparte por la sintaxis, la arquitectura o los detalles de implementación. Suena tentador, ¿verdad? Bienvenido al mundo del «vibe coding», una práctica que está provocando uno de los debates más acalorados en la comunidad de desarrollo de software desde la irrupción de la inteligencia artificial generativa.

El término «vibe coding» fue acuñado en febrero de 2025 por Andrej Karpathy, cofundador de OpenAI y ex director de Inteligencia Artificial en Tesla. En su definición original, Karpathy describió esta práctica con un tono casi provocador: programar dejándote llevar completamente por las vibraciones, aceptando todas las sugerencias de la IA sin cuestionarlas, sin revisar los cambios en el código, y cuando aparecen errores, simplemente copiarlos y pegarlos de vuelta en el chat sin añadir contexto adicional.

Lo que comenzó como una observación sobre cómo algunos desarrolladores estaban utilizando herramientas de IA como GitHub Copilot, Cursor o ChatGPT, rápidamente evolucionó en un movimiento completo. El vibe coding representa un cambio radical en el rol del programador: de ser quien escribe cada línea de código a convertirse en una especie de «director creativo» que comunica ideas en lenguaje natural mientras la IA maneja toda la implementación técnica.

La práctica se generalizó cuando desarrolladores como Pieter Levels compartieron historias de éxito. Levels, un emprendedor indie sin experiencia previa en desarrollo de juegos, creó un simulador de vuelo funcional en apenas tres horas usando Cursor. El proyecto no solo funcionaba, sino que generó cincuenta mil dólares mensuales (supuestamente), convirtiéndose en el ejemplo perfecto del potencial disruptivo de esta aproximación. De repente, parecía que cualquiera podía ser programador con solo tener una idea clara y la herramienta de IA adecuada.

Pero como suele ocurrir con las revoluciones tecnológicas, la realidad es considerablemente más compleja que la narrativa inicial.

La Cara y la Cruz de Programar por Intuición

El atractivo del vibe coding es innegable y se basa en promesas muy concretas. La velocidad de desarrollo se multiplica exponencialmente cuando no necesitas preocuparte por escribir cada función o depurar línea por línea. Lo que tradicionalmente podría tomar semanas de trabajo puede condensarse en horas o incluso minutos. Esta aceleración tiene un valor especialmente tangible en contextos donde el tiempo es crítico: prototipos para inversores, pruebas de concepto rápidas o herramientas internas desechables que solo necesitan funcionar lo suficientemente bien.

Además, el vibe coding promete algo aún más revolucionario: la democratización del desarrollo de software. Personas con ideas brillantes pero sin años de formación técnica pueden finalmente materializar sus conceptos sin depender de equipos de desarrollo. Esta accesibilidad tiene un potencial transformador, especialmente en comunidades donde el acceso a educación en programación es limitado.

Sin embargo, esta visión tiene un reverso considerablemente más oscuro. El primer y más importante problema es la comprensión del código. Cuando aceptas código generado sin entenderlo realmente, estás construyendo sobre una fundación opaca. Cada componente que no comprendes se convierte en una caja negra, y estas cajas negras se multiplican con cada iteración. El resultado es un sistema que funciona hasta que deja de hacerlo, y cuando eso sucede, te encuentras completamente perdido intentando depurar código que nunca entendiste en primer lugar.

La deuda técnica que genera el vibe coding no es lineal, es exponencial. Cada decisión de diseño subóptima que la IA toma sin tu supervisión consciente se acumula, creando estructuras frágiles que parecen sólidas en la superficie pero colapsan bajo el peso de la complejidad real. Una encuesta de Fastly reveló que el 95% de los desarrolladores terminan invirtiendo tiempo adicional corrigiendo código generado por IA, y algunos reportan que el tiempo de corrección supera el supuesto ahorro inicial.

Los problemas de seguridad son particularmente alarmantes. El código generado mediante vibe coding frecuentemente incluye vulnerabilidades graves: claves API expuestas directamente en el código, credenciales de bases de datos hardcodeadas, contraseñas almacenadas en texto plano. Cuando no revisas lo que la IA produce, estas bombas de relojería de seguridad pasan completamente desapercibidas hasta que es demasiado tarde. En producción, estas omisiones no son simples errores, son desastres en potencia.

Y luego está el problema del mantenimiento. El software no es un artefacto estático que construyes una vez y olvidas. Es casi como un organismo vivo que evoluciona, crece y necesita adaptarse. Mantener código que no entiendes es una pesadilla continua. Cada bug se convierte en un misterio irresoluble, cada nueva funcionalidad en una apuesta sobre si romperá algo existente, cada refactorización en un ejercicio de arqueología frustrada intentando descifrar por qué aquella funcionalidad fue implementada de cierta manera… Seguro que a los desarrolladores que lean esto les suena un poco todo esto.

Las Voces de la Industria: Un Campo de Batalla Ideológico

El debate sobre el vibe coding ha polarizado a figuras prominentes de la industria del software, revelando filosofías profundamente diferentes sobre qué significa programar y quién debería hacerlo.

David Heinemeier Hansson, creador de Ruby on Rails y una de las voces más influyentes en desarrollo web, ha sido particularmente crítico. Para él, el vibe coding representa una traición fundamental a los principios que deberían guiar la programación. Él diseñó Ruby explícitamente alrededor del concepto de «felicidad del programador», la idea de que escribir código debería ser un acto placentero y gratificante, no una carga de la que huir. Cuando escucha sobre vibe coding, ve desarrolladores renunciando a lo mejor de su profesión: la creatividad, la elegancia y el dominio técnico. Ha sido tajante en sus declaraciones en su entrevista con Lex Fridman, afirmando que el vibe coding es aprendizaje superficial que parece productivo pero solo ofrece calorías vacías, y que si solo puedes programar mediante vibe coding, realmente no eres programador. Su crítica más devastadora viene de la experiencia personal: intentó usarlo para construir algo real y descubrió que el enfoque falla rápidamente porque solo crea una fachada, código que luce funcional superficialmente pero carece de sustancia real.

Simon Willison, creador de Datasette y pensador respetado en la comunidad de desarrollo, ha adoptado una postura más matizada pero igualmente preocupada. Willison estableció una distinción crucial en su blog: si un modelo de lenguaje escribió cada línea de tu código pero tú lo revisaste, probaste y entendiste completamente, eso no es vibe coding, eso es usar un LLM como asistente de escritura sofisticado. El vibe coding auténtico, según Willison, ocurre cuando abdicas de esa supervisión y comprensión. Mientras reconoce la utilidad para prototipos rápidos, advierte que para software crítico sin control de calidad humano, el vibe coding es profundamente arriesgado.

Jonathan Blow, el aclamado desarrollador detrás de juegos como Braid, ofreció una perspectiva particularmente incisiva cuando respondió al caso viral de Pieter Levels. Para quienes han desarrollado juegos, incluso simples, señaló Blow, poner cosas en pantalla no es impresionante, es relativamente fácil. Lo verdaderamente difícil es hacer que el juego sea bueno, refinado, con buena sensación de juego. Su punto iba más allá de la crítica: apuntaba a cómo el vibe coding puede generar resultados que aparentan ser algo impresionante para no iniciados pero que carecen de la calidad y pulimento que define el software excelente.

Lawrence Jones, ingeniero de software, acuñó una frase memorable que resume la trampa del vibe coding: el desarrollo guiado por «vibraciones» no funciona como parece. Cuando intentas resolver tareas complejas mediante este enfoque, el fracaso está prácticamente garantizado por diferentes factores entre los que se encuentra la sobrecarga que supone en los equipos de desarrollo la revisión de tanto código, así como el reaprendizaje para codificar con ayuda de la IA.

Del otro lado del debate, los defensores del vibe coding argumentan desde una filosofía radicalmente diferente. Pieter Levels representa la visión pragmática-emprendedora: lo que importa no es la elegancia del código sino si el producto funciona y genera valor. Para Levels y otros como él, el purismo técnico es un lujo que los emprendedores indie no pueden permitirse. La velocidad de iteración y la capacidad de validar ideas rápidamente en el mercado supera cualquier preocupación sobre arquitectura o mantenibilidad a largo plazo.

Plataformas como Replit han institucionalizado este enfoque, promoviendo activamente el vibe coding como una forma de democratizar la creación de software. Su argumento es tanto social como económico: hay millones de personas con ideas valiosas que están siendo excluidas del mundo tecnológico simplemente porque no pueden programar. El vibe coding elimina esa barrera, permitiendo que emerjan soluciones desde lugares inesperados.

Andrew Ng, fundador de DeepLearning.AI y del que ya os he hablado bastante en este blog, ha adoptado una posición intermedia. Promueve el vibe coding pero con una advertencia crítica: debe aplicarse con proceso estructurado. Particionar problemas complejos, crear prompts específicos y bien pensados, probar cada módulo antes de avanzar al siguiente. Para Ng, el vibe coding no debería ser programación caótica guiada por intuición, sino una metodología disciplinada que utiliza IA como herramienta dentro de un marco riguroso.

Quizás lo más revelador es que incluso Andrej Karpathy, quien acuñó el término, ha tenido que reconocer sus limitaciones. Recientemente admitió públicamente que el vibe coding no funciona para sistemas complejos cuando intentó programar manualmente su proyecto «nanochat«. Esta rectificación parcial del creador del término es profundamente significativa: incluso los evangelistas más entusiastas encuentran los límites de esta práctica cuando enfrentan complejidad real.

La Responsabilidad Insustituible del Desarrollador Humano

Después de explorar los argumentos de ambas visiones, emerge una conclusión clara: el vibe coding puede ser una herramienta poderosa, pero nunca debería ser una metodología completa. La inteligencia artificial generativa ha demostrado capacidades impresionantes para generar código funcional, pero funcional no es sinónimo de correcto, seguro, mantenible o escalable.

El camino sensato no es rechazar categóricamente las herramientas de IA ni abrazarlas sin reservas. Es reconocer que la IA debe amplificar las capacidades humanas, no reemplazar el juicio humano. Cada línea de código generada por IA debería pasar por la revisión consciente de un desarrollador que entiende qué hace ese código, por qué fue generado de esa manera, y cuáles son sus implicaciones para el sistema más amplio. Esta revisión no es un formalismo burocrático, es el acto fundamental que transforma código generado en software del que puedes responsabilizarte.

La auditoría humana es especialmente crítica en áreas de seguridad, privacidad y cumplimiento regulatorio. Ninguna IA puede asumir la responsabilidad legal cuando tu aplicación filtra datos de usuarios o cuando un bug causa pérdidas financieras. Esa responsabilidad recae inevitablemente en los humanos que decidieron desplegar ese código. Por eso, comprender profundamente lo que la IA ha creado no es opcional, es obligatorio.

El verdadero poder de las herramientas de IA en desarrollo no está en permitirnos evitar programar, sino en hacernos programadores más eficientes. Usar GitHub Copilot para autocompletar código boilerplate repetitivo mientras mantienes el control de la arquitectura general. Usar ChatGPT para explorar diferentes enfoques a un problema antes de decidir conscientemente cuál implementar. Usar Cursor para refactorizar código que entiendes perfectamente, acelerando tareas mecánicas pero conservando la comprensión conceptual.

Como concluyó el MIT Technology Review en su análisis sobre el fenómeno: mientras el vibe coding puede ayudar a convertir una idea vaga en realidad, no puede hacerla confiable o segura. El mundo tendrá que adaptarse a esta nueva realidad porque no va a desaparecer. Pero adaptarse no significa rendirse ante ella, significa integrarla responsablemente en nuestras prácticas profesionales.

El futuro del desarrollo de software no es elegir entre humanos o máquinas. Es construir una colaboración donde la velocidad y capacidad generativa de la IA se combine con el juicio, la comprensión contextual y la responsabilidad ética que solo los humanos pueden aportar. En esa síntesis, no en el abandono de uno u otro extremo, encontraremos el camino hacia un desarrollo de software más rápido, más accesible, pero también más robusto y responsable.

Programar con IA no debería significar dejar de pensar. Debería significar pensar mejor, más rápido, con herramientas más poderosas. Pero siempre, al final del día, con la certeza de que entiendes lo que has construido y puedes responder por ello.

Para finalizar, si aún os queda energía después de todo esto, os dejo por aquí una reciente entrevista a Andrej Karpathy en el punto en el que comenta este asunto de la asistencia de la IA en su trabajo de desarrollo, indicando que está en la postura de utilizar los LLMs como asistentes de codificación, no como desarrollo completo y autónomo. Esa es la misma visión que tengo yo en este momento.