Resumen Técnico: Change2Task

Planteamiento del Problema

Escalar los agentes de codificación requiere un suministro continuo y de alta calidad de datos ejecutables para el entrenamiento, la evaluación comparativa y la verificación. Cada unidad de tarea debe acoplar un estado de software realista con una especificación, herramientas de desarrollo y una verificación fiable. Los enfoques actuales enfrentan cuellos de botella significativos:

• Costo y Escala: Producir entornos ejecutables es costoso. Sistemas como daVinci-Env y SWE-Universe requieren una infraestructura y un almacenamiento masivos para mantener instantáneas (snapshots) distintas para cada tarea, lo que genera altos costos de construcción y presión de almacenamiento.
• Limitaciones de Datos: Los benchmarks históricos (por ejemplo, SWE-bench) vinculan las tareas a revisiones de repositorios originales, a menudo desactualizadas, lo que limita su aplicabilidad a bases de código modernas. Por el contrario, la generación de tareas sintéticas (por ejemplo, SWE-smith) puede producir instancias que carecen de una intención de desarrollo genuina o de contexto de mantenimiento.
• La Brecha: Existe la necesidad de derivar múltiples tareas verificadas y fundamentadas en desarrolladores a partir de un único entorno de repositorio mantenido, para reducir los esfuerzos redundantes de configuración mientras se expande la diversidad de los datos ejecutables.

Metodología

Change2Task es un marco diseñado para convertir Pull Requests (PRs) fusionados del historial de un repositorio en tareas de agentes de codificación verificadas en revisiones descendentes sanas y modernas del mismo repositorio. El sistema opera sobre el ciclo de vida $V_{pre} \xrightarrow{P_s} V_{post}$ (cambio de estado histórico) y lo reconstruye como $H \xrightarrow{D} C \xrightarrow{G} H'$ (base moderna a estado de la tarea a estado restaurado).

El proceso consta de cuatro etapas clave:

1. Derivación de Evidencia de la Tarea

El sistema extrae evidencia de un PR fusionado, incluyendo su descripción, el parche de implementación y las comprobaciones ejecutables. Esto define:

• Comprobaciones Objetivo (Target Checks): Condiciones a ser reconstruidas.
• Comprobaciones de Regresión (Regression Checks): Comportamientos circundantes que deben permanecer intactos.
• Perfil de Cambio de Fuente (Source Change Profile): Un registro de los componentes afectados y la extensión de la edición.
  Los candidatos se excluyen si las condiciones son ambiguas, si las comprobaciones no son ejecutables o si los cambios no pueden aislarse.

2. Establecimiento de la Base de la Tarea Moderna

Para cada PR elegible, se selecciona una revisión descendente fija y sana ($H$) de la misma línea de tiempo del repositorio. Esta base debe soportar un checkout limpio, dependencias de tiempo de ejecución y comprobaciones ejecutables. El sistema asegura que las comprobaciones objetivo y de regresión mapeadas pasen en $H$ antes de proceder.

3. Construcción del Estado de la Tarea

Change2Task emplea una estrategia de construcción adaptativa de tres niveles para generar el parche de la tarea ($D$) que transforma la base sana ($H$) en el estado de la tarea ($C$):

• Nivel 1: Reversión de Parche (Patch Reversal): Revierte directamente el parche de origen si sigue siendo compatible con el contexto moderno.
• Nivel 2: Mapeo de Código (Code Mapping): Si la reproducción directa falla, el sistema localiza el bloque post-cambio histórico en el archivo moderno y lo reemplaza con su forma pre-cambio, permitiendo la normalización de la indentación y transformaciones locales conservadoras.
• Nivel 3: Reconstrucción por Agente (Agent Reconstruction): Si la correspondencia estructural es insuficiente, un agente de construcción (usando la evidencia del PR y el contexto moderno) propone parches candidatos delimitados. Estos son filtrados por sintaxis, alcance y comprobaciones de ciclo de vida, y luego clasificados por la fidelidad del perfil de cambio de fuente.

4. Validación de Ciclo de Vida y Alcance

Cada candidato se somete a validación a través de tres estados:

