Las heurísticas invisibles: lo que los seniors saben y no saben explicar

En 1984, un psicólogo llamado Gary Klein se sentó frente a un grupo de comandantes de bomberos veteranos con una pregunta simple: ¿cómo tomáis decisiones cuando un edificio se está quemando?

Todos le dijeron lo mismo: "No tomamos decisiones. Simplemente seguimos el procedimiento."

Klein no se lo creyó. Les pidió que describieran su último incendio complicado. Y lo que descubrió cambió la ciencia de la toma de decisiones para siempre.

Resulta que los bomberos veteranos sí tomaban decisiones (docenas de ellas, a toda velocidad, bajo presión extrema). Pero no lo hacían comparando opciones como dice la teoría clásica. Lo hacen reconociendo patrones. Veían el humo, sentían el calor, oían el sonido del fuego, y su cerebro les devolvía instantáneamente una acción. Sin deliberar. Sin analizar alternativas. Sin siquiera ser conscientes de que estaban decidiendo.

En el 80% de los casos, el primer curso de acción que se les ocurría era el que ejecutaban. Y funcionaba.

Llevo meses pensando en esta investigación. Porque estoy viendo exactamente lo mismo en ingenieros de software.

Los bomberos de las 3 AM

En mi artículo anterior escribí sobre un problema que se está extendiendo en silencio: estamos llenando producción de código que nadie entiende del todo. Código generado por IA, código heredado de ingenieros que ya no están, sistemas cuyo modelo mental se evaporó.

Y mencioné algo que me parecía revelador: los ingenieros con más experiencia resuelven incidentes en estos sistemas más rápido. No porque conozcan el código (no lo conoce nadie). Sino porque tienen algo más.

Desde entonces he estado prestando atención a qué hacen exactamente estos ingenieros cuando se enfrentan a un sistema opaco a las 3 AM. Y he ido identificando patrones que se repiten.

Resulta que hacen lo mismo que los bomberos de Klein.

No comparan opciones. No leen el código línea por línea. No siguen un checklist mental de posibles causas. Miran unas pocas señales, y algo en su cabeza les dice "mira ahí." Y casi siempre aciertan.

Lo llamo heurísticas invisibles (porque ni ellos saben que las tienen).

Conocimiento que no puedes articular

En 1958, el filósofo Michael Polanyi escribió algo que suena simple pero es profundo: "Sabemos más de lo que podemos decir." Lo llamó conocimiento tácito. Es lo que te permite reconocer la cara de alguien entre mil personas sin poder explicar cómo lo haces. Es lo que tiene un cirujano cuando sabe que algo "no pinta bien" antes de que ninguna métrica lo confirme.

Los seniors de ingeniería de software están llenos de conocimiento tácito. Años de ver sistemas fallar de formas específicas les han dejado una biblioteca interna de patrones de fallo. Pero si les preguntas "¿cómo supiste que el problema estaba ahí?", la mayoría te dirá algo como "no sé, era obvio" o "tenía pinta de ser eso."

No es que no quieran explicarlo. Es que literalmente no pueden. El conocimiento tácito, por definición, no se puede articular fácilmente. Se adquiere a través de experiencia, no de instrucción. Se transfiere por observación e imitación, no por documentación.

Y aquí viene el problema.

Lo que he observado que hacen (y no saben que hacen)

Después de prestar atención durante meses, he identificado un puñado de heurísticas que los ingenieros seniors usan repetidamente cuando operan sistemas que no entienden. Ninguno me las describió así (las he extraído observando su comportamiento).

No empiezan por el código. Empiezan por los síntomas. Un junior abre el fichero y empieza a leer. Un senior mira las métricas, los logs, y el comportamiento del sistema desde fuera antes de tocar una sola línea de código. Está construyendo un modelo mental del problema antes de buscar la causa. Está preguntándose "¿qué tipo de fallo produce estos síntomas?" antes de preguntarse "¿qué línea está rota?"

Clasifican antes de investigar. Antes de profundizar, un senior ya ha puesto el problema en una categoría: "esto parece un leak de conexiones", "esto huele a race condition", "esto tiene pinta de timeout en un servicio externo." Esa clasificación, que parece instantánea, es el resultado de haber visto decenas de problemas similares. Es exactamente lo que Klein llama recognition-primed decision: el cerebro reconoce el patrón y devuelve una categoría sin que tú lo pidas conscientemente.

Saben qué ignorar. Esto es quizás lo más importante y lo más invisible. En un incidente, la cantidad de información es abrumadora: logs, métricas, alertas, stack traces, código. Un junior intenta procesarlo todo. Un senior descarta el 80% en segundos. Sabe que ese error en los logs siempre aparece y no significa nada. Sabe que esa alerta es ruido. Sabe que el stack trace le está señalando el síntoma, no la causa. Saber qué ignorar es una heurística que solo se construye viendo muchos falsos positivos.

Formulan hipótesis que pueden falsearse rápido. Un senior no piensa "voy a leer todo el código hasta entenderlo." Piensa "si mi hipótesis es correcta, debería ver X en los logs del servicio Y." Va directo a verificar o descartar. Si falla, formula otra hipótesis. Es el método científico comprimido en minutos, aplicado instintivamente. Klein descubrió que los bomberos hacían exactamente esto: simulaban mentalmente su curso de acción antes de ejecutarlo, buscando señales de que podría fallar.

Navegan por la arquitectura, no por el código. Cuando un senior abre código que nunca vio, no lo lee como un libro de principio a fin. Busca los puntos de entrada, identifica los patrones arquitecturales (¿es un event-driven? ¿hay un pipeline? ¿dónde están los boundaries?), y construye un mapa de alto nivel. Solo después de tener ese mapa baja al detalle. Un junior va directamente al detalle y se pierde.

