SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

El artículo presenta SWE-CI, el primer benchmark a nivel de repositorio basado en el ciclo de Integración Continua que evalúa la capacidad de los agentes impulsados por LLM para mantener la calidad del código a largo plazo, superando las limitaciones de las evaluaciones estáticas tradicionales.

Lo esencial

¡Claro que sí! Imagina que el desarrollo de software es como construir y mantener una casa gigante que nunca deja de crecer.

Aquí tienes la explicación de este paper (SWE-CI) usando analogías sencillas:

1. El Problema: "Arreglar lo roto" vs. "Construir un futuro"

Hasta ahora, las Inteligencias Artificiales (IA) que escriben código se han estado evaluando como si fueran fontaneros de urgencia.

• El viejo método (SWE-bench): Le dices a la IA: "Hay una tubería rota en la cocina. Arréglala". La IA pone una cinta adhesiva, la prueba y... ¡Pasa! Se le da una nota de 10.
• La realidad: En el mundo real, una casa no se arregla solo una vez. Tienes que añadir una segunda planta, cambiar la cocina, instalar paneles solares y, años después, reforzar los cimientos. Si el fontanero usó cinta adhesiva para arreglar la tubería, cuando lleguen las nuevas obras, la casa se derrumbará.

El problema: Las pruebas actuales no ven si la IA construye una casa sólida para el futuro, solo si arregla el problema de hoy.

2. La Solución: SWE-CI (El "Simulador de Vida Real")

Los autores crearon SWE-CI, que es como un videojuego de simulación de mantenimiento a largo plazo.

• En lugar de una sola tarea: En lugar de pedirle a la IA que arregle una tubería, le dicen: "Aquí tienes los planos de la casa hace 2 años (el código base) y los planos de cómo debería verse hoy (el código objetivo). Tienes que transformar la casa de un estado a otro, pero pasando por 71 etapas intermedias".
• La trampa: La IA no puede saltar al final. Tiene que hacer cambios pequeños, probarlos, y luego hacer el siguiente cambio. Si en el paso 3 hizo un trabajo sucio, en el paso 50 la casa será imposible de ampliar.

3. Los Personajes: El Arquitecto y el Constructor

Para hacer esto más realista, usaron un equipo de dos IAs trabajando juntas, como en una empresa de verdad:

1. El Arquitecto (El cerebro): Mira los planos, ve qué falta y dice: "Necesitamos una escalera aquí, pero no te preocupes por los tornillos, solo dime qué debe hacer la escalera".
2. El Constructor (Las manos): Toma las instrucciones del arquitecto y empieza a poner ladrillos.
   • La magia: Si el constructor pone los ladrillos mal (código sucio), el Arquitecto se dará cuenta en el siguiente turno y tendrá que pedirle que lo reescriba. Si el constructor hizo un trabajo limpio, el siguiente turno será fácil.

4. La Puntuación: "El Score de Evolución" (EvoScore)

Imagina que calificas a un constructor no por lo rápido que puso el primer ladrillo, sino por qué tan fácil es poner el ladrillo número 100.

• Puntuación baja: La IA arregló el problema rápido, pero dejó un desorden tal que, al intentar añadir una habitación nueva, todo se rompió.
• Puntuación alta: La IA construyó de forma que, aunque tardó un poco más al principio, cada nueva modificación fue fácil y segura.

5. ¿Qué descubrieron? (Los Resultados)

Después de probar con 18 modelos de IA diferentes (como los de Google, OpenAI, Anthropic, etc.), encontraron cosas interesantes:

• Van mejorando: Las IAs nuevas son mucho mejores que las viejas. Están aprendiendo a pensar a largo plazo.
• Algunas son más "cuidadosas": Hay modelos que prefieren hacer las cosas bien para el futuro (aunque tarde más), y otros que prefieren soluciones rápidas que luego causan problemas.
• El gran fallo: La mayoría de las IAs siguen teniendo miedo a estropear lo que ya funcionaba. En el juego, a menudo intentan arreglar una pared y, sin querer, rompen el techo. En términos técnicos, esto se llama "regresión". La mayoría de las IAs fallan en mantener la estabilidad a largo plazo.

En resumen

SWE-CI es el primer examen que le dice a la IA: "No me importa si arreglas esto en 5 minutos. Me importa si, dentro de 6 meses, cuando queramos añadir una nueva habitación, tu código siga siendo fácil de entender y no se rompa todo".

Es como pasar de evaluar a un fontanero por cómo arregla una fuga, a evaluarlo por cómo construye una casa que aguante terremotos durante décadas.

Resumen técnico

Resumen Técnico: SWE-CI

1. El Problema: La Limitación de los Paradigmas Actuales

Aunque los agentes impulsados por Modelos de Lenguaje Grande (LLM) han demostrado capacidades notables en tareas de ingeniería de software estáticas (como la corrección de errores puntuales o bug fixing), existen brechas críticas al evaluarlos en escenarios del mundo real:

• Paradigma de "Instantánea" (Snapshot): Benchmarks actuales como SWE-bench, HumanEval o LiveCodeBench evalúan la capacidad de un agente para generar una solución correcta en una sola toma (one-shot) basada en un requisito estático.
• Falta de Mantenibilidad: En la realidad, el desarrollo de software es un proceso iterativo de larga duración. Un agente puede escribir un código que pase las pruebas iniciales pero que sea frágil, difícil de extender o que acumule "deuda técnica", lo cual no se detecta en una evaluación estática.
• Degradación de la Calidad: Según las Leyes de Lehman, la calidad del software tiende a degradarse con el mantenimiento si no se gestiona adecuadamente. Los benchmarks actuales no capturan la capacidad del agente para mantener la calidad del código a lo largo de múltiples iteraciones y cambios de requisitos.

