Con los capítulos 1 y 2 ya deberías tener claro qué es Claude Code y cómo funciona. Lo que construimos en este capítulo es un ritmo que puedas repetir igual todos los días: los cuatro tiempos de explorar, planificar, implementar y confirmar.
La razón de tener un patrón está clara: cuando un día sale mal, la causa suele ser haberse saltado un tiempo. Le hiciste escribir sin haberle hecho leer, le delegaste sin darle una forma de verificar, lo dejaste correr sin marcar cortes. Los síntomas varían, pero el sitio al que hay que volver es el mismo.
La forma de un día: cuatro tiempos
Hazle leer los archivos implicados y que ponga en palabras el estado actual. Todavía no le dejes escribir.
Que saque los pasos por delante y tú los corrijas. Es el único punto de corrección barato.
Déjalo escribir y que ejecute la verificación ahí mismo. Que complete el bucle del capítulo 1.
Cuando pasa, marca un punto al que volver. La siguiente exploración arranca de ahí.
La medida de una vuelta es «si ya no puedes recordar por dónde ibas, es demasiado grande». Cuatro vueltas de una hora son casi siempre más estables que una vuelta de medio día.
Esto no significa «hazlo todo cada vez». Corregir una errata no necesita plan. Lo que hay que decidir es qué tiempo puedes saltarte, y el valor de partida es «hazlos todos».
Antes de empezar, dale una forma de verificar
Antes de entrar en los cuatro tiempos hay algo que conviene hacer una sola vez: darle de antemano una forma de que Claude se compruebe a sí mismo.
Como vimos en el capítulo 1, por dentro hay un bucle de reunir, actuar y verificar. Su fuerza viene de que existe el STEP 3, que le permite seguir corrigiendo hasta que pasen las pruebas. Visto al revés: sin forma de verificar, el bucle se detiene en la primera vuelta. Escribe, dice que probablemente esté bien, y ahí acaba. Igual que una herramienta de chat.
Basta con «haz que pasen las pruebas». La salida del fallo se convierte en la siguiente entrada y el bucle gira aunque no lo estés mirando.
Lo ejecutas tú, le cuentas el resultado y le haces escribir otra vez. El cuello de botella eres tú. Solo tienes la sensación de haber delegado.
Lo que le das no tiene que ser nada aparatoso. Basta con una línea del tipo «si ejecutas este comando sabrás si está bien». Y es más fiable escribirlo en un archivo que decirlo de viva voz, porque el CLAUDE.md de la raíz del proyecto se relee desde el disco incluso después de comprimir la conversación.
Lo que rinde escrito en CLAUDE.md (ejemplo)
- Comandos que hay que pasar tras un cambio: pruebas / tipos / linter
- No informar de «hecho» mientras no pasen
- Zonas que no se tocan (artefactos generados, configuración de producción, etc.)
Escrito así, empieza a comprobarlo por su cuenta en cada cambio sin que tengas que decir «prueba esto» cada vez. No es que des menos instrucciones, sino que hay menos situaciones que exigen una instrucción: así es como rinde el patrón (la forma de escribirlo, en el capítulo 6). Y las tareas que en el capítulo 1 quedaron en el lado del «mal encaje» caen aquí precisamente porque no hay forma de verificarlas.
Explorar: que lea antes de escribir
Primer tiempo. Solo hay una cosa que hacer: hacerle leer los archivos implicados y que explique cómo están las cosas ahora. Todavía no le dejes escribir. Si te saltas esto, Claude rellena con suposiciones la parte que no ha leído. Devuelve código plausible, que discrepa sutilmente del estilo existente, y de esa desviación te enteras en la revisión o en producción.
Mala exploración: «arregla lo de la autenticación»
→ empieza a editar de golpe. No sabes de qué ha partido
Buena exploración: «busca y lee los archivos de la autenticación.
Explícame cómo se procesa ahora el inicio de sesión,
junto con la lista de los archivos implicados.
No cambies nada todavía»
→ las premisas aparecen en pantalla. Si algo no cuadra, se corrige aquí
La explicación que te devuelve léela. Este es el punto de intervención más barato que hay. Decir «ese archivo ya no se usa» cuesta una fracción minúscula de lo que cuesta descubrir una implementación equivocada en la revisión.
Además, explorar tiene un coste. Los archivos leídos se cargan en el contexto, así que cuanto más amplia es la exploración, menos margen queda después: el «se vuelve pesado y olvida la primera parte» del capítulo 1 empieza aquí. Hay tres formas de contenerlo.
- Acota el alcance: limítalo con un «de momento solo la parte de la autenticación». Hace falta la visión de conjunto, no todos los archivos
- Los archivos enormes, léelos por partes: enteros llenan el contexto de golpe. Suele bastar con un rango de líneas o con una función
- Separa las investigaciones que generan mucha salida: el análisis de logs y las búsquedas masivas, a un subagente. Como tiene su propio contexto y solo devuelve el resumen, la sesión principal no se hincha (capítulo 6)
Planificar: cuándo compensa el modo plan y cuándo lastra
Segundo tiempo. Haz que saque qué va a cambiar y en qué orden antes de empezar a escribir. Claude Code tiene un modo plan pensado justo para este tiempo: investiga, se detiene al presentar el plan y no pasa a escribir hasta que lo apruebas. La forma de activarlo cambia según la versión, así que compruébala en la ayuda de la versión que tengas.
El fondo del asunto es mover la barrera de permisos de «cada edición» a «la entrada del trabajo». Por defecto aparece una confirmación en cada llamada a una herramienta; el modo plan las agrupa en una sola y la adelanta. Y lo que apruebas ya no es «esta línea», sino «el enfoque de este trabajo».
Abarca varios archivos / hay dos o más formas de hacerlo / hay que encajar con el diseño existente / deshacerlo es engorroso si sale mal / ni tú mismo has decidido aún la mejor jugada
Solo hay una cosa que hacer / los pasos ya están decididos / si falla se deshace al instante / leer el plan lleva más tiempo que implementarlo
El lado derecho sáltatelo sin reparos. El plan no es gratis: consume tiempo de elaboración, tiempo de lectura y contexto. Cuando lo recibas, mira solo tres cosas. 1) Si las premisas cuadran (si el primer tiempo se desvió, el plan se desvía entero). 2) Si incluye verificación (si no aparece un «haz que pasen las pruebas», añádelo). 3) Si está troceado con suficiente finura (un plan que lo hace todo de una vez no te deja localizar la causa cuando falla).
Si el trabajo es largo, vuelca el plan a un archivo. Un plan que solo existe dentro de la conversación acaba aplastado por el resumen cuando la sesión se alarga. Si haces que lo escriba en un sitio como PLAN.md, podrás releerlo aunque pliegues el contexto, y te servirá de punto de reenganche cuando te levantes y vuelvas.
Implementar: pasos cortos, corregidos sobre la marcha
Tercer tiempo. Aquí es donde por fin le dejas escribir. Hay dos principios.
Primero: ejecuta la verificación en cada paso. Si juntas cinco cambios y luego pruebas, cuando falle te toca el trabajo de aislar cuál de ellos lo provocó. Si escribes uno y lo haces pasar, la causa es el paso anterior. Es una costumbre más para ti que para Claude.
Segundo: pásale la salida del fallo tal cual. No hace falta que la resumas ni que se la reformules. El STEP 3 consiste en «leer la salida y volver al STEP 1», así que la salida en bruto es la entrada con más información. Si la masticas, lo que consigues es reducir las pistas.
Una vuelta durante la implementación (trocéala y repítela)
[EDITAR] reescribir solo un punto del plan
↓
[EJECUTAR] lanzar las pruebas / la comprobación de tipos
↓
verde → al siguiente punto (o a confirmar los cambios)
rojo → leer la salida y volver a [EDITAR]
Si sale rojo tres veces en el mismo sitio, no le dejes seguir corrigiendo
→ para y pasa al diagnóstico (capítulo 4)
La última línea es una regla empírica. Cuando empieza a repetirse el mismo fallo, no suele ser señal de «ya casi está», sino de «la premisa es errónea».
Cuando verificar lleva tiempo (compilaciones largas, esperar a que termine la CI) también puedes delegarlo sin quedarte pegado a la pantalla. Claude Code dispone de un mecanismo para repetir una instrucción a intervalos, y si omites el intervalo el propio Claude decide cada cuánto vuelve a mirar y detiene el bucle cuando considera que ha terminado. El mecanismo y sus limitaciones, en qué es el comando /loop. Ojo con un detalle: si cierras la sesión, se detiene.
Confirmar: los puntos de corte los marcas tú
Cuarto tiempo. Cuando las pruebas pasan, confirma los cambios en ese mismo momento. No «cuando llegue a un punto redondo»: el punto redondo es el instante en que pasa.
- Se convierte en un punto al que volver: si el siguiente paso falla, puedes regresar a un sitio que con seguridad estaba en verde
- El diff queda de un tamaño legible: medio día de cambios no se lee. Un diff que no se lee no se revisa de verdad
- Puedes cortar la conversación sin miedo: con el resultado ya guardado, tirar la sesión deja de dar reparo
Puedes dejar que escriba también el mensaje de la confirmación, pero no lo apruebes sin mirar el diff. Si te fijas no en «qué he cambiado» sino en «si se ha colado algo que no pretendía cambiar», la vista no se te resbala.
Y ojo: confirmar y publicar los cambios son dos decisiones distintas. Hasta dónde delegar las operaciones difíciles de deshacer, como un despliegue, lo vemos en el capítulo 5.
Cómo plegar una sesión y cómo rebobinar
Tras unas cuantas vueltas de los cuatro tiempos, chocas sin falta con el problema de que el contexto se llena. Cuando aparecen los dos síntomas del capítulo 1 (las respuestas se vuelven pesadas y se olvida la primera parte), toca plegar. Hay dos vías, comprimir o empezar de nuevo, y lo que las separa es una sola cosa.
Si lo siguiente es «la continuación», comprime: puedes arrastrar el recorrido como resumen, y poder indicar qué se conserva es justo lo que lo diferencia de dejar que se ejecute solo. Si lo siguiente es «otro asunto», empieza de nuevo: si no necesitas ni el resumen, tampoco necesitas pagar por producirlo. Y ganas precisión al no arrastrar un trabajo que no viene al caso.
El momento también tiene su patrón. No lo pulses por reloj ni por porcentaje, sino en un corte del trabajo: al terminar una vuelta, justo antes de meterte en el siguiente bloque largo. Si lo pulsas a medias, el resumen aplasta también los detalles que ibas a usar más adelante. El razonamiento está en ¿conviene ejecutar /compact de forma periódica?.
Antes de plegar, saca a un archivo lo que no puedes permitirte perder. El CLAUDE.md de la raíz del proyecto y la memoria automática se releen desde el disco, así que sobreviven a cuantos pliegues quieras; pero las decisiones que solo existen dentro de la conversación se diluyen en el resumen.
Hay otro mecanismo que cambia la propia forma de delegar. Claude Code crea automáticamente un punto de retorno en cada instrucción, así que, si algo se tuerce, puedes rebobinar hasta ahí. Puedes elegir entre solo el código, solo la conversación o ambos, y lo que más se usa es «devuelve el código pero deja la conversación»: los cambios quedan como si no hubieran existido, pero puedes reformular la petición conservando el recuerdo de qué falló.
Lo que rinde aquí no es la comodidad de la operación, sino cómo asumes el riesgo. Si das por hecho que no hay vuelta atrás, acabas confirmando paso a paso y se diluye el sentido de usar un agente. Si sabes que puedes volver, puedes delegar en bloques grandes y probar y tirarlo si no sale se convierte en una opción real.
Eso sí, lo único que vuelve atrás son «los archivos que Claude reescribió con la herramienta de edición». No vuelven los archivos creados o borrados con comandos de shell, ni tus propias ediciones, ni el estado de la base de datos. No sustituye a Git y da por supuesto que lo combinas con confirmaciones en los momentos clave. La línea se puede trazar así: el trabajo que se resuelve editando archivos, delégalo en bloques grandes; el trabajo que cambia estado a través del shell, confírmalo antes de delegarlo. El detalle, en puntos de control y rebobinado.
Hacer que lo revise: separar a quien escribe de quien lee
Que el código pase las pruebas no significa que sea buen código. Las pruebas garantizan que no está roto, pero no responden a si esa era la forma adecuada de escribirlo.
Hay un principio: separa el contexto en el que se escribió del contexto en el que se lee. Si le dices «revísalo» a la misma conversación que acaba de terminar esa implementación, tenderá a ratificar sus propias decisiones. Un estado en el que se ven todos los motivos de cada elección no sirve para buscarle defectos. En concreto, tres cosas.
- Haz que lo lea en otra sesión: confirma los cambios, genera el diff y pásale solo el diff a una conversación en blanco. Que lo lea con unos ojos que desconocen el recorrido
- Indica el eje de la revisión: no «mejóralo», sino «condiciones límite» o «coherencia con el estilo existente». Una petición vaga produce observaciones vagas
- No des por buenas sus observaciones: comprueba en el material real si son correctas. Antes de mandarle corregir, lee tú
La tercera enlaza con otros puntos de este capítulo. La revisión es el ejemplo típico de «tarea sin forma de verificar» y, como no hay nada que decida automáticamente qué es correcto, Claude también dice cosas desacertadas con un tono seguro. Si lo conviertes en instrucciones de corrección sin filtrar, rompes código que estaba bien: trata cada observación como una candidata y resuélvelas de una en una. Cuando te apetezca repetir siempre los mismos ejes de revisión, es la señal de convertirlo en mecanismo (capítulo 6).
Varias sesiones: hasta dónde compensa
Mientras una está pasando unas pruebas largas, querer avanzar otro asunto es una idea que surge sola. Claude Code permite levantar varias sesiones independientes por detrás y gestionarlas en una sola pantalla. La clave es el aislamiento: las sesiones en segundo plano se mudan a un directorio de trabajo propio antes de editar archivos. Como la lectura se comparte y la escritura se separa, los accidentes de sobrescribirse el mismo archivo no pueden darse por construcción. El detalle, en la vista de agentes y el despacho.
Las tareas son independientes entre sí / no necesitas ver el proceso / basta con decidir al recibir el resultado / una de ellas implica una espera larga
Dependen de la misma decisión de diseño / hay que redecidir el rumbo por el camino / incluyen operaciones que no se pueden deshacer / son tantas que no llegas a comprobar los resultados
Lo último de la derecha es la limitación que más pesa. Paralelizar aumenta el volumen total de revisión. Si lanzas tres, te vuelven tres «¿de verdad es así?»; el trabajo de comprobar no se paraleliza. El número máximo que puedes lanzar es el número de resultados que puedes verificar. Y el coste también sube: que corra en segundo plano no lo abarata (capítulo 7).
Antes de empezar a paralelizar, revisa la configuración de permisos. Las sesiones que corren por detrás no eligen los permisos sobre la marcha: los heredan de la configuración. Cuanto más laxo lo tengas de costumbre, más «sesiones con permisos laxos que nadie está mirando» se generan, tantas como sesiones lances. Primero, el capítulo 5.
Poco vistoso pero fuente de muchos accidentes es la limpieza posterior. El espacio de trabajo que crea una sesión en segundo plano se borra con ella cuando eliminas la sesión. «Ha terminado» y «lo he incorporado» no son lo mismo: confirma los cambios antes de borrar.
Resumen
- El ritmo del día son los cuatro tiempos de explorar, planificar, implementar y confirmar. Cuando algo va mal, la causa suele ser haberse saltado un tiempo
- Antes de empezar, dale una forma de verificar. Sin ella, el bucle de reunir, actuar y verificar se detiene en la primera vuelta
- En explorar, que lea antes de escribir. Pero cada lectura reduce el margen, así que acota el alcance
- Planificar es el mecanismo que agrupa la barrera de permisos en la entrada del trabajo. Lastra en los trabajos de un solo paso
- En implementar, verifica en cada paso y, tras tres fallos, pasa al diagnóstico. Confirma en el instante en que pasa
- Plegar o empezar de nuevo depende de «si lo siguiente es la continuación o es otro asunto». Justo antes de plegar, vuelca a un archivo
- El rebobinado solo deshace las ediciones de archivos. Los cambios hechos vía shell no vuelven, así que combínalo con confirmaciones
- En la revisión, sepárala del contexto en el que se escribió y trata las observaciones como candidatas. El límite del paralelismo es lo que puedes verificar
Aunque tengas el patrón, seguirás atascándote de vez en cuando. En el próximo capítulo nos quedamos con un orden para diagnosticar. Pasa al capítulo 4, «Salir de los atascos».