Hoy, cuando una aplicación o un algoritmo se comporta de forma extraña, la primera reacción suele ser mirar el código, las librerías, los logs o el framework de turno. Es lógico: las herramientas actuales nos lo ponen fácil. Sin embargo, en no pocos casos el fallo no está ahí. Está más atrás: en los datos de entrada, en la forma en que se representan, en una variable que nadie está contemplando o en una interacción que el sistema no estaba preparado para manejar. Y es precisamente en ese momento cuando se nota una diferencia de enfoque.
No se trata de restar valor a los profesionales más jóvenes. Al contrario: la generación actual está muy preparada, domina lenguajes, frameworks y metodologías que hace décadas ni existían, y es capaz de construir sistemas de una complejidad y escala que en su momento resultaban inimaginables. El punto es otro. Tiene que ver con el tipo de entrenamiento al que obligaban las restricciones técnicas de los años setenta y ochenta.
En 1975, trabajar en un mainframe IBM 370 con 512 KB de RAM no era una experiencia «rústica». Era una escuela de análisis. El espacio era carísimo. Cada byte importaba. Las fechas, por ejemplo, no se almacenaban como «12 de junio de 1976». Se codificaban de la forma más compacta posible (12/6/76) y, cuando hacía falta mostrarlas en claro, se convertían mediante rutinas en Assembler. Todo el ciclo —diseño, codificación, compilación, prueba, corrección— pasaba por las mismas manos, con la única excepción de la perforación de las tarjetas. No había depuradores visuales, ni mensajes de error amables, ni repositorios de soluciones ya hechas. Si algo fallaba, tenías que reconstruir mentalmente el estado del sistema: qué datos entraban, cómo se representaban, qué límites de memoria se estaban rozando y dónde podía haberse producido la desviación.
Esa obligación de contemplar muchas variables a la vez deja una huella. No desaparece cuando el hardware se multiplica por miles y las abstracciones hacen el trabajo sucio. Se convierte en una forma de mirar los problemas. Ante un comportamiento anómalo, la primera sospecha no siempre es «el código está mal». A veces es «esto me huele a un problema de datos de entrada», o a una representación incompleta, o a un caso límite que nadie había contemplado porque el entorno actual lo oculta. No es intuición mágica. Es reconocimiento de patrones formado cuando eras responsable de casi todo el sistema.
Da igual lo sofisticado que sea el proceso: si la entrada es errónea, la salida también lo será.
Esta idea conecta con algo que ya comenté sobre la ley de Entrada, Proceso, Salida. Lo que añado aquí es el otro lado de esa misma moneda: no solo que el dato de entrada importa, sino que hay una forma de mirar, entrenada por la escasez, que te lleva a sospechar de él antes que de ninguna otra cosa.
Hoy las abstracciones son extraordinariamente potentes. Nos permiten avanzar a una velocidad que antes era impensable. Pero también tienen un efecto secundario: reducen la necesidad de mantener el modelo mental completo. Muchas variables que antes había que vigilar de forma consciente ahora quedan encapsuladas. El riesgo es que, cuando el sistema falla de forma no trivial, esas variables reaparecen… y quien no está acostumbrado a buscarlas tarda más en encontrarlas.
La experiencia de haber trabajado bajo restricciones extremas no garantiza, por sí sola, mejores soluciones. Pero sí suele entrenar una disciplina de análisis que sigue siendo valiosa. Una disciplina que no mira solo el código que se ejecuta, sino el conjunto de condiciones que hacen que ese código se comporte de una manera u otra.
En un momento en el que las herramientas son cada vez más potentes y las abstracciones más altas, recuperar esa mirada —la que obliga a preguntarse qué variables están realmente en juego— no es nostálgico. Es práctico. Tanto si tienes veinticinco años como si llevas cincuenta programando.
Con la inteligencia artificial, esta lección se vuelve todavía más urgente, no menos. Un modelo de IA es, en el fondo, la abstracción definitiva: encapsula millones de variables detrás de una respuesta que parece segura de sí misma. Cuando algo falla —una desviación, un sesgo, una recomendación absurda—, la tentación es mirar el modelo, ajustar el prompt, cambiar de versión. Pero quien tiene entrenada esa mirada antigua sabe que, casi siempre, conviene preguntarse primero qué datos entraron ahí y cómo se representaron, antes de sospechar de nada más. La IA no ha cambiado esa lección. Solo ha subido la apuesta.
