← Volver al listado de tecnologías ← Índice de Claude Code

Cap 10: Workflows de Desarrollo

3 de marzo de 2026 Por: Artiko

claude-codeworkflowsrpiplan-modedesarrollo

Vanilla Claude Code vs Workflows

Vanilla (sin configuración)

Abrir claude, escribir lo que necesitas. Funciona para tareas simples pero tiene limitaciones:

Claude puede desviarse del objetivo
No hay estructura para tareas complejas
Difícil reproducir resultados consistentes

Con Workflows

Usar commands, agents y skills para estructurar el trabajo. Beneficios:

Resultados reproducibles
Tareas complejas divididas en pasos
Conocimiento compartido entre el equipo

RPI: Research → Plan → Implement

El patrón más efectivo para tareas complejas. Tres fases claras:

Fase 1: Research (Investigar)

claude "Investiga cómo funciona el sistema de autenticación actual.
Lee los archivos relevantes, identifica los componentes,
y documenta el flujo completo."

Claude explora el codebase, lee archivos, y presenta un resumen. No modifica nada.

Fase 2: Plan (Planificar)

claude "Basándote en tu investigación, crea un plan para migrar
de JWT a sesiones server-side. Lista los archivos a modificar,
el orden de cambios, y los riesgos."

Claude crea un plan detallado. Se puede usar el plan mode para esto:

claude --permission-mode plan

En plan mode, Claude solo puede leer — no puede editar archivos ni ejecutar comandos destructivos. Ideal para la fase de planificación.

Fase 3: Implement (Implementar)

claude "Implementa el plan que creaste. Empieza por el paso 1.
Commitea después de cada paso completado."

Claude ejecuta el plan paso a paso, commiteando incrementalmente.

Plan Mode

El plan mode restringe a Claude a solo lectura:

# Iniciar en plan mode
claude --permission-mode plan

Herramientas disponibles en plan mode:

Read, Glob, Grep — lectura
WebSearch, WebFetch — investigación
Agent con agentes de tipo Explore/Plan

Herramientas bloqueadas:

Edit, Write — modificación de archivos
Bash (comandos destructivos) — ejecución

Cuándo usar plan mode

Explorar un codebase nuevo
Diseñar arquitectura antes de implementar
Auditoría de código sin riesgo de cambios accidentales
Review de PRs

Boris Feb26 Workflow

Workflow popularizado en la comunidad. Estructura disciplinada en 4 fases:

1. Definir el objetivo

Escribir exactamente qué se quiere lograr en un mensaje claro y específico.

2. Investigar primero

"Antes de hacer cualquier cambio, investiga:
- ¿Qué archivos están involucrados?
- ¿Qué dependencias hay?
- ¿Qué tests existen?
Presenta tus hallazgos."

3. Crear plan con checkpoints

"Crea un plan con pasos numerados.
Después de cada paso, commitea y verifica que los tests pasen."

4. Implementar con commits atómicos

Cada paso del plan = un commit. Si algo falla, es fácil revertir.

Commit often

Una de las mejores prácticas más importantes:

<!-- En tu CLAUDE.md -->
## Reglas de desarrollo
- Commitear después de cada cambio funcional
- Cada commit debe dejar el proyecto en estado funcional
- Ejecutar tests antes de cada commit

Beneficios:

Checkpoints naturales para /rewind
Fácil identificar qué cambio introdujo un bug
Permite paralelizar trabajo con agent teams

Workflow de debugging efectivo

1. "Reproduce el bug. Muéstrame el error exacto."
2. "Investiga la causa raíz. No propongas soluciones aún."
3. "Propón 2-3 soluciones con pros/contras."
4. [Usuario elige solución]
5. "Implementa la solución X. Agrega un test que verifica el fix."
6. "Ejecuta todos los tests relacionados."

Workflow de refactoring

1. "Asegúrate de que todos los tests pasan." (baseline)
2. "Identifica el código a refactorizar y sus dependencias."
3. "Refactoriza paso a paso, ejecutando tests después de cada cambio."
4. "Verifica que no hay regresiones."

Ejemplo de CLAUDE.md con workflow

## Workflow de desarrollo
1. Investigar antes de implementar
2. Crear plan para cambios > 3 archivos
3. Commitear después de cada paso funcional
4. Ejecutar tests: bun test
5. Build final: bun build

Flujo completo RPI con ramas git

Cada fase del RPI vive en su propia rama. Esto permite pausar, revisar y revertir sin contaminar main.

gitGraph
   commit id: "baseline"
   branch research
   checkout research
   commit id: "exploración plan mode"
   commit id: "hallazgos documentados"
   checkout main
   merge research id: "research completo"
   branch plan
   checkout plan
   commit id: "plan de implementación"
   commit id: "plan revisado"
   checkout main
   merge plan id: "plan aprobado"
   branch implement
   checkout implement
   commit id: "paso 1: cambio A"
   commit id: "paso 2: tests"
   commit id: "paso 3: cambio B"
   checkout main
   merge implement id: "PR mergeado"

Comandos por fase

Fase Research — solo lectura, plan mode:

