💻 computer science

A Study of LLMs' Preferences for Libraries and Programming Languages

Este estudio revela que los modelos de lenguaje grandes (LLMs) tienden a priorizar la familiaridad y popularidad de bibliotecas como NumPy y del lenguaje Python sobre la idoneidad técnica en la generación de código, lo que subraya la necesidad de ajustar estos modelos y diversificar los datos de entrenamiento para mejorar la selección óptima de herramientas.

Autores originales: Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

Publicado 2026-04-09

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes un chef de cocina muy inteligente (un Modelo de Lenguaje o IA) al que le pides que prepare un plato. Le dices: "Hazme una ensalada" o "Prepárame un postre".

Este chef es increíble: sabe cocinar rápido, sigue las recetas a la perfección y nunca se equivoca en los ingredientes básicos. Pero, ¿sabías que este chef tiene muy mal gusto para elegir qué ingredientes usar, incluso cuando no son necesarios?

Así es como funciona el estudio que acabamos de leer. Los investigadores decidieron investigar no si el chef sabe cocinar, sino qué ingredientes y utensilios elige automáticamente cuando nadie le dice qué usar.

Aquí tienes los hallazgos principales, explicados con analogías sencillas:

1. El Chef Obsesionado con la "Marca Popular" (Librerías)

Imagina que tienes que medir un poco de harina. El chef, en lugar de usar una simple cuchara de cocina (que sería suficiente), saca una balanza industrial gigante (una librería de software pesada como NumPy) que ocupa toda la encimera.

El problema: El estudio descubrió que estos chefs (las IAs) usan librerías famosas y pesadas (como las de ciencia de datos) en un 45% de las veces cuando no las necesitan.
La analogía: Es como si, para escribir una carta de amor, siempre usaras una máquina de escribir de la Segunda Guerra Mundial porque es "famosa", en lugar de usar un lápiz simple que es más rápido y adecuado para la tarea.
La consecuencia: Se pierden herramientas nuevas y más eficientes porque el chef solo conoce y confía en las "viejas y famosas".

2. El Chef que solo sabe cocinar "a la Italiana" (Python)

Ahora, imagina que le pides al chef que prepare un plato que requiere fuego muy alto y control de precisión, como una parrilla de acero o un motor de coche. Lo ideal sería usar herramientas de metal y fuego directo (lenguajes como C++, Rust o Go).

El problema: El chef, sin importar la tarea, siempre decide usar el mismo tipo de pasta (Python).
La estadística: Incluso en tareas donde Python es lento y torpe (como crear un servidor web rápido o un sistema de trading de alta velocidad), el chef usa Python en el 58% de los casos. ¡Y en el caso de Rust (un lenguaje muy rápido y seguro), no lo usó ni una sola vez!
La analogía: Es como si te pidieran construir un cohete espacial y el arquitecto dijera: "¡Perfecto! Usaremos madera y pegamento porque es lo que tengo en el garaje y es lo que todos usan para construir casas". Funciona para una casa, pero el cohete no volará.

3. El Chef que miente sobre lo que va a cocinar (Inconsistencia)

Aquí viene la parte más curiosa. Si le preguntas al chef: "¿Qué utensilio es mejor para cortar un tomate?", él te dirá honestamente: "Un cuchillo afilado y ligero".

Pero, cuando le das la orden de cortar el tomate, saca un machete gigante y empieza a golpear el tomate.

El hallazgo: Las recomendaciones que dan las IAs en texto (lo que dicen que harían) no coinciden con el código que realmente escriben.
La analogía: Es como un amigo que te dice: "Para ir a la playa, lo mejor es llevar un coche pequeño y ágil", pero cuando llegas a la puerta, sale conduciendo un camión de mudanzas enorme. Confía en sus palabras, pero no en sus acciones.

¿Por qué pasa esto?

Los investigadores creen que estos chefs (las IAs) han aprendido cocinando viendo millones de recetas en internet (datos de entrenamiento). Como la mayoría de las recetas populares en internet usan los mismos ingredientes viejos y el mismo tipo de pasta, el chef asume que eso es lo correcto.

