Un arnés a medida para cada tarea: flujos de trabajo dinámicos en Claude Code

• Los flujos de trabajo dinámicos son una función que permite a Claude Code escribir sobre la marcha un arnés (harness) adaptado a la tarea, manejando de forma nativa dentro del código arneses personalizados que antes había que construir por separado
• Ejecuta archivos JavaScript para crear y coordinar subagentes (subagents), y permite elegir incluso el modelo que usará cada agente y si tendrá aislamiento en worktree
• Previene de forma estructural modos de falla como agentic laziness, self-preferential bias y goal drift que ocurren dentro de una sola ventana de contexto, separándolos en contextos aislados
• También puede usarse en tareas no técnicas fuera de la programación, como migraciones, investigación profunda, ordenamiento, triage e investigación de causa raíz
• Consume muchos tokens, así que no hace falta para todas las tareas, pero es un punto de partida para ampliar Claude Code de nuevas maneras mediante un uso creativo

---

Resumen de los flujos de trabajo dinámicos

• La semana pasada se lanzó flujos de trabajo dinámicos en Claude Code, lo que permite que Claude escriba al instante un arnés adaptado a la tarea
• El arnés base de Claude Code fue creado para programar, pero como muchas tareas se parecen al trabajo de desarrollo, también resulta útil para otros tipos de trabajo
• Research, security analysis, agent teams y Code Review han logrado su mejor rendimiento construyendo hasta ahora arneses personalizados por separado sobre Claude Code
• Los workflows resuelven estos problemas de forma nativa dentro de Claude Code y también permiten compartirlos y reutilizarlos
• Las mejores prácticas todavía están evolucionando, y como el consumo de tokens es alto, conviene pensar bien cuándo y cómo usarlos

Prompts de ejemplo

• "Esta prueba puede fallar aproximadamente 1 de cada 50 ejecuciones. Construye un workflow que pueda reproducirlo. Formula varias hipótesis sobre la condición de carrera y sigue avanzando hasta que aparezca una hipótesis válida respaldada por evidencia."
• "Usa un workflow para revisar las últimas 50 sesiones y encontrar partes que se corrigen repetidamente, y convierte las partes repetidas en reglas de CLAUDE.md"
• "Usa un workflow para analizar #incidents de Slack durante los últimos 6 meses y encontrar causas raíz recurrentes para las que nadie haya creado un ticket."
• "Toma mi plan de negocio y ejecuta un workflow donde varios responsables lo analicen a fondo desde la perspectiva de inversionistas, clientes y competidores."
• "Aquí hay una carpeta con 80 currículums. Usa un workflow para clasificarlos según su ajuste a un puesto de backend y vuelve a revisar los 10 mejores. Usa la herramienta AskUserQuestion para entrevistarme siguiendo una rúbrica de evaluación."
• "Necesito ponerle nombre a esta herramienta CLI. Usa un workflow para hacer lluvia de ideas con varias opciones y seleccionar las 3 mejores con un formato de torneo."
• "Usa un workflow para cambiar el nombre del modelo User a Account en todas partes."
• "Revisa cuidadosamente el borrador de mi artículo de blog y usa un workflow para contrastarlo con el codebase y todas las afirmaciones técnicas. No quiero publicar algo incorrecto."

Cómo funcionan los flujos de trabajo dinámicos

• Ejecutan un archivo JavaScript que incluye varias funciones especiales para ayudar a crear y coordinar subagentes
• También incluyen funciones estándar de JavaScript como JSON, Math y Array para facilitar el procesamiento de datos
• Es posible elegir el modelo que usará cada agente y decidir si los subagentes tendrán aislamiento en worktree, de modo que Claude seleccione el nivel de inteligencia y aislamiento necesario
• Aunque el workflow se interrumpa por una acción del usuario o por el cierre de la terminal, al reanudar la sesión continúa desde el punto en que se detuvo

Por qué hacen falta los flujos de trabajo dinámicos

• El arnés base realiza planeación y ejecución al mismo tiempo dentro de una única ventana de contexto; funciona bien para muchas tareas de programación, pero tiene límites en trabajos largos, masivamente paralelos, altamente estructurados o adversariales
• Cuanto más tiempo se mantiene una tarea compleja dentro de un solo contexto, más vulnerable se vuelve a ciertos modos de falla
  • Agentic laziness: se detiene antes de terminar una tarea compleja de varias etapas y declara que ya terminó tras completar solo una parte (por ejemplo, revisar solo 20 de 50 puntos en una auditoría de seguridad)
  • Self-preferential bias: tendencia a favorecer su propio resultado al validar o juzgar frente a una rúbrica
  • Goal drift: pérdida gradual de fidelidad al objetivo original a lo largo de varios turnos, especialmente después de la compaction, haciendo que se pierdan requisitos de edge case o restricciones como "no hacer X"
