CodeTaste: Can LLMs Generate Human-Level Code Refactorings?

El artículo presenta CodeTaste, una evaluación que revela que, aunque los agentes de LLM pueden ejecutar refactorizaciones cuando se les especifican en detalle, a menudo fallan en identificar las decisiones humanas naturales, aunque una estrategia de "proponer e implementar" mejora su alineación con las preferencias de los desarrolladores.

Lo esencial

¡Claro que sí! Imagina que el código de un programa es como una casa.

Cuando un arquitecto (un desarrollador humano) diseña una casa, no solo se preocupa de que tenga techo y puertas. Se preocupa de que los pasillos tengan sentido, de que la cocina esté cerca del comedor y de que, si en el futuro quieren añadir una habitación, sea fácil hacerlo sin romper todo.

Los Agentes de IA (como los modelos de lenguaje o LLMs) son como constructores robots muy rápidos. Pueden levantar muros, poner ventanas y hacer que la casa funcione en cuestión de segundos. El problema es que, a veces, estos robots construyen casas que funcionan, pero que son un desorden: tienen pasillos que dan vueltas sin sentido, puertas que se abren a la nada y cimientos frágiles. Con el tiempo, la casa se vuelve imposible de ampliar o reparar.

Aquí es donde entra el reordenamiento (refactorización). Es el arte de reorganizar la casa sin cambiar lo que hace (la gente sigue viviendo ahí igual), pero mejorando su estructura para que sea más limpia y duradera.

¿Qué descubrió este estudio? (CODETASTE)

Los autores de este papel crearon un examen muy difícil llamado CODETASTE para ver si estos "constructores robots" pueden hacer ese trabajo de reordenamiento tan bien como un humano experto.

Imagina que el examen tiene dos partes:

1. La parte "Con Receta" (Instructed Track)

Aquí, les das al robot una receta paso a paso: "Quita esta pared, mueve la ventana 2 metros a la derecha y cambia el suelo por madera".

• Resultado: ¡Van bastante bien! Los robots más avanzados (como GPT-5) siguen las instrucciones casi a la perfección. Saben mover los muebles si se lo dices exactamente cómo hacerlo.

2. La parte "Sin Receta" (Open Track)

Aquí es donde se pone interesante. Les das al robot una instrucción vaga: "Esta sala se siente un poco desordenada, haz que se vea mejor". No les dices qué mover, solo les das el objetivo general.

• Resultado: ¡Desastre! Los robots se pierden. En lugar de reorganizar la estructura de la casa, a veces deciden:
  • Cambiar el color de la puerta (algo superficial).
  • Poner un parche rápido y feo en la pared para que no se vea el agujero (soluciones "hacky").
  • O peor aún, empiezan a pintar el techo cuando el problema era el suelo.

La analogía del "Chef vs. El Comensal"

Piensa en un Chef experto (el desarrollador humano) y un Robot de cocina (la IA).

• Si le dices al robot: "Corta las zanahorias en rodajas de 2mm", lo hará perfecto.
• Pero si le dices: "Hoy la comida está muy aburrida, dale un toque especial", el robot podría:
  • Ponerle mucha sal (demasiado).
  • Cambiar el plato por otro que no combina.
  • O simplemente no saber qué hacer y dejar la comida igual.

El estudio descubrió que, aunque los robots son geniales siguiendo instrucciones, les cuesta mucho tener el "instinto" o el "gusto" humano para saber qué es lo que realmente necesita arreglarse en un código complejo sin que se lo digan.

¿Qué aprendimos?

1. El "Ojo Humano" falta: A los robots les falta la capacidad de ver el panorama completo y decir: "Aquí hay un problema de diseño que nadie ha notado, pero que vamos a arreglar".
2. Planear ayuda (pero no es magia): Si obligamos al robot a escribir un plan antes de tocar el código ("Primero voy a mover la pared, luego el suelo..."), mejora un poco, pero sigue lejos de lo que haría un humano.
3. La calidad a largo plazo: Si dejamos que estos robots construyan y reordenen código solos sin supervisión, terminaremos con "deuda técnica": casas que parecen funcionar hoy, pero que dentro de un año serán un caos imposible de vivir.

En resumen