git checkout -b research
claude --permission-mode plan
# Claude usa Glob, Grep, Read, WebSearch — no modifica archivos
git add notas-research.md && git commit -m "research: hallazgos del sistema de auth"
git checkout main && git merge research

Fase Plan:

git checkout -b plan
claude "Basándote en la investigación previa, crea un plan detallado..."
git add plan.md && git commit -m "plan: migración JWT → sesiones server-side"
git checkout main && git merge plan

Fase Implement:

git checkout -b implement
claude "Implementa el paso 1 del plan. Commitea al terminar cada paso."
# Claude hace commits atómicos en cada sub-paso
# Al finalizar → PR review → merge a main

Workflow de Developer Productivity (Scenario 4)

Onboarding rápido a codebase desconocido

Cuando entras a un proyecto nuevo, la secuencia óptima es: ampliar → enfocar → profundizar.

flowchart TD
    A[Codebase desconocido] --> B[Glob: estructura general\n*.config.* / src/**]
    B --> C{¿Entiendo la arquitectura?}
    C -- no --> D[Grep: funciones clave\nmain / handler / router]
    C -- sí --> E[Read: archivos críticos\nconfig, entry points]
    D --> E
    E --> F{¿Hay patrones claros?}
    F -- no --> G[Grep: patrones de naming\nconvenciones de tests]
    F -- sí --> H[Hacer pregunta específica\na Claude]
    G --> H
    H --> I[Contexto suficiente\npara contribuir]

Prompt de onboarding efectivo:

"Tengo 30 minutos para entender este proyecto antes de hacer un cambio.
1. ¿Cuál es el flujo principal de datos?
2. ¿Dónde viven los tests?
3. ¿Qué convenciones de naming usa el proyecto?
4. ¿Cuáles son los archivos que más frecuentemente se modifican?
Solo lee, no cambies nada."

Autocompletar boilerplate con patrones del proyecto

En lugar de describir cómo quieres el código, muestra ejemplos existentes:

"Lee estos tres archivos que son similares a lo que necesito:
- src/handlers/user-handler.ts
- src/handlers/product-handler.ts
- src/handlers/order-handler.ts

Ahora crea src/handlers/invoice-handler.ts siguiendo exactamente
el mismo patrón: estructura, naming, manejo de errores, tipos de retorno.
No improvises — copia el patrón."

Claude infiere: estructura de imports, convención de nombres de funciones, manejo de errores, tipos compartidos, y tests esperados.

Automatizar tareas repetitivas

Ejemplo real: renombrar variables con criterio semántico

"En todos los archivos de src/models/, renombra las variables que usen
el prefijo 'tmp_' por nombres descriptivos basados en su uso.
Por ejemplo: tmp_data → parsedData, tmp_result → validationResult.
Muéstrame una lista de cambios propuestos ANTES de aplicarlos."

Cuándo usar Ralph Loop vs comando directo:

Tarea	Usar	Razón
Renombrar en 1-3 archivos conocidos	Comando directo (`Edit`)	Más rápido, menos tokens
Renombrar con criterio semántico en N archivos	Ralph Loop	Claude necesita leer para decidir
Transformar formato de datos en tests	Comando directo	Patrón mecánico, no requiere juicio
Refactorizar para mejorar legibilidad	Ralph Loop	Requiere entender el contexto
Agregar logging en puntos de error	Ralph Loop	Claude identifica los puntos

Ralph Loop = Research → Proponer lista → Aprobar → Apply. Nunca apply directo sin ver la lista primero.

Cuándo NO usar Claude Code en workflows

Hay situaciones donde Claude Code no debe ser el tomador de decisiones, aunque pueda ejecutar los cambios técnicamente.

Situaciones de alto riesgo

Contexto de negocio opaco: Claude no sabe que “renombrar el campo legacy_id” rompe 3 integraciones con sistemas externos no documentados
Decisiones de arquitectura transversales: Si el cambio afecta la estructura de directorios de toda la empresa o el contrato público de una API
Operaciones irreversibles sin backup confirmado: Migraciones de base de datos en producción, eliminación de datos de usuarios, cambios de schema sin rollback

Tabla de decisión

Tarea	Recomendación
Agregar un endpoint nuevo	Usar Claude Code
Decidir si usar GraphQL o REST para el sistema	No usar — decisión de arquitectura
Escribir tests para código existente	Usar Claude Code
Eliminar una feature completa con usuarios activos	No usar — requiere contexto de negocio
Refactorizar una función de utilidades	Usar Claude Code
Migrar base de datos en producción	Usar con supervisión — generar script, revisar, ejecutar manualmente
Renombrar variables internas en un módulo	Usar Claude Code
Cambiar el contrato público de una API	Usar con supervisión — verificar todos los consumidores primero
Corregir un bug con test reproducible	Usar Claude Code
Decidir qué deuda técnica priorizar	No usar — decisión estratégica del equipo

Regla práctica: Si la pregunta empieza por “¿deberíamos…?”, es decisión humana. Si empieza por “¿cómo…?”, Claude Code puede ayudar.

Siguiente: Agent Teams y Worktrees