La frase que lo rompe todo

Qué es y por qué importa

La frase que lo rompe todo es la que sueltas sin pensar: «arregla el login», «haz que la página vaya más rápido», «añade los pagos». Claude Code se la toma en serio y hace algo. El problema es que decide él qué significa «arreglado», qué puede tocar y cuándo ha terminado.

No es un defecto de la IA. Es que no te lee la mente. La propia guía de Anthropic sobre prompts lo dice de forma sencilla: trátalo como a un compañero brillante pero recién llegado, que no conoce tus reglas ni tu proyecto. Cuanto más preciso seas con lo que quieres, mejor es el resultado.

Por eso, antes de cada petición, relleno una plantilla de tres líneas: qué tiene que pasar, qué no debe cambiar, cómo lo comprobamos. Me lleva poco. Me ahorra la peor parte, que es descubrir al final que ha reescrito algo que funcionaba. La misma IA, con una petición clara, te da un resultado distinto. No es magia: es ser claro con alguien que no te lee la mente.

La plantilla de tres líneas

Aquí la tienes. Cópiala y rellena los corchetes. Con una línea por parte basta.

Qué tiene que pasar: [el resultado que quieres ver, con tus palabras]
Qué no debe cambiar: [archivos, páginas o funciones que no debe tocar]
Cómo lo comprobamos: [cómo sabes que funciona: un test, un clic, un dato que tiene que aparecer]

Qué tiene que pasar

El resultado que quieres ver, no la forma de llegar a él. Escríbelo con tus palabras, como lo dirías en voz alta. «Cuando pulso Guardar, la nota aparece en la lista» funciona mejor que «arregla el bug del guardado», porque dice lo que tiene que ver quien usa la app. Si sabes dónde pasa, qué página, qué botón, escríbelo: así Claude no tiene que adivinar.

Qué no debe cambiar

Los límites: archivos, páginas o funciones que tienen que quedarse como están. Para arreglar una cosa, a veces Claude «mejora» otras cercanas que nadie le había pedido. Si le dices dónde no meter las manos, tiene un límite claro. Es la línea que casi todos se saltan, y vuelvo a ella más abajo.

Cómo lo comprobamos

Cómo sabes que funciona: un test, un clic, un dato que tiene que aparecer. Esta línea te sirve a ti y le sirve a Claude. Si tiene una comprobación que puede hacer solo, como un test que pasa o falla, puede probar, leer el resultado y corregirse antes de decirte que ha terminado. Sin ella, la única señal es que el trabajo «parece hecho», y comprobarlo te toca a ti.

Dos ejemplos para copiar

Ejemplo 1: un botón que no guarda

Qué tiene que pasar: cuando pulso el botón Guardar en la página Notas, tiene que crear una fila en la tabla de notas de la base de datos.
Qué no debe cambiar: no toques el login y no cambies el diseño de la página.
Cómo lo comprobamos: dime exactamente cómo lo pruebo, paso a paso, y si puedes escribe un test que lo verifique.

Fíjate en la tercera línea. No hace falta saber escribir un test: le pido a Claude que me diga cómo probarlo y, si puede, que lo escriba él. No tienes que saber tú cómo se comprueba. Solo tienes que exigir que haya una forma.

Ejemplo 2: una página lenta

Qué tiene que pasar: la página de precios tiene que abrirse en menos de dos segundos, también desde el móvil.
Qué no debe cambiar: los precios, los textos y el pago se quedan idénticos.
Cómo lo comprobamos: mide el tiempo de carga antes y después, y enséñame los dos números.

Aquí la comprobación es un número antes y otro después. Si Claude te dice «ahora va más rápido» sin los dos números, no sabes si es verdad. Y la línea del medio protege lo que no quieres que cambie por error mientras optimiza: precios, textos, pago.

Tres consejos para usarla en Claude Code

1. Si no sabes cómo comprobarlo, para

Si no sabes responder a «cómo lo comprobamos», todavía no sabes lo que quieres. Pasa, y es mejor darse cuenta antes que después. En lugar de arrancar el trabajo, pide ayuda para entenderlo:

Ayúdame a entender cómo verificar esto, no escribas código.

Para los trabajos más grandes uso el modo plan de Claude Code (plan mode). Claude lee los archivos y te propone un plan, pero no modifica nada hasta que lo apruebas. Entras pulsando Shift+Tab hasta que abajo aparece «plan mode on», o escribiendo /plan delante del mensaje. Ahí pego la plantilla y pregunto:

Lee la plantilla de abajo y proponme un plan. Dime qué archivos piensas tocar, confirma que no tocas los que he excluido y explícame cómo haremos la comprobación de la última línea.

[pega aquí la plantilla rellenada]

Para un cambio pequeño no hace falta el plan: si lo describes en una frase, como corregir una errata en un texto, pídelo directamente.

2. No te saltes la línea del medio

«Qué no debe cambiar» es la parte que todos se saltan, y es la que te salva el login, los pagos y los datos reales. Lo que no debe tocar nunca lo escribo también en el CLAUDE.md, el archivo de la carpeta del proyecto que Claude Code lee al principio de cada sesión. Por ejemplo, esta línea:

No modifiques el login, los pagos ni los datos de los usuarios sin preguntarme antes.

Ojo, eso sí: el CLAUDE.md es una instrucción, no un candado. Claude lo trata como contexto, no como un bloqueo. Por eso, cuando la petición pasa cerca de esas partes, las vuelvo a escribir en la plantilla.

3. Al final, pide el resumen

Cuando termine, pregunta siempre:

Dime qué has cambiado y qué no has tocado.

Luego compara la respuesta con la plantilla. Si ha tocado algo de la línea del medio, o falta la comprobación de la tercera línea, lo ves enseguida. En ese caso no sigo y pregunto:

Enséñame la prueba de la última línea de la plantilla: el test con el resultado, o los pasos exactos para probarlo yo.

Errores comunes

• Describir el código en vez del resultado, tipo «cambia esa función»: escribe lo que tiene que ver quien usa la app y deja el cómo a Claude.
• Dejar vacía «qué no debe cambiar» porque parece obvio: escribe al menos login, pagos y datos reales cuando el trabajo pasa cerca.
• Una comprobación vaga como «verifica que funcione»: pide algo que se vea o se mida, o sea, un test que pasa, un clic, un número.
• Meter tres peticiones en la misma plantilla: una plantilla, una sola cosa, y las demás las pides después, de una en una.
• Fiarse del «hecho» sin resumen: pregunta qué ha cambiado y qué no ha tocado, y compáralo con la plantilla.

Lista de comprobación

• He escrito el resultado con mis palabras
• He escrito lo que no debe tocar
• Sé cómo voy a comprobar que funciona
• La plantilla pide una sola cosa
• Para un trabajo grande he pedido antes un plan
• Al final he preguntado qué ha cambiado y qué no

Preguntas frecuentes