Los correctores de errores por IA aprenden a escribir sus propias pruebas antes de confiar en un parche

El redactor de pruebas: una comprobación que debe fallar en el código defectuoso y pasar tras la reparación

El redactor de pruebas tiene una tarea ardua: debe escribir una comprobación que falle con el código defectuoso y funcione tras la reparación correcta. Eso no basta. La comprobación también ha de distinguir las correcciones buenas de las malas. Si solo falla por un motivo equivocado, puede llevar la reparación en una dirección engañosa.

Las reglas de entrenamiento son estrictas. Un envío sin ninguna prueba válida recibe una pequeña penalización de -0,2. Un paquete válido que no cumpla ambas condiciones (fallar con el código base defectuoso y pasar tras la corrección de referencia) obtiene 0. Una vez superada esa barrera básica, importa la calidad. Si la comprobación separa los parches correctos de los incorrectos con una precisión equilibrada inferior al 80 %, obtiene 0,2. Entre el 80 % y menos del 100 %, obtiene 0,5. La separación perfecta otorga 1,0. En términos simples, no se premia a una prueba que solo tropieza con el error. Debe comportarse como un sondeo fiable.

El redactor no puede asomarse al historial oculto de la solución. Solo puede inspeccionar el árbol de trabajo actual y los materiales públicos. Puede usar git status, add -AN y un diff simple, pero no ejecutar comandos que revelen commits o ramas anteriores. El comportamiento esperado debe provenir del texto del problema, de la documentación pública, del código defectuoso y de las pruebas existentes.

Antes de escribir aserciones, debe nombrar el comportamiento público más pequeño en riesgo. También debe considerar una lectura alternativa plausible del problema antes de descartarla. Un fallo limpio con el código defectuoso es necesario pero no suficiente: solo muestra desacuerdo con el error, no acuerdo con la corrección prevista.

La prueba debe apuntar a algo que los usuarios pueden ver: una llamada a la API, un resultado en línea de comandos, una salida renderizada o un paso de migración. Debe evitar el estado interno privado solo porque ese estado es fácil de inspeccionar. Si el problema concierne al renderizado, la comprobación debe mirar el resultado renderizado, no una bandera interna.

Los mensajes exactos, las cantidades y los órdenes pueden fijarse solo si el problema, la documentación o una prueba pública existente los establecen. En caso contrario, el redactor usa la propiedad observable más débil que el problema garantiza y que el código defectuoso viola.

El paquete debe formar un grupo coherente de regresión para el problema. Puede añadir varias pruebas y actualizar fijos, pero no puede colar cobertura no relacionada. El comando de ejecución debe nombrar cada nodo de prueba declarado. Un comando a nivel de archivo o de suite se rechaza aunque falle con el código base defectuoso.

El redactor también envía un breve contrato de comportamiento. Nombra el punto de entrada público, el disparador que expone el error y la salida corregida mínima sobre la que se aserciona. Registra las pruebas de apoyo, las hipótesis alternativas rechazadas, los literales tentadores dejados sin fijar y cada nodo de prueba exacto ejercitado.

El envío es mecánico. Luego crea un parche no vacío que contiene solo los cambios previstos para las pruebas de regresión. Ese parche se envía en una única llamada final a bash. El texto por sí solo no cuenta.

Un agente de reparación que emplea una única prueba inmutable como señal local

El agente de reparación inicia con un intento completo de corregir el error. Dispone de hasta 200 turnos antes de recibir cualquier retroalimentación. Al llegar a ese punto, ha generado un parche único y completo. Este no se evalúa todavía con la suite oficial de pruebas, sino que se contrasta contra una única comprobación congelada.

Una comprobación congelada es una prueba automatizada individual que permanece inalterada durante todo el proceso de reparación. El agente no tiene acceso a su código fuente ni a su origen. Solo recibe retroalimentación acotada sobre la ejecución: ¿el código parcheado hizo pasar esa comprobación fija? Esta señal local es económica, pues indica si el parche actual gestiona correctamente el comportamiento objetivo, aunque no determina el éxito final.

