TL;DR Antes de una tarea larga, pásale a Claude cómo se terminó un trabajo parecido (un write-up de seis líneas, un PR o sus commits) y dile "ejecútalo como esto". En la misma migración, "muerde trozos grandes" acabó 3 de 3 veces sin tests, sin commits y con una pregunta; con el ejemplo, 3 de 3 veces con todo hecho y sin preguntar.
Aquí no hablo de los avisos de permiso antes de cada comando: eso se arregla con los modos de permisos, y lo tienes en Claude Code pide permiso para todo. Hablo de otra cosa: Claude hace un par de cambios, termina su turno con un resumen y una pregunta, y la tarea se queda parada hasta que contestas.
Por qué para, y por qué "hazlo más grande" no sirve
Son dos comportamientos documentados que se suman:
- Lee tu petición por lo bajo. Las best practices de Claude Code lo dicen así: Claude tiende a construir lo mínimo que cumple lo que pediste, porque no ve cuánto esperabas.
- Reporta en mitad de la tarea. La guía de prompting de Opus 5.5 cuenta que en tareas largas con varias partes algunas de sus actualizaciones de progreso cierran el turno con texto en vez de con otra herramienta. Entre las paradas que lista: ofrecerse a seguir salvo que prefieras otra cosa, y una lista de decisiones que no bloquean nada.
"Muerde trozos grandes" es un adjetivo. No dice qué es terminar: si hay que pasar los tests, si toca un commit por módulo, si se borra lo viejo, cuándo sí merece la pena parar. Un trabajo ya terminado dice todo eso a la vez.
Es lo que contó Andrew Edstrom, ingeniero de Anthropic, en la newsletter de Claude Code del 3 de octubre: su sesión larga hacía cambios pequeños y paraba a preguntar, pedirle pasos más grandes no ayudaba, y le hizo leer el write-up de una migración grande que un compañero había terminado. A la mañana siguiente tenía 133 PRs.
La prueba: la misma migración, con y sin ejemplo
Un repo con cinco módulos que usan oldlog, un logger.js nuevo y un test.js. La misma petición, "migra los módulos de src/ de oldlog a logger", con tres finales distintos. Claude Code v2.1.316 en -p, una ejecución por fila:
| Final del prompt | Modelo | node test.js |
Commits | oldlog.js |
|---|---|---|---|---|
| "Muerde trozos grandes, no te pares a cada paso" | Sonnet 5.5 (×2) | 0 | 0 | sigue ahí |
| "Muerde trozos grandes, no te pares a cada paso" | Opus 5.5 | 0 | 0 | sigue ahí |
| "Be ambitious: hazlo completo" | Sonnet 5.5 | 0 | 0 | sigue ahí |
| "Ejecútalo como se ejecutó @docs/migracion-fechas.md" | Sonnet 5.5 | tras cada módulo | 6 | borrado |
| "Ejecútalo como se ejecutó @docs/migracion-fechas.md" | Opus 5.5 | tras cada módulo | 6 | borrado |
| "Hazlo como la migración de moment: mira sus commits con git log" | Sonnet 5.5 | tras cada módulo | 6 | borrado |
Sin ejemplo, las cuatro ejecuciones aseguraron que el repo no tenía tests, con test.js en la raíz, y todas cerraron igual. Así terminó una de Sonnet:
Dejé `src/oldlog.js` sin tocar, y ya no lo importa ningún módulo. ¿Lo borro?
Y la de Opus 5.5:
No he borrado `src/oldlog.js` (ya no lo usa nadie) ni he hecho commit. Dime si quieres alguna de las dos cosas.
Con el ejemplo, la misma petición acabó en la lista de commits, y Sonnet explicó por qué no había preguntado:
- **Borrado de `src/oldlog.js`:** antes de borrarlo busqué `oldlog` en todo el repo y no quedaba ninguna referencia. Por eso no hizo falta parar a preguntar, como sí se hizo en la migración de fechas con el fichero que importaba otro equipo.
Cómo darle el ejemplo
1. Busca un trabajo terminado que se parezca
Vale cualquier cosa que muestre el proyecto entero de principio a fin: el write-up de una migración, un PR mergeado o una serie de commits. Con los commits basta: en la última fila de la tabla no había ningún documento, solo un git log.
2. Si no existe, escríbelo en seis líneas
Este es el de la prueba, completo:
# Cómo migramos de moment a date-fns (cerrado)
- Alcance: los 7 módulos que importaban moment. Ninguno se quedó a medias.
- Un commit por módulo, con el mensaje `migrate <módulo>: moment -> date-fns`.
- Después de cada módulo, `node test.js`. Si fallaba, se arreglaba antes de seguir.
- Nadie preguntó nada entre módulos: las dudas de estilo se resolvieron copiando lo que ya hacía el primer módulo migrado.
- Al final: se borró `src/moment-shim.js`, se pasó `node test.js` una última vez y se escribió un resumen con la lista de commits.
- Solo se paró una vez, para preguntar si borrar un fichero que otro equipo importaba.
Cada línea responde a una pregunta que, sin ella, Claude te habría hecho: hasta dónde llega, qué unidad de trabajo, qué comprobación, cómo resolver dudas, cómo se cierra y cuándo sí se para.
3. Pídele que lo ejecute igual
Migra los módulos de src/ de oldlog a logger (src/logger.js). Ejecútalo como se ejecutó la migración descrita en @docs/migracion-fechas.md.
En una sesión que ya lleva horas vale igual: el ejemplo es un mensaje más, y Edstrom lo usó justo así.
4. Si la tarea dura horas, ponle además una condición de parada
El ejemplo enseña cómo trabajar. Para que la sesión no te devuelva el control hasta acabar, súmale /goal con una condición que se pueda comprobar, como "todos los módulos migrados y node test.js pasa".
Los casos que te vas a encontrar
- Copia también las paradas. La única parada del ejemplo se convirtió en la única duda que Claude se planteó. Si quieres que pare antes de algo, escríbelo en el ejemplo como una parada que ya ocurrió.
- Copia los detalles, no solo la escala. Los mensajes de commit salieron con el formato del ejemplo,
migrate auth: oldlog -> logger. Si el trabajo de referencia tiene una costumbre que no quieres, quítala o dilo. - Rellena lo que el ejemplo no dice. Opus 5.5 creó por su cuenta una rama,
migrate-oldlog-to-logger, porque estaba enmaster. El ejemplo no hablaba de ramas. - Cuesta más turnos. Con Opus 5.5, la ejecución con ejemplo hizo 27 turnos y la de "trozos grandes", 16. Es el trabajo que antes te tocaba pedir en tres mensajes.
- Un ejemplo de otra escala arrastra la escala. El ejemplo de Edstrom era una migración grande y amanecieron 133 PRs. Para un arreglo de tres ficheros, dale un trabajo de tres ficheros.
Documentación oficial: Best practices for Claude Code · Prompting Claude Opus 5.5: unattended agentic runs
