La torre llena de fallas, el mareo vibe y el bobsleigh vibe

• A medida que se expande una forma de desarrollo en la que, aunque las personas no entiendan el código creado por un LLM, vuelven a pedirle al LLM que lo interprete, la frontera entre la ingeniería agéntica y el vibe coding, antes diferenciadas, se está desdibujando rápidamente
• Vibe bobsled se refiere a una ruta prefijada que va del autocompletado a la generación de código, al abandono de la revisión y luego al abandono de los prompts; cuanto más se aprovecha la velocidad de generación, más se aleja uno de la construcción de teoría y la revisión, que son el rol central del programador
• En el experimento de Pvote, expertos en seguridad sabían de antemano dónde mirar y aun así, tras revisar unas 100 líneas de código durante cerca de 20 horas, no encontraron el bug difícil de tres bugs, mostrando que la premisa de que una persona puede revisar por completo grandes volúmenes de salida de un LLM es poco realista
• Se está propagando el mareo vibe, donde código y artefactos no comprendidos se infiltran en pósters de restaurantes, chatbots de atención al cliente, código de verificación de edad e incluso issues y PR de open source; incluso quienes no usan estas herramientas se ven afectados al tener que revisar lo generado por otros
• La IA generativa puede ser útil para encontrar problemas, pero es especialmente débil al generar; incluso en un flujo donde sistemas incomprensibles reemplazan al mundo, no deberíamos renunciar también a la capacidad humana de crear directamente un entorno mejor

---

La torre del código incomprensible

• The Tower Keeps Rising observa que, incluso en situaciones que antes se resolvían hablando con compañeros de equipo, ahora se puede seguir avanzando usando agentes
  • Armin no lo juzgó ni como algo bueno ni como algo malo, y tampoco lo defendió como un estado sostenible
  • Aun así, está en una posición que impulsa esta tendencia al dirigir una empresa de vibe coding
• Los sistemas de vibe coding pueden seguir apilando código y abstracciones hasta llegar finalmente a un estado en el que ningún ser humano puede entender la base de código
  • Incluso las partes que una persona no puede entender pueden ser reinterpretadas otra vez por un LLM, lo que crea una nueva forma de operar en la que el desarrollo puede continuar
• Incluso quienes lo defienden reconocen ese punto final donde los humanos ya no entienden el sistema, y aparece un cambio que acepta ese estado como la forma de desarrollo del futuro

Colapso de la frontera entre ingeniería agéntica y vibe coding

• Simon Willison al principio distinguía con claridad la ingeniería agéntica (agentic engineering) del vibe coding
  • En un texto de marzo de 2025, estableció el principio de que, si se trata de programación asistida por IA con calidad de producción, uno debería poder leer todo el código que se hace commit al repositorio y explicárselo con precisión a otra persona
  • Diferenciaba que, incluso si el código lo escribió un LLM, si una persona puede revisarlo, probarlo a fondo y explicar cómo funciona, entonces no es vibe coding sino desarrollo de software
• Algo más de un año después, en Vibe coding and agentic engineering are getting closer than I’d like, dijo que, como los agentes de código se habían vuelto más confiables, había dejado de revisar cada línea incluso del código de producción
  • Confía en que Claude Code cree correctamente un endpoint de API que ejecute consultas SQL y devuelva JSON, y además agregue pruebas y documentación
  • Al mismo tiempo, siente culpa y se pregunta si es responsable usar en producción código que no revisó
• La distancia entre ambas posturas es de poco más de un año
• Se difundió ampliamente la percepción de que la ingeniería agéntica era la forma deseable de usar estas herramientas, pero en la práctica los usuarios, incluido el propio Simon, muestran una tendencia a ser arrastrados hacia el vibe coding

Vibe bobsled

• El bobsleigh es un deporte en el que se desciende rápido por una pista de hielo, pero en realidad casi solo hay una dirección posible
  • Los atletas pueden medir su destreza y sentir la adrenalina, pero los ocupantes no tienen mucho margen para elegir el trayecto en sí
