Resumen Técnico: Prefactory – Descubrimiento Automatizado y Aplicación de Refactorizaciones de Adopción de Librerías

Declaración del Problema

La refactorización de adopción de librerías consiste en reemplazar implementaciones de código escritas a mano por llamadas a las API de librerías existentes. Esta práctica reduce el tamaño del código, mejora la calidad idiomática y aprovecha implementaciones bien probadas. Sin embargo, automatizar este proceso es un desafío debido a que:

1. Falta de pistas explícitas: El código original escrito a mano a menudo no menciona la librería de destino ni la API específica, lo que dificulta que las herramientas que dependen de sentencias de importación o referencias directas encuentren oportunidades.
2. Variabilidad sintáctica: Los desarrolladores implementan la misma funcionalidad de diversas formas (diferentes nombres de variables, flujos de control o funciones auxiliares), lo que significa que los patrones sintácticos fijos o las reglas de linter suelen fallar en generalizar.
3. Limitaciones de los enfoques existentes:
   • Herramientas estáticas: Los linters y modernizadores (por ejemplo, Ruff, Pylint) son efectivos solo para patrones precisos especificados manualmente.
   • Agentes de LLM: Aunque los Modelos de Lenguaje de Gran Escala (LLM) pueden generalizar a patrones variados, usarlos para escanear bases de código completas mediante prompts repetidos es costoso, difícil de reproducir y difícil de controlar sistemáticamente a escala.

El cuello de botella central es la detección: encontrar regiones de código relevantes sin menciones explícitas de la librería y generalizar más allá de plantillas fijas, seguido de la generación de un reemplazo que preserve el comportamiento.

Metodología: El Pipeline de Prefactory

Prefactory es un pipeline automatizado de cuatro etapas diseñado para convertir el conocimiento semántico de los LLM en mecanismos de búsqueda deterministas y reutilizables. Opera sobre un proyecto objetivo y el nombre de una librería objetivo.

Etapa 1: Generación de Detectores

En lugar de pedir a un LLM que escanee el código directamente, Prefactory utiliza un LLM para sintetizar detectores ejecutables.

• Entrada: Metadatos de la librería objetivo (de PyPI, documentación y ejemplos minados de refactorizaciones pasadas) y vocabulario del proyecto (nombres frecuentes del proyecto objetivo).
• Salida: Dos familias de detectores:
  1. Detectores Léxicos: Expresiones regulares que coinciden con términos de dominio, nombres relacionados con la API y patrones textuales asociados con implementaciones escritas a mano.
  2. Detectores Estructurales: Coincidencias de AST (Árbol de Sintaxis Abstracta) que identifican formas algorítmicas (por ejemplo, bucles sobre valores, computación de índices aritméticos, acumulación en estructuras de datos) independientemente de los nombres de variables específicos.
• Validación: Los detectores generados se filtran para asegurar que compilen, no fallen y no produzcan coincidencias excesivamente amplias (por ejemplo, coincidir con >20% de los archivos).

Etapa 2: Escaneo del Proyecto

Esta etapa es determinista y libre de LLM.

• Prefactory filtra archivos que no son de código fuente (por ejemplo, código vendido, pruebas, documentación).
• Los detectores léxicos y estructurales validados se ejecutan contra los archivos de código fuente restantes.
• Las coincidencias se registran, identificando archivos y funciones candidatas, junto con la coincidencia de detector específica que activó la alerta.

Etapa 3: Clasificación y Filtrado de Candidatos

Para gestionar los costos de los LLM, Prefactory clasifica los candidatos y selecciona un subconjunto pequeño para la reescritura.

• Métrica de Clasificación: Se calcula una tupla $(D(c), B(c), -S(c))$ para cada candidato $c$:
  • $D(c)$: Fuerza de coincidencia del detector (suma ponderada de coincidencias, priorizando coincidencias estructurales).
  • $B(c)$: Densidad de patrones básicos de implementación de Python (bucles, aritmética, ramas) que indican lógica escrita a mano.
  • $S(c)$: Tamaño del candidato (se prefiere uno más pequeño).
