La ‘bug blindness’ según Dan Luu: por qué tu equipo no ve fallos

La observación que incomoda a los equipos

Dan Luu, ingeniero conocido por sus análisis técnicos de larga data, publicó un ensayo que circula con fuerza entre desarrolladores y líderes de producto: bajo el título Bug Blindness, sostiene que ve entre cientos y miles de bugs por semana en productos que sus creadores defienden como «excelentes». La mayoría de las personas con las que habla, dice, no nota nada similar.

La hipótesis de Luu no es que él sea un usuario extraño. Es que los equipos golpean los mismos defectos y simplemente no los registran. Una acumulación de pequeñas adaptaciones inconscientes — gestos del ratón para compensar un sensor sucio, teclas que se presionan en un orden específico para esquivar un fallo, hábitos formados hace años que ya nadie cuestiona — termina por ocultar el problema real, tanto para los usuarios como para los propios creadores del software.

Qué es la «ceguera de bugs», según el propio Dan Luu

Luu describe un patrón repetido: cuando un producto tiene defectos severos, los comentarios internos de la empresa suelen alabarlo; al abrirlo y usarlo, el producto «solo funciona si se aplican varios workarounds no intuitivos». Una persona normal no podría usarlo, y aun así los equipos lo califican como exitoso.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Lo formula así en su texto: «If a product seems severely flawed when I use it, it probably is.» Cuando un evaluador externo detecta defectos severos consistentes con los reportes de usuarios finales, lo más probable es que el producto tenga un problema real, no que el evaluador esté reproduciendo un caso de esquina extraño.

Los ejemplos que cita Dan Luu

Luu evita dar nombres de productos donde trabajó como auditor interno porque el tono podría leerse distinto fuera de contexto, pero comparte tres casos públicos:

Motores de búsqueda bajo prueba. En una serie de consultas que documentó, los principales buscadores devolvieron resultados llenos de spam SEO y sitios que eran directamente estafas. Cuando alguien lo confrontó con resultados de Kagi, los ejemplos que recibió eran igual de malos: spam mezclado con resultados no actualizados. La métrica interna de los fans del producto no coincidía con la experiencia concreta.
Blackboard. El LMS universitario fue, según Luu, el software más ampliamente detestado en sus círculos durante años. La página de Wikipedia recoge que en una encuesta de Amplicate de 2011, 93% de los encuestados dijo odiar a la empresa, y la propia wiki cita a Blackboard como una de las compañías más rechazadas en educación. Aun así, un empleado con el que habló en su juventud estaba genuinamente sorprendido: pensaba que el producto era querido. Luu describe la conversación y la perplejidad que le generó.
Discourse. Uno de los detonantes del ensayo fue conversar con empleados de Discourse que creían que el rendimiento web de la plataforma era excelente. Luu descubrió que el software incluía código que retrasaba deliberadamente la carga real para mejorar métricas como LCP, no para ayudar al usuario sino para inflar el benchmark. Hay un punto en el que «optimizar para el benchmark» se vuelve trampa contra el usuario.

El patrón se repite: la ceguera no se limita al software. Luu menciona el caso de foros de Volvo, donde aficionados defienden la fiabilidad de la marca pese a que los datos públicos la situaban como mediocre durante más de una década, y un jugador de baloncesto cuyas contorsiones son celebradas por su hinchada con el chiste recurrente de «movimiento natural de rebote».

Por qué el sesgo es tan persistente

Luu apunta a un mecanismo concreto. Los programadores son excepcionalmente buenos desarrollando workarounds sin darse cuenta. Cuando un software falla en una secuencia concreta, el ingeniero aprende a evitarla por instinto. La otra cara de la moneda: si el equipo no nota esos workarounds, el fallo permanece invisible.

Él mismo relata un caso de la infancia: la bola de su ratón mecánico estaba sucia y se movía erráticamente. Cuando un amigo intentó usar el equipo, era imposible. Luu había aprendido a mover la mano de forma violenta y contrapesada para corregir el defecto, sin notar que lo hacía. Esa misma clase de adaptación inconsciente opera sobre fallos mucho más profundos en el software moderno: abrir un Google Doc y esperar un segundo antes de escribir el título, desactivar el Wi-Fi antes de iniciar sesión en Windows para esquivar un check de dominio fallido, pulsar Shift para terminar un salvapantallas porque minimiza efectos colaterales.

Una parte enorme de la «alfabetización digital» — apunta Luu — es justamente ese repositorio de hábitos inconscientes que cada persona acumula para sobrevivir software defectuoso. Cuando el equipo lo vive a diario, deja de verse como un problema y empieza a verse como parte del producto.

Dogfooding: la cura incompleta

Una respuesta habitual a la ceguera de bugs es obligar al equipo a usar su propio producto, lo que en la industria se conoce como dogfooding (literalmente «comer tu propia comida»). El término se atribuye a un memo interno de Paul Maritz en Microsoft en 1988, retando a su equipo de LAN Manager a usar más los productos de la propia empresa, según documenta Wikipedia.