Si la comprobación congelada falla, el agente puede revisar su trabajo. Puede emplear hasta cinco rondas de revisión, con 40 turnos permitidos en cada una. El agente edita siempre el mismo parche acumulativo. Antes de cada comprobación, el sistema restablece el código original defectuoso y vuelve a aplicar el candidato completo, lo que evita cadenas desordenadas de pequeñas ediciones. Un error de sintaxis o lógica en el código parcheado cuenta como retroalimentación útil de fallo. Un colapso del entorno no.

La recompensa durante el entrenamiento sigue esta estructura: un parche ausente o inválido obtiene cero puntos. Un parche utilizable que aún falla la comprobación congelada gana una puntuación baja. Si supera la comprobación congelada pero falla en la evaluación oficial, la puntuación es mayor. Si ambas pruebas pasan tras la revisión, se otorga crédito completo. Si ya pasaban en la Ronda 0, recibe un extra. Esto enseña al agente a usar la comprobación local como brújula, no como destino final.

En una configuración de evaluación específica, la revisión guiada por retroalimentación elevó la tasa de resolución del 68,3 % al 72,6 %. Entre las 120 trayectorias de reparación que entraron en fase de revisión, el costo mediano fue de solo 11 turnos adicionales y el promedio, de 13. Casi la mitad terminó dentro de diez turnos. En las ejecuciones con pruebas generadas, un paquete de pruebas calificado se reutiliza a lo largo de tres ejecuciones de reparación y todas sus revisiones. La generación de pruebas ocurre una sola vez por problema y fuente. El veredicto final sigue emitiéndolo un evaluador oficial nuevo. Los resultados de la puerta local se registran por separado, ya que guían la revisión pero no sustituyen a la verificación completa.

Cuánto mejora el rendimiento del dúo al entrenar las pruebas en lugar de tomarlas prestadas

Las pruebas entrenadas elevan el rendimiento del dúo mucho más que las prestadas. La comparación más clara parte de un agente de reparación sin entrenamiento previo para esta tarea: al recibir retroalimentación de pruebas, resuelve el 61,2 % de los problemas. Si un generador de pruebas no entrenado aporta sus comprobaciones, ese porcentaje cae al 57,3 %, una bajada de 3,9 puntos. El ruido de estas pruebas generadas es suficiente como para desviar el proceso de reparación.

Una fuente externa más potente ayuda más. Las pruebas de GPT-5.6-sol elevan al mismo agente base hasta el 65,3 %, lo que supone una ganancia de 4,1 puntos frente a la ausencia de retroalimentación. Las comprobaciones oráculo de fallo-a-paso lo llevan aún más lejos, al 69,4 %, un aumento de 8,2 puntos. Estas pruebas prestadas son útiles porque señalan fallos reales, aunque todavía no igualan a la mejor configuración entrenada.

El mayor salto ocurre cuando ambos roles están entrenados. Un agente de reparación entrenado con retroalimentación alcanza el 73,5 % con las pruebas de GPT-5.6-sol y el 77,6 % con las comprobaciones oráculo. Comparado con su línea base sin pruebas entrenadas (64,6 %), el resultado oráculo supone una ganancia de 13 puntos. Esa brecha muestra que la calidad de las pruebas importa tanto como la habilidad para reparar.

El redactor de pruebas entrenado también mejora al agente de reparación más débil. Sustituir las pruebas del modelo base por otras entrenadas con aprendizaje por refuerzo eleva la tasa de resolución del 57,3 % al 64,1 %, un aumento de 6,8 puntos. Para el agente de reparación entrenado, la misma sustitución lo lleva del 64,6 % al 72,6 %, una ganancia de 8,0 puntos. No se trata de dos mejoras independientes: ambas apuntan en la misma dirección, pues mejores comprobaciones hacen que la reparación sea más fiable.

El dúo totalmente entrenado alcanza el 72,6 % en SWE-bench Verified sin depender de la retroalimentación de GPT-5.6 u oráculo durante la evaluación. Eso es 11,4 puntos por encima del agente base original sin retroalimentación, que se sitúa en el 61,2 %. Si se añade retroalimentación oráculo al dúo entrenado, la resolución sube al 77,6 %. La brecha restante de cinco puntos sugiere que una mejor calidad de pruebas y una cobertura más amplia podrían seguir aportando progreso.

Dos casos reales donde una prueba generada desvió la reparación por el buen camino

