Resumen Técnico: Síntesis Agéntica contra Bocetos Suplementados con Contraejemplos

Planteamiento del Problema

Los agentes de codificación pueden generar parches plausibles que satisfacen señales inmediatas (por ejemplo, pruebas fallidas, deltas de estado o instrucciones de prompts) mientras violan reglas de dominio subyacentes que aún no han sido codificadas en el repositorio. Cuando un Experto en la Materia (SME, por sus siglas en inglés) rechaza una reparación debido a una violación de política, esa regla suele permanecer en la memoria humana o en las transcripciones de chat en lugar de integrarse en el código base. Consecuentemente, las ejecuciones subsiguientes del agente pueden repetir el mismo "error plausible". El problema central es que los bucles de reparación estándar carecen de un mecanismo para convertir una única reparación rechazada en una política de gobierno duradera y nativa del repositorio que prevenga la recurrencia de ese modo de falla específico.

Metodología: El Bucle Sketch-CE

El artículo propone la Síntesis Agéntica contra Bocetos Suplementados con Contraejemplos (Sketch-CE), un flujo de trabajo nativo del repositorio diseñado para evolucionar una política de gobierno (el "boceto" o sketch) mediante la aprobación explícita de contraejemplos por parte del operador. El método se basa en seis artefactos específicos y una estricta separación de roles.

Artefactos Principales

1. Boceto ($S$): Un artefacto revisable y editable por el agente que contiene prosa, estructuras de código y reglas de política. Define el espacio de estrategia, el orden de prioridad y los huecos por llenar. Crucialmente, el boceto evoluciona; cada contraejemplo aceptado debe revisar el boceto para codificar la nueva regla.
2. Archivo de Contraejemplos Aceptados ($A$): La procedencia completa de los fallos aprobados. Cada registro incluye la entrada, la salida corregida autorizada, la salida errónea "tentadora", la regla distintiva y la aprobación del operador.
3. Conjunto de Regresión ($R \subseteq A$): Un subconjunto curado de casos ejecutables seleccionados para rechazar implementaciones incorrectas conocidas y proteger límites de política específicos.
4. Anclas de Código Conocido ($K$): Formas existentes del repositorio (APIs, convenciones, accesorios/fixtures) que el agente debe preservar para evitar la invención de convenciones locales paralelas.
5. Superficie de Implementación: El código versionado (Oráculo A) o el texto del prompt (Oráculo B) que aplica las reglas del boceto. Estos son reemplazables; una implementación fresca debe ser regenerable a partir del boceto evolucionado y los anclajes sin tener que reproducir todo el archivo.
6. Puerta ($G$): Un paquete de validación ejecutable con dos capas distintas:
   • Replay (Reproducción): Verifica si la salida candidata repara la brecha de estado codificada (por ejemplo, ¿funciona la matemática?).
   • Comparación Semántica: Verifica si la salida coincide con la expectativa aprobada en los campos que portan la política (por ejemplo, ¿se seleccionó la operación correcta?).

Roles y Flujo de Trabajo

El bucle involucra distintos actores para evitar la autojustificación:

• SME (Experto en la Materia): Juzga salidas concretas y proporciona correcciones con explicaciones.
• Operador: Aprueba explícitamente los contraejemplos que contradicen el boceto actual. Esta aprobación otorga al caso "autoridad de especificación" y exige una revisión del boceto.
• Mantenedor: Cura el conjunto de regresión y mantiene la maquinaria.
• Agente de Codificación: Repara las superficies de implementación (código o prompts) bajo las restricciones del boceto actual, los anclajes y el fallo activo único.

La Secuencia del Bucle:

1. Un caso observado falla la implementación actual.
2. Si el fallo contradice el boceto, el SME proporciona una corrección.
3. El Operador aprueba explícitamente el contraejemplo.
4. El Desarrollador (agente) revisa el boceto para codificar la nueva regla y repara la superficie de implementación para ese fallo específico.
5. La Puerta ejecuta el caso activo y el conjunto de regresión ($R$).
6. Si la puerta pasa, el caso se cura en $R$ (si no está ya cubierto), y se revela el siguiente caso. Si falla, el agente repara la regresión específica.
7. Regeneración Limpia Periódica: Para verificar que el boceto porta la política aprendida, se descarta la implementación y se regenera a partir del boceto evolucionado y los anclajes únicamente. Si esto falla, el boceto no ha sintetizado la política suficientemente.

Contribuciones Clave

