Context Rot es la erosión progresiva del contexto operacional, de diseño y de negocio que rodea a un sistema de software. Se manifiesta cuando la información crítica sobre 'por qué' un sistema fue construido de cierta manera, 'cómo' interactúa con otros componentes, y 'quién' tiene la experiencia para mantenerlo o evolucionarlo, se pierde o se dispersa. Esto no es solo una falta de documentación, sino una pérdida activa de la memoria institucional y del conocimiento tácito, haciendo que el sistema sea más difícil de entender, depurar, modificar y escalar.
Este fenómeno es omnipresente en sistemas complejos y de larga vida. Por ejemplo, en microservicios, un servicio antiguo que nadie ha tocado en años puede sufrir Context Rot, haciendo que cualquier intento de actualización o migración sea un esfuerzo de arqueología. En infraestructuras como código (IaC), configuraciones complejas que carecen de comentarios o de un historial claro de decisiones pueden llevar a Context Rot, donde los ingenieros no comprenden por qué ciertos parámetros fueron elegidos. Grandes empresas con múltiples equipos y alta rotación de personal, como Google o Amazon, invierten fuertemente en herramientas de documentación interna y 'knowledge sharing' para mitigar este problema, aunque nunca lo eliminan por completo.
Para un Arquitecto de Sistemas, el Context Rot es una preocupación estratégica crítica. Ignorarlo conduce a un aumento del 'Total Cost of Ownership' (TCO), ralentiza la innovación y eleva el riesgo de fallos catastróficos. Las decisiones de diseño deben considerar cómo preservar el contexto a lo largo del tiempo: favorecer arquitecturas auto-documentadas (ej. 'clean architecture', 'event sourcing' con esquemas claros), invertir en 'observability' que revele el comportamiento interno, fomentar la cultura de 'knowledge sharing' y 'pair programming', y establecer procesos de 'onboarding' robustos. El trade-off principal es el esfuerzo inicial en documentación y diseño explícito frente a la deuda técnica y operativa futura. Un arquitecto debe abogar por soluciones que, aunque requieran más disciplina al principio, reduzcan la probabilidad de que el sistema se convierta en una 'caja negra' inmanejable.