¿Pone el Vibe Coding en jaque el rol de los programadores?

Cuando el software funciona pero nadie sabe por qué

Tras la explosión de los LLM, el boom del llamado vibe coding no tardó en llegar: consiste en describir un problema en lenguaje natural y dejar que un modelo de lenguaje genere el código para su implementación. En teoría, el desarrollador ya no construye línea a línea. Supervisa el proceso, corrige errores y guía al sistema. Un programador abre un repositorio y encuentra miles de líneas de código que funcionan. El software compila. Los tests pasan. El producto parece estar listo. Pero si alguien le pidiera explicar exactamente cómo funciona el sistema, probablemente no podría hacerlo.

Este pequeño cambio entre "pedir código" a una máquina y "entender" lo recibido está empezando a aparecer en miles de equipos de desarrollo. Y apunta a algo más profundo que una simple evolución de herramientas, porque la inteligencia artificial no está sustituyendo a los programadores, lo que ocurre es que está complicando algo que hace unos años se daba por sentado: la relación entre escribir código y comprenderlo.

El nacimiento del slop técnico

Como es sabido, Internet ya conoce una palabra para describir cierto tipo de contenido generado por IA: slop. A grandes rasgos, el slop es material producido en masa, aparentemente útil, pero demasiado abundante para ser revisado con rigor. Artículos, imágenes o vídeos que aparentemente son suficientemente creíbles o llamativos para circular, aunque nadie ha verificado su origen, rigor o calidad.

Cuando algo similar ocurre con el código de programación, podemos llamarlo slop técnico: código generado rápidamente por máquinas, válido en apariencia, pero cuya lógica interna no siempre es comprendida por quienes lo implementan. No es necesariamente incorrecto, pero su comprensión entra en un terreno pantanoso.

Un caso real (entre muchos) código que funciona (y borra los datos al mismo tiempo)

En 2025, un desarrollador relató un incidente ocurrido en su propio equipo mientras utilizaban GitHub Copilot para acelerar tareas rutinarias. El asistente generó una función aparentemente correcta para limpiar cuentas inactivas en una base de datos. El código pasó revisión, se integró en el sistema y superó los tests automáticos. El problema apareció después. La función eliminaba usuarios que no debía eliminar. Copilot había mezclado patrones de otros archivos del proyecto y generó una lógica errónea que combinaba un campo is_archived con una operación db.session.delete(). El resultado era un código coherente desde el punto de vista sintáctico, pero incorrecto desde el punto de vista del sistema.  

Otro detalle inquietante es que los tests también habían sido generados por la IA: verificaban que la función se ejecutaba, pero no que su comportamiento fuera correcto. En otras palabras: el sistema validaba su propio error. El software funcionaba, sí, pero los datos que debían mantenerse desaparecieron.

El problema del “casi correcto”

Este tipo de incidentes no son anecdóticos. Estudios recientes muestran que una parte significativa del código generado por IA contiene fallos de seguridad o prácticas dudosas. Un análisis de más de cien modelos de generación de código encontró vulnerabilidades en aproximadamente el 45 % de los fragmentos generados, incluso cuando parecían listos para producción. Los problemas más frecuentes incluyen: validación insuficiente de datos, vulnerabilidades de inyección, errores de autenticación, configuraciones inseguras. Efectivamente, el código compila y los tests pasan, pero el sistema contiene defectos "invisibles". Sería el equivalente técnico de una frase gramaticalmente correcta que, sin embargo, no dice exactamente lo que parece decir, incluso dice lo contrario por falta de puntuación correcta (algo como No estoy seguro VS. No, estoy seguro)

La deuda invisible

Antes de la disrupción del vibe coding, el principal problema del software fue la deuda técnica: sistemas difíciles de mantener debido a decisiones apresuradas. La IA introduce otra forma de deuda más difícil de medir: deuda de comprensión. Cuando un desarrollador escribe código, incluso si es imperfecto, entiende por qué existe, y qué puede fallar. Cuando el código aparece generado por un sistema externo, ese vínculo puede desaparecer: el resultado es software que operativo, pero cuya lógica nadie domina completamente. Cuando algo falla, entender el sistema se convierte en una excavación arqueológica, con más suposiciones que certezas.

Arquitectos, operadores y curadores

Este cambio de paradigma está empezando a dividir el oficio, y es que en muchos equipos están apareciendo diversos perfiles nuevos, que se pueden resumir en tres.

El arquitecto: Diseña sistemas y utiliza la IA como asistente.

El operador: Produce software mediante prompts y ajustes iterativos.

El curador: Revisa, limpia y corrige el código generado por máquinas.

El programador clásico hacía las tres cosas al mismo tiempo y, ante la disrupción de la IA, se han empezado a separar.

El retorno del código humano

Curiosamente, algunos desarrolladores están reaccionando en dirección contraria, volviendo a escribir código manualmente en partes críticas del sistema. Esta reacción tiene todo el sentido y no responde al mero romanticismo, porque defiende el control de lo que se está haciendo como valor que no se puede dejar en manos de una IA falible y críptica. La regla que empieza a circular en algunos equipos es simple: No debería entrar en producción ningún código que el equipo no pueda explicar. En un mundo dominado por el slop técnico, comprender el sistema vuelve a convertirse en una ventaja competitiva, especialmente si se busca seguridad, confiabilidad y no se priorizan las soluciones "mágicas".

Desde su aparición y posterior desarrollo, el software era un lenguaje compartido entre humanos expertos y versados en la materia. Cada línea de código era una forma de pensamiento estructurado que otra persona podía leer, entender y modificar. La inteligencia artificial y el "vibe coding" han abierto otro camino, en el que su rapidez y enorme capacidad sitúan el conocimiento humano en el lado de la fragilidad y la sospecha (¿Puedo fiarme de esta solución que me propone la máquina, que aparentemente es impresionante, o hay algo detrás que está poniendo en jaque todo lo hecho?

Porque la lógica del software funcional incorpora lógicas internas que nadie comprende completamente. Si este modelo se impone, el futuro del desarrollo no será una profesión automatizada, sino un juego complejo y frecuentemente confuso entre ensayo-error, problemas difíciles de solucionar y soluciones asombrosas que quizás acaban resultando un Caballo de Troya.