# ¿Cómo se reproduce un fallo de un agente de programación entre versiones de modelos? > Reproduzca un fallo de un agente de programación capturando la ejecución completa como un fixture versionado y repitiendo el mismo prompt, commit del repositorio, contrato de herramientas, entorno y reglas de parada con ID de modelo fijados. Compare eventos estructurados y el estado final del repositorio, no solo el texto del asistente. # ¿Cómo se reproduce un fallo de un agente de programación entre versiones de modelos? Una reproducción útil es un experimento ejecutable, no una transcripción copiada. Parta del estado fallido del repositorio, congele toda entrada observable por el agente y defina una aserción verificable por máquina. Después, repita el fixture varias veces con versiones de modelo fijadas. Una ejecución combina comportamiento del modelo, herramientas, archivos, red, orquestación y tiempos. Si cambia cualquiera de ellos, un resultado diferente no demuestra que el modelo causó o corrigió el problema. ## Defina el fallo como una aserción Escriba la condición observable mínima que separa fallo y éxito. Puede ser una prueba aún roja, un archivo modificado inesperadamente, un comando prohibido, una migración ausente o un parche que compila pero cambia el comportamiento. Evite criterios como «la respuesta parece peor». Para una reparación, la aceptación puede exigir: * la prueba de regresión original pasa; * las pruebas existentes siguen pasando; * no cambia ningún archivo fuera de la lista permitida; * el agente se detiene dentro de un número fijo de llamadas; * el diff final no contiene secretos generados ni cambios accidentales del lockfile. ## Capture el perímetro completo de ejecución El prompt es solo una entrada. Guarde junto al fixture: | Capa | Qué fijar | Por qué cambia el resultado | |---|---|---| | Repositorio | Commit, submódulos, parche sucio y archivos no rastreados | El agente razona sobre ese código exacto | | Instrucciones | Prompt del sistema, reglas y tarea del usuario | Pequeños cambios alteran la planificación | | Modelo | Proveedor, ID inmutable y parámetros | Alias y valores predeterminados pueden moverse | | Herramientas | Nombres, esquemas JSON, permisos y tiempos | Las capacidades condicionan el plan | | Entorno | Imagen, sistema operativo, arquitectura y locks | Comandos y pruebas pueden variar | | Datos externos | HTTP simulado, reloj y entradas aleatorias | Los servicios vivos introducen deriva | | Orquestador | Límite de bucles, reintentos y compactación | El modelo puede recibir historiales distintos | Elimine secretos, pero conserve si una credencial existía y su alcance. ## Registre eventos estructurados, no solo texto Guarde cada solicitud y respuesta de modelo, llamada y resultado de herramienta, reintento y decisión de parada como eventos ordenados. Para salidas grandes, añada un hash y almacene el artefacto original aparte. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Así verá si el modelo nuevo eligió otra herramienta, interpretó de otra forma el mismo error o recibió evidencia diferente. ## Fije versiones y elimine variación viva Use identificadores fechados o inmutables cuando existan. No compare un fallo histórico con un alias `latest`, porque puede apuntar ya a otra compilación. Ejecute en un contenedor o máquina virtual limpia. Sustituya búsquedas y registros de paquetes cambiantes por respuestas grabadas o snapshots internos. Congele el reloj cuando la fecha importe. Si la red es obligatoria, registre cada respuesta y marque la prueba como parcialmente controlada. Una semilla ayuda, pero no congela inferencia distribuida, tiempos de herramientas ni cambios del proveedor. ## Repita una matriz, no una sola pareja Una ejecución por versión no distingue regresión de variación. Mantenga fijo el fixture y use una matriz pequeña: | Versión del modelo | Repeticiones | Tasa de éxito | Mediana de llamadas | Firma del fallo | |---|---:|---:|---:|---| | ID base fijado | 5 | 4/5 | 9 | Omitió prueba límite | | ID candidato fijado | 5 | 1/5 | 13 | Editó archivo generado | | Candidato con prompt anterior | 5 | 1/5 | 12 | Misma firma | Cinco repeticiones son un buen comienzo. Amplíe la muestra para fallos intermitentes o críticos. Mantenga iguales temperature y demás controles salvo que sean el objeto del experimento. ## Compare decisiones y estado del repositorio Compare por separado: * eventos normalizados de modelo y herramientas; * comandos y códigos de salida; * árbol final de archivos y parche; * pruebas de aceptación y consumo de recursos. No exija razonamiento textual idéntico. Dos versiones pueden seguir rutas distintas y producir parches equivalentes. También un texto parecido puede ocultar comandos o cambios materiales distintos. ## Minimice el fixture después de reproducir Cuando el fallo se repita, elimine uno a uno archivos, herramientas, párrafos y llamadas externas no relacionados. Un fixture pequeño corre más rápido y expone mejor el límite causal. Conserve dos artefactos: la repetición completa del incidente para auditoría y la regresión minimizada para evaluación continua. Añada esta última a la puerta de actualización del modelo. ## Use un adaptador de modelo portable Una puerta de enlace como Atlas Cloud puede colocar varios modelos tras un cliente compatible con OpenAI, pero compatibilidad no significa comportamiento idéntico. Mantenga ID, opciones y peculiaridades en un adaptador; el arnés común debe controlar fixtures, eventos, reintentos y aserciones. Así podrá ejecutar la misma reproducción entre proveedores sin reescribir la evaluación. ## En resumen Congele el perímetro de ejecución, repita modelos fijados y evalúe resultados ejecutables. Si no puede reproducir todo el incidente, declare qué entradas siguen vivas y trate el resultado como una comparación, no como prueba de una regresión del modelo. ## FAQ ### ¿Qué hay que capturar para reproducir un fallo de un agente de programación? Capture el commit y el parche sin confirmar, los prompts e instrucciones del sistema, el ID y los parámetros del modelo, los esquemas y resultados de herramientas, la imagen del entorno, los archivos de bloqueo, la política de credenciales, la red y la aserción exacta de éxito. ### ¿Debo repetir el fallo con un alias de modelo latest? No. Use ID de modelo inmutables o fechados. Un alias latest puede cambiar durante la prueba e impedir que un éxito o fallo se atribuya correctamente. ### ¿Por qué no basta con fijar una semilla aleatoria? La semilla no congela la infraestructura del proveedor, los tiempos de herramientas, los resultados de recuperación ni las revisiones del modelo. Es un control más, no una garantía de determinismo. ### ¿Cuál es la mejor señal de éxito o fallo para un agente de programación? Prefiera aserciones ejecutables: pruebas, lint, diffs esperados, comprobaciones de archivos prohibidos y códigos de salida. La similitud textual suele ser demasiado débil para tareas de código. ### ¿Cuántas repeticiones debo ejecutar por versión de modelo? Ejecute suficientes repeticiones para separar una regresión determinista de la variación. Cinco es un punto de partida útil; los fallos de alto impacto pueden exigir veinte o más. ### ¿Puede el mismo arnés comparar modelos de distintos proveedores? Sí, si normaliza la solicitud, el contrato de herramientas, el registro de eventos y las aserciones. Mantenga las opciones específicas del proveedor en adaptadores para conservar la portabilidad del fixture.