Usan el tiempo como variable de diagnóstico. "¿Esto empezó de golpe o fue gradual?" es una pregunta que un senior hace casi siempre y un junior casi nunca. La respuesta cambia completamente el espacio de búsqueda. Un cambio abrupto sugiere un deploy, un cambio de configuración, o un threshold cruzado. Un cambio gradual sugiere un leak, una degradación, o un efecto acumulativo. Esa pregunta simple elimina el 50% de las hipótesis posibles.

Por qué esto importa ahora más que nunca

Todo esto existía antes de la IA. Los seniors siempre han sido mejores debuggeando código ajeno. Eso no es nuevo.

Lo que es nuevo es la escala del problema.

Cuando la IA escribe el 30-40% del código, la cantidad de "código ajeno" en producción se multiplica exponencialmente. Ya no es código que escribió un compañero que se fue hace dos años, es código que generó un modelo estadístico que nunca tuvo intención, nunca entendió el dominio, y nunca documentó sus decisiones.

Un artículo reciente en InfoWorld lo describió con precisión: los seniors tienen "memoria arquitectural" (recuerdan el outage causado por un servicio acoplado, recuerdan el debate que llevó a aislar un componente, recuerdan por qué se eligió simplicidad sobre extensibilidad en un módulo específico). La IA no tiene acceso a esa memoria. Y cuanto más AI-driven es el workflow, más valiosa se vuelve esa memoria.

Mientras tanto, la encuesta de Stack Overflow de 2025 muestra que el 45% de los developers dice que debuggear código generado por IA les lleva más tiempo que haberlo escrito ellos mismos. Y el 66% dice que su mayor frustración son las soluciones de IA que están "casi bien, pero no del todo."

Las heurísticas invisibles de los seniors son exactamente lo que necesitas para operar en este mundo. Y hay un problema enorme: nadie las está transmitiendo.

El pipeline roto

Tradicionalmente, las heurísticas se transmitían sin que nadie lo planificara. Un junior se sentaba al lado de un senior durante un incidente. Veía qué miraba primero, qué descartaba, qué preguntaba. Hacía pair programming. Revisaba PRs y aprendía a reconocer patrones. Con los años, acumulaba su propia biblioteca de patrones de fallo.

Ese pipeline se está rompiendo por dos bandas a la vez.

Primero, la IA está absorbiendo las tareas simples que servían de entrenamiento. Los juniors de hoy tienen menos oportunidades de construir modelos mentales de forma gradual porque la IA se come exactamente ese trabajo.

Y segundo, los propios seniors no saben que tienen estas heurísticas. No las enseñan porque no son conscientes de ellas. Cuando Klein preguntó a los bomberos cómo decidían, dijeron "simplemente seguimos el procedimiento." Cuando le preguntas a un senior cómo supo que el problema era un connection leak, te dice "no sé, se veía claramente." No te está ocultando nada. Es que el conocimiento tácito, por naturaleza, es invisible para quien lo tiene.

Hacer visible lo invisible

¿Cómo empezar a transmitir algo que ni siquiera sabemos articular? Klein también trabajó en eso. Desarrolló técnicas como el Critical Decision Method: sentarte con un experto, recorrer un incidente paso a paso, y hacerle preguntas específicas sobre qué vio, qué esperaba ver, y qué habría cambiado su decisión. El objetivo no es que el experto te dé una regla (es que tú, como observador, puedas extraer la regla que él no sabe que está usando).

Creo que podemos hacer algo parecido en ingeniería de software. Algunas ideas que estoy explorando:

Postmortems centrados en el razonamiento. En vez de preguntar solo "qué falló y cómo lo arreglamos," preguntar "¿qué miró primero la persona que lo diagnosticó? ¿Qué descarta? ¿Qué le hizo sospechar de la causa real? ¿Qué habría mirado diferente si los síntomas hubieran sido otros?" Eso convierte cada incidente en una oportunidad de hacer explícitas las heurísticas del senior que lo resolvió.

Debugging en voz alta. Cuando un senior investiga un incidente, que lo haga narrando su pensamiento. No para enseñar, sino para que otros puedan observar el proceso de razonamiento. Es lo más parecido a un aprendizaje de oficio que puedes hacer en software. "Estoy mirando los logs del gateway porque la latencia sugiere que el problema está antes del servicio, no dentro..."

Catálogo de patrones de fallo. Documentar los patrones que tu equipo ve repetidamente. No como documentación técnica formal, sino como heurísticas operacionales: "Cuando la latencia sube gradualmente durante horas, lo primero que miramos es X. Cuando sube de golpe después de un deploy, miramos Y." Hacer explícito lo que los seniors ya saben implícitamente.

Lo que viene después

Estoy convencido de que las heurísticas invisibles van a definir la diferencia entre un ingeniero que simplemente usa IA y uno que puede operar lo que la IA produce. Es la diferencia entre el piloto que confía en el piloto automático y el que sabe volar cuando el piloto automático falla.

Klein demostró que los bomberos expertos no eran más inteligentes ni tenían mejores reflejos. Tenían una biblioteca interna de patrones más rica, construida con miles de horas de experiencia real. Los seniors de software tienen la misma ventaja. Y ahora mismo es una ventaja que se está volviendo crítica, pero que no estamos ni reconociendo ni transmitiendo.

El código gratis no existe. Alguien tiene que operarlo. Y las heurísticas de quien lo opera son lo único que no puede generar un LLM.

Pregunta para ti: ¿Puedes identificar una heurística que uses cuando debuggeas y que nunca has articulado en voz alta? Me encantaría que la compartieras (porque exactamente esa es la que necesitamos hacer visible).