Resumen Técnico: Sumar es Máquina, Restar es Humano

Declaración del Problema

Aunque los Modelos de Lenguaje de Gran Escala (LLM) funcionan cada vez más como agentes de codificación capaces de resolver problemas y generar pull requests, la evidencia sugiere que sus parches suelen degradar la mantenibilidad del código. Un modo de fallo específico y sistemático identificado en este trabajo es la evitación de la eliminación: la tendencia de los modelos a retener código que una edición prevista requiere eliminar. En lugar de realizar una edición sustractiva, los modelos suelen preservar la lógica obsoleta y desviar la ejecución mediante guardas condicionales o mecanismos de respaldo (fallbacks). Este comportamiento, denominado Guard-and-Go (Proteger y Continuar), permite que los parches superen las suites de pruebas existentes (que rara vez verifican la eliminación de código) mientras dejan las bases de código infladas y más difíciles de mantener. El artículo postula que los benchmarks de evaluación actuales, como SWE-bench Verified, pueden sobreestimar la preparación de los modelos para entornos de producción porque no penalizan estas estrategias de no-eliminación.

Metodología

El estudio emplea un enfoque multifacético que combina el análisis empírico de benchmarks existentes, la creación de un benchmark de diagnóstico especializado y una intervención controlada de post-entrenamiento.

1. Análisis Empírico de SWE-bench Verified

Los autores analizaron las cinco principales contribuciones al leaderboard de SWE-bench Verified (GLM-4.6, GPT-5, Kimi-K2, Opus-4.5 y Salesforce SAGE) utilizando un scaffold de OpenHands consistente para controlar la variación de los agentes.

• Métrica: La recuperación de eliminación (deletion recall) se calculó comparando los parches de los modelos con los parches de los desarrolladores, midiendo la proporción de líneas eliminadas por el desarrollador que el modelo también eliminó.
• Verificación de Localización: El estudio distinguió entre fallar al encontrar el código (error de localización) y fallar al eliminarlo (error de ejecución) comprobando el archivo, el alcance (función/clase/módulo) y la modificación exacta de la línea.
• Clasificación de Estrategia: Un clasificador basado en LLM categorizó los parches aprobados en "Eliminar y Reemplazar", "Guard-and-Go" (retención de la lógica con una guarda) o "Alternativa de no referencia".

2. Retroajuste Sensible a la Eliminación

Para determinar si las pruebas aprobadas realmente validan la eliminación de código, los autores retroajustaron 34 tareas con alta densidad de eliminación de SWE-bench Verified con nuevas pruebas FAIL_TO_PASS (F2P). Estas pruebas fallan explícitamente si el código objetivo permanece en el archivo, aislando el requisito de eliminación de otras especificaciones de comportamiento.

3. Benchmark CanItDelete

Para aislar el comportamiento de eliminación de factores de confusión como la dificultad de localización o la necesidad de código aditivo, los autores curaron CanItDelete.

• Construcción: 200 tareas extraídas de commits reales donde la edición requerida era íntegramente una eliminación (sin adiciones). Las tareas se seleccionaron de los 100 repositorios de Python y JavaScript con más estrellas, clasificados por complejidad estructural (tamaño pre-edición, líneas eliminadas y fragmentos de eliminación).
• Evaluación: Un evaluador determinista y consciente de la ocurrencia califica las salidas basándose en si el objetivo está totalmente ausente, si se preserva la estructura no relacionada y si no se introducen adiciones que afecten al comportamiento.
• Escalera de Diagnóstico: El benchmark utiliza cuatro modos acumulativos para diagnostar puntos de fallo:
  1. Vanilla: Petición estándar de estilo desarrollador.
  2. Eliminación Explícita: La instrucción prohíbe guardas o fallbacks.
  3. Puntero de Región: Identifica las funciones o regiones relevantes.
  4. Líneas Exactas: Proporciona los rangos exactos para eliminar.

4. Intervención de Post-Entrenamiento (Prueba de Concepto)

Un modelo de 7 mil millones de parámetros fue aumentado con una mezcla de post-entrenamiento enfocada en la eliminación.

• Datos: Se añadieron 12,821 ejemplos de eliminación (10,000 a nivel de archivo y 2,821 a nivel de repositorio) al conjunto de entrenamiento. Estos ejemplos aportaron 112.1M de tokens a la mezcla de 15.9B de tokens, constituyendo aproximadamente el 0.7% del total de tokens.
• Evaluación: El modelo fue probado en CanItDelete, SWE-bench Verified, CanItEdit y EditBench para medir la mejora dirigida y posibles regresiones.