• En el vibe bobsled, el LLM es el vehículo y el usuario es el pasajero
  • El usuario tiene mucho menos control real de lo que percibe, y se parece menos a una pendiente resbaladiza que a un trayecto ya construido de antemano
• El desarrollador se va quitando a sí mismo del proceso de producción de código al pasar por las siguientes etapas
  • Al principio cree que solo lo usa como autocompletado avanzado
  • Después ejecuta un agente para explorar ideas, pero dice que escribirá el código por su cuenta
  • Luego el agente genera el código, pero promete revisar todos los resultados
  • Poco después casi deja de revisar el código y empieza a creer que el agente quizá sea mejor desarrollador que él mismo
  • Al final puede avanzar más allá de “ya no programo” hacia la etapa de “ya ni siquiera escribo prompts”
• Cada etapa es un movimiento hacia una producción de código basada en la confianza, donde se asume que el LLM entiende y resuelve bien el trabajo

El choque entre velocidad de generación y revisión

• En programación, la parte lenta no es la generación sino la construcción de teoría y la revisión, y los resultados plausibles pero incorrectos son muy difíciles de depurar y entender
• Como el atributo más poderoso de los LLM es la velocidad de generación, si una persona revisa todos los resultados resulta difícil aprovechar realmente esa velocidad
• En cambio, la construcción de teoría y la revisión son el rol más importante del programador, así que cuanto más se maximiza la ventaja del LLM, más aparece una tensión que aleja de ese rol central
• El artículo de Ka-Ping Yee, Building Reliable Voting Machine Software, señala cuatro factores que dificultan la verificación del software
  • la cantidad de componentes
  • las interacciones complejas
  • el impacto amplio
  • la no linealidad
• Estos cuatro problemas pueden agravarse con la forma en que los LLM generan código

Experimento de revisión de bugs en Pvote

• Ka-Ping Yee y David Wagner insertaron en la máquina de votación modelo Pvote un bug fácil, uno intermedio y uno difícil que podían explotarse para alterar resultados electorales
• Los tres bugs se colocaron dentro del segmento de 100 líneas correspondiente a las líneas 11 a 109 de Navigator.py
  • Era una parte interesante desde la lógica del programa y una elección hecha considerando el tiempo limitado de los revisores
  • A los revisores se les dijo qué zona examinar, pero no cuántos bugs había
• Los resultados de la revisión del tercer día fueron los siguientes
  • Dan Sandler, muy familiarizado con Python, encontró el bug fácil y el intermedio en unos 70 minutos
  • Yoshi Kohno y Mark Miller encontraron el bug fácil después de unas 4 horas
  • Nadie encontró el bug difícil
• En el cuarto día, Ian Goldberg encontró el bug fácil en unas 2 horas, pero no detectó los otros bugs
• Los expertos en seguridad, aunque sabían incluso la ubicación, invirtieron en total unas 20 horas-revisor y aun así no encontraron los tres bugs
• Más tarde, tras verificar los bugs, Mark S. Miller expresó sorpresa al ver que todos coincidían en que eran bugs evidentes y que debieron haberlos encontrado
• Si incluso programadores de primer nivel pasan por alto bugs que con seguridad están dentro de 100 líneas, el enfoque de que humanos revisen la enorme salida de los LLM se vuelve inmanejable
  • Al final, los usuarios terminan abandonando la revisión y eliminándose gradualmente del proceso de producción de código

Psicosis de IA y mareo vibe

• “AI psychosis” se usa de forma amplia para referirse a malos comportamientos o malos resultados causados por IA generativa, pero originalmente se acercaba más a un estado en el que, al interactuar con chatbots excesivamente afirmativos, los usuarios sufrían una psicosis real y una desconexión delirante de la realidad
• Para el malestar generalizado causado por IA generativa, que no llega a ser una psicosis clínica, mareo vibe (vibe sickness) resulta una expresión más adecuada
• En el reporte de Glyph sobre PyCon US 2026 aparecen al mismo tiempo las siguientes situaciones
  • un mareo vibe generalizado
  • una crisis masiva de sostenibilidad en el open source
  • una avalancha de PR de seguridad de baja calidad
  • esperanza, energía y esfuerzo por el entendimiento mutuo, y gratitud por el trabajo