¿Por qué nos debería importar?

Si dejamos que estos chefs diseñen el futuro del software:

Perderemos innovación: Las herramientas nuevas y mejores nunca se usarán porque el chef las ignora.
Seremos ineficientes: Tendremos programas lentos y pesados (como usar un camión para ir a la tienda de la esquina) porque el chef no sabe elegir lo óptimo.
Crearemos un círculo vicioso: Como las IAs escriben más código con estas herramientas viejas, las futuras IAs aprenderán que esas son las únicas herramientas que existen.

En resumen

Este estudio nos advierte que, aunque las IAs son geniales escribiendo código, son muy conservadoras y predecibles. Prefieren lo que es "famoso" a lo que es "mejor".

La solución no es prohibirles cocinar, sino enseñarles a ser más curiosos, a probar nuevos ingredientes y a elegir la herramienta adecuada para cada trabajo, no solo la que todos usan por costumbre.

Resumen Técnico: Preferencias de los Modelos de Lenguaje Grande (LLM) en la Selección de Tecnologías

1. Planteamiento del Problema

A pesar de los rápidos avances en la generación de código por parte de los Modelos de Lenguaje Grande (LLM), las evaluaciones existentes se centran casi exclusivamente en la corrección funcional o la validez sintáctica. Existe una brecha crítica en el conocimiento sobre cómo los LLMs toman decisiones de diseño fundamentales, específicamente:

Selección de bibliotecas: ¿Qué librerías eligen cuando el usuario no especifica dependencias?
Selección de lenguaje de programación: ¿Qué lenguaje eligen cuando no se le indica uno?

Estas preferencias pueden tener efectos tangibles en el rendimiento del software, la eficiencia, la mantenibilidad y la diversidad del ecosistema. El riesgo es que los LLMs refuercen tecnologías dominantes (como Python y bibliotecas establecidas) ignorando alternativas más adecuadas para tareas específicas (por ejemplo, lenguajes de alto rendimiento como Rust o C++), creando ciclos de retroalimentación que limitan la innovación y la diversidad técnica.

2. Metodología

Los autores realizaron el primer estudio empírico sistemático de las preferencias de ocho LLMs de nivel de producción (incluyendo GPT-4o-mini, GPT-3.5-turbo, Claude-3.5 Sonnet/Haiku, Llama-3.2-3B, Mistral-7B, Qwen-2.5-Coder y DeepSeek-LLM).

El estudio se estructuró en tres experimentos principales:

Experimento 1: Preferencias de Bibliotecas (Python)
- Tareas de Benchmark: Utilizaron BigCodeBench (525 tareas filtradas para eliminar referencias a bibliotecas externas en el prompt). Se pidió a los modelos generar código autocontenido usando al menos una librería externa.
- Inicialización de Proyectos: Se generaron 100 respuestas por modelo para cinco tipos de proyectos (Base de datos, Aprendizaje profundo, Computación distribuida, Web scraper, Servidor web) con descripciones abiertas.
- Objetivo: Medir qué bibliotecas eligen los LLMs cuando no se les da una dirección específica.
Experimento 2: Preferencias de Lenguajes de Programación
- Tareas de Benchmark: Utilizaron seis conjuntos de datos agnósticos al lenguaje (Multi-HumanEval, MBXP, AixBench, CoNaLa, APPS, CodeContests), eliminando tareas que mencionaban explícitamente un lenguaje.
- Inicialización de Proyectos: Se plantearon escenarios donde Python es subóptimo (servidores web concurrentes, interfaces gráficas, plataformas de trading de baja latencia, procesamiento paralelo, aplicaciones a nivel de sistema).
- Objetivo: Determinar si los LLMs eligen Python por defecto incluso cuando no es la opción técnica óptima.
Experimento 3: Consistencia de Recomendaciones
- Se compararon las recomendaciones en lenguaje natural (NL) de los LLMs (qué tecnología dicen que es mejor) con las tecnologías que realmente usaron al generar el código.
- Se utilizó el coeficiente de correlación de rangos de Kendall ( $\tau_b$ ) para medir la consistencia entre la recomendación y la implementación.

