Por qué Claude hace lo que no quieres: 3 prompts
MarkdownClaude escribe algo que no querías porque se lanza a programar sin entender tu intención. Te explico por qué y te doy 3 prompts listos para que primero te haga preguntas.
Leer el artículo completo
Punto clave
Claude escribe algo que no querías porque se lanza a programar y completa por su cuenta lo que cree que le has pedido. A menudo se equivoca. Casi nunca el problema es el modelo: incluso el más potente fallará si la tarea es ambigua. Lo soluciono de una vez: hago que Claude me entreviste primero, que averigüe qué quiero y solo entonces escriba. Aquí tienes tres prompts listos para copiar y pegar.
Para obtener más información sobre cómo usar el servicio, consulta la documentación de Ailoot.
¿Por qué Claude hace lo que no quieres?
Punto clave
Claude recibe una petición breve, rellena enseguida lo que falta y se pone a escribir código basándose en su propia interpretación de la tarea. Esa interpretación no coincide con la tuya. Así acabas con un diff que afecta a 14 archivos cuando esperabas un cambio de una sola línea. La causa es la distancia entre lo que dijiste y lo que tenías en mente. El modelo casi no tiene nada que ver.
Escribes: «Añade filtros a la página de productos». En tu cabeza, eso significa un par de casillas y una lista actualizada. Claude oye lo mismo y decide crear un motor de filtrado completo: su propio almacén de estado, lógica independiente para el retraso de entrada, sincronización de URL y una docena de funciones auxiliares. Cientos de líneas cuando habrían bastado unos pocos parámetros de URL.
En un caso así, la conclusión es clara: el agente no cometió un error; simplemente resolvió un problema mucho mayor de lo necesario. El fallo fue no describir el resultado deseado de forma breve y precisa.
La palabra clave es «intención». Tú la tienes en la cabeza; Claude no. Ve el texto de tu petición y todo el contexto que tiene hasta ese momento. Después rellena los huecos con suposiciones. Cuanto más breve sea la petición, más suposiciones hará y más se alejará el resultado de lo que querías.
Anthropic lo dice claramente en la documentación de Claude Code:
Si dejas que Claude pase directamente al código, puede que resuelva el problema equivocado.
Me pasó en mi propio proyecto. Pedí corregir una pantalla de autorización y recibí un diff que afectaba a la mitad de un módulo vecino. Claude no tuvo la culpa: le di una línea y completó el resto por su cuenta. Desde entonces, empiezo con preguntas cualquier tarea que vaya más allá de corregir una errata: las preguntas que Claude me hace.
¿De verdad es culpa del modelo? ¿Por qué fallan incluso los más potentes?
Punto clave
El modelo importa menos de lo que suele pensarse. Ante una tarea ambigua, incluso el más potente fallará: recibe las mismas instrucciones incompletas y rellena los huecos con sus propias suposiciones. Los desarrolladores que mantienen al agente bajo control obtienen los mismos resultados con un modelo de primer nivel que con uno de gama media. Todo depende de la claridad con que describas lo que quieres. Aquí la potencia del modelo es secundaria.
Cada semana aparece un modelo «más inteligente» que el anterior, y cada vez parece que por fin ha llegado el momento en que la IA nos entenderá con solo unas palabras. No es así. Un modelo más potente escribe código más rápido y maneja mejor la lógica compleja, pero sigue sin poder leerte la mente. Si la tarea está mal planteada, obtendrás algo muy bien escrito que seguirá estando mal.
La conclusión para ti es sencilla. Perseguir el modelo más nuevo para que adivine mejor no lleva a ninguna parte. Es más barato y fiable aprender a plantearle tareas de forma que no tenga que adivinar. Eso es lo que veremos a continuación.
¿Qué es el grilling y cómo corrige la falta de alineación con la IA?
Punto clave
El grilling consiste en hacer que la IA te entreviste antes de empezar a trabajar: te hace preguntas detalladas sobre la tarea hasta que ambos llegáis a una comprensión común. El objetivo es cerrar la brecha de comunicación antes de escribir la primera línea de código.
Parece contradictorio. Recurrimos a la IA para hacer las cosas más rápido, y ahora nos dicen que la frenemos y hagamos que pregunte primero. Pero cinco minutos de preguntas antes de programar pueden ahorrarte una hora de correcciones después.
El problema no es solo que hayas explicado mal las cosas a Claude. A menudo, ni siquiera tú has pensado a fondo la tarea: qué casos contemplar, dónde están los límites, qué importa más. El grilling hace que lo aclares mediante preguntas. Al acabar la conversación, no solo tienes una tarea que la IA entiende; también tienes tu propia tarea, por fin descrita con detalle.
Así funciona la ingeniería de contexto: el trabajo principal ocurre antes del prompt, no durante. No buscas una formulación mágica para el prompt; expones de antemano lo que necesitas que Claude sepa hasta que lo entiende sin explicaciones adicionales.
¿Cómo consigues que Claude te haga preguntas primero?
Punto clave
Dale a Claude una descripción breve de la tarea y pídele explícitamente que te entreviste antes de empezar: que pregunte por los detalles, los casos límite y las restricciones, y que al final lo reúna todo en un archivo de especificaciones. Esta es la recomendación oficial de Anthropic: la documentación de Claude Code incluye una plantilla de prompt lista para usar. Cópiala, cambia la descripción y pégala al empezar una sesión.
Anthropic no solo permite este enfoque, sino que lo recomienda. Su documentación tiene una sección llamada «Deja que Claude te entreviste», con un prompt ya preparado. Aquí tienes una versión práctica:
Prompt
Prompt de grilling: haz que Claude te entreviste
Quiero crear [breve descripción de la tarea].
Entrevístame en detalle antes de escribir código. Haz preguntas sobre la implementación, la interfaz, los casos límite, los riesgos y las compensaciones. No hagas preguntas obvias: profundiza en los aspectos complicados que quizá no haya tenido en cuenta.
Haz una pregunta cada vez y espera mi respuesta. Para cada pregunta, sugiere de inmediato la respuesta que recomiendas.
Continúa hasta que lo hayamos cubierto todo. Después, redacta una especificación completa en un archivo llamado SPEC.md.
Tres detalles hacen que este prompt sea útil y no meramente decorativo. Primero: «una pregunta cada vez». Si la IA te lanza diez preguntas a la vez, te abruma y respondes por encima. Segundo: «sugiere tu respuesta»: no tienes que inventártelo todo desde cero; puedes aceptar o corregir la propuesta. Tercero: «redacta una especificación en un archivo»: la intención que has explicado se convierte en un documento que no se perderá.
Anthropic describe el beneficio en términos de esfuerzo:
El tiempo dedicado a acertar con la especificación es más valioso que el tiempo que pasas observando la implementación.
Después de la entrevista, abre una sesión nueva y dale la especificación terminada. Contexto limpio e intención claramente expresada: Claude acierta a la primera.
La técnica «demuéstrame que este es el mejor plan»
Punto clave
No te limites a hacer que la IA pregunte: haz que también defienda sus decisiones. Añado un requisito a la tarea: que demuestre que el plan propuesto es el mejor, no solo el primero que se le ocurre, y que está pensado con varios pasos de antelación. Así Claude sale del modo «haré algo parecido» y pasa al modo crítico, en el que revisa su propio trabajo antes de que dediques tiempo a implementarlo.
El grilling hace aflorar tu intención. Pero la IA tiene otro hábito: quedarse con la primera solución que parece plausible. Anthropic llama a esto la brecha entre «confiar y verificar»: Claude genera una implementación plausible que no resiste los casos límite. La solución es pedir pruebas antes del código.
Si no puedes comprobar el resultado, no lo envíes.
Casi siempre añado una sección «demuéstralo» a mi prompt. Esta es la formulación exacta:
Prompt: haz que la IA defienda su plan
Antes de escribir código, analiza la tarea con espíritu crítico.
Encuentra 2-3 formas de resolverla. Para cada una, demuéstrame que realmente resuelve mi tarea en lugar de añadir complejidad porque sí. No escribas código por el mero hecho de escribirlo.
Después, elige una y demuestra que es la mejor solución y que has pensado varios pasos por delante. ¿Qué se romperá a medida que crezca el proyecto? ¿Qué nos estamos dejando fuera ahora mismo?
Solo entonces propón una implementación.
Sin esta sección, Claude te da la primera opción viable. Con ella, descarta por sí mismo los callejones sin salida, explica su elección y te permite ver su razonamiento antes de tocar un solo archivo. Lees un texto breve que lleva dos minutos en vez de pasar una hora intentando averiguar por qué el código terminado no funciona como esperabas.
Premortem: haz que la IA encuentre 10 razones de fracaso antes de empezar
Punto clave
Un premortem es una técnica que consiste en pedir a la IA que imagine que el proyecto ya ha fracasado y que enumere las razones. Claude pasa del optimista «lo sacaré adelante» a buscar debilidades que, de otro modo, saldrían a la luz tras una semana de trabajo. Obtienes una lista de riesgos antes de invertir tiempo en el proyecto y puedes abordarlos de antemano.
Esta es mi técnica favorita, y es psicológica. Cuando le pides a la IA que «haga un buen trabajo», la predispones al éxito y pasa por alto los agujeros. Pídele que imagine el fracaso y empezará a ver lo que antes ignoraba. El prompt es breve:
Prompt de premortem: encuentra los huecos antes de empezar
Imagina que estamos dentro de un año. El proyecto que estamos planificando ha fracasado.
Escribe 10 razones por las que ocurrió. ¿Qué no tuvimos en cuenta al principio, qué subestimamos, dónde recortamos gastos y qué suposiciones resultaron ser falsas?
Después, dime qué podemos corregir ahora mismo para abordar cada razón.
Uso este prompt antes de aprobar el plan. La mitad de las razones resultan absurdas, pero la otra mitad son escollos reales con los que me habría encontrado una semana después. Resolverlos durante la planificación lleva diez minutos. Encontrártelos en un proyecto terminado cuesta varios días de investigación.
La combinación es sencilla: el grilling hace aflorar la intención, «demuéstralo» defiende la decisión y el premortem encuentra los huecos. Tres textos breves que pegas antes de escribir código. Transforman a Claude de ejecutor precipitado en colaborador que primero piensa.
¿Por qué un contexto saturado hace que Claude parezca tonto?
Punto clave
Claude tiene una ventana de contexto limitada, es decir, la cantidad de información que puede mantener presente a la vez. Cuando está llena en más de la mitad, empieza a perder detalles importantes, confunde acuerdos anteriores y rellena huecos en vez de recordar. Una sesión larga sobre cualquier tema es una razón habitual por la que la IA acaba haciendo algo completamente distinto de lo acordado por la mañana.
Hasta una tarea perfectamente planteada se viene abajo si trabajas en un contexto abarrotado. Funciona así: cada nueva petición incorpora todo el historial del chat al contexto de trabajo de Claude. Cuanto más larga es la sesión, más rápido se llena la ventana. Procura que no supere la mitad; a partir de ahí, la IA empieza a comportarse de forma torpe y a olvidar cosas importantes que hablasteis al principio.
Esta es la regla que más frustración me ahorra: una tarea, un chat. ¿Has terminado una función? Cierra el chat y abre uno nuevo para la siguiente tarea. Sí, a veces resulta más cómodo hacerlo todo en una sola ventana, pero lo pagarás con pérdida de contexto y respuestas fuera de tema.
Anthropic llama a este modo de fallo una «sesión cajón de sastre». La solución es sencilla: usa /clear entre tareas no relacionadas para vaciar la ventana y evitar arrastrar el desorden de la tarea anterior a la nueva.
Si haces sesiones largas y no sabes adónde van el dinero y la atención de la IA, lo explico por separado en la guía sobre dónde van los tokens de Claude Code. También he reunido los fundamentos del contexto persistente, que Claude lee cada vez que se inicia, en la guía para configurar CLAUDE.md.
Grilling o Plan Mode: ¿en qué se diferencian y cómo se complementan?
Punto clave
El grilling y Plan Mode resuelven dos partes distintas del mismo problema. El grilling aclara tu intención mediante preguntas antes de que haya un plan. Plan Mode toma una tarea que ya se entiende y te muestra un plan de cambios, sin tocar nada hasta que lo apruebes. Funcionan mejor juntos: primero el grilling aclara qué vamos a construir y después Plan Mode muestra exactamente cómo.
A menudo se confunden estas dos técnicas o se piensa que solo hace falta una. En la práctica, corresponden a etapas diferentes del proceso.
| Característica | Grilling | Plan Mode |
|---|---|---|
| Cuándo ocurre | Antes del plan: aclara la intención | Después: crea un plan de cambios |
| Quién pregunta a quién | La IA te entrevista | Tú lees y apruebas el plan |
| Qué obtienes | Una especificación de la tarea | Un plan de cambios archivo por archivo |
| Ventaja principal | Evita «eso no es lo que quería» | Evita «no toques nada más» |
Anthropic describe un flujo de trabajo canónico de cuatro fases: primero Explore (Claude estudia y hace preguntas), después Plan (elabora un plan sin hacer cambios), luego Implement (escribe código siguiendo el plan) y, por último, Commit (registra el resultado). El grilling tiene lugar en la primera fase y Plan Mode, en la segunda. Para ver un análisis completo de esta última, consulta la guía sobre Plan Mode en Claude Code.
Anthropic también hace una advertencia importante: no sobrecargues las tareas pequeñas con este proceso.
Si puedes describir un cambio en una frase, omite el plan.
Para corregir una errata, cambiar un nombre o modificar una línea, escribe directamente lo que quieres, sin entrevistas ni planes. El grilling merece la pena en tareas ambiguas y con un coste alto si algo sale mal. Para tareas triviales, solo te ralentiza.
5 errores al plantear tareas que hacen que la IA se equivoque
Punto clave
Casi todos los errores de la IA se reducen a cinco fallos al plantear la tarea: una frase vaga, ninguna restricción, «escribe código» sin una fase previa de comprensión, no definir qué significa «terminado» y usar una sesión interminable para todo. Cada uno hace que Claude complete la tarea con suposiciones. A continuación verás cómo es cada error y cómo sustituirlo.
He resumido los errores habituales en una tabla. A la izquierda está lo que la gente suele hacer y hacer mal; a la derecha, lo que debería hacer en su lugar.
| Error | Cómo suena | Qué hacer en su lugar |
|---|---|---|
| Frase vaga | «Mejora el panel» | Describe la tarea e inicia una sesión de grilling: deja que la IA saque los detalles a la luz mediante preguntas |
| Sin restricciones | «Añade autorización» | Di qué no debe romperse, qué bibliotecas no hay que incorporar y qué queda fuera del alcance |
| «Escribe código» de inmediato | Prompt y a programar | Primero «entiende y pregunta» y luego escribe código |
| Sin definir qué es «terminado» | Esperas que la IA adivine el resultado | Da un ejemplo, una captura de referencia o una prueba que muestre qué significa que «funcione» |
| Una sesión para todo | Pasar todo el día en un chat | Una tarea, un chat nuevo, para que el contexto no se llene de ruido |
Revisa el último prompt en el que la IA te dio una respuesta incorrecta. Casi seguro que se debió a uno de estos cinco errores. El más habitual es el primero: le diste una frase breve y esperabas que Claude completara correctamente el resto. Lo completó, pero no de la manera que tenías en mente.
Qué hacer ahora: crea un sistema para que la IA te entienda con pocas palabras
Punto clave
Los prompts individuales resuelven tareas individuales. Para que la IA te entienda sin largas explicaciones cada vez, necesitas un sistema: el grilling saca a la luz la intención para cada tarea, un Second Brain guarda los conocimientos del proyecto y la ingeniería de contexto conecta todo lo que Claude lee antes del prompt. Entonces desaparece la razón por la que hace lo que no quieres: siempre dispone de contexto suficiente para no tener que adivinar.
Los tres prompts de esta guía —grilling, «demuéstralo» y el premortem— se ocupan de la tarea concreta. Eso ya es mucho: dejarás de recibir un diff de 14 archivos cuando solo querías cambiar una línea.
Pero el grilling tiene un límite. Sacar tu intención desde cero cada vez lleva mucho tiempo. El verdadero cambio llega cuando siempre hay algo de contexto disponible: en una carpeta con conocimientos sobre tu proyecto, en un archivo CLAUDE.md que Claude lee al iniciarse y en tu metodología codificada en skills. Así la IA llega a la tarea conociendo ya tu negocio, tus objetivos y tu estilo, y te entiende con pocas palabras porque has preparado la mitad del contexto de antemano.
Un análisis reciente de Anthropic muestra cuánto trabajo supone: los desarrolladores usan la IA en aproximadamente el 60% de su trabajo, pero solo pueden confiar plenamente en ella para el 0-20% de las tareas. El resto requiere que tú entiendas, supervises y expliques qué hay que construir. Esa es la habilidad que merece la pena desarrollar, no perseguir el modelo más inteligente.
Fuentes
Conoce Ailoot.
Más detalles
Preguntas sobre Claude Code
¿Cuándo uso el prompt de entrevista en lugar de ir directamente al código?
Cuando el resultado, los casos límite o las restricciones sean poco claros y equivocarse salga caro. Haz una pregunta cada vez y guarda lo acordado en SPEC.md. Una errata o un cambio de una línea claramente descrito puede pedirse directamente.
¿Qué compruebo antes de aceptar el plan propuesto?
Pide dos o tres enfoques y compara cómo cumplen la especificación y las restricciones. Ejecuta después el prompt de análisis previo de fallos, revisa sus causas posibles y aborda los riesgos pertinentes antes de implementar.