La generación de código con LLM puede llevar a una pérdida de confianza

• Recientemente, la generación de código basada en LLM se está usando cada vez más entre los desarrolladores
• El código generado automáticamente está aumentando la preocupación por la calidad y confiabilidad del código
• Los desarrolladores experimentan un aumento en la dificultad de mantenimiento de los proyectos debido a la falta de comprensión del código y a verificaciones insuficientes
• La expansión del uso de código no confiable afecta a todo el ecosistema de software
• Se enfatiza la necesidad de preparar medidas para asegurar la confiabilidad junto con el avance tecnológico

---

Resumen

Jay aborda en su blog el impacto que la reciente tecnología de generación de código basada en LLM (modelos de lenguaje de gran tamaño) está teniendo en el desarrollo de software. Aunque el avance de estas herramientas mejora la eficiencia del desarrollo, al mismo tiempo están surgiendo problemas de confiabilidad y calidad del código.

El auge de la generación de código con LLM

• En el entorno de desarrollo se están expandiendo rápidamente las herramientas de generación automática de código que utilizan LLM
• Ofrecen alta productividad en la implementación de funciones complejas o en tareas de codificación repetitivas
• Tienen la ventaja de permitir la creación rápida de prototipos y de reducir la carga de aprender nuevos lenguajes

Problemas de confiabilidad

• Se presentan casos en los que el código generado por LLM no siempre funciona como se pretende
• La intención interna y la lógica de diseño del código no quedan claras, lo que dificulta el proceso de comprensión y verificación
• Si el proceso de revisión y pruebas es insuficiente, existe la posibilidad de que aparezcan bugs o vulnerabilidades inesperadas

Mantenimiento de proyectos e impacto en el ecosistema

• Surgen problemas de falta de documentación y explicaciones insuficientes sobre el código generado automáticamente
• A los desarrolladores les cuesta entender cómo funciona el código, lo que incrementa la complejidad del mantenimiento
• Existe el riesgo de que se deteriore una cultura de desarrollo de software confiable

Conclusión y propuestas

• La tecnología de generación de código basada en LLM es innovadora, pero asegurar la confiabilidad es una tarea esencial
• Al adoptar código generado automáticamente, se enfatiza la necesidad de reforzar la verificación y realizar revisiones de código sistemáticas
• A largo plazo, es importante establecer estándares para proteger la confianza en el ecosistema informático

[GN⁺]

Opiniones de Hacker News

• Comparten un enlace de archive.is, funciona incluso en navegadores antiguos y JavaScript solo hace falta para evadir CloudSnare

• Un amigo mío siempre decía: "la innovación ocurre a la velocidad de la confianza". Desde la aparición de GPT-3, esa frase no deja de darme vueltas en la cabeza. Verificar tiene un costo alto, y la confianza es una de las principales formas de bajar ese costo. Pero no sé cómo construir confianza con los LLM. Son increíblemente fluidos tanto para programar como para lenguaje natural, pero al mismo tiempo se desvían en direcciones que, si lo hiciera una persona, se verían como algo malintencionado

  • Soy el autor: me encanta esa cita. Resume de forma muy concisa lo que intenté explicar en varios párrafos. Sinceramente, vivir en un mundo donde ahora hay que verificar todo una por una es realmente agotador y lento
  • No se puede tener confianza total en los resultados de un LLM. Pero sí se puede depurar y limitar el radio de impacto. Filtrar entradas de usuario, hacer pruebas de penetración, guardar secretos en archivos dot... al final todo va a converger en estándares tipo "buenas prácticas" y "cumplimiento regulatorio SOC-AI". Los LLM son demasiado útiles como para ignorarlos aunque uno quiera. Y la confianza también se construye paso a paso. Los humanos tampoco es que sean precisamente confiables, y si lo comparas con autos autónomos, parece posible que dentro de reglas definidas terminen produciendo código con menos bugs que los humanos. Después de eso, solo irán mejorando la complejidad poco a poco
  • "La innovación ocurre a la velocidad de la confianza" necesita algo más de explicación. ¿Acaso existía ese nivel de confianza cuando se descubrieron por primera vez la electricidad, el vuelo o la radiactividad? En la ciencia, la confianza se construye sobre la marcha

• En el trabajo viví este tema de una forma inesperada. Un compañero y yo, bajo presión por resultados rápidos, fusionamos un gran refactor que yo había hecho, aunque todavía estaba como PR temporal. Después aparecieron bugs en código no probado. Mientras depurábamos, mi compañero me confesó que pensó que yo había programado eso con IA y que se frustró tratando de entender a posteriori un código que creía generado por IA. Pero ese código lo había escrito yo mismo con cuidado, a mano, y los bugs venían de pequeños errores durante un simple cambio de API. Más bien, esa experiencia nos permitió sacar de forma natural una tensión de confianza entre nosotros y hablarla de manera constructiva. Viéndolo ahora, fue una experiencia significativa de construcción de confianza, y siento que en otro entorno podría haberse enredado muchísimo más. Da la sensación de que siempre hay que andar con cuidado

