Prueba los flujos de trabajo dinámicos de Claude con errores plantados en tu repositorio

Estás decidiendo si los flujos de trabajo dinámicos de Claude deben buscar errores en tu repositorio. La prueba de lanzamiento de Anthropic plantó 70 errores en una base de código de 116k líneas. En tres ejecuciones, un solo agente encontró 14, 15 y 27 errores. Cada una de las tres ejecuciones del flujo de trabajo encontró 66 errores.

Anthropic puso los flujos de trabajo dinámicos para Claude Managed Agents disponibles en beta pública el 9 de octubre de 2026. Esas cifras no deberían decidir por ti. Ejecuta un pequeño benchmark de errores plantados en tu propia base de código y luego establece un presupuesto de sesión antes de activar el flujo de trabajo. Usa el benchmark para saber si el tiempo de ejecución vale la pena en tu código, no para demostrar que el flujo de trabajo es inteligente.

Ejecuta un benchmark de defectos plantados en cinco pasos

Mantén los defectos realistas. Un error que solo aparece bajo carga es más difícil de puntuar que uno que aparece en una prueba unitaria. Un defecto que se esconde detrás de una bandera de funcionalidad es aún más difícil. No busques una prueba perfecta. Busca una que puedas volver a ejecutar después de un refactor.

• Elige un repositorio y una rama lo suficientemente cercanos a tu carga de trabajo real para que importen. Registra el prompt, la rama y la ventana de tiempo para que el benchmark pueda volver a ejecutarse después de un refactor.
• Planta un número conocido de defectos. Añade un pequeño conjunto de errores realistas y registra cada uno en una hoja de defectos. Listo: una lista que puedes puntuar sin adivinar.
• Ejecuta pasadas emparejadas de un solo agente y del flujo de trabajo. Da al agente único el mismo prompt, el mismo estado del repositorio y la misma ventana de tiempo. Inicia el flujo de trabajo en la misma rama y déjalo usar sus propias fases. Termina con dos listas de hallazgos que indiquen archivo, línea y severidad.
• Compara los hallazgos completos y las omisiones. Marca cada defecto plantado como encontrado, omitido o falso positivo. La salida debe ser una tabla donde la ventaja del flujo de trabajo sea visible, no implícita.
• Establece un presupuesto de sesión y un guardarrail de vida de ejecución. Elige un límite de gasto en tokens para la prueba y un límite de vida para la ejecución. El resultado debe ser un guardarrail que detenga la ejecución antes de que se convierta en una factura sorpresa.

La trampa es asumir que puedes dirigir la ejecución después del lanzamiento. Una vez que la ejecución está activa, sus hilos no aceptan mensajes de seguimiento del agente. Escribe el primer mensaje con el alcance de la prueba, la hoja de defectos y la condición de parada. Pistas adicionales para la pasada de un solo agente convierten la comparación en una prueba de prompting.

Una ejecución del flujo de trabajo puede lanzar hasta 1,000 agentes durante su vida, con hasta 64 activos a la vez. La vida útil predeterminada de la ejecución es de 24 horas, y una sesión puede mantener 10 ejecuciones abiertas. En un monorepo grande, esos límites multiagente importan más que el prompt.

Calcula el coste de la ejecución antes de confiar en ella

El modelo de precios es fácil de presupuestar. Una ejecución del flujo de trabajo no tiene tarifa separada. El uso de tokens de los agentes se cobra al precio del modelo, y Managed Agents añade una tarifa de tiempo de ejecución de sesión de $0.08 por hora de sesión. El gasto a temer es una sesión de larga duración que sigue consumiendo tiempo de ejecución mientras los agentes trabajan.

Antes de que comience la ejecución, escribe qué aspecto tiene un resultado útil. Un mayor número de hallazgos es una señal. Los mismos hallazgos con más tiempo de ejecución necesitan un umbral diferente. Las omisiones evidentes requieren inspeccionar el prompt antes de culpar al modelo.

Si se alcanza el presupuesto de sesión, una ejecución activa del flujo de trabajo se pausa y queda inactiva. Aumentar o eliminar el presupuesto puede reanudarla, a menos que una interrupción también la haya pausado. Para un benchmark, eso es útil. Puedes detenerte, inspeccionar la lista parcial de hallazgos y decidir si el flujo de trabajo justificó el coste.

Mantén el benchmark lo suficientemente pequeño para terminar en una revisión breve. Una prueba larga que nadie revisa es peor que una prueba corta que cambia una decisión. Vuelve a ejecutarla cuando la base de código cambie de forma, porque un flujo de trabajo que gana en un servicio pequeño puede perder en un backend grande.

Activa la búsqueda de errores por flujo de trabajo en producción solo después de que tu propio benchmark supere de forma fiable la línea base de un solo agente en tu repositorio, tus dependencias y tu presupuesto.