Mascotas: el software que ninguna empresa quiere dejar morir

Durante veinte años tratamos al código como mascota: le pusimos nombre, lo curamos, lo mantuvimos vivo a cualquier costo. ¿Y si siempre fue ganado?

El código tardó tres horas en escribirse. La revisión lleva tres días.

Tres días de un senior leyendo línea por línea lo que un developer y su pair-programmer de IA generaron entre el desayuno y el almuerzo. Y nadie en la sala se anima a decir en voz alta lo que todos sospechan: que esa revisión dejó de ser una garantía y se convirtió en un ritual. Como el mate que cebás por costumbre, no por sed.

Hace unas semanas escribí sobre latencia: las empresas hoy producen más rápido de lo que pueden absorber. Esta escena es la versión de bolsillo de ese problema. La ejecución se aceleró diez veces; el control quedó a velocidad humana. Y cuando el control no escala, hay dos caminos: ponerle más gente al control —que es lo que estamos haciendo, con resultados previsibles— o aceptar que quizás estamos controlando la cosa equivocada.

Para entender el segundo camino, conviene mirar una película que ya vimos.

Nadie llora un container

Hubo una época en que los servidores tenían nombre. Apolo, Zeus, Morpheus. El administrador los conocía uno por uno, sabía cuál se ponía caprichoso los lunes, cuál necesitaba un reinicio con cariño. Cuando uno se enfermaba, se lo curaba a mano, a las tres de la mañana, con la dedicación de quien cuida a un familiar.

Después llegó la infraestructura como código y cambió el verbo. Un container no se arregla: se destruye y se vuelve a crear. Idéntico, o mejor. Martin Fowler les puso un nombre hermoso a esas máquinas que no se reparan: servidores fénix —se queman y renacen de sus cenizas.

En la jerga de aquella transición se hablaba de mascotas y ganado. A las mascotas les ponés nombre y las cuidás cuando se enferman. Al ganado no: si una instancia falla, la reemplazás y seguís. Nos costó muchísimo soltar a las mascotas. Había identidad profesional invertida en saber curar servidores. Pero hoy nadie llora un container. Nadie le hace un velorio a un pod de Kubernetes.

Ahora la pregunta incómoda: durante veinte años tratamos al código como mascota. Lo refactorizamos con cariño, lo documentamos, lo mantuvimos vivo a cualquier costo, porque reescribirlo era carísimo. ¿Y si gran parte de tu código siempre fue ganado, y recién ahora el costo de regeneración lo hace evidente?

El software que renace

Eso es lo que viene: software que no se mantiene, se regenera. Detectás un problema y en lugar de parchar, volvés a generar el módulo desde la especificación, con todo lo aprendido incorporado. Aplicaciones que nacen para una campaña, una migración, un experimento —y mueren sin culpa cuando cumplieron su ciclo. Obsolescencia continua, pero como decisión de diseño, no como deuda técnica.

Suena a herejía. A los que venimos del software "bien hecho" nos rechina. Pero ojo: la herejía no es nueva, es la misma de los containers, una capa más arriba. Y aquella vez los herejes tenían razón.

¿Y la revisión de los tres días? Se transforma. A un container no le revisás los bits: le verificás el comportamiento. Contratos, tests, observabilidad. La confianza se muda del artefacto al sistema que lo verifica. El senior deja de leer línea por línea y pasa a diseñar las condiciones que cualquier línea debe cumplir. Menos inspector, más legislador.

Qué merece durar

Ahora bien, antes de que algún entusiasta salga a regenerar el core bancario un viernes a la tarde: no todo es ganado.

Stewart Brand estudió cómo envejecen los edificios y encontró que un edificio no es una cosa, son varias cosas que cambian a velocidades distintas. Los cimientos duran siglos. La estructura, décadas. Las instalaciones, años. Los muebles se mueven todos los días. Los edificios que envejecen bien son los que no encadenan las capas rápidas a las lentas.

Tu sistema es igual. El modelo de dominio, los datos, los contratos entre servicios: cimientos. Cambian lento y caro, y está bien que así sea. La interfaz, el pegamento, los reportes, las integraciones: muebles.

Te propongo un ejercicio, y es de los que valen una reunión entera: juntá a tu equipo frente al mapa de tus sistemas y recorran componente por componente con una sola pregunta —¿esto es mascota o es ganado? Si desapareciera mañana, ¿lo reconstruirían igual, o aprovecharían para hacerlo distinto? Si la respuesta es "distinto", acabás de encontrar ganado disfrazado de mascota. Vas a descubrir que es la mayoría. Y vas a descubrir algo más incómodo: que buena parte del presupuesto de mantenimiento está cuidando mascotas que nadie quiere.

Y acá viene la inversión que cambia todo: si el código se vuelve regenerable, el código deja de ser el activo. El activo es lo que sobrevive a cada regeneración —el dominio entendido, la intención escrita, los tests que encarnan lo que el negocio realmente necesita. El software renace porque hay algo que el fuego no toca.

La pregunta para tu empresa ya no es "¿cómo mantenemos todo este software?". Es "¿qué partes de esto merecen durar?". Y esa pregunta, te adelanto, no la contesta ningún modelo.

El 1%

Porque acá está el fondo del asunto. Antes le buscábamos el sentido a la IA; ahora empezamos a buscarle el propósito al humano. La IA puede regenerar todo el código del mundo, mejor y más barato cada vez. Lo que no puede es decidir qué vale la pena hacer renacer.

Decidir qué dura y qué se quema es una apuesta sobre el futuro. Y a veces es la apuesta del 1%: esa probabilidad mínima que ningún dato justifica, donde alguien igual dice "esto lo construimos para que dure", y esa decisión es la diferencia entre que un proyecto exista o muera.

Renacer es espectacular. Pero alguien tiene que decidir qué se quema.

Y ese es el único trabajo que no se regenera.

Autor: Fabi Mesaglio