Plan para una nueva funcionalidad
Imagínalo así: Vas a construir una habitación nueva en la casa. Sin un plano, es posible que las tuberías no lleguen hasta allí. Con un plano, todo se conecta. Para las nuevas funciones, el plan garantiza que la nueva funcionalidad encaje en la arquitectura existente.
Una nueva feature es donde más destaca el plan mode. El prompt ideal incluye: qué hace la feature, qué componentes toca, qué patrones sigue el proyecto y cómo validar que funciona. Cuanto más contexto le des, más preciso será el plan.
El secreto está en especificar las restricciones: "sigue el patrón del middleware de autenticación existente", "usa el mismo estilo de pruebas que user.test.ts", "no crees nuevos archivos de configuración". Las restricciones claras generan planes que encajan en el proyecto en lugar de inventar una arquitectura nueva.
En 1 frase: para funciones nuevas, con contexto de las restricciones y estándares existentes; el plan encaja por sí solo.
Plan para refactorizar
Imagínalo así: Quieres cambiar el piso de la casa sin derribar las paredes. Necesitas saber el orden: quita los muebles, retira el piso viejo, coloca el nuevo, vuelve a poner los muebles. Con la refactorización es igual: el orden de los pasos lo es todo.
Las refactorizaciones son peligrosas sin un plan porque afectan código existente que funciona. El prompt ideal le pide a Claude que primero mapee todas las dependencias del código que se refactorizará. ¿Quién llama a esta función? ¿Quién importa este módulo? ¿Qué pruebas lo cubren?
La técnica más segura es la refactorización incremental: pedir un plan que cambie una cosa a la vez y ejecutar pruebas entre cada paso. Si un paso rompe algo, sabes exactamente a dónde volver. El plan debe incluir un "paso cero" para hacer una instantánea (commit o stash) antes de empezar.
En 1 frase: los refactors requieren un plan incremental con pruebas entre cada paso y un snapshot antes de empezar.
Plan para corregir un bug
Imagínalo así: Un detective no empieza arrestando sospechosos. Investiga, recopila pruebas, arma la teoría y solo después actúa. Corregir un bug es investigar: reproducir, diagnosticar, corregir y validar.
El error más común al corregir un bug es pasar directamente a la solución sin entender la causa raíz. El plan ideal empieza con: (1) reproducir el bug, (2) identificar la causa, (3) proponer la solución, (4) agregar una prueba de regresión. Pedirlo explícitamente en el prompt garantiza que Claude no se salte pasos.
Consejo: incluye en el prompt el mensaje de error exacto, el comportamiento esperado y el real, y las hipótesis que ya descartaste. Así ahorras rondas de ida y vuelta y el plan parte del punto adecuado.
En 1 frase: bug fix = reproducir, diagnosticar, corregir, probar. En ese orden, siempre.
Cada tipo de plan tiene su estructura, pero todos convergen en el mismo patrón: contexto, constraints y pasos.
Ejemplo resuelto: plan de corrección de errores
Bug: "la página de checkout se bloquea cuando el usuario tiene un cupón vencido".
Paso 1: Reproducir: abrir el checkout con un cupón vencido y confirmar que se bloquea.
Paso 2: Diagnosticar — el error está en coupon.validate(), que devuelve undefined en vez de error.
Paso 3: Corregir: agregar una guard clause en coupon.validate() para cupones vencidos.
Paso 4: Probar — agregar un caso de prueba para un cupón vencido en checkout.test.ts.
Profundicemos (opcional): ¿cuándo descomponer y cuándo mantenerlo monolítico?
Si la tarea tiene dependencias lineales (A antes de B antes de C), mantén todo en un único plan secuencial. Si tiene partes independientes que pueden ejecutarse en paralelo, divídela en subplanes. La regla: divídela cuando las partes puedan fallar de forma independiente.
Descomposición de tareas
Imagínalo así: Comerse un buey entero es imposible. Cortarlo en bistecs es fácil. Descomponer es dividir la tarea grande en partes que quepan en un bocado.
Cuando la tarea es demasiado grande para un solo plan, divídela en subtareas independientes. Cada subtarea debe ser verificable: puedes decir «esto funciona» o «esto no funciona» sin depender de las demás.
La regla práctica: si un paso del plan tiene más de 3 subpasos, probablemente haya que descomponerlo. Pídele a Claude: "divide el paso 3 en subtareas atómicas". Atómico = un único cambio con un único criterio de éxito.
En 1 frase: descompón hasta que cada paso tenga un único criterio de éxito verificable.
Mapeo de dependencias
Imagínalo así: No puedes poner el techo antes que las paredes. Las dependencias marcan el orden natural de las cosas: qué debe existir antes que qué.
Un plan sin dependencias mapeadas es una lista de compras, no un plan. Claude necesita saber qué pasos dependen de otros, cuáles pueden ejecutarse en paralelo y cuáles son bloqueantes. Pide explícitamente: "mapea las dependencias entre los pasos".
Visualízalo como un grafo: si el paso C depende de A y B, entonces A y B pueden hacerse en cualquier orden (o en paralelo), pero C solo comienza después de ambos. Esto es especialmente útil cuando vas a combinar el modo plan con el modo loop en el módulo 2.5.
En 1 frase: sin dependencias mapeadas, el plan es solo una lista; con ellas, es una ruta crítica.
Estimación del esfuerzo
Imagínalo así: Un presupuesto de obra no tiene que ser exacto, pero tiene que existir. Si el albañil dice "unos 3 días" y ya van 10 días, algo salió mal. Con los tokens y el tiempo pasa lo mismo.
Antes de aprobar el plan, estima: cuántos tokens consumirá, cuánto tiempo llevará y cuántas iteraciones probablemente serán necesarias. No hace falta ser preciso. El orden de magnitud ya ayuda: "¿esto lleva 5 minutos o 2 horas?".
Heurísticas útiles: cada archivo editado consume ~2-5k tokens de contexto. Un loop de pruebas normalmente necesita 3-7 iteraciones. Si el plan tiene más de 10 pasos, considera dividirlo en dos planes. Si la estimación te preocupa, simplifica el plan.
En 1 frase: estima los tokens, el tiempo y las iteraciones antes de aprobar. Si te asusta, simplifícalo.
# Feature nova "Plan: adicione endpoint POST /api/invoices que cria fatura. Siga o pattern de /api/orders. Inclua validacao de input, testes e migration de DB." # Refactor "Plan: refatore o modulo de notificacoes para usar o pattern Observer. Mantenha a interface publica igual. Rode testes entre cada passo." # Bug fix "Plan: o upload falha para arquivos >5MB. Erro: 'PayloadTooLargeError'. Reproduza, identifique a causa, corrija e adicione teste de regressao."
¿Cuál es la técnica más segura para planificar una refactorización?
Resumen del módulo
Siguiente módulo:
2-3 — Loop Mode — Automatización iterativa: cómo Claude ejecuta en un bucle autónomo.