Resultados Clave

1. Prevalencia de la Evitación de la Eliminación

• Baja Recuperación: Incluso en las 197 tareas resueltas por los cinco modelos, la recuperación de eliminación osciló entre el 65.2% y el 71.7%. Los modelos dejaron entre el 28.3% y el 34.8% de las eliminaciones requeridas en su lugar.
• Localización vs. Ejecución: Los modelos localizaron con éxito el archivo correcto para >92% de las eliminaciones y el alcance envolvente para ~70%, pero eliminaron la línea exacta en solo el 44.6% al 51.6% de los casos. La brecha es principalmente un fallo de ejecución, no de localización.
• Dominancia de Guard-and-Go: Entre los 1,703 pares tarea-modelo aprobados analizados, 494 (29.0%) siguieron el patrón Guard-and-Go, donde el modelo retiene la lógica eliminada por el desarrollador y añade un bypass condicional. Estos parches fueron, de media, un 61.1% más grandes que el parche del desarrollador.

2. Brecha de Evaluación

Cuando se reevaluaron 34 tareas con alta densidad de eliminación con controles sensibles a la eliminación:

• Las tasas de resolución de cuatro modelos de frontera cayeron del 63.2% al 41.9% (una disminución de 21.3 puntos porcentuales).
• El 33.7% de los parches que pasaron las suites de pruebas originales retuvieron el objetivo de eliminación validado.

3. Hallazgos de CanItDelete

• Varianza de Rendimiento: En las 200 tareas de solo eliminación, las tasas de éxito variaron desde el 79.0% (Claude Opus 4.8) hasta el 18.0% (modelos abiertos más pequeños).
• Modos de Fallo: La eliminación incompleta (dejar código requerido) representó el 69.8% de los fallos en todos los modelos. Sin embargo, a medida que los modelos mejoraron en la localización de objetivos, surgió un segundo modo de fallo: la sobre-eliminación (eliminar código más allá del límite).
• Impacto de la Guía: Proporcionar los rangos de eliminación exactos (el modo "Exact lines") casi eliminó la eliminación incompleta en cuatro de los cinco modelos, pero no solucionó la sobre-eliminación. Por ejemplo, el éxito de GPT-5.6 Sol aumentó al 80.5%, pero aún falló en el 16.5% de las tareas al eliminar más allá de los rangos especificados. Esto indica una falta de control sobre el límite de la eliminación más que una falta de capacidad para encontrar el código.

4. Intervención de Post-Entrenamiento

Añadir supervisión de eliminación a la mezcla de post-entrenamiento del modelo de 7B:

• Redujo la eliminación incompleta en CanItDelete en 13.9 puntos porcentuales (de una tasa de fallo del 80.4% al 66.5%).
• Mejoró SWE-bench Verified en 5.3 puntos y CanItEdit en 1.4 puntos.
• No introdujo regresiones significativas en otros benchmarks.
• Compromiso (Trade-off): La intervención aumentó la tasa de sobre-eliminación (eliminación completa con ediciones inválidas), lo que sugiere que, si bien el modelo aprendió a eliminar, todavía tiene dificultades con dónde detenerse.

Significancia y Reivindicaciones

El artículo sostiene que la evitación de la eliminación es un comportamiento sistemático y mal entrenado en los LLM actuales, más que una limitación intrínseca. Los autores argumentan que:

1. Los Benchmarks Actuales son Insuficientes: Las métricas estándar de paso de pruebas enmascaran el patrón "Guard-and-Go", lo que lleva a una sobreestimación de la preparación de los modelos para el mantenimiento de código.
2. El Control es el Cuello de Botella: Los modelos poseen la capacidad de localizar el código para ser eliminado, pero carecen del control para ejecutar eliminaciones precisas y delimitadas sin sobre-editar o añadir guardas.
3. La Eliminación es Aprendible: La intervención de prueba de concepto demuestra que el post-entrenamiento dirigido puede reducir la evitación de la eliminación y mejorar el rendimiento general de la edición de código, lo que sugiere que el déficit se debe a la representación de los datos (sesgo aditivo en los datos de entrenamiento) y no a la arquitectura del modelo.

Los autores mantienen la modestia sobre el alcance, señalando que la intervención se probó en un único modelo de 7B y que el compromiso de "sobre-eliminación" indica que la finalización de la eliminación y el control de los límites son objetivos de entrenamiento distintos que requieren más investigación para resolverse simultáneamente a escala.