• Esto se evita coordinando múltiples Claude con ventanas de contexto separadas y objetivos enfocados y aislados

Flujos dinámicos vs. estáticos

• Antes ya era posible escribir flujos de trabajo estáticos para coordinar múltiples instancias de Claude Code con Claude Agent SDK o claude -p
• Los workflows estáticos suelen ser más generales porque deben responder a todos los edge cases
• Con Claude Opus 4.8 y los flujos dinámicos, ahora Claude ya es lo bastante inteligente como para escribir por sí mismo un arnés personalizado según el caso de uso

Patrones de uso de los flujos de trabajo dinámicos

• Puedes pedirle a Claude que genere un workflow, o usar la palabra gatillo ultracode para garantizar que lo cree
• Hay patrones comunes que Claude combina al construir workflows

• Classify-and-act

  • Un agente clasificador determina el tipo de tarea y luego la enruta hacia distintos agentes o acciones según el caso, o también puede decidir la salida final al terminar

• Fan-out-and-synthesize

  • Divide una tarea en pasos pequeños, ejecuta agentes para cada paso y luego sintetiza los resultados
  • Es útil cuando hay muchos pasos pequeños o cuando cada paso se beneficia de una ventana de contexto limpia, evitando interferencias y contaminación cruzada
  • La etapa de synthesize actúa como una barrera: espera a todos los agentes del fan-out y fusiona sus salidas estructuradas en una sola

• Adversarial verification

  • Para cada agente generado, ejecuta otro agente separado que verifique de forma adversarial su salida contra una rúbrica o criterio

• Generate-and-filter

  • Genera muchas ideas sobre un tema y luego las filtra con una rúbrica y validación, elimina duplicados y devuelve solo las ideas verificadas de mayor calidad

• Tournament

  • En lugar de dividir la tarea, hace competir a los agentes: N agentes intentan la misma tarea con enfoques distintos y un agente juez decide por pares hasta que queda un ganador

• Loop until done

  • Cuando la carga de trabajo es incierta, en vez de fijar un número de repeticiones crea agentes de forma iterativa hasta que se cumpla la condición de parada, como no encontrar nada nuevo o no ver errores en los logs

Casos de uso

• En algunos casos, los workflows son incluso más útiles para tareas no técnicas

• Migraciones y refactors

  • Bun fue reescrito de Zig a Rust con workflows; se puede ver más detalle en el hilo de Jarred en X
  • La clave está en descomponer el trabajo en etapas como callsites, pruebas fallidas y módulos
  • Para cada cambio se crean subagentes dentro de worktrees, otro agente los revisa de forma adversarial y luego se integran
  • También se les indica evitar comandos que consuman muchos recursos para maximizar el paralelismo sin agotar la máquina

• Investigación profunda

  • Se presentó la skill de deep research (/deep-research) que usa flujos dinámicos para repartir búsquedas web en fan-out, recuperar fuentes, verificar afirmaciones de forma adversarial y sintetizar un informe con citas
  • Además de la búsqueda web, puede usarse para redactar reportes de estado con contexto de Slack o para investigar en profundidad cómo funciona una característica dentro de un codebase

• Verificación profunda

  • Si quieres confirmar y documentar la fuente de cada afirmación factual en un informe, puedes generar un workflow donde un agente identifique todas las afirmaciones y subagentes separados verifiquen cada una en detalle
  • Los agentes verificadores también pueden revisar la calidad de las fuentes usadas por los subagentes que aportan la evidencia

• Ordenamiento

  • Es útil para ordenar elementos según criterios cualitativos, por ejemplo tickets de soporte por gravedad del bug
  • Si intentas ordenar más de 1000 filas con un solo prompt, la calidad baja y puedes exceder el contexto; en su lugar se usan torneos, pipelines de comparación por pares y bucket-rank en paralelo antes de fusionar
  • El juicio comparativo (comparative judgment) es más confiable que una puntuación absoluta, y como cada comparación la hace un agente separado, un loop determinístico conserva el bracket y en el contexto solo queda el orden de ejecución

