La fluidez no es verdad Imagen: generada por IA

Le pedí a una IA que investigara algo, y volvió con una respuesta pulida, estructurada, segura — y equivocada de una manera que solo detecté por accidente. Mi primera reacción fue: ¿la estoy usando mal? La literatura dice que no. No notarlo es el resultado por defecto incluso para las personas cuidadosas, y la solución no es la vigilancia. Es convertir la incomodidad en algo que una máquina pueda verificar.

La heurística de fluidez que los LLM rompieron

Los humanos funcionan con un atajo barato: si algo es fácil de procesar, probablemente sea verdad. Los psicólogos la llaman la heurística de fluidez, y durante la mayor parte de la historia fue una apuesta razonable — un orador que suena articulado, seguro y coherente suele ser más competente, porque producir ese tipo de discurso bajo restricciones humanas es difícil de fingir por mucho tiempo. Los LLM son los primeros oradores producidos en masa que rompen esa correlación. La fluidez ahora no le cuesta nada al modelo. La confianza es una distribución de tokens, no una señal de comprensión verificada.

La brecha aparece directamente en cómo la gente califica el resultado de la IA: dada la misma respuesta, la gente la juzga como más segura cuando se le dice que proviene de una IA que cuando se le dice que proviene de un humano (phys.org, 2026-05). El modelo no se volvió más seguro de sí mismo. Lo hizo el prior del lector.

Los expertos no están exentos

Si esto fuera un problema de inexperiencia, la formación lo resolvería. No lo hace.

Los médicos que ya habían sido entrenados en diagnóstico asistido por IA seguían sin filtrar recomendaciones de LLM que sonaban plausibles pero eran incorrectas — el sesgo de automatización sobrevivió a la formación que se suponía debía inocular contra él (medRxiv, 2025-08). Ese es el mecanismo, y es peor de lo que parece, porque los errores que se cuelan no son del tipo fácil. Los errores de nivel interpretativo son más difíciles de detectar que los factuales — un nombre equivocado o una fecha equivocada destaca; un marco equivocado no, porque suena plausible y encaja con la narrativa que el lector ya esperaba (Not Wrong, But Untrue, arXiv:2509.25498). El conocimiento del dominio detecta hechos. No detecta de forma fiable el encuadre.

Debajo de ambos hallazgos hay una brecha de calibración: los LLM reportan un nivel de confianza que excede sistemáticamente su precisión real. Medido en once modelos y seis conjuntos de preguntas, la confianza declarada promedio fue del 88% frente a una precisión real del 79% (Confidence Calibration in Large Language Models, arXiv:2605.23909). El modelo no miente sobre estar seguro. Está mal calibrado, y esa mala calibración se lee como autoridad.

Sentirse más rápido mientras se es más lento

La demostración más clara de que esto no es un problema de conocimiento viene del estudio de METR de 2025 sobre desarrolladores experimentados de código abierto — 16 desarrolladores, 246 tareas reales, repositorios con un promedio de más de un millón de líneas de código. Estas no son personas que confían en la IA ingenuamente. Trabajan en código de producción todos los días.

  • Esperaban que la IA los hiciera un 24% más rápidos.
  • Se midió que fueron 19% más lentos.
  • Después de terminar las tareas — con el costo real de tiempo ya detrás de ellos — seguían creyendo que habían sido 20% más rápidos.

La ilusión persistió incluso después de que la tarea ya había terminado y había sido cronometrada. Esa es la parte que vale la pena detenerse a considerar: la experiencia sentida no es evidencia, y no se autocorrige. Un estado de “se siente productivo” — funcional, entregable — puede persistir de forma estable incluso cuando, de manera medible, no es productivo, y ninguna cantidad de haberlo vivido lo arregla por sí sola.

Para ser precisos sobre lo que este estudio puede sostener: dieciséis desarrolladores es una muestra pequeña, y el propio METR es explícito en que el resultado es específico del contexto — mantenedores experimentados, bases de código maduras de un millón de líneas que conocían a fondo — y no debería extenderse a “la IA ralentiza a todo el mundo”. Así que no lleves el 19% a ningún otro lado como estimación puntual. En lo que se apoya este argumento no es en la magnitud sino en el signo de la brecha: el efecto medido fue negativo, el efecto percibido fue positivo tanto antes del trabajo como después, y la estimación promedio posterior aterrizó cerca de la expectativa previa, en ningún lugar cerca de la medición. Si la autopercepción fuera simplemente ruidosa, las estimaciones posteriores se dispersarían alrededor de la verdad medida. No lo hicieron. Se quedaron donde estaba la expectativa.

