Si tu día con Claude se ve así —le pides algo, te entrega, le corriges, te vuelve a entregar, le vuelves a corregir— no estás delegando. Estás editando. Y editar el trabajo de alguien más toma casi el mismo tiempo que hacerlo tú.
La parte incómoda es que casi siempre el problema no está del lado del modelo. Está en que le entregaste una tarea sin contexto, sin criterio de terminado y sin permiso de preguntar. Un empleado nuevo con esas tres carencias también te devolvería trabajo para corregir.
Estos son los cuatro movimientos que me quitaron ese ciclo. No son trucos de prompt: son cambios en cómo entregas el trabajo. Al final está el prompt de arranque que uso la primera vez que le paso una tarea nueva a Claude.
Corregir y delegar no son lo mismo
Corregir es intervenir después del resultado. Delegar es invertir antes, para que el resultado no necesite intervención.
La prueba es simple: si mañana tuvieras que pedir la misma tarea otra vez, ¿tendrías que volver a explicar lo mismo? Si la respuesta es sí, todavía no delegaste nada. Nada más hiciste el trabajo con pasos extra.
Los cuatro movimientos
1. Escribe el contexto una vez, en un archivo
Todo lo que le explicas al inicio de cada sesión —cómo se llama el cliente, qué formato usan, qué está prohibido tocar, cómo se corren las cosas— no va en el chat. Va en el CLAUDE.md del proyecto, que Claude lee solo cada vez que abres una sesión ahí.
La regla que uso para saber qué meter: si ya lo escribiste dos veces en dos conversaciones distintas, es contexto, no instrucción. Va al archivo.
Lo que se ahorra: los primeros diez minutos de cada sesión, y la mitad de las correcciones, que son correcciones de contexto disfrazadas de correcciones de calidad.
2. Pide el plan antes del trabajo
Para cualquier tarea de más de dos pasos, primero el plan. En Claude Code eso tiene un modo propio: arrancas con claude --permission-mode plan, o presionas Shift+Tab a media sesión hasta que la barra de estado muestre que el modo plan está activo. En ese modo lee y propone, pero no toca tus archivos hasta que apruebes.
Corregir un plan de ocho líneas toma treinta segundos. Corregir el trabajo ya hecho toma media hora y te deja con archivos que hay que revertir.
Lo que se ahorra: el rehacer completo. Es el movimiento con mejor relación entre esfuerzo y devolución de los cuatro.
3. Define el terminado antes de empezar
"Hazme el reporte" no tiene final. "El reporte está listo cuando trae las cuatro secciones, el gasto total cuadra con la plataforma, y no hay ninguna cifra sin fuente" sí lo tiene.
Cuando el criterio se puede verificar solo, puedes dejarlo trabajando hasta cumplirlo con /goal seguido de la condición: Claude sigue turno tras turno y un modelo aparte revisa después de cada uno si ya se cumplió. Ojo con una restricción del mecanismo: ese evaluador no corre comandos ni abre archivos por su cuenta, solo lee la conversación, así que la condición tiene que ser algo que el trabajo mismo deje escrito ahí.
Lo que se ahorra: las rondas de "casi, pero le falta". Si el criterio existe desde el principio, no hay casi.
4. Manda la exploración a un subagente
Cuando la tarea empieza con "primero averigua cómo funciona X", esa parte no la quieres en tu conversación. Leer veinte archivos para encontrar tres llena tu contexto de basura y a partir de ahí todo lo que pidas sale peor.
Se pide directo: "usa un subagente para investigar cómo está armado el flujo de facturación". El subagente lee en su propio espacio y te regresa la conclusión. Tu conversación se queda limpia con lo que importa.
Lo que se ahorra: la degradación de la sesión larga. Es la razón por la que tu Claude "se pone tonto" a la hora y media.
El paso que todo mundo se salta: volver al archivo después de corregir. Cada vez que corriges algo, para dos minutos y pregúntate si esa corrección es de una sola vez o es una regla. Si es regla, escríbela en el CLAUDE.md ahí mismo. La gente que dice que Claude "no aprende" es la que corrige veinte veces la misma cosa en el chat y nunca la escribe en el archivo.
El prompt de arranque de delegación
Este no lo uso para pedir trabajo. Lo uso una sola vez por tarea nueva, para armar la delegación completa antes de que empiece.
Voy a delegarte una tarea que hago seguido. Antes de hacerla,
ayúdame a armar bien la delegación.
LA TAREA
Qué es: [descríbela como se la contarías a alguien que entra hoy]
Cada cuánto la hago:
Cuánto me toma hoy a mano:
Dónde vive lo que necesitas: [archivos, carpetas, herramientas]
Cómo se ve una entrega buena: [describe una que sí sirvió]
Cómo se ve una mala: [describe un caso real que salió mal]
Qué tienes prohibido: [tocar, publicar, borrar, mandar]
QUÉ QUIERO QUE HAGAS AHORA (no la tarea todavía)
1. Hazme las 5 preguntas cuya respuesta más cambiaría tu resultado.
Solo 5, las que más pesan. Espera mi respuesta.
2. Con mis respuestas, escríbeme el bloque de contexto que debería
quedar guardado en el CLAUDE.md del proyecto, redactado como
reglas, no como descripción.
3. Escribe el criterio de terminado en forma de lista verificable.
Cada punto tiene que poder contestarse con sí o no, sin opinión.
4. Dime qué parte de esta tarea NO deberías hacer tú y por qué.
5. Hasta el final, propón el plan de ejecución en pasos numerados.
No ejecutes nada hasta que lo apruebe.El punto 4 es el que la gente borra y el que más vale. Una tarea bien delegada casi siempre tiene un pedazo que se queda contigo, y saber cuál es de entrada evita el peor resultado posible: que te entregue algo completo donde una parte está inventada.
El orden importa
No hagas los cuatro hoy. El movimiento 1 solo, aplicado a tu proyecto más recurrente, ya te quita el pedazo más grande. Vive con eso una semana y ve qué correcciones te siguen apareciendo: esas son las reglas que le faltan al archivo.
El 2 entra cuando empieces a pedirle cosas de varios pasos. El 3, cuando quieras dejar de estar sentado esperando. El 4, cuando notes que las sesiones largas se ponen peores.
Y la señal de que ya delegaste de verdad no es que quede perfecto. Es que puedas describir la tarea en una frase y salga bien, porque todo lo demás ya está escrito en algún lado. Si el archivo es lo que te falta, empieza por el archivo más importante de Claude Code; y cuando quieras que además arranque solo, sigue con ingeniería de loops.