El estudio CODETASTE nos dice que, aunque la IA es increíble para escribir código nuevo o seguir instrucciones precisas, aún no tiene el "sentido común" ni la visión arquitectónica para mejorar el código por sí misma cuando solo le decimos "arregla esto".

Para que la IA sea un verdadero socio en la ingeniería de software, no solo necesitamos que escriba mejor, sino que aprenda a pensar como un humano y a tomar decisiones de diseño inteligentes, no solo mecánicas. Por ahora, los humanos seguimos siendo los mejores arquitectos de nuestras casas digitales.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "CODETASTE: Can LLMs Generate Human-Level Code Refactorings?" en español, estructurado según los puntos solicitados:

1. El Problema

Los agentes de programación basados en Modelos de Lenguaje Grande (LLM) han demostrado una gran capacidad para generar código funcional y resolver problemas específicos. Sin embargo, existe una preocupación crítica sobre la calidad a largo plazo del código que producen. A medida que evolucionan los requisitos, las soluciones generadas por agentes tienden a acumular complejidad, duplicación y "deuda técnica", volviéndose difíciles de mantener y extender.

El problema central abordado en este trabajo es la incapacidad de los agentes para realizar refactorizaciones autónomas que preserven el comportamiento pero mejoren la estructura del código. Mientras que los desarrolladores humanos utilizan la refactorización para limpiar la deuda técnica, los agentes actuales:

• Suelen fallar al identificar oportunidades de refactorización por sí mismos.
• Tienden a aplicar cambios mínimos o "parches" insuficientes si no se les da una instrucción detallada.
• No logran alinear sus decisiones de refactorización con las preferencias humanas en escenarios de especificación abierta.

2. Metodología

Los autores presentan CODETASTE, un nuevo benchmark (punto de referencia) diseñado para evaluar rigurosamente la capacidad de los agentes de codificación para realizar refactorizaciones en repositorios reales de código abierto.

Pipeline de Construcción del Benchmark

El proceso sigue seis etapas clave (ilustradas en la Figura 1 del artículo):

1. Descubrimiento de Commits: Minería de repositorios populares de GitHub para identificar 100 refactorizaciones grandes y multi-archivo realizadas por humanos.
2. Generación de Tareas: Creación de descripciones de tareas estructuradas (simulando issues de GitHub) a partir de los mensajes de commit y los cambios de código.
3. Generación de Reglas Estáticas: Uso de un agente LLM para generar reglas de análisis estático (basadas en OpenGrep) que capturan la intención semántica de la transformación (patrones deseables a introducir y patrones no deseables a eliminar). Estas reglas utilizan razonamiento de flujo de datos simbólico, no solo coincidencia sintáctica.
4. Entorno de Ejecución: Creación de contenedores reproducibles que aíslan el entorno de prueba, garantizando que el agente no pueda acceder a la solución "dorada" (golden patch) y que pueda ejecutar la suite de pruebas del repositorio.
5. Inferencia: Los agentes intentan aplicar la refactorización basándose en la descripción de la tarea.
6. Evaluación: Se evalúa el parche generado comparándolo con las reglas estáticas y la suite de pruebas.

Pistas de Evaluación (Tracks)

El benchmark incluye dos pistas complementarias:

• Pista Instruida (Instructed Track): El agente recibe una descripción detallada de la refactorización exacta a realizar. Evalúa la capacidad de ejecución y seguimiento de instrucciones.
• Pista Abierta (Open Track): El agente recibe solo un área de enfoque general (ej. "mejorar la organización interna") sin detalles sobre la solución específica. Evalúa la capacidad de descubrimiento autónomo y alineación con las decisiones humanas.

Métricas

• Puntuación de Alineación (Alignment Score): Combina la corrección funcional (pasar las pruebas) con la adherencia a la intención de refactorización (cumplir las reglas estáticas).
• Tasa de Seguimiento de Instrucciones (IFR): Mide qué porcentaje de patrones deseados se introdujeron y qué porcentaje de patrones no deseados se eliminaron.
• Precisión: Evalúa si los cambios realizados se limitan al ámbito relevante o si introducen modificaciones no relacionadas.

3. Contribuciones Clave

