Veinte años, de la infraestructura a la pantalla

La medida del trabajo invisible es que solo se juzga cuando falla. Durante veinte años lo aprendí; luego pasé al lado visible.

Las carreras parecen ordenadas vistas hacia atrás. No lo son mientras se viven: cada periodo empieza con un problema que el anterior no supo resolver.

Este texto trata de cuatro periodos. Pero no es un currículum — trata de qué hábito resultó útil en la capa siguiente y cuál hubo que soltar.

2005–2013 — Infraestructura corporativa

Servidores, almacenamiento, copias de seguridad, continuidad.

Si este periodo enseñó una cosa, es esta: un sistema que funciona es invisible mientras funciona. Las copias de seguridad no entran en la agenda de nadie durante años. Luego un día hacen falta, y ese día es el examen de todo lo hecho hasta entonces.

La consecuencia profesional es extraña. El trabajo de infraestructura bien hecho no produce elogios, solo silencio. El elogio llega solo cuando algo falla y la recuperación es rápida — es decir, tu momento más visible es tu peor día.

El hábito que se trajo: escribir el escenario de recuperación antes de la instalación. La primera pregunta al construir un sistema no es «cómo va a funcionar» sino «cómo volvemos cuando se rompa». Que exista una copia no basta; la restauración tiene que haberse ensayado. Una copia sin probar no es una copia.

2013–2019 — Redes y seguridad

Enrutamiento, cortafuegos, acceso.

El trabajo de red enseña a ver un sistema como una topología. No cajas sueltas sino las relaciones entre ellas. Por dónde pasa un paquete, qué regla lo detiene, por qué se prefiere un camino a otro.

La lección más duradera de este periodo no va de seguridad sino de visibilidad: la condición previa para resolver un problema es poder verlo. La mayoría de las averías de red no son misteriosas; solo están sin medir. Pon un contador en el punto correcto y el misterio se disuelve.

La segunda lección va de los valores por defecto. Las reglas del cortafuegos se acumulan con el tiempo; cada una hizo falta una vez, ninguna se retiró jamás. Cinco años después nadie sabe explicar la lista entera. Un equipo que no escribe por qué existe una regla nunca podrá borrarla.

Por eso los comentarios de código que escribo hoy explican «por qué es así», no «qué hace». Qué hace ya está en el código.

2019–2024 — Identidad y M365

Active Directory, migraciones, identidad en la nube. Orden a escala de miles de cuentas.

El trabajo de identidad es una lección de escala. Diez cuentas las gestionas a mano. A miles, todo lo hecho a mano se convierte tarde o temprano en incoherencia — porque el trabajo manual no es repetible.

El hábito que se trajo: una excepción no es una solución, es una deuda. Una regla especial abierta para un usuario permanece en el sistema mucho después de que ese usuario se haya ido. A escala la respuesta correcta no es registrar la excepción sino reescribir la regla para que la excepción sobre.

Los proyectos de migración añaden su propia lección: una migración sin plan de vuelta atrás no es una migración, es una apuesta. Y el plan de vuelta atrás debe ensayarse antes de la migración, no después.

2024 — hoy

Aplicaciones web impulsadas por IA y tecnologías web. Modelos y agentes, vueltos hacia la pantalla con la misma disciplina.

La transición es menos abrupta de lo que parece. Una aplicación web moderna son problemas de sistemas distribuidos en miniatura: gestión de estado, coherencia, recuperación de errores, observabilidad. Los nombres cambian, las preguntas siguen.

La capa de IA, mientras tanto, premia los hábitos de infraestructura de un modo inesperado. Un modelo de lenguaje es un componente incierto: puede devolver salidas distintas para la misma entrada, puede estar equivocado en silencio y falla sin producir un mensaje de error. Es exactamente la clase de fallo sobre la que se trabajó durante años — solo cambió la capa.

Por eso las preguntas que me hago al escribir un agente son las mismas que al montar un servidor: ¿Dónde estoy midiendo? ¿Cómo sabré que ha respondido mal? ¿Cuánto puedo retroceder si se rompe?

La diferencia se agudiza en un punto. Cuando un servidor se rompe, te lo dice: el servicio cae, la monitorización avisa, una línea aterriza en un registro. Cuando se rompe un modelo de lenguaje, produce una frase fluida. El fallo es silencioso y, además, persuasivo.

La consecuencia práctica es que la monitorización clásica no basta. Para un servidor basta «¿está en pie?»; para un modelo hay que preguntar «¿es correcto?» aparte, y esa pregunta no se responde sola. Atar la salida a un suelo verificable — una fuente, un cálculo, una medición — tiene que ser parte de la arquitectura.

Veinte años de hábito encajan aquí exactamente: no confíes en la salida sino en su base.

Qué se trajo

El denominador común de los cuatro periodos son cuatro hábitos:

Los cuatro hacen hoy el mismo trabajo. La suite de verificación de este sitio — la serie de pruebas que se niega a mirar capturas de pantalla y lee la luma del canvas — es producto directo del segundo. Las actas de decisión del repositorio, del cuarto.

El hilo común: un presupuesto de error

Hay un concepto que se repite en los cuatro periodos, aunque su nombre cambie cada vez.

En infraestructura se llamaba «objetivo de disponibilidad». El cien por cien de disponibilidad no existe; lo que existe es decir de antemano cuánta interrupción aceptas. Un equipo que no lo dice repite la misma discusión en cada caída.

En redes se llamaba «latencia aceptable». En seguridad, «riesgo aceptado». En gestión de identidades, «qué excepciones están aprobadas». En el lado del producto, «presupuesto de rendimiento».

Todo es lo mismo: escribir un límite de antemano. Donde no hay límite escrito, cada decisión se convierte en una negociación, y las negociaciones suele ganarlas quien en ese momento habla más alto.

La sección de escritura de este sitio también tiene un presupuesto escrito: mayor renderizado de contenido por debajo de 2,5 segundos, script de página por debajo de 60 KB, ninguna puerta de opacidad delante del texto. Los tres los mide la suite de verificación en cada ejecución. Si se supera el número, la prueba se pone roja — no se abre discusión.

Puede que sea la lección más práctica de veinte años: la buena voluntad no es un mecanismo de control. Un límite o está medido o no existe.

Qué se quedó atrás

Hay cosas que no se trajeron, y soltarlas costó más que cargarlas.

La expectativa de funcionamiento impecable. En infraestructura el objetivo es cero caídas. En el lado del producto un objetivo de cero defectos acaba en no publicar nunca nada. El nuevo criterio dejó de ser «¿no se rompe nunca?» para ser «¿qué pasa cuando se rompe?».

La resistencia al cambio. En la sala de servidores el movimiento más seguro es no moverse; tocar un sistema que funciona es riesgo. En el lado del producto vale lo contrario: lo que no se toca envejece. La misma prudencia debe aplicarse en otra dirección — no impedir el movimiento, sino hacerlo reversible.

Tomar la invisibilidad por virtud. Durante veinte años el buen trabajo fue el trabajo que no se nota. Ese criterio era correcto en su campo pero no se generaliza. Donde existe un campo en el que el trabajo debe ser visible, allí el silencio no es virtud sino ausencia.

Este sitio es el acta de esa diferencia. Durante veinte años construí sistemas que nadie ve; ahora construyo la superficie — y aprendo que la superficie también tiene que ser medible.

Por qué la transición parece fácil y no lo es

La mayoría de quienes pasan de la infraestructura al producto cae en la misma trampa: supone que la competencia técnica es transferible. Lo es — pero por sí sola no basta.

Lo que falta no es técnico. En infraestructura «correcto» suele ser singular: una configuración funciona o no funciona, una copia restaura o no restaura. En el lado del producto lo correcto es plural y depende del contexto. Que una decisión de interfaz sea «correcta» cambia según para quién es y qué debe lograr.

Para un hábito de ingeniería ese es un estado incómodo. La certeza a la que uno está acostumbrado ya no está. En su lugar entra la medición: donde la verdad no es singular, medir qué produce cada opción sigue siendo el único camino honesto.

La segunda carencia: el trabajo invisible no tiene público, el visible sí. Durante veinte años el interlocutor del trabajo fue un sistema. Ahora el interlocutor es una persona, y su paciencia, su atención y su contexto varían. No es un problema a resolver sino una realidad a tener en cuenta.

Una nota

Cada uno de los periodos anteriores contiene hechos concretos que podrían contarse uno a uno: una migración determinada, una noche de avería determinada, una decisión de arquitectura determinada. Este texto no los contiene.

La razón es sencilla: este texto va de disciplinas, no de casos. Los casos merecen textos propios, y cada uno debería llegar con su propia medición — como los demás escritos de esta sección.

Generalizar tiene un riesgo y soy consciente de él: reducir veinte años a cuatro puntos aplana las decisiones reales tomadas en esos años. Explicar de dónde viene un hábito no es lo mismo que explicar cómo se adquirió. Lo segundo lleva más tiempo y exige ejemplos más concretos.

Aun así esta lista tiene una función: fija el terreno sobre el que leerás el próximo texto. Por qué una sección de escritura tan atada a la medición se construyó así se explica con estos cuatro hábitos. El resto está en los casos.