Luu concede que dogfoodear funciona mejor que no hacerlo, pero advierte de su límite: mientras los programadores sigan construyendo workarounds inconscientes, el sesgo no se rompe por usar el propio software. La guía de Testomat.io sobre dogfooding, publicada en abril de 2026, enumera los beneficios —mejorar la calidad, validar casos reales, reducir tiempo de salida al mercado— pero asume que el equipo realmente identifica problemas, algo que el ensayo de Luu pone en cuestión.

En contextos corporativos mayores, el dogfooding ha sido políticamente sensible. Tras el incidente de CrowdStrike en julio de 2024, el CEO Adam Meyers compareció ante el Congreso de Estados Unidos y mencionó el aumento del dogfooding como una de las medidas adoptadas para prevenir futuras caídas, según BBC News recogido por Wikipedia. Es decir, una de las salidas públicas más sonadas a un fallo masivo fue pedirle al equipo que use más su propio producto.

Por qué importa más en 2026

El ensayo de Luu tiene casi una década en borrador, pero él mismo lo reactualizó al publicarlo. El contexto que lo hace más urgente: la irrupción de los coding agents.

Según investigación de JetBrains recogida por Analytics Insight en julio de 2026, 90% de los desarrolladores profesionales usan coding agents al menos una vez por semana y 68% los usan a diario. Stack Overflow, también citado por ese medio, reporta que 84% de los desarrolladores usan o planean usar herramientas de IA, aunque solo 29% confía en la precisión de su output. La adopción ya no es opcional; la confianza, en cambio, sigue siendo baja.

La velocidad de generación de código que aportan los agentes amplifica exactamente el problema descrito por Luu: más cantidad de código con menos ojos humanos por línea. Un artículo de TechCrunch de mayo de 2026 recoge varios datos preocupantes:

Aiswarya Sankar, fundadora y CEO de Entelligence AI, afirma que las empresas gastan 44% de sus tokens en arreglar bugs que su propia IA generó. La cifra es de su interés comercial, pero apunta a un patrón consistente con el sesgo de Luu.
La herramienta de code review CodeRabbit asegura haber analizado pull requests open source y encontrado que el código producido por IA tiene 1.7 veces más problemas que el código humano. También es dato de un vendedor, pero coincide con la advertencia.
Investigadores de la Singapore Management University publicaron en abril de 2026 un informe advirtiendo que «el código generado por IA puede introducir costos de mantenimiento a largo plazo en proyectos de software reales».
James Shore, autor y programador, lo resumió en un post viral en Hacker News: «You write code twice as quick now? Better hope you’ve halved your maintenance costs. Otherwise, you’re screwed.» Si no reduces a la mitad el costo de mantenimiento, estás cambiando velocidad temporal por servidumbre permanente.

METR, laboratorio de investigación en IA, intentó en febrero de 2026 repetir un experimento de productividad y no pudo: los desarrolladores se negaron a participar si no podían usar IA, según TechCrunch. La velocidad del coding agent se ha vuelto condición de trabajo, no herramienta opcional.

Qué significa esto para tu startup

Bug blindness no es un defecto moral ni de inteligencia. Es un sesgo cognitivo con mecanismos claros, y por eso es atacable. Luu cuenta que ha logrado «curarlo» en varios colegas simplemente señalando defectos que no habían visto; semanas después, esas personas empiezan a detectar bugs por su cuenta. Lo que funciona:

Mide, no opines. La calidad subjetiva del equipo casi nunca coincide con la calidad objetiva del producto. Sustituye el «se siente bien» por métricas: tasa de bugs abiertos en producción, tiempo medio de resolución, errores por cada mil líneas, NPS por versión. Publica esos números internamente, sin maquillaje, como hace la guía de Testomat.io con sus recomendaciones de feedback loops.
Separa dogfooding de auditoría. Que el equipo use el producto es sano, pero no detecta lo que ya está acostumbrado a evitar. Programa sesiones de «usuario nuevo» quincenales: alguien que no haya tocado la feature abre la app en frío y narra lo que ve en voz alta, mientras otro toma nota. Es la única forma de exponer los workarounds inconscientes que Luu describe.
Asume que los coding agents heredan la ceguera. Si tu equipo ya tenía sesgos de calidad, la IA los va a amplificar. Stack Overflow reporta que solo 29% de los desarrolladores confía en el output de IA, y JetBrains confirma que 90% ya lo usa semanalmente: esa brecha entre adopción y confianza es tu ventana de oportunidad. Invierte en code review humano sobre el código generado, métricas de regresión y tests E2E que fallen de verdad, no que pasen por inercia.

El argumento de Dan Luu es incómodo porque sugiere que la confianza de un equipo en su propio producto puede ser, en sí misma, una señal de alarma. En 2026, con agentes escribiendo más código del que cualquier humano revisa, mirar los propios defectos dejó de ser opcional.