Por qué colapsó la economía de la verificación

Antes de los LLM, juzgar la calidad de un resultado mirando el resultado era un proxy razonable para juzgar la competencia de quien lo produjo — ambas cosas estaban correlacionadas, porque el trabajo descuidado venía de una producción descuidada. Los LLM cortaron ese vínculo. La calidad del resultado y la competencia del productor ya no están acopladas, lo que significa que la evaluación basada únicamente en el artefacto dejó de funcionar como diagnóstico (Fluent, Confident, Wrong, ScienceDirect 2026). Verificar se volvió más caro que producir.

Peor aún, el costo de un error no es proporcional a la tasa de error. Cuando las partes equivocadas se leen exactamente igual que las partes correctas — mismo registro, misma confianza, mismo pulido — no puedes localizar el daño, así que un pequeño porcentaje de contaminación no te cuesta un pequeño porcentaje. Envenena todo el conjunto: cada afirmación del resultado ahora carga con la sospecha de la peor de ellas. Por eso “el modelo acierta el 95% de las veces” no es el número tranquilizador que parece. La confianza colapsa de forma discontinua mucho antes de que lo haga la precisión.

Casi nadie actualizó sus hábitos de verificación para estar a la altura — que es exactamente la brecha sobre la que está construido el argumento del Ratchet Pattern de este sitio: la generación puede seguir siendo probabilística, pero la verificación sobre ella no puede serlo.

No es mal uso — es el comportamiento por defecto de la población

Entonces: ¿la estoy usando mal? La literatura dice lo contrario. La definición de manual del mal uso es tratar la fluidez como una señal de confianza y desactivar la verificación — y eso no es un caso extremo, es a lo que por defecto recurre la mayoría de la gente, incluida la entrenada. Los médicos del estudio sobre sesgo de automatización no se aferraron a su propia señal de desacuerdo. Tampoco lo hicieron los desarrolladores del estudio de METR. Si mantenerse suspicaz frente a una respuesta fluida y aparentemente infalsable se siente como paranoia, vale la pena notar que eso ya te pone por delante de la mayor parte de la población medida — incluidos aquellos cuyo trabajo era específicamente detectar esto.

Esto no es una observación nueva para este sitio — es el mismo territorio al que llegan tanto la sicofancia como característica de negocio como por qué los agentes funcionan y por qué se rompen: el modo de falla es estructural, no un desliz personal de atención, y ninguna cantidad de “simplemente ten más cuidado” escala contra él.

El único arreglo

Hay exactamente un ajuste que importa aquí: no te quedes en la sensación de inquietud. Conviértela en un criterio de aceptación observable, y fija ese criterio antes de que empiece el trabajo, no después. La sensación no se autocorrige — METR lo demostró directamente —, pero la medición sí.

“Convertir” es un procedimiento, no un estado de ánimo. Para cualquier afirmación estructuralmente relevante — una que esté a punto de moldear una decisión — responde dos preguntas antes de aceptarla:

  1. ¿Qué tendría que ser cierto para que esto se sostenga? El resultado fluido rara vez expone sus premisas; las disuelve en el marco, que es exactamente por lo que el conocimiento del dominio resbala sobre él. Esta pregunta arrastra la premisa oculta hasta el nivel de una afirmación, donde por fin puede ser atacada.
  2. ¿Qué observaría si esto fuera falso? Esto obliga a la afirmación a apostar algo en el mundo. Una conclusión que no implica ninguna diferencia observable respecto de su propia negación no es conocimiento — es coherencia, y la coherencia es lo que un modelo optimiza cuando no hay nada en juego.

Para código generado por IA, ambas preguntas se comprimen en un único espacio en blanco, que se rellena antes de que el código exista: “Si esto es útil, entonces inmediatamente después de publicarse, un usuario puede ___.” El espacio en blanco debe nombrar una acción en el mundo del usuario, no en el del código — una compilación limpia y una ejecución en tiempo real sin errores son comprobaciones de coherencia, no comprobaciones de utilidad. Y si no puedes llenar el espacio en blanco, ese es el resultado más valioso de todo el procedimiento: significa que todavía no sabes qué pediste, y la respuesta fluida estaba a punto de ocultártelo.

Todo lo demás en la literatura de mitigación — separar el lenguaje seguro del hecho verificado, descomponer el resultado en unidades verificables de forma independiente, introducir fricción antes de que llegue la respuesta fluida — es esta misma conversión aplicada en capas distintas.

“¿No es esto simplemente escepticismo con otro nombre?”