1. Artefacto Nativo del Repositorio: La introducción del "boceto suplementado con contraejemplos" como un artefacto central que vincula las decisiones del operador, los registros del archivo y las cláusulas de política revisadas.
2. Modelo de Proceso: Un flujo de trabajo que transforma las correcciones aprobadas por el operador en un boceto evolucionado, un archivo completo y un conjunto de regresión curado, separando el modelo de gobierno de la historia de implementación.
3. Implementación de Doble Oráculo: Un enfoque híbrido que utiliza código determinista (Oráculo A) para reglas codificables y completado mediado por prompts (Oráculo B) para la narrativa o políticas subcodificadas, ambos restringidos por el mismo boceto y puerta.
4. Teorema de Regresión Finita: Una formalización de la condición de "Paso de la Puerta", que demuestra que una puerta que pasa garantiza la corrección de $R$ (satisfacción de la reparación de estado y campos de política) para el conjunto de regresión específico, limitado por los verificadores actuales y las filas aprobadas.
5. Validación Empírica (CatSynth): Un experimento de aplicación sintética de navegador que demuestra la mecánica del método y lo compara contra condiciones de control.

Resultados Experimentales (CatSynth)

Los autores evaluaron el método utilizando CatSynth, una aplicación sintética que involucra la selección de mascotas con reglas de política estrictas (por ejemplo, alergias) y preferencias blandas. El experimento utilizó GPT-5.4-mini como Desarrollador.

• Configuración: Una ejecución de mundo abierto donde el agente descubría reglas mediante contraejemplos, comparado contra dos controles:
  • Replay-All (Reproducir Todo): Reconstruir desde el boceto inicial y reproducir todos los ejemplos aceptados como contexto.
  • Evolved-Sketch Rebuild (Reconstrucción de Boceto Evolucionado): Reconstruir desde el boceto evolucionado y los anclajes únicamente (regeneración limpia).
• Hallazgos:
  • Retención de Política: El "Evolved-Sketch Rebuild" pasó 19 de 21 casos retenidos, superando al "Replay-All" que pasó 15 de 21. Esto sugiere que el boceto evolucionado sintetizó la política aprendida mejor que el modelo redescubriendo reglas a partir de ejemplos brutos.
  • Eficiencia: Mantener el código a través de los contraejemplos (Sketch-CE) requirió 9 llamadas al Desarrollador y 719 líneas de cambio de artefactos, comparado con 15 llamadas y 2,394 líneas para el enfoque Replay-All.
  • Densidad de Contraejemplos: En la ejecución de mundo abierto, 8 de 14 casos candidatos congelados se convirtieron en contraejemplos. Los tres caminos (Sketch-CE, Replay-All, Evolved-Sketch) pasaron los 8 casos aceptados.
  • Uso de Tokens: El enfoque Sketch-CE consumió más tokens durante la fase de aceptación visible (1,021,822) en comparación con los controles, debido principalmente al costo de evaluar candidatos externos y proponer reglas generales, en lugar de generarlas.

Reivindicaciones y Significancia

El artículo realiza afirmaciones modestas y acotadas sobre su significancia:

1. Inspectabilidad: La contribución principal es un flujo de trabajo inspectable donde cada contraejemplo aceptado conecta una decisión del operador, un registro de archivo y una cláusula de boceto revisada. Esto evita que las "reparaciones erróneas plausibles" desaparezcan en el historial de chat.
   2.Política vs. Implementación: El método demuestra que un boceto nativo del repositorio puede portar la "política aprendida" de tal manera que una implementación fresca pueda ser regenerada sin reproducir todo el historial de ejemplos.
2. Reducción de Trabajo Repetitivo: En la ejecución específica de CatSynth, mantener el código a través de los contraejemplos redujo la rotación de la implementación y las llamadas al desarrollador en comparación con reproducir todos los ejemplos.
3. Corrección Acotada: Los autores declaran explícitamente que un paso de la puerta no prueba la corrección general o la superioridad. La afirmación está limitada al conjunto de regresión actual, los predicados de reproducción/comparación codificados y las filas esperadas aprobadas. Los resultados no establecen una superioridad o corrección general del modelo más allá de las comprobaciones codificadas.
4. Limitaciones: El artículo reconoce que la evidencia es limitada a un modelo, un orden de revelación y datos sintéticos. No pretende resolver el problema de la verificación formal ni reemplazar el juicio humano en la definición de políticas.

En resumen, el artículo argumenta que para reparaciones con mucha carga de política, el repositorio debe tratar al boceto como el modelo de gobierno duradero y al archivo de contraejemplos como la fuente de evolución de la política, en lugar de depender únicamente de la acumulación de historial de prompts o casos de prueba.