3. Contribuciones Clave

Primer estudio empírico que cuantifica sistemáticamente los sesgos de preferencia de LLMs hacia bibliotecas establecidas y Python.
Análisis de la brecha entre recomendación y realidad: Demostración de que las recomendaciones en lenguaje natural son un indicador débil de lo que el modelo realmente implementará.
Recurso abierto: Publicación del código, conjuntos de datos y resultados completos para fomentar la investigación futura sobre sesgos en la generación de código.

4. Resultados Principales

A. Sesgo hacia Bibliotecas Establecidas (Overuse)

Dominio de las "Tres Grandes": En las tareas de BigCodeBench, todos los modelos mostraron una distribución casi idéntica, utilizando masivamente NumPy, pandas y Matplotlib.
Uso innecesario: En hasta el 45% de los casos, los LLMs importaron NumPy cuando la solución de referencia (ground truth) no lo requería.
Falta de diversidad: A pesar de existir miles de bibliotecas en PyPI, los modelos utilizaron menos de 40 bibliotecas distintas en cientos de tareas.
Ignorancia de alternativas de alto impulso: Los modelos prefirieron bibliotecas antiguas (ej. Flask, Dask, Matplotlib) sobre alternativas más modernas y de alto rendimiento con mayor crecimiento en GitHub (ej. FastAPI, Ray, Polars, Plotly). Por ejemplo, Polars (más rápido que pandas) no fue utilizado en absoluto en las tareas de benchmark.

B. Preferencia Abrumadora por Python

En Benchmarks: Python fue el lenguaje elegido en el 93-97% de las respuestas, incluso en conjuntos de datos multilingües.
En Proyectos Subóptimos: En tareas donde Python es técnicamente inferior (alta concurrencia, baja latencia, gestión de memoria), los LLMs siguieron eligiendo Python en el 58% de los casos.
Ausencia de otros lenguajes: En tareas de alto rendimiento, lenguajes como Rust no fueron utilizados ni una sola vez en muchos de los modelos estudiados, a pesar de ser la opción óptima para seguridad de memoria y rendimiento.

C. Inconsistencia entre Recomendación y Código

Baja correlación: Existe una baja consistencia entre lo que los LLMs recomiendan en texto y lo que codifican.
Datos: Para las tareas de inicialización de proyectos, los LLMs contradicen sus propias recomendaciones de lenguaje el 83% de las veces. Por ejemplo, pueden recomendar Rust o C++ para un servidor de alta velocidad, pero generar el código en Python.
Señal débil: Las respuestas en lenguaje natural no son un predictor fiable del comportamiento de generación de código.

5. Significado e Implicaciones

Riesgos del Ecosistema: La tendencia a homogeneizar el código hacia Python y bibliotecas antiguas puede estancar la adopción de tecnologías más eficientes y seguras, creando un "ciclo de retroalimentación" donde los LLMs entrenan con datos generados por LLMs, reforzando el sesgo.
Impacto en la Seguridad y Rendimiento: La selección automática de Python para tareas de baja latencia o gestión de memoria crítica puede introducir cuellos de botella de rendimiento o vulnerabilidades de seguridad que otros lenguajes evitarían.
Necesidad de Mejoras:
- Afinado (Fine-tuning) dirigido: Los modelos deben ser ajustados para priorizar la idoneidad técnica sobre la popularidad.
- Diversificación de datos: Se requiere una composición de datos de entrenamiento más equilibrada que no favorezca excesivamente a Python.
- Nuevas Métricas: Las evaluaciones de LLMs deben incluir métricas de "fidelidad en la selección de lenguaje y librería", no solo corrección funcional.

Conclusión:
El estudio revela que los LLMs actúan como amplificadores de la popularidad histórica de las tecnologías en lugar de asesores técnicos objetivos. Priorizan la familiaridad y la disponibilidad de datos de entrenamiento sobre la optimalidad específica de la tarea, lo que plantea desafíos significativos para la diversidad y la eficiencia futura del desarrollo de software asistido por IA.