Artefactos generados que se extienden a la vida diaria y al open source

• La gente se queja del slop, esos artefactos generados de baja calidad, pero quienes usan IA generativa no llaman slop a sus propios resultados
• Los artefactos generados que parecen plausibles pero no se pueden entender aparecen por todos lados en la vida cotidiana
  • pósters de restaurantes locales con diseños difíciles de entender
  • chatbots de atención al cliente que frustran a los usuarios
  • código de verificación de edad
  • issues y PR de baja calidad enviados a proyectos open source
• Estas herramientas pueden ser útiles para ciertas tareas y puede haber espacio para evaluarlas de otra forma en la detección de problemas
• Sin embargo, la generación que enfatiza el nombre “genAI” es precisamente la parte en la que peor funcionan estas herramientas
  • El problema no es solo la calidad de lo generado, sino también que nadie entiende cómo se construyen, estructuran y mantienen los sistemas

Un entorno del que no se puede escapar de la IA generativa

• Aunque uno no use directamente IA generativa, colegas o contribuyentes de open source pueden enviar como “aporte” artefactos generados que ni ellos mismos entienden
  • Quien revisa tiene que preguntarse si sería grosero preguntar si algo fue generado por un LLM
  • Mientras responde a issues o PR, interactúa indirectamente con agentes y termina participando sin querer en un flujo de trabajo de vibe coding
• Glyph compara rechazar todo software que incluya LLM con contener la respiración hasta que todo el mundo deje de usar gasolina con plomo como protesta por su introducción en los autos
  • En la práctica no queda otra que aceptarlo hasta cierto punto, y aunque uno trace una línea ética personal, eso no significa tener expectativas o entusiasmo por el entorno de IA generativa
• El uncanny valley está ocupando el mundo real y sistemas que nadie entiende están reemplazando al mundo anterior
• Aún no se conoce el costo que habrá que pagar al recuperarse de este estado, y vale la pena respetar a los proyectos que eligen no participar en la IA generativa actual

Elegir crear un terreno mejor

• Puede que, por trabajo o por el entorno, no sea posible negarse por completo a contribuir a los problemas de la IA generativa
• Aunque un conductor se enoje con los ciclistas en la vía, si falta infraestructura ciclista, los usuarios quedan en peligro por puertas de autos estacionados o conductores impacientes
• Si al conducir hay una bicicleta delante, uno puede agradecer su presencia y pensar en formas de cambiar el terreno y la infraestructura para que las bicicletas puedan participar con más seguridad
  • Esos cambios facilitan conducir autos y, según la situación, también facilitan elegir la bicicleta
• No debemos renunciar a la convicción de que, en vez de entregarnos al camino fijado por la tecnología, los humanos pueden participar directamente para construir un mundo mejor

[GN⁺]

Opiniones en Lobste.rs

• De los textos recientes sobre los cambios en la industria de la ingeniería de software que he estado observando con inquietud, este es de lejos uno de los mejor escritos

