El espejismo del vibe coding: cuando la relajación progresiva convierte al programador en espectador

IMAGE: A stressed software developer sits in front of glowing code screens while a humanoid AI robot works behind him, symbolizing loss of control and over-reliance on automated coding

La discusión sobre el vibe coding ha alcanzado un punto interesante cuando deja de ser una crítica externa y empieza a formularse desde dentro del propio ecosistema que lo impulsa. Que el CEO de una de las herramientas más avanzadas de programación asistida por inteligencia artificial advierta de que estamos construyendo software sobre cimientos frágiles no es una anécdota ni un ejercicio de falsa modestia: es una señal de alerta que conviene tomarse muy en serio. No porque la inteligencia artificial no funcione, sino porque funciona lo suficientemente bien como para inducir una peligrosa complacencia.

El vibe coding promete fluidez, rapidez y una experiencia casi mágica: describir lo que se quiere y ver cómo el código aparece. En su versión más extrema, el desarrollador se limita a aceptar lo que el modelo genera «si tiene buena pinta» y pasa las pruebas básicas. Es una dinámica seductora, como ya señalé anteriormente, porque reduce el esfuerzo cognitivo inmediato y genera una sensación constante de progreso. El problema es que esa reducción de esfuerzo no es gratuita: va acompañada de una pérdida progresiva de comprensión.

Aquí aparece el que para mí es el concepto clave que explica buena parte del riesgo: la «relajación progresiva». Al principio, el desarrollador revisa cuidadosamente el código generado por la inteligencia artificial, lo entiende y lo corrige. Después ya va revisando menos. Más adelante confía casi por completo. El resultado final es un profesional que ya no domina el sistema que mantiene, que no comprende del todo las decisiones de arquitectura que han emergido de una conversación entre prompts y modelos, y que, cuando aparece un error serio, carece de las herramientas mentales para diagnosticarlo, porque lo que no se usa, invariablemente se atrofia. No es solo que la inteligencia artificial cometa errores, eso es inevitable, es que quien debería detectarlos ha perdido la capacidad de hacerlo.

Para entender la relevancia de esta advertencia conviene explicar qué es Cursor y qué papel juega en este panorama. Cursor es un entorno de desarrollo que integra de forma profunda modelos de lenguaje de gran escala dentro del editor de código, hasta el punto de convertirse en un “copiloto” permanente del programador. No se limita a sugerir líneas sueltas: genera funciones completas, reescribe archivos enteros, propone refactorizaciones y razona sobre el contexto global del proyecto. Detrás está Anysphere, una empresa fundada en 2022 por antiguos alumnos del MIT, que ha crecido a una velocidad vertiginosa y cuya herramienta se utiliza ya en entornos profesionales reales, no como experimento sino como parte del flujo de trabajo cotidiano. Precisamente por eso, que su propio CEO advierta de los peligros del uso acrítico de estas herramientas resulta especialmente significativo.

El riesgo no está en usar inteligencia artificial para programar, sino en delegar sin entender. Cuando el flujo de trabajo se convierte en un diálogo constante con el modelo, el desarrollador corre el peligro de pasar de autor a mero validador superficial, juzgando resultados por intuición en lugar de por comprensión. En sistemas complejos, esa intuición es un pésimo sustituto del conocimiento. El software no siempre falla de inmediato: muchas veces lo hace meses después, bajo condiciones no previstas, y entonces exige una comprensión profunda de interacciones que no están explícitas en el código generado.

La investigación académica empieza a respaldar estas preocupaciones. Estudios recientes muestran que los asistentes de código basados en inteligencia artificial tienden a amplificar defectos presentes en el contexto, reproduciendo patrones incorrectos incluso cuando se les pide explícitamente que los ignoren, lo que da lugar a errores difíciles de detectar. Otros trabajos analizan las vulnerabilidades de seguridad del código generado automáticamente y concluyen que, en tareas reales de ingeniería de software, muchas soluciones carecen de protecciones básicas, exponiendo problemas estructurales que no se resuelven con más velocidad.

La paradoja es que cuanto mejores son estas herramientas, mayor es la tentación de dejar de pensar. Cursor, por ejemplo, se promociona (con razón) como un sistema capaz de entender el contexto completo de un proyecto y acelerar enormemente el desarrollo. Pero esa misma capacidad fomenta una relación con el código en la que la inteligencia artificial se convierte en el principal agente creativo, y el humano en un revisor cada vez más pasivo. No es casualidad que la propia empresa haya lanzado herramientas como Bugbot para detectar errores introducidos tanto por humanos como por agentes de inteligencia artificial: es el reconocimiento implícito de que el código generado automáticamente no es, ni de lejos, infalible. Básicamente, salvar a los desarrolladores de sí mismos y de su progresiva complacencia.