• No termino de entender la premisa. La confianza en que alguien escribe buen código viene de la experiencia real de que esa persona programó directamente y el resultado fue bueno. Si usa un LLM y igual entrega código sin bugs, confío; si usa un LLM y mete bugs, no confío. No veo en qué sería distinto de escribirlo solo con la cabeza

  • Soy el autor: mi punto es que, en entornos de baja confianza como equipos grandes con confianza intermedia u open source, los LLM hacen cada vez más difícil juzgar la habilidad de un desarrollador viendo solo el código enviado. Como no puedes entender la disposición o estilo de la otra persona, al final tienes que tratar todo como "confianza cero" y revisar cada línea con cuidado. Los atajos que antes servían para revisiones rápidas ya no funcionan, y en organizaciones acostumbradas a esa cultura puede ser bastante doloroso. Si ya trabajas en un equipo de alta confianza, puede que este problema no te diga nada
  • Antes, si A=B, un B alto implicaba que A también era bueno. Ahora A+AI=B, así que aunque B sea alto, A puede no serlo. Y como la IA actual es probabilística, a veces incluso sale peor que no hacer nada
  • Dijiste "solo confío en el código que funciona", pero la base de esa confianza es que el desarrollador sabe de antemano que el código realmente está libre de bugs. En sistemas complejos, para entender cómo interactúa ese código con otras partes y qué edge cases pueden aparecer, quien lo escribe tiene que entender el contexto completo. Si un LLM escribió el código y el desarrollador no entiende del todo lo que hace, la carga de validación termina cayendo sobre quien revisa, y eso lleva a saturación. Ese es el argumento
  • Cuando programas con LLM, después de que te sale bien unas cuantas veces, te da exceso de confianza y empiezas a aflojar con las pruebas. En la práctica, muchos problemas vienen de errores de comunicación. Aunque la persona entienda claramente la tarea completa, al LLM le cuesta mantener el estado y, si el contexto es ambiguo, hace suposiciones absurdas. Ojalá un enfoque como el de 4o, que pide primero información adicional de forma insistente, se volviera estándar en todos los modelos de generación de código; de verdad evitaría muchísimos problemas
  • La confianza no se construye solo por si funciona o no. También cuenta explicar claramente los cambios, tener historial de buenas contribuciones, hacer cambios en unidades razonables (commits de tamaño adecuado), priorizar bien los problemas (arreglar bugs antes de agregar features), capacidad de mantener código existente, actividad constante, etc.

• Ya vivimos en esa época. Veo demasiadas veces frases como "perdón por pasar por alto ese punto, tienes razón". Las veo 8 o 9 veces de cada 10. En cambio, también veo seguido gente que copia y pega sin sentido código generado por LLM y luego se enoja porque no cumple expectativas. De hecho eso me parece mejor. Prefiero algo claramente roto a algo que por fuera parece correcto

  • En mi experiencia, los LLM tienden más a modificar el código para que pasen los tests que a cumplir realmente los requisitos
  • ¿Están usando LLM como chatbot en el navegador? Nosotros usamos un agente de IA con acceso directo al código, habla mucho menos y en la práctica hace tareas mejores que varios juniors a mi alrededor. Ejecuta bien tareas cortas y específicas, así que casi basta con una code review y ya. Claro, un prediction engine no sabe hacer ingeniería de verdad. Por ejemplo, si no le pides explícitamente un generator de Python, muchas veces entrega código que consume una barbaridad de memoria. Pero varios desarrolladores Python a mi alrededor cometen errores parecidos. De hecho, eso ayuda a empujar a la gente a escribir especificaciones claras en vez de pedir simplemente "agrega la feature". Donde más útil me resulta el agente de IA es en código legacy que a nadie le interesa tocar. Tenemos un sistema que extrae datos de documentos recibidos por fax usando 200 coordenadas; llevaba más de 30 años igual, y hace poco cambió el documento. A copilot le tomó 30 segundos ajustar las coordenadas. A una persona le habría tomado fácilmente un día entero. Pero no sé cómo se supone que alguien se volverá experto en una era de programación así
  • Eso de 8 o 9 de cada 10 es demasiado exagerado. Es una estadística inventada al 100%

