Patrones de flujo de trabajo de Claude Code que usamos para enviar código a producción cada día

Un patrón de flujo de trabajo de Claude Code es una forma de sesión repetible (cómo configuras el contexto, cuándo dejas que Claude escriba, qué revisas antes de hacer merge) que convierte una sesión de coding con IA improvisada en un proceso que puedes ejecutar dos veces al día sin sorpresas.

Anthropic indica que la mayoría de su propio código ya lo escribe Claude Code, mientras los ingenieros se desplazan hacia roles de arquitectura y orquestación (Anthropic, 2026). Esa productividad solo se sostiene cuando la sesión está estructurada, no improvisada. Abajo van siete patrones que aplicamos en cada proyecto de Studio, ordenados aproximadamente por impacto en la seguridad en producción.

Qué medimos

Para cada patrón miramos cuatro propiedades:

• Fricción: coste de configuración antes de la primera llamada.
• Cumplimiento: cuánto el patrón hace cumplir una regla, frente a pedírsela amablemente a Claude.
• Coste en tokens: cómo cambia el gasto por tarea.
• Recuperación: qué pasa cuando Claude se desvía.

1. El bucle plan-first

Qué es. Entra en plan mode (Shift+Tab hasta plan, o /plan) antes de cualquier cambio no trivial. Claude puede leer, buscar y razonar, pero la capa de herramientas bloquea físicamente las escrituras y los comandos shell destructivos (Anthropic, permission modes). Iteras el plan con las preguntas que harías a un senior engineer ("¿cuál es el peor modo de fallo?", "¿qué rompe esto que los tests no cubren?") y luego pasas a Accept Edits para ejecutar.

Qué resuelve. Las pruebas internas de Anthropic muestran que los intentos sin guía aciertan alrededor del 33% de las veces. Plan mode es la corrección más barata disponible, porque en esa fase aún no se ha escrito código.

Dónde flaquea. Para arreglos de una línea el ritual del plan es puro sobrecoste. Sáltatelo en erratas, ordenado de imports y retoques CSS que caben en una pantalla.

A quién le sirve. A cualquiera que toque código que va a producción.

2. CLAUDE.md como documento de guía

Qué es. Un archivo en la raíz del proyecto que Claude lee al inicio de cada sesión. Documentas convenciones, rutas, zonas vetadas, ejemplos de comando y el test runner. Los equipos internos de Anthropic tratan CLAUDE.md como un registro de errores pasados y de las reglas de estilo que nacieron de corregirlos.

Qué resuelve. El contexto repetitivo. Sin CLAUDE.md, los primeros 30 minutos de cada sesión se queman volviendo a explicar qué es el código y cómo se despliega.

Dónde flaquea. El cumplimiento ronda el 70% sobre las reglas que CLAUDE.md describe (Anthropic, 2026). Claude lo lee y luego, bajo presión, decide por su cuenta. Para reglas innegociables, mira los hooks abajo.

A quién le sirve. A todos los proyectos. Mantenlo bajo 200 líneas para que se cargue cada sesión sin devorar el presupuesto de contexto.

3. Hooks para las reglas duras

Qué es. Scripts deterministas que se disparan en uno de los 25 puntos del ciclo de vida (PreToolUse, PostToolUse, SessionStart, etc.). Los hooks bloquean la llamada de una herramienta antes de que se ejecute, corren cualquier bash o Python y devuelven un código de salida que Claude está obligado a respetar.

Qué resuelve. El 30% de hueco que CLAUDE.md no cierra. "No pushees a main", "no hagas rm -rf a la carpeta de migraciones", "corre el lint antes de commitear". Los hooks convierten estas instrucciones en infraestructura (Anthropic, best practices).

Dónde flaquea. Los hooks necesitan un script por regla y disciplina para mantenerlos al día. Un hook obsoleto que bloquea un comando renombrado es su propio incidente.

A quién le sirve. A equipos que despliegan más de una vez por semana. Un dev solo puede esperar hasta el primer susto.

4. Subagentes para separar calidad

Qué es. Un subagente es una sesión Claude separada con su propia ventana de contexto, invocada desde la sesión principal. El patrón canónico es escritor/revisor: un agente escribe el código, un segundo lo revisa en frío, sin el sesgo de "código que acabo de escribir" (Anthropic, subagents).