El debate, por tanto, no es tecnológico, sino epistemológico. La productividad no consiste solo en producir más líneas de código en menos tiempo, sino en construir sistemas que sean comprensibles, mantenibles y robustos. Confundir velocidad con valor añadido es una trampa muy clásica, y en el contexto del vibe coding se vuelve especialmente peligrosa, porque erosiona precisamente aquello que hace valioso al desarrollador humano: su capacidad de entender, anticipar y corregir.

Como señalaba recientemente la prensa generalista al analizar el auge de estas herramientas, el entusiasmo por la programación asistida por inteligencia artificial convive con una creciente preocupación por la pérdida de criterio y de habilidades fundamentales. No se trata de rechazar estas tecnologías, que sería absurdo, sino de usarlas como amplificadores de inteligencia, no como sustitutos de la comprensión.

El vibe coding funciona mientras todo vaya bien. Pero el software importante, el que sostiene negocios, infraestructuras y decisiones críticas, no se define por cuando funciona, sino por cuando falla. Y en ese momento, no hay prompt que sustituya a un desarrollador que sabe leer, pensar y corregir su propio código, escrito con sus propias manos sobre su propio teclado. Si seguimos relajándonos progresivamente, el día que el sistema se derrumbe – que se derrumbará – descubriremos de repente que ya no queda nadie que sepa cómo levantarlo de nuevo.

3 comentarios

  • #001
    Buzzword - 26 diciembre 2025 - 12:11

    El otro día estaba con unas portadas de unos discos, y le pedí a Sonet que me hiciera en python un pequeño script para hacer un collage de 2×2 o 3×3 de imágenes que previamente las había trabajado en formato 1:1. Por probar… me hizo un script muy digno y sencillo, y bien estructurado, que me hubiera costado unas horitas. Sonet lo hizo en 15min. ( contando la mitad en prompt, y un pequeño cambio, que me sugirió la propia IA).

    Al final lo veo algo similar a: entrar en snapfiles y encontrar una app ya hecha por alguien.

    Para hacer pequeñas cosas rápidas lo veo útil. Para ayudarte a teclear menos cuando ya sabes lo que quieres también. El que se considere programador por hacer cosas similares se lo debería hacer mirar…

    Responder
  • #002
    FreeEurope - 26 diciembre 2025 - 14:09

    Concuerdo al 100 %.
    Trabajo con sistemas embebidos complejos y me estoy mal acostumbrando a CoPilot. Y cuando los plazos se están terminando, es peor. Te bloqueas y dependes de la IA.
    Realmente es un vicio que hay que controlar. Cuando logro hacerlo, voy mas lento pero siguiendo y corrigiendo a la IA.
    Pero la IA mejorará (no tengo dudas) y mas pronto que tarde, deberé buscar otro trabajo….

    Responder
    • JM - 26 diciembre 2025 - 14:34

      El problema es que aunque el programador tenga la voluntad de comprender lo que hace el asistente y mantener el control muchas veces los plazos son ajustados y la gestión casi siempre prioriza las metas a corto plazo sobre los problemas a medio-largo plazo.

      A finde cuentas esos problemas a medio-largo plazo los sufrirá el cliente u otro equipo de mantenimiento o desarrollo.

      Responder

Dejar un Comentario a JM

Los comentarios en esta página están moderados, no aparecerán inmediatamente en la página al ser enviados. Evita, por favor, las descalificaciones personales, los comentarios maleducados, los ataques directos o ridiculizaciones personales, o los calificativos insultantes de cualquier tipo, sean dirigidos al autor de la página o a cualquier otro comentarista. Estás en tu perfecto derecho de comentar anónimamente, pero por favor, no utilices el anonimato para decirles a las personas cosas que no les dirías en caso de tenerlas delante. Intenta mantener un ambiente agradable en el que las personas puedan comentar sin temor a sentirse insultados o descalificados. No comentes de manera repetitiva sobre un mismo tema, y mucho menos con varias identidades (astroturfing) o suplantando a otros comentaristas. Los comentarios que incumplan esas normas básicas serán eliminados.

 

XHTML: Puedes utilizar estas etiquetas: A ABBR ACRONYM B BLOCKQUOTE CITE CODE DEL EM I Q STRIKE STRONG IMG

Cancelar respuesta

Resumen de privacidad

Este sitio web utiliza cookies para que pueda ofrecerte la mejor experiencia de usuario/a posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves al sitio web o ayudar a comprender qué secciones del sitio web encuentras más interesantes y útiles.