2. Metodología: SWE-CI y el Paradigma de Evolución

Los autores proponen SWE-CI (SoftWare Engineering – Continuous Integration), el primer benchmark a nivel de repositorio diseñado bajo un paradigma de evaluación basada en la evolución en lugar de una instantánea.

A. Formalización de la Tarea:
En lugar de un requisito fijo, SWE-CI simula un bucle de Integración Continua (CI):

1. Se parte de un commit base ($c_0$) y un commit objetivo u "oráculo" ($c^*$) de un repositorio real.
2. El agente debe iterativamente cerrar la brecha funcional entre el código actual y el objetivo.
3. El proceso es dinámico: en cada iteración $i$, se generan nuevos requisitos ($r_i$) basados en la diferencia actual entre el código y el objetivo, y el agente actualiza el código ($c_{i+1}$).
4. Esto permite que las decisiones tempranas afecten la dificultad de las iteraciones futuras.

B. Protocolo de Evaluación de Doble Agente (Architect-Programmer):
Para simular un equipo de desarrollo profesional, SWE-CI utiliza dos agentes colaborativos:

• Agente Arquitecto: Analiza las pruebas fallidas, identifica las causas raíz y genera un documento de requisitos de alto nivel (no código). Se le instruye para ser incremental (máximo 5 requisitos urgentes) y abstracto.
• Agente Programador: Recibe los requisitos del Arquitecto, planifica la implementación y escribe el código. No tiene acceso directo a las pruebas fallidas, imitando el flujo de trabajo real donde los desarrolladores reciben especificaciones.

C. Métricas Clave:

• Cambio Normalizado ($a(c)$): Una métrica que mide el progreso relativo. Si el agente mejora el código, la puntuación sube; si introduce regresiones (rompe pruebas que antes funcionaban), la puntuación cae negativamente.
• EvoScore (Puntuación de Evolución): Una métrica agregada que pondera el rendimiento a lo largo del tiempo. Utiliza un factor de peso $\gamma \ge 1$ para dar más importancia a las iteraciones posteriores. Un código verdaderamente mantenible es aquel que sigue siendo fácil de modificar en las etapas avanzadas del proceso.

D. Curación de Datos:

• Se seleccionaron 100 tareas de 68 repositorios de Python reales en GitHub.
• Criterios de selección: Mantenimiento activo (>3 años), >500 estrellas, licencia permisiva y presencia de pruebas unitarias.
• Cada tarea abarca un promedio de 233 días y 71 commits consecutivos de historia real, con al menos 500 líneas de código modificado.
• Se construyeron entornos Docker reproducibles para cada par de commits.

3. Resultados Experimentales

Los autores evaluaron 18 modelos de diferentes proveedores (incluyendo Claude, GPT, GLM, Qwen, etc.) consumiendo más de 10 mil millones de tokens.

• Observación 1: Avance Acelerado: Los modelos más recientes (post-2026) muestran mejoras significativas en el mantenimiento de código, superando a sus predecesores. La serie Claude Opus lidera consistentemente, seguida por GLM-5.
• Observación 2: Preferencias de Proveedores: Al variar el peso de la mantenibilidad a largo plazo ($\gamma$), se observa que diferentes proveedores tienen estrategias de entrenamiento distintas.
  • Modelos como MiniMax, DeepSeek y GPT tienden a priorizar ganancias a largo plazo (mantenibilidad).
  • Modelos como Kimi y GLM muestran una preferencia por retornos a corto plazo.
  • Qwen, Doubao y Claude mantienen una estabilidad relativa.
• Observación 3: Déficit en el Control de Regresiones: Este es el hallazgo más crítico. La mayoría de los modelos tienen una tasa de "cero regresiones" (no romper pruebas existentes durante todo el proceso) inferior al 25%. Solo dos modelos de la serie Claude Opus superan el 50%. Esto indica que, aunque los LLMs son buenos para escribir código nuevo, siguen luchando para mantener la estabilidad del sistema en escenarios de mantenimiento a largo plazo y múltiples rondas.

4. Contribuciones Clave

1. Nuevo Paradigma de Evaluación: SWE-CI cambia el foco de la "corrección funcional estática" a la "mantenibilidad dinámica a largo plazo".
2. Dataset Realista: Proporciona un conjunto de datos de alta calidad basado en la historia evolutiva real de repositorios de software, no en problemas sintéticos.
3. Protocolo de Agentes: Introduce una metodología de evaluación de doble agente (Arquitecto/Programador) que refleja mejor los flujos de trabajo de CI/CD reales.
4. Métrica EvoScore: Propone una métrica que penaliza la deuda técnica y recompensa la estabilidad futura, alineada con estándares de ingeniería de software (ISO/IEC 25010).

5. Significado e Impacto

SWE-CI demuestra que, a pesar de los avances en la generación de código, los agentes de IA actuales aún no están listos para asumir el rol de desarrolladores autónomos en proyectos de software complejos y de larga duración. La incapacidad de evitar regresiones en iteraciones sucesivas sugiere que los modelos actuales carecen de una comprensión profunda de las consecuencias a largo plazo de sus decisiones de diseño.

Este trabajo establece un nuevo estándar para la investigación en ingeniería de software asistida por IA, señalando que el siguiente gran salto no será solo en "escribir código que funcione", sino en "escribir código que pueda evolucionar sin romperse".