• Las herramientas de abstracción anteriores reducían complejidad, pero al mismo tiempo daban por sentada la "corrección" de esa abstracción. Claro, no eran perfectas y tenían bugs, pero esos eran problemas de implementación, no fallas esenciales. Una vez corregidos, tendían a volverse más sólidos. En cambio, los LLM son motores de predicción probabilística que solo muestran una precisión aproximada durante cierto tiempo. Lo que el autor pasa por alto aquí es que sí se pueden construir sistemas deterministas confiables a partir de agentes probabilísticos imperfectos. Por ejemplo, no confías en una herramienta de garbage collection porque le tengas fe a su autor, sino porque la herramienta en sí ha sido suficientemente probada y se ha demostrado que hace lo que debe. En el futuro, parece probable que el desarrollo guiado por pruebas se vuelva más fuerte. No es confianza, es verificación

  • Pensar que las pruebas automatizadas pueden atrapar todos los problemas es ingenuo. Hay demasiadas cosas difíciles de automatizar: concurrencia, manejo de recursos, vulnerabilidades de seguridad, etc. ¿Y quién verifica los tests? Tanto el código como las pruebas implementan lógica, y a veces la causa del bug aparece del lado de los tests, no del código. Tampoco se debe confiar ciegamente en las pruebas
  • Soy el autor: aquí estoy enfocándome más en la naturaleza de la herramienta que en sus efectos. Por ejemplo, si el propio modelo actuara directamente como recolector de basura, recibiendo memory dumps del programa y liberando bloques innecesarios, nunca podría confiar para siempre en ese juicio. Por más que lo “parches” o lo “fine-tunees”, hay un límite. En un sistema de salida determinista como la JVM, si aparece un error, una vez corregido ese error desaparece para siempre. Con un LLM no pasa eso. Creo que ahí está la bifurcación esencial entre las abstracciones tradicionales y el mundo LLM. Pienso que el impacto industrial de los LLM será grande, pero como hay pocos precedentes históricos, de verdad estamos en territorio desconocido
  • Esa idea de que "de un factor probabilístico (una máquina de entropía) puede salir un sistema determinista confiable" me suena bastante radical. Y además, TDD siempre se presenta como si fuera una herramienta mágica que resolviera todo. Pero he visto, de forma casi vergonzosa, demasiados casos de software equivocado construido a partir de tests equivocados

• El rechazo a los LLM no sirve de nada. Hoy los LLM aumentan la productividad de los desarrolladores. Al menos son todavía más útiles para quienes tienen menos experiencia. Una herramienta que sube tanto la productividad no va a ser abandonada por más que alguien se oponga. Aunque aparezcan casos de daño —por ejemplo, grandes servicios caídos durante mucho tiempo por bugs graves—, si la productividad pesa más, la tecnología no se va a detener. La única salida realista es avanzar junto con la tecnología resolviendo o mitigando esas debilidades. En ese proceso, si una medida de mitigación afecta demasiado la productividad, la gente la va a rodear; terminarán imponiéndose complementos que convivan bien con la tecnología

  • Eso de que "los LLM aumentan la productividad de los desarrolladores" varía enormemente según la persona y el contexto. En mi experiencia, quienes hablan de "10x de productividad" suelen ser juniors de frontend o gente de startups que hace apps iniciales una y otra vez. Claro, son casos válidos, pero esa gente y un senior de C embebido muchas veces ni siquiera están hablando el mismo idioma. Por eso el debate de productividad con IA suele ser una conversación entre contextos distintos. Y en cuanto al "uso racional", incluso dudo si la idea misma de agente de IA es buena. Viendo el caso de Copilot, tanto Microsoft como la IA quedaron en ridículo. Puede que delegar trabajo autónomamente a la IA no sea tan inteligente. Algo parecido pasó con blockchain: hubo todo tipo de exageraciones en el auge cripto, pero también casos que sí encontraron un nicho real, como Coinbase. En 2020 IBM decía que gestionaría la cadena de suministro del café con blockchain (visto desde hoy, 2025, suena a chiste de Twitter, pero en ese momento lo decían en serio). Al final, los agentes de IA actuales y otras aplicaciones de IA generativa también podrían terminar viéndose como ejemplos de hype exagerado caso Copilot artículo de Forbes
  • Se repite mucho eso de "más productivo", pero no dice si la combinación humano/IA termina ajustándose mejor a lo que el usuario necesita; solo significa que "se produce más código". Nunca he oído que un LLM haya generado un PR que elimine 2,000 líneas de código. Cuando dicen "mejora la productividad del ingeniero", en realidad casi siempre quieren decir que se escribe más código
  • Se malinterpreta creer que la intención del autor es realmente crítica. No está planteando un sí o no respecto a usar LLM, sino enfocándose en gestión y mitigación del riesgo. Para ponerlo como analogía: no es oponerse al desarrollo del automóvil, sino decir que como los autos pueden explotar, deberíamos concentrarnos más en reducir esa explosión
  • A mí el post original no me suena a "queja vacía", sino a una preocupación realista sobre trampas en las que es fácil caer al colaborar con LLM y sobre qué contramedidas adoptar dentro del equipo
  • Me acuerdo de haberme arrepentido de no aprender React cuando recién salió. También sigo teniendo rechazo hacia GPT, y a mi alrededor todos dicen "eso lo dijo chatGPT" o "este código es de chatGPT", mientras yo siento orgullo de programar pasando por el esfuerzo directo. No uso GPT, pero pensándolo bien, Google o Stack Overflow también podrían verse como un GPT lento