La objeción obvia: “verificar antes de confiar” es lo que el escepticismo siempre ha significado, así que ¿qué hay realmente de nuevo aquí? La respuesta es cuándo ocurre el juicio, y el momento es todo el mecanismo.

El escepticismo es una postura que aplicas mientras miras el resultado — y cada estudio mencionado arriba es una medición de exactamente esa postura fallando. Los médicos no eran crédulos; habían sido entrenados en diagnóstico asistido por IA — la intervención que se supone instala exactamente esta postura — y estaban mirando directamente las recomendaciones. Las recomendaciones los desarmaron de todos modos, porque un artefacto fluido modula el juicio que se le aplica — eso es precisamente lo que es la heurística de fluidez. Un criterio fijado antes de que exista el resultado no tiene ningún artefacto fluido por el cual dejarse desarmar. No hay nada sobre lo que la confianza pueda trabajar, porque la prueba quedó fijada en un punto en el tiempo que el resultado no puede alcanzar.

La ciencia institucionalizó el mismo movimiento por la misma razón. El preregistro no existe porque los revisores carezcan de escepticismo; existe porque un investigador que mira datos ya recolectados puede racionalizar cualquier resultado con fluidez, así que el campo trasladó la hipótesis a antes de los datos. Si esta distinción fuera vacía — si el escepticismo posterior funcionara tan bien como los criterios previos —, entonces los evaluadores entrenados filtrarían las malas recomendaciones a tasas altas. Ese es precisamente el experimento que hizo el estudio sobre sesgo de automatización, y salió negativo.

“La verificación cuesta más que la producción — ¿quién puede pagarla?”

La objeción más afilada: si verificar un resultado cuesta más que generarlo, entonces “verifica antes de confiar” es el consejo de ser más lento que todos los demás, y la mayoría de las decisiones reales no pueden costearlo. Esto malinterpreta la propuesta dos veces.

Primero, el criterio no es la verificación. Escribir lo que observarías si la afirmación fuera falsa cuesta una frase, y el costo de verificar solo se paga sobre las afirmaciones que son estructuralmente relevantes. Un observable preespecificado también es mucho más barato de comprobar que auditar un artefacto fluido de forma abierta — la mayor parte del costo de la verificación posterior no es la comprobación en sí, es no saber por dónde empezar, y el criterio es precisamente lo que colapsa ese espacio de búsqueda.

Segundo, saltarse la verificación no elimina el costo — lo traslada río abajo y lo saca de la contabilidad. Los desarrolladores de METR no evitaron pagar; el costo apareció en el tiempo medido mientras su contabilidad sentida registraba una ganancia. Esa es la comparación que la objeción entiende mal. No es “verificación contra gratis”. Es verificación ahora, con precio y visible, contra absorción del error después, sin precio y contabilizada como ganancia.

Escribe al revisor como código

El procedimiento de dos preguntas de arriba todavía tiene un punto débil: depende de que alguien recuerde ejecutarlo. Es el mismo fallo repetido un nivel más arriba. Una disciplina que solo vive en la cabeza de una persona se degrada exactamente igual que la inquietud — nítida en la primera lectura cuidadosa, desaparecida en la décima lectura fluida. La forma duradera de “conviértelo en un criterio de aceptación observable” no es un hábito. Es un paso de compilación: entrégale el criterio a una máquina y haz que el pipeline se niegue a pasar sin él.

Esto no es hipotético — es lo que sirvió de compuerta al artículo que estás leyendo. Reins es un framework de código abierto construido exactamente para esto: cada criterio de aceptación se convierte en una quest, una regla que evalúa un Fact{Where, Expected, Actual} y reporta éxito o fracaso sin preguntar nunca si la prosa que lo rodea suena convincente. Antes de que existiera una sola frase de este texto, un humano anotó las afirmaciones concretas que tenía permitido hacer; una máquina cotejó el borrador contra esa lista; y quien revisó la cobertura de las afirmaciones trabajó desde un contexto separado del que escribió el borrador, porque autorrevisarse no es revisar — abloq, el sistema de quests con el que funciona este sitio, codifica eso como una regla, no como una petición.

Ese es el contenido real de “no te quedes solo en la sensación”. No se trata de más vigilancia — sino de un lugar en el pipeline donde la vigilancia deja de ser la dependencia. Las dos preguntas de la sección anterior — qué tendría que ser cierto, qué la falsearía — dejan de ser algo que hay que recordar preguntar en cuanto se convierten en una regla de compuerta en vez de una nota mental. Una quest no se cansa en la décima lectura.

Artículos relacionados

Referencias

Registro de cambios

  • 2026-07-09: Publicación inicial