Una petición, un objetivo: deja de saturar a Claude Code

Si Claude Code te devuelve trabajo a medias, casi nunca es que el modelo sea malo. Es que le has metido cinco objetivos en un mismo mensaje y los está repartiendo. Aquí tienes la regla y el checklist para reescribir esas peticiones.

La idea

Cuando le sueltas algo así:

Arregla el bug del login, refactoriza el servicio de auth,
añade tests y de paso renómbrame las variables a camelCase.

No le has dado una tarea: le has dado cuatro objetivos peleándose por la misma atención. El modelo intenta avanzar en todos a la vez, hace cada uno a medias y tú acabas revisando un marrón: el bug medio arreglado, tests que no cubren nada, y un refactor que se ha llevado por delante algo que funcionaba.

No es que el modelo rinda peor. Lo sobrecargas tú.

La regla

Una petición = un objetivo. Terminas ese, revisas el resultado, y vas al siguiente.

Encadenas, no apelmazas. Cada mensaje tiene una sola cosa que validar, así que sabes exactamente qué mirar antes de seguir.

Checklist: reescribe una petición sobrecargada

Cuenta los verbos de acción. “Arregla”, “refactoriza”, “añade”, “renombra”… cada uno es un objetivo. Si hay más de uno, hay que partir.
Ordénalos por dependencia. ¿Qué tiene que estar bien antes de tocar lo siguiente? El bug primero; el refactor, después de que funcione.
Manda solo el primero. Un mensaje, un objetivo, una cosa que revisar.
Revisa antes de encadenar. Lee lo que ha hecho. Si está bien, vas al siguiente. Si no, lo corriges sobre ese mismo paso, no arrastrando el lío a los demás.
El “de paso” es una bandera roja. Cada “y de paso…” es un objetivo extra disfrazado. Sácalo a su propio mensaje.

Ejemplos antes / después

Antes:

Arregla el bug del login y ya que estás refactoriza
el servicio de auth y añade tests.

Después:

1) En el login, el token expira y no redirige a /login.
   Encuentra por qué y arréglalo.

→ revisas →

2) Ahora añade tests para el flujo de expiración de token
   que acabamos de arreglar.

→ revisas →

3) Refactoriza el servicio de auth para separar
   la validación del token de la lógica de sesión.

Antes:

Móntame el endpoint de checkout, conéctalo a Stripe,
maneja los errores y documéntalo.

Después:

1) Crea el endpoint POST /checkout que reciba el carrito
   y devuelva un total validado. Sin pagos todavía.

→ revisas →

2) Conecta ese endpoint a Stripe para crear el PaymentIntent.

→ revisas →

3) Añade el manejo de errores de Stripe (tarjeta rechazada,
   importe inválido) devolviendo códigos claros.

Por qué NO es más lento

Parece que mandar uno a uno tarda más. Es al revés.

Cuando metes todo junto y sale a medias, no has terminado: empieza la ronda de “no, eso no”, “vuelve a ese fichero”, “deshaz lo del refactor”. Tres o cuatro idas y vueltas para desliar lo que se mezcló.

Con un objetivo por mensaje, cada paso sale bien a la primera. No corriges, no deshaces, no repites. El tiempo que parecías ahorrar metiéndolo todo junto lo pagas con intereses arreglando el batiburrillo.

Regla de oro

Si en una petición cuentas más de un verbo, no es una tarea: son varias esperando a salir mal a la vez. Pártelas.

Sígueme para más trucos con Claude Code e IA → @pabloinpublic

Únete a la comunidad → pabloinpublic.com