Bias de automatización — por qué confías en Claude más que en tu colega senior

Si tu compañero senior te suelta “esta función es thread-safe, fíate de mí”, le preguntas por qué. Cuando Claude te dice exactamente lo mismo, apruebas el pull request en ocho segundos.

Esa asimetría tiene nombre técnico: bias de automatización. En 2026 le está costando bugs en producción a la mitad de los equipos que usan asistentes de IA para escribir código.

Los tres sesgos que aparecen cuando metes un LLM en tu revisión, con una lista concreta para cada uno. Es lo que hago yo antes de dar el visto bueno a código de Claude o Copilot.

Por qué el LLM se lleva menos escrutinio que el humano

El bias de automatización es la tendencia a sobreestimar las respuestas de un sistema automatizado. Se empezó a estudiar en aviación en los noventa: pilotos que ignoraban lo que veían por la ventana porque el piloto automático “sabía más”. Ahora nos pasa con LLMs, en el editor.

El informe de Georgetown CSET de 2024 lo documentó desde los coches autónomos hasta la revisión de código. La lista OWASP Top 10 for LLM Applications lo llama Overreliance y lo mete en el top 10 de riesgos.

El estudio de METR de 2025 midió algo más incómodo: los desarrolladores con experiencia usando IA decían sentirse más rápidos, pero cuando alguien cronometraba las tareas de verdad, tardaban más. Ahí, en el hueco entre “me siento productivo” y “soy productivo”, es donde se cuela el sesgo.

Hay una razón mecánica: el LLM habla como si supiera. Prosa de enciclopedia, tono seguro, sin titubeos. Tu cerebro procesa eso como autoridad. Un compañero humano suele decir “yo creo que…”. Claude dice “esta es la mejor implementación”. A ver cuál de los dos pasa antes la revisión.

Los tres sesgos donde se cuela el 90% de los bugs de IA en producción

Sesgo 1. Automatización: “si el LLM lo generó, algo sabe”

Síntoma: apruebas código de Copilot en menos de 10 segundos sin mirar los edge cases.

Ejemplo real: pediste una query SQL para un informe de ventas. El LLM devuelve un SELECT sin LIMIT. La integras sin pensarlo. En producción devuelve 400.000 filas, el backend se cae y se te va la tarde.

Lista práctica:

1. Antes de mirar el resultado del LLM, escribe en 30 segundos qué esperas ver (firma de la función, condiciones principales)
2. Compara: ¿coincide con lo que esperabas? Si algo no cuadra, investiga por qué antes de aceptar
3. Para código que va a producción, ejecuta al menos un test escrito por ti antes de aceptar el que te propone el LLM

El paso 1 es el que más te salva. Anclarte a tu propia expectativa antes de leer la del LLM te recupera el juicio crítico.

Sesgo 2. Anclaje: “ya lo escribió, no voy a rehacerlo”

Síntoma: aceptas la primera sugerencia del LLM aunque haya alternativas mejores, porque cambiar de enfoque implica pensar más.

Ejemplo real: Copilot te propone un try/except con pass vacío. Lo aceptas sin más. Tres semanas después descubres que ese pass llevaba tiempo tragándose un error de red que te ha costado datos.

Investigadores de ICSE vieron que los desarrolladores con LLM barajan menos alternativas que los que trabajan solos. La primera propuesta se te queda como ancla.

Lista práctica:

1. Después de recibir la propuesta del LLM, pídele: “dame 3 alternativas con trade-offs distintos”
2. Elige entre las 4 opciones (la original más 3 alternativas), no des por hecho la primera
3. Si te sorprende una alternativa, es señal de que el ancla te tenía comida la cabeza

Son 15 segundos más. Y cambia bastante cuánto código malo se te cuela.

Sesgo 3. Confirmación: “si le pregunto si es correcto, me dice que sí”

Síntoma: cuando le preguntas al LLM “¿esto está bien?”, te dice que sí. Cuando le preguntas “¿esto está mal?”, te dice que sí también.

Ejemplo real: le preguntaste a Claude “¿esta función es thread-safe?”. Respondió “sí, el Mutex protege el estado compartido”. La desplegaste. Un mes después apareció una race condition en una ruta donde el Mutex nunca se adquiría. Claude no mintió: respondió la pregunta que le hiciste, no la que deberías haberle hecho.

El LLM responde dentro del marco de tu pregunta. Es una máquina de completar patrones. Si preguntas “¿es X?” te contesta “sí, es X, por estas razones”. Si preguntas “¿no es X?” te contesta “correcto, no es X, por estas razones”. La misma máquina, contradiciéndose sola según cómo formules el prompt.

Lista práctica:

1. Invierte el marco: “dame 3 escenarios donde esta función NO es thread-safe”
2. En decisiones de arquitectura, pregúntale: “¿qué enfoque alternativo sería mejor y en qué contexto?”
3. Si vas a preguntar por seguridad, di “¿qué vulnerabilidades podría tener este código?” en lugar de “¿es seguro?”

Se trata de obligar al LLM a hacer de abogado del diablo. Cuando entra en ese modo, encuentra cosas que en modo “confirmación” ni siquiera menciona.

Lo que sale cuando aplicas las tres listas

Llevo unos meses aplicando estas rutinas en mi propio flujo de revisión de código generado por IA. Los patrones que van saliendo:

• Errores de manejo silencioso (catch sin log, valores por defecto peligrosos): cazados antes de merge en 8 de 10 casos
• Race conditions o problemas de concurrencia mal declarados: la técnica de “dame escenarios donde NO es thread-safe” los pilla en la mayoría de casos donde antes se colaban
• Queries SQL sin LIMIT o sin índice: la técnica de “escribe tu expectativa en 30 segundos” los caza antes de que lleguen a producción

Esto no es un estudio con N grande y control aleatorio. Es la experiencia diaria de un desarrollador que se hace responsable de sus propios sesgos antes de culpar al LLM.

Calibra cuánto te fías del LLM

Microsoft publicó en 2024 el concepto de appropriate reliance: confianza calibrada según el tipo de tarea. Ni rechazo total ni fe ciega. Es la habilidad que va a marcar la diferencia entre los senior de 2027.

La forma más práctica de dar con esa calibración: cuando te descubras dándole las gracias al LLM, ya la has perdido. Con una herramienta lo que toca es verificarla. El día que escribí “gracias, Claude” en el prompt fue el mismo día que me di cuenta de que la estaba tratando como si fuera un compañero. Ahí empecé a preocuparme.

Resumen

• Bias de automatización: aceptamos el resultado del LLM más rápido que el humano porque el tono suena a autoridad. Solución: escribe tu expectativa en 30 s antes de ver ese resultado
• Anclaje: la primera propuesta del LLM se te queda como único enfoque en la cabeza. Solución: pídele 3 alternativas
• Confirmación: el LLM responde dentro del marco de tu pregunta. Solución: dale la vuelta al marco: “dame escenarios donde NO funciona”
• El LLM es una herramienta que exige verificación. Si le das las gracias, ya has perdido la calibración

El terreno de los sesgos cognitivos aplicados a la ingeniería es algo que Kahneman y, más recientemente, ACM/IEEE están cartografiando dentro del desarrollo asistido por IA. La survey Coding Beyond Your Training (arXiv 2605.25438) cubre buena parte del estado del arte para 2026 si quieres darle una vuelta más a fondo.

Si trabajas en un equipo que integra Claude Code, Copilot o Cursor en el día a día, el problema no acaba en el LLM: empieza en cómo procesa tu cerebro lo que te dice.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev