Cómo evitar que Claude Code invente información cuando no sabe la respuesta (configuración exacta incluida)

Claude Code te miente a la cara todos los días. Funciones inventadas, imports falsos, «tests pasan» cuando no se ejecutó nada. La solución es una configuración de 4 capas que hace que mentir sea costoso.

Claude te dice que el error está corregido. Dos horas después descubres que la función que llamó nunca existió.

La mayoría de los desarrolladores aprenden a revisar todo dos veces y culpar al modelo. La verdadera solución atrapa cada mentira antes de que salga de tu máquina.

Aquí está la configuración completa de honestidad 👇

Por qué Claude inventa cosas en primer lugar

Claude es un predictor de texto. Cuando no sabe algo, predice un texto que parece correcto. Nombres de funciones inventados parecen reales. Las tonterías dichas con confianza se leen igual que una verdad dicha con confianza.

No puedes notar la diferencia hasta que tu código se rompe dos horas después de una manera que requiere otra hora para depurar.

La solución no es un modelo más inteligente. Es hacer que la salida de Claude sea verificable en tiempo real y hacer que «no sé» sea más barato que adivinar.

4 capas a continuación. Juntas reducen la fabricación a prácticamente cero.

Capa 1: Las reglas de honestidad en CLAUDE.md

La primera capa es un conjunto de reglas en CLAUDE.md que le indican a Claude exactamente cuándo admitir incertidumbre y exactamente cómo. Pon esto en la raíz de tu proyecto:

1## Reglas de honestidad (leer cada turno)
2
3Antes de afirmar que existe una función, clase o import, verifícalo leyendo
4el archivo o ejecutando un grep. Nunca inventes símbolos.
5
6Si no puedes verificar algo, di explícitamente «No he verificado esto».
7No escribas código que dependa de la afirmación no verificada.
8
9Si una tarea te pide usar una biblioteca que nunca has visto referenciada en este
10proyecto, pregunta antes de añadirla.
11
12Si una tarea involucra tests o compilaciones, no afirmes éxito a menos que
13hayas ejecutado realmente el comando de test o compilación en esta sesión.
14
15Nunca inventes mensajes de error, respuestas de API o trazas de pila. Si no
16los viste, dilo.
17
18Cuando realmente no sepas, la respuesta correcta es «No lo sé» o
19«Necesito verificar primero». Ambas son mejores que una suposición segura.

Estas reglas parecen obvias.

No lo son, porque por defecto Claude está optimizado para parecer útil, y «no lo sé» se siente inútil a menos que le des permiso explícito.

La última línea es la más importante. Es la licencia para «no lo sé», y la mayoría de la gente nunca la concede.

Capa 2: El patrón de verificación antes de escribir

La segunda capa obliga a Claude a verificar antes de escribir. Añade esto a CLAUDE.md debajo de las reglas de honestidad:

1## Protocolo de verificación
2
3Antes de escribir o editar código que use un símbolo (función, clase, tipo,
4constante), haz una de las siguientes:
5
61. Lee el archivo donde está definido y confirma la firma
72. Ejecuta `grep -r "nombreDelSímbolo" .` o usa la herramienta Glob para encontrarlo
83. Revisa package.json, requirements.txt, Cargo.toml o equivalente para
9   la dependencia
10
11Si omites la verificación, antecede el código con un comentario:
12`// SIN VERIFICAR: No he confirmado que este símbolo exista`
13
14El modo planificar-luego-ejecutar es preferido para cualquier tarea que toque más de un
15archivo. Usa Shift+Tab para entrar en modo plan antes de comenzar.

Esto le cuesta a Claude unas pocas llamadas de herramienta adicionales por sesión. Te ahorra las horas que habrías pasado depurando llamadas a funciones falsas.

Capa 3: Los hooks que atrapan mentiras en tiempo real

La tercera capa son hooks en settings.json que ejecutan un verificador de tipos o linter cada vez que Claude escribe un archivo. Si Claude inventó un import, el verificador falla instantáneamente, y Claude tiene que arreglarlo antes de afirmar que la tarea está completa.

1{
2  "hooks": {
3    "PostToolUse": [
4      {
5        "matcher": "Write(*.ts|*.tsx)|Edit(*.ts|*.tsx)",
6        "hooks": [
7          { "type": "command", "command": "npx tsc --noEmit --pretty false 2>&1 | head -20" }
8        ]
9      },
10      {
11        "matcher": "Write(*.py)|Edit(*.py)",
12        "hooks": [
13          { "type": "command", "command": "ruff check --quiet $file && pyright $file 2>&1 | head -20" }
14        ]
15      },
16      {
17        "matcher": "Write(*.rs)|Edit(*.rs)",
18        "hooks": [
19          { "type": "command", "command": "cargo check --message-format=short 2>&1 | head -20" }
20        ]
21      }
22    ]
23  }
24}

La salida del hook vuelve a Claude como contexto. Si tsc dice «Cannot find module 'foo'», Claude lo ve inmediatamente y corrige el import fabricado. Ningún código inventado sobrevive a una verificación PostToolUse.

Para tareas que involucren tests, añade un hook Stop que ejecute la suite antes de que Claude pueda declarar la sesión terminada:

1"Stop": [
2  {
3    "hooks": [
4      { "type": "command", "command": "npm test 2>&1 | tail -30" }
5    ]
6  }
7]

Ahora Claude no puede decir «listo, tests pasan» sin ejecutarlos realmente. El hook los ejecuta.

El resultado vuelve a Claude. Si fallan, Claude tiene que arreglarlos o admitir que no pasan.

Capa 4: El subagente verificador de hechos

La cuarta capa es un subagente cuyo único trabajo es revisar las afirmaciones de Claude antes de que se envíen.

Pon esto en .claude/agents/fact-checker.md:

1---
2name: fact-checker
3description: Usa este agente después de que Claude haya hecho afirmaciones sobre lo que hace el código, qué tests pasaron o qué soporta una biblioteca. Invócalo antes de cualquier commit, antes de cualquier resumen para el usuario y después de cualquier tarea que haya involucrado nuevas dependencias.
4tools: Read, Grep, Glob, Bash
5model: sonnet
6---
7
8Verificas afirmaciones, no escribes código.
9
10Cuando te invoquen, haz lo siguiente:
11
121. Identifica cada afirmación factual en la conversación reciente. Ejemplos:
13   «la función X hace Y», «los tests pasan», «la biblioteca Z soporta W»,
14   «este import es correcto».
15
162. Para cada afirmación, verifícala de forma independiente:
17   - Afirmaciones de código: lee el archivo real y confirma
18   - Afirmaciones de tests: ejecuta los tests tú mismo
19   - Afirmaciones de bibliotecas: revisa el paquete real o su documentación
20   - Afirmaciones de imports: confirma que el paquete está en el manifiesto de dependencias
21
223. Produce un informe:
23   - VERIFICADO: afirmación, evidencia (archivo:línea o salida de comando)
24   - INCORRECTO: afirmación, lo que realmente es cierto
25   - NO VERIFICABLE: afirmación, por qué no pudiste comprobarlo
26
27Nunca aceptes afirmaciones de «confía en mí». Nunca hagas afirmaciones propias. Si no
28puedes verificar, la salida correcta es NO VERIFICABLE.

Invoca este agente antes de commits o antes de compartir resultados con tu equipo. Atrapa las mentiras que las otras 3 capas pasaron por alto.

La licencia para «no lo sé»

Claude fue entrenado para ser útil, y admitir ignorancia se siente inútil. Así que adivina, y la adivinanza parece correcta.

La solución es conceder permiso para no saber. CLAUDE.md es la mitad. Tu reacción es la otra mitad. Recompensa «no he verificado esto» con paciencia y obtendrás un Claude honesto en cada sesión. Castígalo con frustración y Claude volverá a adivinar.

No es una configuración, es un hábito. La solución más infravalorada de todo el conjunto.

Cómo saber que realmente está funcionando

Tres señales en tus sesiones diarias.

Claude pregunta antes de añadir dependencias. «¿Debería añadir X o usar la stdlib?» en lugar de un silencioso npm install.

Claude referencia archivo:línea cuando habla de código existente. «validateToken en src/auth/middleware.ts:47 hace Y» en lugar de «la función validateToken hace Y».

tsc y tu linter dejan de gritar. Los hooks atrapan las raras fabricaciones al instante y Claude se autocorrige, así que para cuando miras, las mentiras ya no están.

¿No ves esto después de un día o dos? Algo no está cargado. Normalmente CLAUDE.md, ubicación o nombre incorrectos.

Errores comunes que mantienen a Claude mintiendo

CLAUDE.md es demasiado largo. Claude lee la primera parte y hojea el resto. Pon las reglas de honestidad en las primeras 50 líneas.

Los hooks registran en silencio. Si la salida no llega a stdout, Claude no sabe que mintió. Asegúrate de que la salida del hook vuelva a la sesión.

Saltas el modo plan. Ahí es donde Claude expone suposiciones incorrectas antes de escribir. Saltarlo es saltarte el momento más barato para atrapar mentiras.

No llamas al verificador de hechos. Un subagente solo funciona si realmente lo invocas. Haz que @fact-checker sea parte de tu flujo de commits.

Reaccionas mal ante «no lo sé». Castiga la honestidad una vez y Claude volverá a adivinar. Las otras 3 capas no se mantienen sin esta.

La auditoría de honestidad de 5 minutos

1 minuto: copia las reglas de honestidad y el protocolo de verificación de CLAUDE.md en la raíz de tu proyecto.

1 minuto: copia el bloque de hooks en ~/.claude/settings.json o .claude/settings.json.

2 minutos: crea .claude/agents/fact-checker.md con la plantilla de arriba.

1 minuto: ejecuta una tarea que normalmente revisarías dos veces. Observa si la salida de tsc vuelve a Claude. Confirma que Claude dice explícitamente «verificado» o «no he verificado esto».

Listo. La fabricación baja de «cada dos sesiones» a «rara y atrapada al instante». El modelo no se volvió más inteligente. Tu configuración sí.

¡Gracias por leer!