Resumen Técnico: SWE-RPG

Declaración del Problema

Los agentes de codificación impulsados por modelos de lenguaje de gran tamaño (LLM) se despliegan cada vez más para modificar repositorios de código existentes para tareas como la corrección de errores y la implementación de funcionalidades. Sin embargo, los benchmarks actuales a nivel de repositorio (por ejemplo, SWE-bench, RACE-bench) evalúan principalmente el éxito basándose en un resultado binario de "pasa/falla" del parche de código final frente a pruebas ejecutables. Este enfoque centrado en el resultado no logra diagnosticar por qué falla un agente. La resolución de un problema a nivel de repositorio requiere una cadena compleja de razonamiento interdependiente: la recuperación de requisitos explícitos e implícitos, la formulación de un plan de implementación fundamentado en el repositorio y la traducción de ese plan en código correcto. Un veredicto final no puede distinguir si un fallo se debió a una mala comprensión de las restricciones implícitas, a la generación de un plan insuficiente o a la escritura de código incorrecto. En consecuencia, los benchmarks existentes carecen de la granularidad necesaria para identificar cuellos de botella específicos o proporcionar direcciones claras para mejorar las arquitecturas de los agentes.

Metodología

Para abordar estas limitaciones, los autores presentan SWE-RPG (Software Engineering - Requirement, Planning, and Generation), un benchmark unificado diseñado para la evaluación consciente de las etapas (stage-aware).

Construcción del Benchmark

SWE-RPG consta de 163 tareas derivadas de 31 repositorios maduros de Python y Java, que incluyen 113 correcciones de errores y 50 adiciones de funcionalidades. El proceso de construcción implicó un filtrado riguroso de más de 2,000 pares de problemas-PR iniciales para asegurar entornos reproducibles y pruebas estables.

La innovación central de SWE-RPG es la construcción de referencias de Verdad de Terreno (GT) validadas para las etapas intermedias, no solo para el parche final:

1. Clarificación de Requisitos GT: Reconociendo que las descripciones iniciales de los problemas suelen omitir detalles críticos de implementación, los autores desarrollaron una taxonomía guiada por profesionales de seis categorías (Intención Funcional, Semántica de Negocio, Contexto Técnico, Especificaciones de Interfaz/Protocolo, Estructura de Código/Convenciones y Semántica de Estructura de Datos). Utilizando agentes de síntesis y validación contra evidencia del repositorio (problemas, PRs, parches), generaron "Clarification GTs" en forma de pares QA que hacen explícitos los requisitos implícitos.
2. Planificación de Implementación GT: Los autores sintetizaron planes de implementación accionables y paso a paso. Crucialmente, estos planes fueron validados para su reproducibilidad: se pidió a un agente de codificación que generara código a partir de cada paso del plan para verificar que producía un sub-parche funcionalmente equivalente a la referencia de oro. Esto asegura que los planes son suficientes para generar código correcto.
3. Generación de Código GT: Los parches de oro finales se obtuvieron directamente de Pull Requests fusionados, con pruebas relevantes para la tarea sirviendo como oráculo ejecutable.

Protocolo de Evaluación

El benchmark evalúa a los agentes a través de tres etapas:

• Clarificación de Requisitos: Mide la capacidad del agente para recuperar requisitos implícitos frente al Clarification GT.
• Planificación: Evalúa si el plan generado por el agente cubre los pasos y restricciones necesarios definidos en el Planning GT.
• Generación de Código: Evalúa el parche final frente a pruebas ejecutables.

Para las ejecuciones no resueltas, un juez de LLM atribuye el fallo a la etapa de desviación más temprana (Requisito, Planificación, Generación de Código u Otros), permitiendo un diagnóstico retrospectivo de la trayectoria del agente.

Contribuciones Clave

1. Benchmark SWE-RPG: El primer benchmark a nivel de repositorio que evalúa conjuntamente las capacidades de los agentes en clarificación de requisitos, planificación de implementación y generación de código, respaldado por verdades de terreno intermedias validadas.
2. Diagnóstico Consciente de la Etapa: Un protocolo que va más allá de las métricas de éxito binarias para atribuir los fallos a etapas de razonamiento específicas, revelando cuellos de botella de capacidad distintos.
3. Evaluación Exhaustiva: Una evaluación de tres marcos de agentes de codificación populares (Claude Code, Codex, OpenCode) emparejados con seis backends de LLM recientes (incluyendo Claude-Sonnet-5, GPT-5.6-Terra y MoonshotAI-Kimi-K3).

Resultados

La evaluación de 18 configuraciones de agente-LLM arrojó los siguientes hallazgos:

• Baja Resolución General: La tasa de resolución promedio en todas las configuraciones fue de solo 31.5%, lo que indica desafíos significativos en la resolución de problemas a nivel de repositorio incluso para modelos de vanguardia.
• La Recuperación de Requisitos Implícitos como el Principal Cuello de Botella: El análisis de atribución de fallos reveló que el 46.7% de todas las ejecuciones de agentes fallaron principalmente durante la clarificación de requisitos o la planificación de la implementación. Específicamente, la recuperación de requisitos implícitos representó entre el 24.5% y el 46.0% de las ejecuciones de los agentes, convirtiéndose en el punto de fallo más común.
• Perfiles de Fallo Específicos de la Etapa: Diferentes combinaciones de agente-LLM exhibieron modos de fallo distintos. Por ejemplo, mientras que algunas configuraciones tenían tasas de resolución general similares, sus distribuciones de fallos subyacentes variaban significativamente (por ejemplo, alto fallo de requisitos frente a alto fallo de generación de código).
• Brechas de Cobertura: El análisis de las trayectorias de los agentes frente a los GT mostró que, si bien los agentes cubrían de manera confiable la intención de alto nivel, su cobertura disminuía significativamente para las categorías orientadas a la implementación, como contratos de interfaz, estructura de código y semántica de datos. Del mismo modo, la cobertura de planificación disminuía desde la identificación de ubicaciones objetivo hasta la especificación de enfoques de implementación y estrategias de validación.

Significado y Reivindicaciones

El artículo sostiene que SWE-RPG proporciona un cambio necesario de la evaluación basada en resultados hacia un diagnóstico consciente del proceso. Al proporcionar referencias validadas para los pasos de razonamiento intermedio, el benchmark permite a los investigadores:

• Identificar que la barrera principal para el éxito no es necesariamente la generación de código, sino la recuperación de requisitos implícitos y la formulación de planes de implementación suficientes.
• Ir más allá del análisis de fallos de "caja negra" para señalar etapas específicas donde los agentes divergen de las trayectorias correctas.
• Sugerir que las mejoras futuras en los agentes de codificación deben priorizar la recuperación de restricciones implícitas y la reproducibilidad de plan-a-código en lugar de centrarse únicamente en la generación del parche final.

Los autores mantienen una postura modesta, reconociendo limitaciones como el enfoque actual en Python y Java, la falta de evaluación de la interacción humano-en-el-bucle y la dependencia de la construcción de verdades de terreno asistida por LLM (aunque validada manualmente). Posicionan a SWE-RPG como un paso fundacional hacia agentes de codificación a nivel de repositorio más interpretables y efectivos.