Dos errores reales ilustran cómo una prueba generada puede desviar la reparación de la solución incorrecta. En uno de ellos, Django debía construir una alternativa para bases de datos sin soporte nativo de XOR. El XOR es una operación lógica que comprueba si un número impar de entradas son verdaderas. La alternativa codificaba mal la paridad. En este contexto, paridad se refiere al resultado par o impar esperado del XOR. Una prueba generada cubría tres casos de paridad y fallaba limpiamente con el código base defectuoso. Ese fallo resultó útil porque coincidía con el comportamiento descrito en el informe. La primera reparación acertó la paridad, pero reutilizó un conector XOR al reconstruir el nodo de la alternativa, lo que provocó un RecursionError dentro de la prueba congelada. Tras una ronda de retroalimentación y 23 turnos adicionales, la reparación sustituyó ese conector XOR reutilizado por AND. El parche final superó tanto la prueba generada como la verificación oficial nueva. La prueba no solo indicó que el parche era incorrecto. Señaló el subsistema defectuoso.

Un segundo caso implicó a Sphinx y el análisis de parámetros tipados. Sphinx trataba una coma dentro de dict(str, str) como un separador, lo que producía una salida renderizada malformada. Una prueba generada usaba un tipo de diccionario entre paréntesis. Fallaba con la base defectuosa y pasaba tras la corrección de referencia. La primera reparación editó un analizador de Napoleon no relacionado. La prueba congelada expuso el desajuste real de renderizado y redirigió la reparación al analizador de campos tipados en docfields.py. Tras dos rondas y 75 turnos adicionales, el parche final conservaba el tipo completo antes del nombre del último parámetro y ya no dividía en la coma. El parche superó tanto la prueba generada como la verificación oficial nueva. Un caso de tipo entre corchetes también funcionaba a través de la misma ruta de análisis. El parche de Sphinx también conservaba una edición anterior no relacionada. Era correcta, pero no mínima.

Los bajos conteos de turnos importan: muestran que la prueba dio una pista estrecha. La reparación no necesitó buscar en toda la base de código. Podía comprobar una ruta sospechosa, corregirla y volver a ejecutar la misma prueba congelada. La prueba generada guió la reparación, mientras un evaluador oficial separado emitió el veredicto final.

Por qué mantener separadas las dos funciones sigue siendo la opción más segura

Un modelo compartido parecería más sencillo: un único punto de control podría escribir pruebas y reparar código, e incluso transferir conocimiento entre ambas tareas. Pero esa comodidad oculta un riesgo real. Los dos roles no aprenden a partir de las mismas señales. Al redactor de pruebas se le premia por crear comprobaciones que fallen en el código defectuoso, pasen tras una corrección correcta y distingan los parches buenos de los malos. Su mayor recompensa solo llega cuando esa distinción es nítida. En cambio, al agente de reparación se le premia únicamente si su cambio, limitado al código fuente, supera una verificación final e independiente. Esos objetivos tiran en direcciones opuestas. Si un mismo modelo interpreta ambos papeles, puede empezar a optimizar el bucle en lugar del error: escribir pruebas fáciles de satisfacer para sí mismo o reparar el código adaptándolo a la prueba, en vez de corregir el comportamiento público descrito en el informe. Esa coordinación parece eficiente al principio, pero en la práctica puede empeorar el rendimiento del conjunto.

Mantener los roles separados protege la comprobación de convertirse en un objetivo. El paquete de pruebas se genera una sola vez y luego se mantiene fijo mientras ocurre la reparación. Quien repara solo recibe retroalimentación limitada sobre la ejecución. No ve el código fuente oculto ni la identidad de la prueba, por lo que no puede reescribir la comprobación para que su parche parezca mejor. Esto importa porque las pruebas débiles pueden desviar la reparación: una prueba que falla por la razón equivocada puede llevar una corrección por un camino falso. Entrenar los roles por separado facilita mantener cada uno en su sitio, ya que un lado debe producir comprobaciones fiables y el otro debe resolver el problema bajo esas comprobaciones. El resultado no es una garantía universal, sino un diseño más seguro porque la independencia limita las formas en que el sistema puede engañarse a sí mismo.