• Memoria y cumplimiento de reglas

  • Si hay reglas que Claude sigue pasando por alto incluso cuando están en CLAUDE.md, se puede crear un workflow con una lista de reglas y un agente verificador para cada una
  • Para reducir falsos positivos, también se puede crear un subagente con persona skeptic que revise las reglas
  • También es posible hacerlo a la inversa: extraer correcciones repetidas de sesiones recientes y comentarios de code review, agruparlas con agentes en paralelo y luego validar de forma adversarial cada regla candidata ("¿esta regla realmente habría evitado el error?") antes de refinar las sobrevivientes en CLAUDE.md

• Investigación de causa raíz

  • El debugging funciona mejor cuando se plantean y validan varias hipótesis independientes, pero en una sola ventana de contexto puede aparecer self-preferential bias
  • Un workflow lo evita de forma estructural generando hipótesis con agentes separados para cada pieza de evidencia, como logs, archivos o datos, y luego sometiendo cada hipótesis a un panel de verificadores y refutadores
  • También puede usarse en post-mortems fuera del código, como ventas (por qué bajaron los ingresos en marzo) o ingeniería de datos (por qué falló un pipeline)

• Triage a gran escala

  • Para colas de soporte, reportes de bugs y backlogs que una persona no puede procesar por completo, un workflow de triage clasifica cada elemento, elimina duplicados frente a ítems ya rastreados y decide la acción a tomar, ya sea intentar una corrección o escalarlo a una persona
  • Un patrón útil es quarantine, que bloquea acciones de alto privilegio a agentes que leen contenido público no confiable y deja el procesamiento de la información en otros agentes
  • Puede combinarse con /loop para ejecutarse de forma continua

• Exploración y gustos

  • Es útil para explorar soluciones basadas en preferencias, como diseño o naming, donde una rúbrica aporta ventajas
  • Se pueden explorar múltiples soluciones, dar al agente revisor una rúbrica sobre qué define una buena solución, y hacer que marque la tarea como terminada cuando decida que se cumple el criterio; luego puede ordenarlas y elegirlas con un torneo

• Evaluaciones (Evals)

  • Se pueden ejecutar evaluaciones ligeras creando agentes separados en worktrees y usando un agente comparador que puntúe contra una rúbrica; por ejemplo, para evaluar y mejorar una skill generada según ciertos criterios

• Enrutamiento de modelo e inteligencia

  • Se puede crear un agente clasificador que decida el modelo según la tarea, identificando mediante investigación previa cuál conviene más en trabajos con muchas llamadas a herramientas
  • Por ejemplo, para la tarea "explicar cómo funciona el módulo auth", el mejor modelo depende de cuántos archivos tenga el módulo auth y de la forma del codebase; el clasificador investiga y enruta a Sonnet u Opus según la complejidad

Cuándo no usarlo

• Los workflows son una función nueva y, aunque hay muchos casos de uso con resultados importantes, no hacen falta para todas las tareas y pueden aumentar mucho el consumo de tokens
• Son apropiados para usos creativos que lleven Claude Code a territorios que antes no era posible intentar
• En tareas normales de programación conviene preguntarse: "¿de verdad necesito más cómputo?"; en la mayoría de los casos no hace falta un panel de 5 revisores para trabajo de desarrollo tradicional

Consejos para construir flujos de trabajo dinámicos

• Prompting

  • Los mejores resultados se obtienen con prompts detallados que usen las técnicas descritas antes
  • No son solo para tareas grandes; también puedes pedir un "quick workflow" para hacer, por ejemplo, una revisión adversarial rápida de ciertos supuestos

• Combinar con /goal y /loop

  • Los workflows repetibles, como triage, research o verification, pueden combinarse con /loop para ejecutarse periódicamente y con /goal para definir requisitos estrictos de finalización

• Presupuesto de uso de tokens

  • Puedes establecer un presupuesto explícito de tokens para limitar el gasto por tarea, fijando un tope con prompts como "use 10k tokens"

• Guardar y compartir

  • Puedes presionar "s" en el menú de workflows para guardarlo y luego hacer check-in en ~/.claude/workflows o publicarlo como una skill
  • Si lo compartes como skill, coloca el archivo JavaScript del workflow en la carpeta de la skill y haz referencia a él en SKILL.md; para mayor flexibilidad, el prompt debe tratar el workflow dentro de la skill como una plantilla y no como un script que deba ejecutarse tal cual

• Punto de partida para expandirse

  • Los workflows son una nueva forma de ampliar Claude Code, y el mejor modo de aprovecharlos sigue siendo un punto de partida con mucho por descubrir