• Selección: Se seleccionan los 5 archivos superiores y, dentro de ellos, se eligen las 10 funciones superiores para la siguiente etapa.

Etapa 4: Generación de Refactorización y Validación

• Generación: Se le proporciona a un LLM la función candidata, el contexto circundante, pistas de la API de la librería objetivo y las coincidencias específicas del detector. Intenta reescribir la función utilizando la librería objetivo.
• Filtrado de Relevancia: Verificaciones basadas en AST aseguran que la edición realmente llame a la librería objetivo y no sea un cambio cosmético.
• Validación:
  1. Pruebas Diferenciales: Un LLM genera un script de prueba independiente que compara las funciones original y refactorizada con entradas generadas (usando la original como oráculo). Si la prueba falla, se le pide al LLM que repare la edición (hasta 3 intentos).
  2. Pruebas del Proyecto: Si las pruebas diferenciales pasan, el código refactorizado se ejecuta contra la suite de pruebas existente del proyecto para asegurar que no haya regresiones.

Principales Contribuciones

1. PrefactoryBench: Un benchmark de 100 refactorizaciones de adopción de librerías del mundo real de 61 proyectos de código abierto en Python y 18 librerías. Incluye entornos de ejecución de referencia, pruebas de proyecto y pruebas dejadas fuera (held-out) para evaluar tanto la detección como la transformación.
2. Sistema Prefactory: Un enfoque automatizado que sintetiza detectores ejecutables y reutilizables (léxicos y estructurales) a partir del conocimiento de los LLM, permitiendo un escaneo eficiente y determinista sin llamadas repetidas al LLM durante la fase de búsqueda.
3. Evidencia Empírica: Una comparación controlada que demuestra que la síntesis de detectores supera al prompting directo de LLM, la búsqueda agéntica y las herramientas basadas en reglas tanto en precisión de detección como en eficiencia de costos.

Resultados

Evaluado en PrefactoryBench, Prefactory logró lo siguiente:

• Detección: Detectó 75 instancias a nivel de archivo y 56 a nivel de función.
• Refactorización: Produjo 40 refactorizaciones validadas (que pasan tanto las pruebas diferenciales como las del proyecto) a partir de las 56 funciones detectadas.
• Comparación: Superó a la base más fuerte, Codex CLI (que detectó 35 archivos y 32 funciones y produjo 22 refactorizaciones validadas), así como a linters, el prompting de LLM puro y Semgrep+LLM.
• Eficiencia:
  • Tiempo de Escaneo: Promedio de 1.3 segundos por proyecto (libre de LLM).
  • Costo: El costo de extremo a extremo es inferior a $0.05 por instancia, aproximadamente un tercio del costo de la base de referencia Codex CLI.
  • Reutilización: Los detectores se generan una vez por par proyecto-librería y se reutilizan para el escaneo, haciendo que los escaneos repetidos sean económicos.
• Aplicación en el Mundo Real: En un estudio sobre versiones actuales de cinco proyectos de referencia, Prefactory presentó oportunidades accionables, con dos pull requests aceptados por los mantenedores.

Significancia y Reivindicaciones

El artículo afirma que la síntesis de detectores es un flujo de trabajo práctico y escalable para la refactorización de adopción de librerías. Al convertir el conocimiento semántico del LLM en mecanismos de búsqueda deterministas y ejecutables, Prefactory evita el alto costo y los problemas de reproducibilidad de la búsqueda agéntica directa.

Los autores señalan que el enfoque es más efectivo cuando las oportunidades de la librería exponen tanto vocabulario como estructuras de implementación reconocibles. Las limitaciones persisten para librerías grandes y heterogéneas (por ejemplo, numpy, pandas) donde las oportunidades abarcan muchas familias de API, y para código que involucra I/O complejo o comportamiento distribuido donde la validación diferencial es difícil. El trabajo demuestra que capturar el conocimiento de los LLM en detectores ejecutables y reutilizables es más efectivo y barato que aplicar el razonamiento de los LLM a través de consultas amplias y repetidas.