Qué resuelve. La ceguera de la auto-revisión. Claude declara muchas veces una tarea completa cuando solo ha cubierto una parte; un revisor con contexto fresco encuentra lo que el escritor pasó por alto.

Dónde flaquea. Dos sesiones cuestan grosso modo 2x en tokens. Reserva los subagentes para diffs que tocan superficies sensibles (auth, pagos, migraciones, cualquier cosa en infra/).

A quién le sirve. A cualquiera que ya haya enviado a producción un bug que Claude declaró "verificado y testeado".

5. Sesiones paralelas en git worktrees

Qué es. Varias instancias de Claude Code, cada una en su propio worktree git del mismo repo, cada una en una tarea independiente.

Qué resuelve. La dependencia secuencial. El creador de Claude Code corre 10 a 15 sesiones en paralelo y entrega 20 a 30 PRs al día, en flujos que de forma secuencial requerirían cinco horas por tarea (Mind Wired AI, 2026). Para un studio, tres o cuatro sesiones paralelas es el tope realista antes de que la code review se convierta en el cuello de botella.

Dónde flaquea. Tú te conviertes en el merge conflict. Sin aislamiento estricto de tareas (un agente por superficie, nada de archivos compartidos), las sesiones paralelas cuestan más tiempo del que ahorran.

A quién le sirve. A ingenieros cómodos sosteniendo tres o más contextos de tarea en la cabeza a la vez.

6. Slash commands para rutinas repetidas

Qué es. Archivos de comando reutilizables en .claude/commands/<nombre>.md que prompean a Claude con una tarea estructurada: "saca una nueva patch", "audita accesibilidad en la página en la que estoy", "genera una migración Supabase a partir de esta definición de tipo".

Qué resuelve. El prompt drift. La misma tarea recurrente formulada de tres formas distintas produce tres formas distintas de trabajo, y la peor versión siempre aparece bajo presión de plazo.

Dónde flaquea. Los comandos se pudren. Si el tooling cambia (un script npm renombrado, una regla de lint reemplazada), el comando produce silenciosamente output obsoleto. Programa una revisión trimestral.

A quién le sirve. A cualquier equipo con más de tres rutinas semanales recurrentes.

7. Servidores MCP en lugar de CLIs crudas

Qué es. Le das a Claude un servidor MCP (Model Context Protocol) en lugar de acceso shell a tus bases de datos, stack de observabilidad o APIs admin. El servidor expone herramientas tipadas con permisos explícitos y logs de auditoría.

Qué resuelve. El blast radius. Un psql crudo en manos de Claude puede tirar una tabla; una herramienta MCP expone solo las consultas que tú metiste en whitelist, con logs estructurados que puedes greppar cuando algo se tuerce. El equipo de data infrastructure de Anthropic migró de la CLI de BigQuery a un servidor MCP exactamente por esto, citando logging y control de PII (Anthropic, 2026).

Dónde flaquea. El servidor MCP lo construyes tú. Para scripts puntuales no compensa. Tratamos la decisión build-vs-buy en nuestro artículo sobre MCP build vs buy.

A quién le sirve. A cualquiera que dé a Claude acceso a datos con compliance, facturación o PII en juego.

Cómo elegir

Elige los patrones que correspondan a la superficie de riesgo de lo que estás construyendo. Un plugin de blog y una pasarela de pagos no piden el mismo flujo.

• Si despliegas a producción, aplica como mínimo plan mode + CLAUDE.md + al menos un hook. Es el suelo.
• Si el repo toca infraestructura compartida (BD de producción, pagos, auth), añade servidores MCP y quita el acceso shell a esos sistemas.
• Si el cuello de botella es la review y no la escritura, añade subagentes con split escritor/revisor antes de meter más escritores en paralelo.
• Si eres solo, con 30 minutos concentrados al día, sáltate las sesiones paralelas y dobla la apuesta en slash commands. La palanca está en reducir repetición, no en paralelismo.

Ninguno de estos patrones aguanta sin un CLAUDE.md que describa el proyecto de forma honesta. Los patrones son palanca encima de un contexto claro. El contexto va primero.