Pipeline de plan, loop y revisión
Imagínalo así: Un director de cine: primero el guion (plan), luego el rodaje (loop), después la edición y aprobación (review). Tres fases, cada una con su función.
El pipeline ideal para tareas complejas: (1) activa el modo plan y pide un plan detallado, (2) perfecciona el plan 2-3 veces, (3) apruébalo y cambia al modo loop para ejecutarlo, (4) cuando termine el loop, revisa el resultado con git diff antes de hacer commit. Tres fases, cada una con su propósito.
La fase de revisión es crucial y muchos se la saltan. Cuando termina el loop, ejecuta git diff y lee los cambios. Pregúntale a Claude: «revisa el diff y confirma que todo esté de acuerdo con el plan». Esto detecta errores que el loop no detectó (por ejemplo, cambios semánticos que pasan las pruebas, pero modifican el comportamiento).
En 1 frase: plan, loop, review. Tres fases, ninguna se puede omitir. El review detecta lo que el loop no ve.
Traspaso entre modos
Imagínalo así: El testigo en una carrera de relevos: si lo pasas mal, el siguiente corredor tropieza. El traspaso entre plan y loop debe ser claro para no perder el contexto.
El momento crítico es la transición del plan a la ejecución. Al aprobar el plan, incluye una instrucción explícita: "ahora ejecuta el plan anterior, paso a paso, validando entre cada paso". Así te aseguras de que Claude siga el plan en vez de improvisar.
Si el plan es largo, divide la ejecución en fases: "ejecuta los pasos 1-3 ahora" y después "ejecuta los pasos 4-6". Así evitas que Claude pierda contexto durante una ejecución larga y puedes validar los avances intermedios.
En 1 frase: handoff limpio = instrucción explícita de «ejecuta el plan anterior». Divídelo en fases si es necesario.
Escalando la complejidad
Imagínalo así: Construir una casita para perros es un proyecto. Construir un edificio de 20 pisos es otro. La técnica es la misma (ladrillo sobre ladrillo), pero la orquestación es completamente diferente.
Para proyectos con decenas de archivos, un solo plan no basta. La estrategia: descompón el proyecto en módulos, crea un plan por módulo y ejecútalos en secuencia. El plan maestro define el orden de los módulos; los subplanes definen los pasos dentro de cada módulo.
Usa commits como puntos de control entre módulos. Si el módulo 3 rompe algo, vuelves al commit del módulo 2 sin perder el trabajo de los módulos 1 y 2. Esto transforma un proyecto grande y arriesgado en una serie de proyectos pequeños y seguros.
En 1 frase: proyectos grandes = plan maestro + subplanes por módulo + commits como checkpoints.
El pipeline de tres fases: plan, loop, review. Ninguna es opcional.
Lista de verificación del plan de handoff para el loop
- - Plan revisado y aprobado (2-3 rondas de refinamiento)
- - Commit de checkpoint creado antes de iniciar
- - Worktree o rama separada activa
- - Instrucción explícita: "ejecuta el plan de arriba, paso a paso"
- - Criterio de detención definido en el prompt
Orquestación de varios archivos
Imagínalo así: Una orquesta: cada instrumento toca su parte, pero todos deben estar sincronizados. Editar varios archivos es orquestar: cada cambio debe ser coherente con los demás.
Cuando una feature afecta a 10 archivos, el orden de las ediciones importa. El plan debe especificar: primero los tipos/interfaces, después la implementación y, por último, las pruebas. Esto evita errores de compilación intermedios que confunden el loop.
Pídele a Claude que mantenga un "mapa de consistencia": qué interfaces cambiaron, qué implementadores deben actualizarse y qué pruebas deben reflejar las nuevas interfaces. El mapa forma parte del plan y guía la ejecución.
En 1 frase: primero los tipos, después la implementación y al final las pruebas. Mapa de consistencia en el plan.
Estrategias de rollback
Imagínalo así: Un alpinista siempre tiene una cuerda de seguridad. No escalas sin poder volver. El rollback es la cuerda: cuanto mejor sea, más alto puedes llegar.
Tres niveles de rollback: (1) git reset vuelve todo al último commit, (2) worktree discard descarta todo el branch sin afectar main, (3) commits incrementales permiten volver a cualquier checkpoint intermedio.
La regla de oro: haz un commit antes de iniciar el loop y otro cada vez que completes una fase. Así siempre tendrás un punto de retorno limpio. Si algo sale muy mal, ejecuta git reset --hard hasta el último checkpoint e intenta un enfoque diferente.
En 1 frase: haz un commit antes de empezar y otro entre fases. Ten siempre un punto de retorno limpio.
Casos prácticos reales
Imagínalo así: La teoría es bonita, pero los ejemplos reales convencen. Veamos dos pipelines plan+loop en proyectos de producción.
Caso 1: Migración de Lodash a ES nativo en un proyecto con 200 archivos. Plan: identificar todas las importaciones de lodash, clasificarlas por función (map, filter, debounce) y priorizarlas por frecuencia. Ciclo: migrar archivo por archivo con tsc entre cada uno. Resultado: 200 archivos en 45 minutos, cero regresiones.
Caso 2: Agregar i18n a un SaaS existente. Plan: extraer todas las cadenas escritas directamente en el código, crear un archivo de traducciones y reemplazarlas por claves i18n. Ciclo: archivo por archivo, verificando que no quedara ninguna cadena escrita directamente en el código. Revisión: comparar manualmente las diferencias de los archivos de traducción. Resultado: 3 horas en lugar de los 3 días estimados.
En 1 frase: plan+loop en proyectos reales: migraciones en 45min, i18n en 3h en vez de 3 días.
Resumen del módulo
Siguiente módulo:
2-6 — Agentic Coding — La nueva normalidad: la filosofía y el cambio de mentalidad.