Lunes, 10:00. El equipo de arquitectura revisa el último pull request generado por IA para un microfrontend en el monorepo principal. El código es correcto, pero algo no encaja. El pipeline de Azure DevOps falla en un paso que nadie recuerda haber configurado. El "gurú" del equipo, único que entiende los triggers y condiciones, está de vacaciones. Nadie sabe si el error es técnico o una regla invisible rota.
No es un incidente aislado. En sistemas enterprise con años de evolución, la IA no tropieza con el código: tropieza con las reglas invisibles, las dependencias tácitas, la memoria institucional. La promesa de automatización choca con la realidad de arquitecturas donde el conocimiento vive en cabezas, hilos de Slack y acuerdos verbales nunca documentados.
Fricción en sistemas complejos: escenas reales
- Monorepo con siete años de historia: la documentación cubre el onboarding técnico, pero nadie ha escrito por qué ciertos microfrontends nunca deben compartir estado. La IA genera código que rompe límites invisibles y dispara incidentes en producción.
- Pipelines legacy en Azure DevOps: 1200 líneas de YAML, triggers y condiciones que solo entiende el "gurú". La IA automatiza cambios, pero elimina pasos críticos porque no están documentados.
- APIM con políticas heredadas: la IA replica la política estándar, pero omite excepciones de negocio que solo existen en emails antiguos.
- Nginx como proxy interno: reglas de routing y rewrites que nadie se atreve a tocar. La IA sugiere cambios que parecen correctos, pero rompen integraciones legacy por dependencias ocultas.
- Onboarding: un developer senior aprende el stack en una semana, pero tarda un mes en entender las reglas no escritas sobre ownership y convenciones.
Contradicciones y tensiones organizacionales
La organización invierte en IA esperando velocidad, pero la falta de contexto explícito genera más errores y retrabajo. Los equipos senior "saben" cómo funciona el sistema, pero no pueden transferir ese conocimiento a la IA ni a nuevos miembros. Cada intento de modernización revela dependencias ocultas y reglas invisibles que nadie se atreve a documentar por miedo a romper algo. La memoria institucional es un asset hasta que se convierte en trampa.
Migrar a IA sin mapear el conocimiento tácito es como automatizar una ciudad sin plano: los atajos matan. La fricción entre desarrollo y operaciones se intensifica: los primeros quieren automatizar, los segundos temen perder control sobre reglas tácitas. El resultado: incidentes en producción, ciclos de blame, parálisis ante cambios estructurales.
Patrones, anti-patterns y consecuencias prácticas
Patrón: documentar el “qué” y el “cómo”, pero nunca el “por qué”. La IA puede replicar acciones, pero no decisiones. Anti-patrón: migrar a IA sin auditar el conocimiento tácito. El código mejora, pero el conocimiento se pierde. Otro anti-patrón: confiar en la memoria institucional para decisiones críticas. Cuando el equipo cambia, la IA y los nuevos fallan igual.
La documentación generada automáticamente (Swagger, YAML, etc.) es útil para integración, pero inútil para decisiones arquitectónicas. El valor está en documentar el criterio, no solo la acción. En legacy, cada decisión no documentada es una mina esperando a explotar.
Hacia el context engineering: de la fricción a la ventaja
La IA amplifica la deuda de conocimiento: lo que no está escrito, no existe. La gestión moderna de sistemas legacy requiere auditar y transformar el conocimiento tácito en explícito: architecture decision records, documentación viva, knowledge graphs, procesos de onboarding que prioricen el “por qué”.
La resiliencia organizacional ya no depende solo del código, sino de la calidad del conocimiento explícito. La ventaja competitiva no es la IA, sino la capacidad de hacer explícito el conocimiento en sistemas complejos. La era de la context engineering no es opcional: es la base de las organizaciones AI-ready.