Flujos de trabajo con Claude Code para desarrolladores

Si ya programas o te manejas con herramientas técnicas, esto te va a resultar directo. Si vienes del lado de negocio, tranquilo, no hace falta que sepas programar para entender la idea de fondo: dividir el trabajo en piezas pequeñas y darle a cada pieza el contexto justo.

Anatomía de un claude code workflow

Un flujo de trabajo con Claude Code no es un chat largo donde le pides todo de golpe. Es una secuencia de pasos con roles distintos: investigar, planificar, ejecutar, verificar y entregar. Cada paso tiene un objetivo concreto y, muchas veces, un agente distinto encargado de él.

La diferencia con usar un chat normal es esta: en un chat, todo lo que investigas, decides y ejecutas se acumula en la misma conversación. El contexto crece, se llena de ruido y, a partir de cierto punto, la precisión baja. En un flujo de trabajo bien montado, cada paso empieza limpio, con solo el contexto que necesita para hacer su parte.

Esto es lo que separa "usar IA agentic" de tener flujos de trabajo con IA agentic de verdad: unos pasos que se repiten, con un orden y un criterio, no una improvisación cada vez que abres el terminal.

Subagentes: divide el trabajo, no la atención

Un subagente es una instancia de Claude Code que lanzas desde el agente principal para que haga una tarea concreta y te devuelva el resultado, sin que todo su proceso interno ocupe espacio en tu conversación principal.

Por ejemplo, si le pido que investigue cómo está montada la autenticación en un proyecto grande, no quiero ver los cuarenta archivos que ha tenido que leer para averiguarlo. Quiero el resumen: dónde vive la lógica, qué patrón sigue, qué archivos tocar. El subagente hace el trabajo sucio y me entrega solo la conclusión.

Uso subagentes sobre todo para tres cosas:

• Explorar código: entender una parte del proyecto que no conozco antes de tocar nada.
• Investigar de forma abierta: preguntas donde no sé de antemano dónde está la respuesta.
• Aislar tareas ruidosas: cualquier cosa que implique leer mucho para decir poco.

El agente principal se queda con la visión completa del encargo. Los subagentes se ensucian las manos y vuelven con lo que importa. Esto solo, sin tocar nada más, ya cambia cómo de largo aguanta un flujo de trabajo con IA sin perder precisión.

Tareas en paralelo: cuándo tiene sentido

No todo se puede paralelizar, y forzarlo es un error. Pero cuando tienes dos o más tareas que no dependen la una de la otra, lanzarlas a la vez ahorra bastante tiempo de reloj.

Un caso típico: quiero investigar cómo funciona el módulo de pagos y, por separado, cómo funciona el módulo de notificaciones. Ninguno depende del otro. En vez de esperar a que termine la primera investigación para lanzar la segunda, mando ambas peticiones juntas y cada subagente trabaja en paralelo.

La regla que aplico es simple: si para hacer la tarea B necesito el resultado de la tarea A, van en serie. Si no, van en paralelo. Sonará obvio, pero es el punto donde más se pierde tiempo al montar flujos de trabajo con IA, encadenando cosas por costumbre que en realidad son independientes.

Esto aplica igual a revisar código: puedo lanzar un agente que revise la lógica de negocio y otro que revise la cobertura de tests, a la vez, y juntar las dos conclusiones al final.

Automatizaciones: hooks, comandos y agentes programados

Un flujo de trabajo que tienes que arrancar a mano cada vez sigue siendo trabajo manual, solo que con IA de por medio. La parte que de verdad ahorra tiempo es la que se dispara sola.

Tres mecanismos que uso para eso:

• Hooks: se ejecutan en un momento concreto del proceso, por ejemplo antes de hacer un commit o al terminar una tarea, sin que tengas que acordarte de pedirlo.
• Comandos personalizados: para flujos que repites tal cual, empaquetas los pasos en un comando y lo invocas en una línea en vez de explicarlo otra vez.
• Agentes programados: corren en un horario fijo, sin que abras tú la sesión. Sirven para tareas recurrentes que no necesitan que estés delante.

La automatización no sustituye el criterio, lo aplica de forma constante.

Un hook que revisa el código antes de cada commit hace exactamente lo mismo cada vez, y eso es justo lo que buscas: que no dependa de si ese día te acordaste o no.

Buenas prácticas para flujos de trabajo con IA agentic

Después de meses montando estos sistemas, esto es lo que sostiene la calidad cuando el flujo crece:

• Dale a cada paso solo el contexto que necesita, no todo el historial del proyecto.
• Separa investigar de decidir, y decidir de ejecutar. Son roles distintos aunque los haga la misma herramienta.
• Verifica el resultado de forma activa (corriendo el código, no solo leyéndolo) antes de dar un paso por bueno.
• Documenta el flujo una vez que funciona, para no reconstruirlo de memoria la próxima vez.
• Empieza con un flujo simple de dos o tres pasos. Añade subagentes y paralelismo solo cuando el flujo simple se te queda corto.

Errores comunes al montar estos flujos

El error más habitual, con diferencia, es pedirle todo a un único agente en una conversación que no para de crecer. Investigación, planificación y ejecución mezcladas en el mismo hilo. Funciona al principio, y falla justo cuando el proyecto se pone interesante.

Otros errores que he cometido y que veo repetir:

• Paralelizar tareas que en realidad dependían unas de otras, y acabar con resultados que no encajan entre sí.
• No verificar el resultado final, confiando en que "si lo ha dicho la IA, está bien". Un flujo de trabajo con IA agentic necesita un paso de verificación real, siempre.
• Montar un flujo tan complejo desde el primer día que cuesta más mantenerlo que hacerlo a mano.

Un flujo real, de principio a fin

Para que no quede en teoría, este es un flujo que uso cuando llego a un proyecto de código que no conozco y tengo que resolver algo concreto:

1. Explorar. Lanzo un subagente a leer el código relevante y que me devuelva dónde vive la lógica que me interesa, sin volcarme el detalle de cada archivo.
2. Planificar. Con ese contexto ya resumido, pido un plan concreto: qué archivos tocar, en qué orden, qué riesgos hay.
3. Ejecutar. El agente principal implementa el plan, paso a paso, sin cargar de nuevo toda la exploración inicial.
4. Verificar. Corro el código, los tests si los hay, y reviso el resultado de verdad, no solo lo que dice el resumen final.

Cuatro pasos, cuatro roles, y solo el contexto necesario en cada uno. Nada exótico. Es la misma lógica que aplico para escribir estos artículos, con subagentes distintos según la tarea, y es lo que explico con más detalle, con capturas y casos concretos, en Claude Code: casos prácticos.

Si quieres el marco completo (qué es Claude Code, cómo se instala y para qué sirve antes de meterte en flujos de trabajo), tienes la guía de referencia en Claude Code.

Preguntas frecuentes sobre flujos de trabajo con Claude Code

Para seguir por aquí: Claude Code, Claude Code: casos prácticos y Claude para empresas.