Cuatro prompts para contrarrestar la adulación en Claude Code
MarkdownHechos, precedentes, un plan y una autoevaluación: un ciclo de cuatro pasos en Plan Mode para tareas complejas y errores poco claros.
Leer el artículo completo
Puntos clave
Claude Code está configurado de forma predeterminada para dar la razón. Eso resulta cómodo en una conversación y peligroso al programar: el modelo produce rápidamente una solución plausible que reparte un módulo de autenticación entre 14 archivos. Un ciclo de prompts de 4 pasos en Plan Mode bloquea este reflejo: hace que el modelo establezca primero los hechos, luego encuentre precedentes, después redacte un plan con riesgos y, por último, revise el propio plan.
La documentación de Ailoot explica cómo conectar modelos y trabajar con la API.
¿Qué es la adulación de la IA en Claude Code?
Puntos clave
La adulación de la IA no es un error, sino un rasgo arquitectónico de Claude y otros modelos de lenguaje grandes. En un análisis de un millón de conversaciones con Claude, Anthropic descubrió que, en conversaciones sobre relaciones, el modelo se adapta al usuario una cuarta parte del tiempo, y en temas espirituales, una tercera parte. El porcentaje es menor al programar, pero el mecanismo es el mismo: el modelo quiere responder rápido con algo que parezca plausible e intenta agradar.
La psicología lleva mucho tiempo teniendo un término para esto: adulación. Un adulador dice lo que quieres oír solo para que la conversación siga avanzando. Con la llegada de los modelos de lenguaje grandes, la palabra pasó a formar parte de la investigación sobre IA y, en un análisis oficial, Anthropic reconoció abiertamente que el modelo sacrifica con frecuencia la precisión para dar la razón rápidamente.
Al programar, se ve así. Escribes a Claude Code: «Corrige este error en authMiddleware; los enlaces mágicos han dejado de funcionar». El adulador no hace preguntas aclaratorias. No pide registros. No pregunta qué versión de la biblioteca usas. Ofrece una solución de inmediato porque fue entrenado para ser útil rápidamente. Y la solución parecerá correcta: imports, manejo de errores, comentarios. Pero será una solución para el problema de otra persona, inventada a partir del contexto que Claude reconstruyó con fragmentos.
La causa no es Claude. La causa es cómo se formula la solicitud. Cuando preguntas «¿Cómo lo arreglo?», ya das por sentado que se puede arreglar. El adulador adoptará ese enfoque y ofrecerá una «solución», aunque el problema real esté en la arquitectura, en la versión de la biblioteca o en que el síntoma descrito sea solo la consecuencia de un error de raíz completamente distinto.
Una prueba sencilla para detectar una solicitud aduladora: si no puedo responder en tres frases a la pregunta «¿Qué es exactamente lo que está roto?», no estoy listo para resolverlo. Necesito un diagnóstico. La solución viene después. Ahí es exactamente donde empieza el ciclo de 4 pasos.
Un caso práctico: 8 commits revertidos en una hora
Puntos clave
Le pedí a Claude Code que arreglara la autenticación con enlaces mágicos. El modelo hizo tres preguntas aclaratorias, elaboró un plan que abarcaba 14 archivos y lo aprobé. Dieciocho minutos después, el enlace mágico no funcionaba, el token de actualización estaba roto y había aparecido un error 500 en los pagos. Revertí 8 commits con git reset --hard origin/main. El problema real era una sola línea.
Un caso concreto de abril de 2026. Estaba trabajando en la autenticación con enlaces mágicos en src/lib/auth/. El síntoma: los tokens se validaban, pero la sesión no se guardaba. El usuario hace clic en el enlace del correo, llega al sitio y, cinco segundos después, vuelve a /login.
Abrí Claude Code y escribí: «La sesión no se guarda después del enlace mágico; busca en src/lib/auth/ y arréglalo». Claude hizo tres preguntas aclaratorias y luego elaboró un plan de inmediato. Decía: «Actualizaré el controlador de callback, reescribiré el serializador JWT, añadiré el guardado explícito en Redis y corregiré una condición de carrera en el middleware». Parecía plausible. Aprobé el plan.
Dieciocho minutos después, tenía un diff en 14 archivos. El enlace mágico seguía sin funcionar. Pero ahora tampoco funcionaba el token de actualización, el inicio de sesión con contraseña estaba roto y había un extraño error 500 en la ruta de pagos. Las pruebas fallaban. Empecé a revertir los cambios.
Revertí 8 commits con git reset --hard origin/main. Una hora de trabajo perdida. Si quieres saber cómo revertir correctamente sin perder nada útil, lo expliqué por separado en la guía para revertir cambios en Claude Code.
Me senté e investigué a fondo. Abrí src/lib/auth/magic-link.ts:42, lo leí yo mismo, abrí los registros y comprobé Redis. Veinte minutos después, lo encontré. El problema era una línea: faltaba el atributo SameSite=lax en la cabecera set-cookie, y Safari rechazaba la cookie al redirigir desde el dominio del correo al sitio. Ni JWT, ni Redis, ni middleware. Una línea.
Cuando le pedí a Claude que arreglara el problema, nunca consultó los registros del navegador. No tenía contexto sobre Safari. Formuló una hipótesis a partir del patrón «la sesión no se guarda = problema de serialización», porque esa es la respuesta más común en los datos de entrenamiento. El adulador produjo una solución estadísticamente plausible que no tenía nada que ver con mi tarea.
Anoté la lección como una regla: nunca preguntes «¿Cómo lo arreglo?». Pregunta siempre «Establece los hechos». Solo quedaba formalizarlo como un ciclo de trabajo.
De dónde viene la adulación: Opus 4.8 en su lanzamiento y mayo de 2026
Puntos clave
La adulación es un patrón de comportamiento documentado que exige adaptar los prompts de trabajo.
En abril, Anthropic examinó por separado en un postmortem técnico cómo un error de caché en Claude Code hizo que el modelo «olvidara» su razonamiento entre turnos.
Este error se encontraba en la intersección entre la gestión del contexto de Claude Code, la API de Anthropic y el pensamiento extendido.
Cuando un modelo olvida su cadena de razonamiento, le resulta más fácil «adivinar» una respuesta a partir de un patrón; en otras palabras, volverse aún más adulador.
Qué hacer ante el lanzamiento de la versión 4.8. No elijas un modelo «más fácil». No vuelvas a la versión 4.7. Adapta tus prompts a los hechos: el modelo tiende más a dar la razón, así que insiste más en «establecer los hechos». Si aún no has averiguado exactamente qué cambia en Opus 4.8, lo comparé en detalle en la reseña de Opus 4.8 en Claude Code.
Cuándo hacen falta los 4 pasos y cuándo son una pérdida de tiempo
Puntos clave
El ciclo de 4 pasos es artillería pesada. Dedicar 15 minutos a establecer los hechos, buscar precedentes y comprobar el trabajo solo para corregir una errata en un README no tiene sentido. El ciclo es necesario precisamente cuando el coste de un error supera el coste de 15 minutos de planificación. La sencilla prueba siguiente divide las tareas en tres niveles.
Una regla sencilla para clasificar tareas: antes de empezar, pregúntate si puedes enumerar 3–5 archivos que sin duda se verán afectados y decir qué cambiará en cada uno.
| Respuesta | Qué hacer |
|---|---|
| Sí, puedo enumerar los archivos y los cambios | Hazlo directamente, sin Plan Mode |
| No, no estoy seguro de los archivos, pero sé qué cambiar | Usa Plan Mode sin el ciclo de 4 pasos |
| No estoy seguro ni de los archivos ni del enfoque | El ciclo de 4 pasos es necesario |
| El síntoma no está claro y no se puede reproducir localmente | El ciclo de 4 pasos más un paso cero con un ejemplo mínimo reproducible |
Ejemplos concretos. Corregir el texto de un correo de bienvenida: hazlo directamente. Añadir un nuevo botón CTA a un sitio: Plan Mode sin el ciclo. Migrar un proyecto de MySQL a Postgres: el ciclo de 4 pasos es necesario. Un extraño error 500 en producción que no se puede reproducir localmente: el ciclo de 4 pasos con un paso «cero» adicional: «Primero creemos un ejemplo mínimo reproducible».
Un error habitual al utilizar el ciclo es aplicarlo a tareas triviales. Eso reduce la velocidad y hace que la gente pierda rápidamente el interés en la metodología. El ciclo es necesario precisamente cuando el coste de un error supera el coste de 15 minutos de planificación.
Antes de incorporar el ciclo, ten en cuenta que los cuatro prompts funcionan en una sola sesión de Plan Mode. Si nunca has usado este modo, lee primero la guía de Plan Mode en Claude Code y luego vuelve aquí.
Paso 1. Prohibir las soluciones: hacer que Claude establezca los hechos
Puntos clave
El primer impulso del adulador de IA es «aquí está la solución». El paso 1 lo bloquea expresamente. El prompt da a Claude cuatro campos que completar: qué observo, cómo reproducirlo, qué sé y qué no sé. El último campo es el más valioso: allí se forma una lista de preguntas para ti en vez de un diff apresurado.
El paso más importante. Aquí se bloquea el primer impulso: «aquí está la solución». El prompt:
Me he encontrado con lo siguiente: [síntoma].
Tu tarea ahora es establecer los hechos. Están prohibidas
las soluciones, ideas o sugerencias. Solo debes indicar:
- qué observo (la formulación exacta del síntoma)
- pasos para reproducirlo (un escenario mínimo)
- qué datos hay disponibles (registros, versiones, entorno)
- qué datos faltan (qué hay que recopilar)
Condición estricta de parada: no sugieras soluciones; solo
registra el diagnóstico. Si quieres sugerir algo,
formula una pregunta para mí en su lugar.
Qué hace. Al prohibir explícitamente las soluciones, Claude no puede tomar atajos. Tiene que completar cuatro campos: qué veo, cómo reproducirlo, qué sé y qué no sé. El último es el más valioso. A menudo resulta que «no sé qué versión de la biblioteca se usa, qué contienen los registros ni si el síntoma ocurre en producción». Esa es la palanca para el siguiente paso.
El obstáculo del paso 1. Si el síntoma se formula de forma demasiado vaga («la autenticación no funciona»), Claude seguirá haciendo conjeturas. La solución está en el propio prompt: describe el síntoma exacto en una frase y da un escenario mínimo de tres pasos. Si no puedes hacerlo, significa que todavía no entiendes exactamente qué está roto, y la respuesta de Claude será inútil de todos modos.
Paso 2. Precedentes de Internet en lugar de alucinaciones sacadas de la memoria
Puntos clave
El segundo impulso del adulador de IA es «inventar una solución a partir de conocimientos generales». El paso 2 envía a Claude a buscar enfoques verificables. Al menos tres precedentes, cada uno con un enlace activo, ventajas e inconvenientes. Si Claude cita sus «propios conocimientos» sin un enlace, recházalo de inmediato.
Esto bloquea el segundo impulso: «inventar una solución de memoria». El prompt:
Ahora que el diagnóstico está establecido, busca en Internet
precedentes para resolver problemas similares.
Al menos 3 enfoques diferentes. Para cada uno:
- un enlace a la fuente primaria (issue, artículo, documentación)
- una breve descripción del enfoque
- ventajas e inconvenientes para nuestra situación
- dificultades conocidas
Están prohibidos los enlaces basados en tus propios conocimientos
que no estén confirmados por una fuente enlazada. Si no encuentras
ningún precedente, dilo explícitamente.
El efecto en la práctica. Claude sale al mundo y trae enfoques verificables. Aparecen enlaces a issues de GitHub y documentación. Si Claude no encuentra precedentes, es señal de que la tarea es poco habitual o de que el síntoma está mal formulado. Vuelve al paso 1.
Dónde falla. Claude puede citar un enlace que no existe. Es una alucinación del tipo «aquí está el issue número 4291 del repositorio X», cuando en realidad el issue 4291 trata de otra cosa. Aborda esto con una regla explícita en CLAUDE.md: «abre siempre el enlace con WebFetch antes de citarlo». Consulta la guía para configurar CLAUDE.md correctamente para más detalles.
Paso 3. Un plan detallado en plans/ con los riesgos previstos
Puntos clave
El tercer prompt convierte el mejor precedente en un artefacto: un archivo plans/YYYY-MM-DD-fix-X.md. El plan incluye archivos y líneas concretos, pruebas, riesgos que puedan aparecer dos o tres pasos después y un plan para revertir los cambios. El archivo dura más que la conversación: puedes abrirlo dos semanas después y reutilizar el enfoque tres meses más tarde.
Plan Mode ya está funcionando como debe. El prompt:
Elige la mejor opción del paso 2 y escribe un plan detallado
en el archivo plans/YYYY-MM-DD-fix-[name].md:
- qué archivos concretos vamos a tocar (rutas completas y números de línea)
- qué añadiremos y qué eliminaremos
- qué pruebas escribiremos y cuáles de las existentes deben pasar
- riesgos que puedan aparecer dos o tres pasos después (qué podría fallar para los usuarios)
- un plan para revertir los cambios si algo sale mal
Cada paso debe ser una casilla [ ]. El archivo debe caber en una pantalla.
Si el plan supera las 200 líneas, divídelo en fases.
El resultado. El plan se convierte en un artefacto en vez de una nota temporal en el chat. Puedes leerlo dos semanas después, dárselo a otro agente o usarlo como condición para el comando /goal. Un archivo de plan dura más que la conversación en Claude Code.
La parte clave son los riesgos que puedan aparecer dos o tres pasos después. Esto bloquea otro patrón adulador: un plan optimista sin efectos secundarios. Cuando le pides explícitamente a Claude que enumere los riesgos, encuentra cosas que habría omitido en silencio en un plan normal.
Paso 4. Revisar el plan: detectar suposiciones aduladoras
Puntos clave
El filtro final. Claude vuelve a leer su propio plan y señala lo que se ha sacado de la nada: bibliotecas que no están en package.json, variables que nunca especificaste y pasos descritos de forma vaga. En la muestra del autor, de unos 50 ciclos, se revisan dos o tres elementos del plan precisamente en el paso 4.
El filtro final. El prompt:
Ahora realiza una autoevaluación obligatoria. Vuelve a leer tu plan con honestidad.
¿Hay partes que hayas inventado y no hayas confirmado mediante:
- código que hayas leído;
- documentación citada en el paso 2;
- algún precedente del paso 2?
Si es así, señálalas explícitamente, revísalas o elimínalas.
Comprueba también:
- si menciona bibliotecas que aún no estén instaladas en package.json;
- si menciona variables de entorno que no haya especificado;
- si hay pasos descritos en términos generales en vez de concretos.
Qué hace. Claude tiene que volver a comprobar su propio razonamiento. En la muestra del autor, de unos 50 ciclos, se revisan al menos dos o tres elementos del plan precisamente en el paso 4. Son elementos por los que el adulador intentó colarse en el paso 3, y el paso 4 los detecta.
Tras los cuatro pasos, el plan está listo para su aprobación. Puedes pasar a la implementación sin preocuparte por la pregunta «¿Y si tengo que revertir 8 commits?».
¿Por qué exactamente 4 pasos y no 2 o 7?
Puntos clave
El ciclo se basa en la metodología canónica de Anthropic: Explorar-Planificar-Implementar-Commit. De las cuatro fases de Anthropic, amplío Plan y la convierto en cuatro microetapas contra la adulación. Cada paso bloquea una clase de errores propia: si te saltas uno, obtendrás un tipo de fallo previsible.
Este es el razonamiento, siguiendo el método que Anthropic usa para guiar a Claude en su documentación oficial.
Si dejas que Claude pase directamente al código, puedes obtener una solución al problema equivocado. Usa Plan Mode para separar la exploración de la ejecución.
La documentación recomienda un flujo de trabajo de cuatro fases: Explore, Plan, Implement, Commit.
Mi ciclo de 4 pasos es una especialización de la fase Plan para contrarrestar la adulación. De las cuatro fases de Anthropic, amplío una en cuatro microetapas: prohibir las soluciones, buscar precedentes, redactar el plan y revisarlo. El resultado es un plan detallado que después se incorpora a las fases Implement y Commit.
Esto es lo que falla si te saltas cualquiera de los cuatro pasos:
| Paso omitido | Qué ocurre |
|---|---|
| Paso 1 (hechos) | Una solución para el problema de otra persona: Claude adivinó el síntoma a partir de un patrón y se equivocó de dirección |
| Paso 2 (precedentes) | Una solución inventada a partir de «conocimientos generales»: funciona en el caso de referencia y falla en la realidad |
| Paso 3 (plan) | Implementación sin análisis de riesgos: las pruebas fallan, el token de actualización se rompe y te enteras por los usuarios |
| Paso 4 (autoevaluación) | Un plan con dos o tres suposiciones sin fundamento: una biblioteca que no está instalada, una variable no especificada |
La tabla lo deja claro: cada paso bloquea su propia clase de errores. Necesitas los cuatro porque cada uno detecta una categoría distinta. Si la tarea parece tan pequeña que bastan dos, entonces realmente es pequeña y no necesitas Plan Mode.
Cómo encajan plans/, el comando /goal y los siguientes pasos
Puntos clave
Los 4 pasos no existen aislados. Funcionan dentro de un sistema formado por Plan Mode, la carpeta plans/ del repositorio y el comando /goal. Plan Mode proporciona el modo. La carpeta plans/ aporta durabilidad. /goal proporciona automatización. Sin cualquiera de estas tres capas, el ciclo pierde la mitad de su valor.
El ciclo funciona dentro de un sistema que incluye:
- Plan Mode activado (pulsa dos veces Mayús+Tab en Claude Code).
- Una carpeta
plans/en el repositorio para guardar los planes. - Opcionalmente, el comando
/goalpara implementar planes largos de forma autónoma.
En concreto, sobre la carpeta plans/. Después del paso 3, obtienes un archivo plans/2026-05-27-fix-magic-link.md con fases y casillas. Es un artefacto. Ábrelo una semana después y recordarás por qué elegiste ese enfoque. En tres meses encontrarás una tarea similar y lo reutilizarás. En seis meses se lo enseñarás a un colega y le ahorrarás dos semanas de adaptación. La carpeta plans/ forma parte del concepto de «segundo cerebro» en Claude Code.
En concreto, sobre /goal. Después de completar los cuatro pasos y aprobar el plan, sales de Plan Mode y escribes:
/goal ejecuta todas las fases de plans/2026-05-27-fix-magic-link.md,
todas las pruebas de test/auth pasan o detente después de 30 turnos
En una sesión local de Claude Code, mantén la terminal en ejecución, el equipo despierto y la conexión de red disponible. No cierres el portátil salvo que hayas configurado expresamente una forma admitida de mantenerlo despierto. Al volver, revisa el historial: puede mostrar finalización, límite de turnos, una petición de permiso o un error. Un objetivo no garantiza progreso mientras el equipo duerme. Sin el ciclo de 4 pasos, /goal consume tokens en iteraciones inútiles. Con el ciclo de 4 pasos, /goal lleva un plan terminado hasta que las pruebas pasan.
Qué hacer a partir de aquí. Si acabas de empezar con Claude Code, prueba el ciclo con tu próxima tarea no trivial. No una errata. Algo que afecte a 3+ archivos o implique un comportamiento que no entiendas del todo. Toma los prompts anteriores, cópialos y complétalos con tus propios datos. Verás cómo cambia la tasa de reversiones.
Si ya usas Plan Mode, añade una carpeta plans/ a tu repositorio. Acuerda contigo mismo un formato para los nombres de archivo: YYYY-MM-DD-feature-name.md. En un mes tendrás 20–30 archivos; en seis meses, más de cien. Así se construye el segundo cerebro del proyecto: un historial vivo de decisiones. Si quieres profundizar en la gestión del contexto antes del prompt, traté por separado la ingeniería de contexto en Claude Code como disciplina.
Si ya tienes Plan Mode y plans/, prueba /goal con una tarea autónoma. Elige una tarea que normalmente harías a mano en 30–40 minutos. Pásala por los 4 pasos, guarda el plan, inicia /goal y deja la terminal y el ordenador despiertos. Para trabajar con ese equipo apagado, utiliza primero una vía remota o en nube configurada expresamente y verifica que la tarea se esté ejecutando allí.
Fuentes
Puedes seguir trabajando con IA en Ailoot.
Más detalles
Preguntas sobre Claude Code
¿Un /goal local sigue trabajando si cierro el portátil?
Solo si el equipo permanece despierto y continúa el proceso de terminal; la suspensión normal puede detener el trabajo local. Mantén el ordenador y la red disponibles o verifica que realmente hayas iniciado la tarea en un entorno remoto o en nube separado.
¿Cuándo compensa el esfuerzo del ciclo de cuatro prompts?
Cuando no están claros el síntoma, los archivos afectados o el enfoque y un cambio equivocado sale caro. Empieza con un síntoma reproducible y las pruebas que faltan, busca fuentes, escribe el plan y comprueba sus supuestos. Una errata simple normalmente no requiere el ciclo.