1. CODETASTE: El primer benchmark a gran escala que evalúa refactorizaciones multi-archivo en repositorios reales, superando las limitaciones de benchmarks anteriores que se centraban en archivos únicos o cambios sintéticos pequeños.
2. Validación Semántica: Introducción de reglas de análisis estático con razonamiento de flujo de datos para verificar transformaciones de código más allá de la simple coincidencia de texto o el paso de pruebas unitarias.
3. Análisis de la Brecha de Alineación: Demostración empírica de que, aunque los modelos avanzados pueden ejecutar refactorizaciones detalladas, fallan estrepitosamente al intentar inferir y ejecutar las decisiones de refactorización humanas en escenarios abiertos.
4. Estrategias de Mejora: Identificación de que una estrategia de "proponer-antes-de-implementar" (Plan Mode) y la selección de la mejor propuesta mediante un juez oráculo mejoran significativamente la alineación en la pista abierta.

4. Resultados Experimentales

Los autores evaluaron modelos de vanguardia (GPT-5.2, GPT-5.1 Mini, Claude Sonnet 4.5, Qwen3) en los 100 casos de estudio.

• Pista Instruida: Los modelos de vanguardia muestran un buen rendimiento, pero con brechas significativas.

  • GPT-5.2 lidera con una puntuación de alineación del 69.6%, superando a Claude Sonnet 4.5 (32.4%) y Qwen3 (11.8%).
  • La principal diferencia radica en la corrección funcional (PASS): GPT-5.2 mantiene mejor la integridad del código (76% de pruebas pasadas) frente a otros modelos que a menudo rompen el código al intentar cambios grandes.
  • Los modelos tienden a ser precisos (evitan cambios irrelevantes) cuando la instrucción es clara.

• Pista Abierta (El desafío real): El rendimiento colapsa cuando no hay instrucciones detalladas.

  • La puntuación de alineación máxima en modo directo es de solo 7.7% (GPT-5.2).
  • Los agentes a menudo se fijan en problemas superficiales (errores tipográficos), aplican soluciones "hacky" o realizan cambios destructivos en todo el repositorio.
  • Estrategia de Planificación: Implementar un paso de planificación previa ("Plan Mode") duplica la puntuación de alineación de GPT-5.2 (de 7.7% a 14.1%), sugiriendo que el razonamiento explícito ayuda a recuperar la intención arquitectónica humana.
  • Selección Oráculo: Permitir que el agente genere múltiples planes y seleccionar el mejor mediante un juez LLM eleva la alineación a 19.4%, aunque sigue estando muy lejos de la perfección humana.

• Costo: Las refactorizaciones exhaustivas son costosas. GPT-5.2 agotó el presupuesto monetario en más casos que otros modelos debido a su enfoque de parches dirigidos y verificación de pruebas.

5. Significado e Impacto

El trabajo de CODETASTE tiene implicaciones profundas para el futuro de la ingeniería de software asistida por IA:

• Límite Actual de la Autonomía: Confirma que, aunque los LLMs son excelentes ejecutores de tareas específicas, carecen del juicio autónomo necesario para identificar y ejecutar refactorizaciones complejas que preserven la calidad a largo plazo.
• Necesidad de Nuevos Paradigmas: Sugiere que para lograr agentes de codificación verdaderamente útiles, es necesario integrar mecanismos de planificación, razonamiento arquitectónico y selección de estrategias antes de la implementación directa.
• Herramienta de Entrenamiento: CODETASTE proporciona una señal de preferencia (preference signal) crucial para alinear futuros modelos con las decisiones de refactorización humanas, moviendo el enfoque de "generar código que funcione" a "generar código que sea mantenible".
• Relevancia Industrial: Dado que la deuda técnica es un problema masivo en la industria, la incapacidad actual de los agentes para resolverla autónomamente representa un obstáculo significativo para la adopción generalizada de agentes de software autónomos.

En resumen, el paper demuestra que la brecha entre la capacidad de un agente para hacer una refactorización (cuando se le dice cómo) y descubrir qué refactorización hacer (cuando se le da libertad) es enorme, y que cerrar esta brecha requiere avances en el razonamiento estratégico de los modelos, no solo en su capacidad de generación de código.