1. Sano ($H$): Las comprobaciones objetivo y de regresión pasan.
2. Tarea ($C$): Las comprobaciones objetivo exponen la condición específica de la tarea (por ejemplo, un error o una característica faltante), mientras que las comprobaciones de regresión continúan pasando.
3. Restaurado ($H'$): Tras aplicar un parche de restauración ($G$), ambos conjuntos de comprobaciones pasan, confirmando que el sistema puede regresar a un estado sano.

El sistema también impone puertas de control de Alcance (Scope) y Fidelidad (Fidelity) para asegurar que la tarea moderna no trivialice el cambio original (colapso de alcance) ni requiera ediciones amplias no relacionadas (inflación de alcance).

Contribuciones Clave

• Marco de Trabajo Change2Task: Una herramienta general que transfiere cambios de mantenimiento fundamentados en desarrolladores al código actual, verificando procedencia, comportamiento, alcance y restauración.
• Construcción Adaptativa: Un enfoque de tres niveles (Reversión, Mapeo, Reconstrucción) que escala la complejidad solo cuando es necesario, maximizando la recuperación de tareas válidas a partir de datos históricos.
• Adaptadores de Tareas: Una interfaz unificada que soporta cinco familias distintas de tareas: Corrección de Errores (Bug Fix), Adición de Funcionalidades (Feature Addition), Generación de Pruebas (Test Generation), Migración de API (API Migration) y Reparación de Seguridad (Security Repair).
• Mecanismo de Eficiencia: Al derivar múltiples variantes ligeras de tareas a partir de un único base mantenido, el sistema reduce significativamente los esfuerzos repetidos de configuración de entorno, almacenamiento y construcción manual.

Resultados Experimentales

El sistema fue evaluado en 1,130 cambios de origen elegibles para construcción a través de cinco familias de tareas.

• Tasa de Recuperación: Change2Task finalizó 900 tareas emparejadas, logrando una tasa de éxito de construcción de tareas verificadas del 79.6% global.
  • Corrección de Errores (Bug Fix): Se recuperaron 500 tareas.
  • Comparación: En un conjunto emparejado de 621 candidatos de Corrección de Errores, Change2Task recuperó 500 tareas, frente a 387 para la línea base de espejo de PR de SWE-smith, lo que representa una ganancia relativa del 29.2%.
• Fidelidad: El corpus alcanzó una fidelidad del perfil de cambio de fuente ponderada por tarea de 0.894. Los casos históricos y reconstruidos mostraron hasta un 98.0% de acuerdo en el resultado bajo la evaluación del agente.
• Consistencia del Agente: A través de 3,600 pares agente-tarea emparejados, el acuerdo agregado entre la rama Original (histórica) y la de Change2Task (moderna) fue del 89.7% (Cohen's $\kappa$ = 0.787). La diferencia en la tasa de resolución emparejada fue insignificante (0.0 puntos), lo que indica que las tareas modernas preservan la señal de evaluación comparativa de sus anclajes históricos.
• Eficiencia de Recursos: El reuso de 388 bases modernas para 900 tareas (frente a la preparación de una base por tarea) resultó en:
  • Una reducción del 58.4% en el tiempo total de configuración.
  • Una reducción del 71.2% en los requisitos de almacenamiento.
  • Una reducción del 10.8% en el gasto de extremo a extremo.

Significado y Reivindicaciones

El artículo afirma que Change2Task transforma efectivamente el historial de los repositorios de un registro pasivo en una fuente recuperable de tareas de codificación verificadas. Su principal significado radica en:

1. Escalabilidad: Proporciona un mecanismo para expandir el suministro de datos ejecutables para el entrenamiento de agentes de codificación sin los costos prohibitivos de crear entornos únicos para cada tarea.
2. Fundamentación: Preserva el "contrato de mantenimiento fundamentado en el desarrollador" de los cambios históricos, asegurando que las tareas reflejen intenciones de mantenimiento del mundo real en lugar de artefactos sintéticos.
3. Eficiencia: Al reutilizar bases modernas, reduce drásticamente la sobrecarga computacional y de almacenamiento asociada con la evaluación de agentes a gran escala.

Los autores posicionan a Change2Task como complementario a las herramientas de preparación de entornos existentes (como RepoLaunch), abordando específicamente la fase después de que una base es ejecutable, donde el objetivo es maximizar el número de tareas distintas y verificadas derivadas de esa inversión.