• Más que políticas como "prometo que el código aportado no viene de un LLM, es original y lo entiendo por completo" o exigir que casi todo sea manual, habría que enfocarse en el resultado. Está bien pedir que quien contribuye entienda bien los cambios. Pero políticas tipo "los juniors deben evitar o tienen prohibido usar herramientas LLM por cierto tiempo" no me convencen. Los LLM ayudan muchísimo con el caos del setup de onboarding. Además sirven para entender código y documentación, y también como herramientas útiles de búsqueda y resumen de texto

  • El onboarding en realidad es aprender a resolver problemas aleatorios de entorno. Si automatizamos y eliminamos por completo toda esa dificultad y complejidad, siento que después nadie va a saber qué hacer en ese tipo de situaciones. No sé si soy el único que piensa así

• Nunca había escuchado el concepto de "AI Cliff" (cuando la precisión del LLM cae de golpe). Me da curiosidad si otras personas también lo han vivido

  • A mí me pasa seguido. Cuando la complejidad del código supera cierto umbral, el LLM ya no puede mantener todo el contexto en la cabeza y empieza a comportarse de forma absurda. Mi trabajo pasa a ser gestionar la complejidad que el LLM va a ver. Los LLM actuales tienden a volver la estructura más compleja con el tiempo. Básicamente yo les pido refactors para simplificar o, si se complica demasiado, lo ordeno yo mismo. Si les dejas la tarea indefinidamente, terminan construyendo una enorme confusión estilo Rube Goldberg, y al final un humano tiene que limpiarla. Un desarrollador con experiencia detecta rápido hasta dónde el LLM lo está llevando mar adentro y puede regresar antes; un principiante, en cambio, puede quedar completamente perdido antes siquiera de darse cuenta de lo que pasa
  • Yo le digo context drunk. Si el contexto de entrada tiene 10 mil tokens y está 99% correcto, el LLM responde con mil tokens que solo están 90% correctos. Si sigues intercambiando mensajes, gran parte de la ventana de contexto termina siendo repetición de esas salidas menos precisas del LLM. Los errores se acumulan y, como la información reciente pesa más, todo se va degradando cada vez más. Esto no pasa solo en código, también en prosa
  • Yo lo llamo context rot. A medida que se acumula contexto, baja la calidad de salida. Cuanta más charla o contenido irrelevante haya, más rápido empeora. Sobre todo cuando el chain of thought (COT) queda dentro del contexto: si el razonamiento se desvía, ese rastro agrava el problema. Personalmente me gustaría una función de pruning para recortar solo partes del contexto. Yo lo manejo resumiendo manualmente y llevándolo a una sesión nueva
  • Solo me ha pasado en interfaces de chat tipo vibe coding; las herramientas orientadas a agentes administran por sí mismas la ventana de contexto del código y ejecutan directamente dev tooling para hacer sanity checks, así que esto ocurre mucho menos
  • Suelo resetear seguido las sesiones de IA para trabajo, así que no siento tanto el "AI cliff". Pero cuando escribía ficción, donde la longitud y consistencia del contexto importan mucho, sí me pasó que de repente la IA dejó de sostener bien la personalidad de un personaje y empezó a responder raro. Fue una experiencia muy extraña porque no se podía revertir

• El autor del post dice que no va a resumir lo que escriben varias personas, pero en la práctica parece que sí lo hace. Aun así, me gustaría que en un PR se marcaran los archivos que incluyen código generado por IA. Los errores del código LLM y los del código humano son distintos, así que poder distinguirlos ahorraría tiempo en la revisión. Me pregunto si alguien ha vivido una política así en una organización grande o si ya existen herramientas automáticas para eso. Si las empresas están midiendo la proporción de código generado por LLM, quizá ya exista una herramienta así para métricas más detalladas

  • Soy el autor: en realidad no he visto muchos casos formalizados porque casi no hay discusión explícita sobre confianza dentro del equipo y LLM. No sé si es porque trabajo en el lugar equivocado para ese tipo de problema o porque simplemente es algo difícil de detectar en la corriente principal