Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés

Cambios verificados con varios modelos

Estado: Activo Alcance: estado actual Última revisión: 2026-08-21 Responsable: entorno de ejecución de AX Code

Una página de flujo para el trabajo «tengo un cambio con consecuencias, quiero más de un intento y quiero que las propias comprobaciones del repositorio decidan qué intento merece conservarse».

Para la referencia del modo — marcas, claves de configuración, entradas de clasificación — consulta modos de ejecución. Esta página es la tarea de extremo a extremo.

Cuándo merece la pena

Ejecutar varios modelos cuesta varias veces más que ejecutar uno. Compensa cuando el cambio tiene consecuencias y el fallo es caro de descubrir más tarde: una refactorización que cruza límites de módulo, una migración, una corrección en código sensible a la seguridad, o un cambio en el que de verdad no sabes qué enfoque es el correcto.

No merece la pena para una edición de una línea, un renombre o cualquier cosa que pudieras verificar leyendo.

Dos herramientas distintas

Usa council para decidir qué hacer: reparte una pregunta de diseño o de revisión entre varios proveedores conectados y agrega las respuestas en hallazgos de consenso, mayoría estricta, minoría y singleton, con rondas opcionales de debate anónimo. Es orientativa. El acuerdo entre modelos no es prueba de corrección; es una señal de lo disputada que está la pregunta.

Usa arena para decidir qué implementación conservar.

El flujo de implementación en Arena

1. Preparar

El modo de implementación exige un proyecto Git con al menos un commit y un worktree primario limpio. Los worktrees de los concursantes se crean a partir de un commit base exacto y no pueden heredar cambios sin confirmar, así que confirma o guarda en stash primero.

También necesitas al menos dos modelos seleccionables y distintos en proveedores conectados (se admite una puerta de enlace compartida) y modes.arena.enabled: true.

2. Ejecutar

/arena <task description>

Cada concursante obtiene su propio worktree de Git creado a partir del commit base registrado, y un agente de implementación se ejecuta en él. Los concursantes no modifican tu árbol de trabajo primario.

3. Qué hace AX Code con cada candidata

• Toma instantáneas de los cambios rastreados y no rastreados del concursante en un commit durable de rama, incluidos los commits que el propio agente haya hecho.
• Ejecuta los comandos de verificación del proyecto detectados — comprobación de tipos, pruebas, lint — pero solo después de capturar un parche no vacío. Un parche vacío no puede ganar.
• Clasifica primero la verificación de forma predeterminada: solo los parches completados y no vacíos que aprueban la verificación pueden ganar. Entre las candidatas que aprueban, prefiere menor riesgo y parches más diversos.

4. Decidir

El informe te da rutas de worktree, nombres de rama e intervalos de commits.

AX Code no fusiona a la ganadora. Inspecciona, fusiona o haz cherry-pick tú mismo. Es deliberado: la verificación significa «tus comprobaciones configuradas aprobaron en este parche», lo cual es una señal real, pero no sustituye a la revisión.

5. Revisar y, si hace falta, revertir

Una vez que una candidata está en tu árbol, los comandos de evidencia se aplican con normalidad:

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

Consulta evidencia de ejecución.

Qué significa aquí «verificado», con precisión

Significa: los comandos detectados de comprobación de tipos, lint y pruebas del proyecto se ejecutaron contra el parche de esa candidata, y aprobaron.

No significa que el cambio sea correcto, completo, seguro o esté bien diseñado. Si tu suite de pruebas no cubre el comportamiento cambiado, una candidata que aprueba solo prueba que no se rompió nada ya cubierto. La verificación eleva el suelo; no certifica el techo.

Tampoco se extiende a la edición interactiva ordinaria. Las candidatas de Arena y la aplicación de refactorización condicionada ejecutan comprobaciones; un edit o write normal en una sesión ordinaria no lo hace de forma automática. Ejecuta verify_project cuando quieras que esa evidencia quede registrada para una ejecución ordinaria.

Coste y modos de fallo

• El coste escala con los concursantes. Cada uno ejecuta un agente de implementación completo.
• Un worktree sucio detiene la ejecución antes de que ocurra nada más, por diseño.
• Menos de dos modelos distintos hace que la comparación carezca de sentido, y la herramienta informa en lugar de inventar una clasificación.
• Todas las candidatas pueden fallar la verificación. Es un resultado útil: suele significar que la tarea estaba poco especificada o que las comprobaciones del repositorio son más estrictas de lo que supusieron los agentes.

Relacionado

• Modos de ejecución — referencia completa de council, arena y los demás modos
• Evidencia de ejecución — revisar y revertir el resultado
• Por qué AX Code — por qué la clasificación que prioriza la verificación es la cuña
• Buenas prácticas de enrutado multimodelo — separar el trabajo premium del de apoyo