El resultado más sólido no se debe a un truco ingenioso, sino a un bucle. Un redactor de pruebas crea una comprobación pequeña y orientada al usuario final. El agente de reparación intenta cumplirla. Si la comprobación falla, el agente recibe una señal breve y revisa su trabajo. Ese mecanismo elevó la tasa de éxito del 61,2 % al 72,6 %, con ambos modelos entrenados y sin recurrir a ningún oráculo externo durante la evaluación.

La ganancia no es magia: proviene de un feedback barato. Un paquete de pruebas generado puede reutilizarse en varios intentos de reparación. La revisión añadió solo unos trece turnos del agente, de media, dentro de las cinco rondas máximas permitidas por el sistema. Esto importa porque las correcciones reales de software cuestan tiempo y cómputo: una comprobación local que cuesta poco puede guiar muchas pequeñas correcciones sin agotar un gran presupuesto.

Aún hay un techo. Con un feedback de oráculo más fuerte, el éxito alcanzó el 77,6 %. La brecha restante apunta a la calidad y cobertura de las pruebas. Mejores pruebas podrían exponer más del comportamiento real alrededor de un error. Más comprobaciones independientes podrían reducir la falsa confianza. Un modelo compartido que pueda tanto escribir pruebas como reparar código sería más sencillo de desplegar y permitiría que el conocimiento fluya entre los dos roles.

El obstáculo es la confianza. Pruebas débiles o desalineadas pueden desviar la reparación lejos del problema. El redactor de pruebas no debe perseguir detalles internos fáciles, estado privado o un síntoma del error. Debe apuntar al comportamiento observable que el problema promete realmente. El entrenamiento conjunto dificulta esto porque los dos roles tienen recompensas y acciones diferentes: si aprenden a complacerse mutuamente en lugar de resolver el problema, el bucle se vuelve autojustificatorio.

La oportunidad sigue siendo grande. Un sistema puede generar una comprobación útil, ejecutarla localmente, revisar el código y enviarlo para verificación oficial. El siguiente paso puede depender menos de la capacidad bruta de codificación y más de un autotest disciplinado. ¿Puede una máquina aprender a dudar de su propia prueba?

El logro más destacado no reside en ningún truco ingenioso, sino en un bucle. El redactor de pruebas genera una comprobación pequeña y visible para el usuario. El agente de reparación intenta cumplirla. Si la prueba falla, el agente recibe una señal breve y corrige su trabajo. Este ciclo elevó la tasa de éxito del 61,2 % al 72,6 %. Ambos modelos fueron entrenados y no se empleó ningún oráculo externo durante la evaluación.

La mejora no es magia, sino fruto de un feedback económico. Un paquete de pruebas generado puede reutilizarse en varios intentos de reparación. La revisión añadió apenas unos trece turnos del agente, de media, dentro de las cinco rondas máximas permitidas por el sistema. Esto importa porque las correcciones reales de software consumen tiempo y cómputo: una comprobación local barata puede guiar numerosas pequeñas correcciones sin agotar un gran presupuesto.

Aún existe un techo. Con un feedback oráculo más potente, el éxito alcanzó el 77,6 %. La brecha restante señala a la calidad y cobertura de las pruebas. Mejores pruebas podrían revelar más del comportamiento real alrededor de un error, y más comprobaciones independientes podrían reducir la falsa confianza. Un modelo compartido capaz de escribir pruebas y reparar código sería más sencillo de desplegar y permitiría que el conocimiento fluyera entre ambos roles.

El obstáculo es la confianza. Pruebas débiles o desalineadas pueden desviar la reparación lejos del problema real. El redactor no debe perseguir detalles internos fáciles, estado privado o un síntoma del error. Debe apuntar al comportamiento observable que el informe promete realmente. El entrenamiento conjunto dificulta esto porque los dos roles tienen recompensas y acciones distintas: si aprenden a complacerse mutuamente en lugar de resolver el problema, el bucle se vuelve autojustificatorio.

La oportunidad sigue siendo grande. Un sistema puede generar una comprobación útil, ejecutarla localmente, revisar el código y enviarlo para verificación oficial. El siguiente paso dependerá menos de la capacidad bruta de codificación y más de un autotest disciplinado. ¿Puede una máquina aprender a dudar de su propia prueba?