• Hace apenas un año, la ingeniería con agentes parecía una dirección deseable, pero la mayoría de quienes usan estas herramientas, aunque dudan en admitirlo, parecen inclinarse por el vibe coding. El miedo a que los LLM vuelvan inútiles mis habilidades y mi pasión se redujo mucho cuando establecí dos principios
  Primero, en mi tiempo libre no uso LLM ni agentes de código, y también rechazo las funciones de IA en las búsquedas. Solo los uso cuando estoy lo bastante desesperado como para no poder resolver algo por mi cuenta y aceptar el riesgo de alucinaciones. Ignorar la tecnología no va a resolver el mundo, pero en una situación donde no puedo atacar a desarrolladores individuales ni cambiar a las grandes empresas, elegir no involucrarla también en mi tiempo libre es una opción realista
  Segundo, incluso en un trabajo donde se recomienda fuertemente usar IA, la uso solo para revisión de código y mandados. Básicamente para preguntar cosas que podría encontrar directamente en el codebase pero da flojera buscar, y todo el código lo escribo yo mismo. Solo así puedo entender intuitivamente cómo funciona y trabajar al nivel que esperamos yo y mis colegas
  Los LLM sirven como apoyo para detectar errores basados en patrones que un linter determinista no encontraría. También dan respuestas disparatadas, pero como escribo y entiendo el código yo mismo, no confío ciegamente en ellos. Si antes de una revisión humana filtran errores lógicos obvios y suposiciones incorrectas, mis colegas pueden concentrarse en las partes más complejas, y además se evita la grosería de hacer que máquinas hablen entre sí en canales públicos en lugar de personas
  Hace poco la empresa limitó estrictamente el uso de tokens, pero como este flujo de trabajo apenas cuesta entre 1 y 2 euros al día, no me preocupa. Quienes dependían por completo de la intuición pueden sentirse ansiosos al tener que volver a usar razonamiento humano, pero el resto simplemente puede resolverlo directamente con sus colegas

  • La crítica de “¿crees que meter la cabeza en la arena va a resolver algo?” no viene de un tercero real, sino que uno mismo la dice en nombre de un crítico imaginario. Yo también trato de cuidarme de eso, porque cuanto más eliges pensando en esa crítica, peor se vuelve la vida
    También hay una epistemología autoflagelante detrás: la idea de que, mientras más doloroso sea, más debes mirar la verdad de frente. Evitar información desagradable puede hacerte sentir poco virtuoso, pero la atención es finita, así que es mejor usarla en cosas que te hagan más feliz y pleno, y te den fuerzas para seguir mañana
  • Esto se parece menos a meter la cabeza en la arena y más a “no me gusta ir a la oficina, así que en mi tiempo libre evito la oficina”. Si puedes evitar algo que no disfrutas, es racional hacerlo
    Quienes tratan todo en la vida como si hubiera que optimizarlo y ser el mejor, como en el trabajo, son los que terminan perdiendo. Si te gusta programar, puedes hacerlo también en tu tiempo libre; si no, puedes dejarlo solo como profesión. En el tiempo libre, a veces está bien ser ineficiente, y si no, tu tiempo libre se convierte en un segundo trabajo y nunca descansas de verdad

• Me molesta demasiado que aquí hayan escrito mal Fawlty

  • Parece que lo hicieron a propósito como un juego de palabras con una Torre de Babel “problemática” o “fallida”

• El texto es excelente como siempre, pero no parece necesario preocuparse por si sería grosero preguntar si fue generado por un LLM. Sin importar si usaron un LLM en el proceso de producción, si recibiste un resultado pésimo, puedes decir que la calidad es mala y no te gusta

  • Si es un colaborador nuevo a quien no conoces, lo razonable es señalar los problemas de calidad en el PR y devolverle la responsabilidad de corregirlos. Aun así, recuerdo que el proyecto Zig adoptó una política anti-IA porque quería que personas, no LLM, orientaran directamente a los nuevos colaboradores para ayudarlos a crecer como contribuidores de largo plazo
    En cambio, con un colega o alguien con quien llevas mucho tiempo interactuando en línea, quizá quieras evitar la grosería en lo posible para preservar la relación. Necesitas saber cómo se produjo la contribución para poder discutirla, y el resultado de esa discusión puede afectar deliberadamente mucho la relación. Asumir el riesgo de parecer grosero, o evitar por defecto el conflicto y preservar la relación, es una elección de personalidad
    Yo también tiendo a evitar el conflicto, así que entiendo de dónde salió esa frase, y tampoco discrepo mucho con la postura original

• Me gusta la metáfora del bobsleigh. No estoy de acuerdo con la idea de que quien usa LLM necesariamente va a llegar hasta el fondo, pero describe el comportamiento que se observa en la industria mejor que cualquier otra metáfora que haya visto hasta ahora

• La “metáfora del bobsleigh” se conoce mejor como la falacia lógica de la pendiente resbaladiza. Hace un año, la proporción de vibe coding era 0%, y Simon Willison publicó varios textos mostrando cómo introducía con cuidado a los agentes de código y aumentaba gradualmente su confianza en ellos
  Pero a partir de eso concluyen tajantemente que “solo hay un destino posible”. Parece más razonable asumir que Willison y otros usuarios también tienen gustos y criterio propios