Las alucinaciones en el código son la forma menos peligrosa de error de los LLM

• Muchos desarrolladores intentan usar LLM para escribir código, experimentan alucinaciones y pierden la confianza
  • Es común que un LLM invente métodos o librerías que no existen
  • Pero las alucinaciones en el código son el tipo de alucinación menos peligroso
• Lo más peligroso es cuando el LLM introduce errores que el compilador o el intérprete no detectan de inmediato
  • Un método alucinado genera un error en cuanto se ejecuta, por lo que es fácil de detectar
  • Incluso se puede volver a pasar el mensaje de error al LLM para que lo corrija automáticamente
• A diferencia de las alucinaciones en texto general, el código puede verificarse contra los hechos mediante su ejecución
• LLM con capacidad de corrección automática de errores
  • Herramientas como ChatGPT Code Interpreter y Claude Code ejecutan el código escrito por el LLM, detectan errores y los corrigen por sí solas
  • Evaluar código escrito por un LLM sin siquiera ejecutarlo es ineficiente
• Algunos desarrolladores intentan rechazar la tecnología por completo porque el LLM generó métodos alucinados
  • Pero para usarla de forma efectiva, el aprendizaje y la experimentación son indispensables
  • El autor lleva más de dos años investigando la programación asistida por IA y aún sigue aprendiendo nuevas técnicas
• Las pruebas manuales del código son indispensables
  • Que el código se ejecute correctamente no garantiza que haga lo que se esperaba
  • Ni la revisión de código ni las pruebas automatizadas pueden verificar por completo la exactitud del código
  • Es indispensable ejecutarlo y validarlo directamente
  • El código generado por LLM suele ser muy legible, lo que puede hacer que uno baje la guardia
  • Lo mismo aplica al código escrito por personas: no debe confiarse en él hasta probarlo directamente
• Cómo reducir las alucinaciones
  • Usar otro modelo: elegir un modelo con datos de entrenamiento más abundantes para una plataforma específica
    • Ejemplo: Claude 3.7 Sonnet (con thinking mode activado), OpenAI o3-mini-high, GPT-4o (incluyendo Python Code Interpreter)
  • Aprovechar el contexto: aunque el LLM no conozca una librería específica, puede aprender el patrón si se le proporciona código de ejemplo
    • Recientemente esto resultó efectivo al usar la integración con GitHub de Claude
  • Elegir tecnología estable: si se eligen librerías antiguas, es más probable que el LLM las maneje mejor
    • Aplicar la filosofía de Boring Technology
• La importancia de la revisión de código
  • Refuta la afirmación de que "si hay que revisar todo el código escrito por un LLM, es más rápido escribirlo uno mismo"
  • También podría ser una declaración que revela falta de habilidad para revisar código
  • Revisar código generado por LLM puede ser una buena oportunidad para mejorar las propias habilidades
• Bonus: comentarios de Claude 3.7 Sonnet
  • El autor pidió a Claude 3.7 Sonnet que revisara un borrador del blog en su "extended thinking mode"
  • Le pidió que revisara "si la lógica de este texto resulta convincente, qué podría mejorarse y qué contenido falta"
  • Claude ayudó a suavizar el tono del borrador
  • Enlace a la conversación con los comentarios de Claude

[GN⁺]

Opiniones en Hacker News

• El autor estuvo de acuerdo con el artículo anterior, pero no con este

  • Está en desacuerdo con la idea de que “si tengo que revisar todo el código que escribe un LLM, me sale más rápido escribirlo yo mismo”
  • No está de acuerdo con la afirmación de que se ha invertido poco en la capacidad de leer, entender y revisar código de otras personas
  • La revisión depende de la experiencia y la confiabilidad del autor, y revisar aportes anónimos es distinto
  • Es importante inferir y comparar la intención y el enfoque del código, y en el caso de los LLM ese alcance es limitado
  • La motivación importa, y no a todos los desarrolladores les gusta revisar código
  • El código de un LLM no tiene un aspecto social, y otra persona tiene que revisar los cambios

• Aunque el código generado por un LLM funcione bien, si uno no es su autor es difícil encontrar bugs o fallas lógicas

  • Si se ve la programación no como la implementación de un plan bien diseñado sino como armar piezas, preocupa que un algoritmo encaje piezas a base de adivinanzas
  • Un LLM no asume riesgos que un humano sí podría asumir, y puede no entender el significado de un bloque de código en un contexto específico

• El código generado por LLM se ve limpio, pero hace que se invierta más tiempo en QA y en trabajo de limpieza

  • Que el código funcione bien y no tenga errores no significa que esté haciendo lo correcto
  • Ejecutar y probar el código por sí solo no puede demostrar su corrección; hay que razonarlo lógicamente

• The Primeagen y Casey Muratori revisaron la salida de los generadores de código LLM más recientes

  • Debería ser fácil desarrollar si se les da tareas bien representadas en los datos de entrenamiento del LLM
  • En la práctica, el desarrollo iterativo converge hacia código inútil, y el LLM cada vez deja de avanzar más

• Otra categoría de error que Simon pasó por alto es la alucinación en la que el modelo olvida funcionalidades

  • Más allá del lado positivo de que el código compile, el lado negativo de olvidar funciones clave es más difícil
  • La funcionalidad puede cambiar ligeramente según código que se espera que esté fuera de la conversación o de la ventana de contexto

• Los métodos alucinados son un obstáculo pequeño, y cuando la gente se queja de eso se asume que dedicó muy poco tiempo a aprender a usar el sistema con eficacia

  • Esa es una suposición muy equivocada, y la gente ve las alucinaciones y piensa: “si ni siquiera puede acertar de forma consistente en lo más fácil, no se le puede confiar algo más difícil”

• La alucinación en sí no es el mayor riesgo que plantean los LLM

  • Un riesgo mayor es que los chatbots puedan persuadir a los humanos para hacerse daño
  • Ya ha habido casos así, y no quiere compartir ideas sobre qué podría ser aún más peligroso

• Solo es menos riesgoso dentro del contexto limitado de los errores de compilación

  • Le molestaría más si, para evitar el esfuerzo de encontrar una solución real, un programador se inventara una biblioteca completa
  • Si se considera la alucinación como una simple pérdida de velocidad, se está subestimando lo que un LLM realmente debería hacer

• Se necesita mucho esfuerzo para obtener buenos resultados de un LLM

  • Eso atraviesa toda la exageración mediática
  • Queda la duda de para qué sirven los LLM y qué se puede esperar si hay que aprender durante años para obtener resultados poco confiables

• Experiencia escribiendo código en un centro médico para encontrar la clínica 'principal' de un paciente

  • Había que encontrar la cita más reciente considerando solo citas clínicas
  • Si no había citas clínicas, había que encontrar la cita más reciente de cualquier tipo
  • Escribió el código ordenando los datos, pero durante el proceso de documentación ChatGPT entendió el orden al revés
  • Ese es un error mucho peor que “el código no corre”