Tu código es una mina de oro que nadie está explotando
El código que no sabías que estabas escribiendo: conocimiento de negocio atrapado en producción
Hay algo que debería incomodar a cualquier CTO o desarrollador senior: la comprensión más sofisticada de tu negocio podría no existir en ningún documento, solo en el código que se ejecuta en producción.
Un estudio reciente del equipo de ServiceMatch plantea una idea provocadora. Argumentan que los sistemas de software maduros no son solo herramientas que ejecutan tu negocio — son representaciones ejecutables de todo lo que tu organización ha aprendido sobre ese negocio. ¿El problema? Ese conocimiento ha estado escondido a plena vista,锁 dentro de repositorios que solo leían compiladores y (de vez en cuando) humanos.
El mito de la documentación
Todos hemos estado ahí. Un nuevo ingeniero se une al equipo y le entregan una pared de páginas de Confluence, registros de decisiones de arquitectura y entradas de Wiki. "Esto te pondrá al día," dice alguien con optimista certeza.
No lo hará.
La documentación captura lo que alguien pensó que valía la pena escribir, en un momento que pudo haber sido hace años. Se pierde los casos extremos. Se pierden las discusiones que ocurrieron en reuniones y que dieron forma a las decisiones. Se pierde la lógica de negocio que evolucionó a través de miles de commits, cada uno luchando con un escenario del mundo real.
Según el argumento de Peter Naur en 1985 (sí, el mismo Naur que nos dio Backus-Naur form), la documentación de programas nunca puede capturar completamente la "teoría" detrás de un sistema. El verdadero entendimiento vive en las cabezas de las personas. Cuando esas personas se van, la teoría se va con ellas.
Pero aquí es donde las cosas se ponen interesantes.
La IA cambia el problema del lector
El argumento de Naur era sobre dos tipos de lectores: compiladores (que ejecutan código sin entenderlo) y humanos (que lo entienden lentamente y de forma costosa). La imposibilidad de revivir documentación asumía que no existía ningún otro tipo de lector.
Los modelos de lenguaje grandes son un tercer tipo de lector. Y son sorprendentemente buenos reconstruyendo las teorías implícitas incrustadas en el código.
El sistema ServiceMatch proporciona evidencia contundente. Su plataforma CMDB codifica conocimiento de gestión de configuración empresarial que llenaría volúmenes si se escribiera en prosa. Pero aquí está el punto — ya está escrita, solo que no en prosa. Está en código.
Considera su lógica de resolución de identidades. En lugar de un ensayo de consultor sobre "cómo funciona la identidad de dispositivos," tienen un archivo de configuración con pesos: número de serie (25), nombre de host (25), etiqueta de activo (25), dirección IP (20), dirección MAC (15). Más umbrales de confianza y reglas de resolución de conflictos. Cada número representa un argumento que alguien ganó. Cada tipo de conflicto representa un incidente real que ocurrió en algún lugar.
Esto no es una descripción de la política. ESTA es la política, ejecutándose cada noche contra estates empresariales reales.
Qué significa esto para tu equipo
Para desarrolladores y líderes técnicos, esta investigación tiene implicaciones prácticas:
Tu código es documentación que no has estado manteniendo — y eso tiene sus propias ventajas. A diferencia de páginas wiki obsoletas, el código que se ejecuta en producción se valida constantemente. Si la documentación no está de acuerdo con el código, la documentación está equivocada.
Las herramientas de IA mejoran越来越好 en extraer este conocimiento. Nos movemos hacia un mundo donde preguntar a una IA sobre "cómo manejamos conflictos de identidad de dispositivos" podría devolver no solo documentación, sino el razonamiento real codificado en los pesos y umbrales.
El conocimiento real vive en los casos extremos. Los flujos principales suelen estar bien documentados. Es el manejo especial, las excepciones, los casos límite resueltos a lo largo de años los que contienen el conocimiento institucional profundo.
La señal de advertencia
Hay un corolario incómodo a todo esto: si tu lógica de negocio solo está en tu código, y tu código tiene mala cobertura de tests, nombres poco claros o estructura caótica, estás sentado sobre una pila de conocimiento que es casi imposible de extraer.
El equipo de ServiceMatch descubrió que su afirmación — que "el repositorio basta" — se rompe de formas predecibles. El residuo tácito de Naur es real. Algún conocimiento genuinamente solo vive en las cabezas de las personas.
Pero el hallazgo más fuerte es que más sobrevive en el código de lo que pensábamos posible. El repositorio captura mucha más teoría que la documentación jamás podría — solo necesitábamos un nuevo tipo de lector para extraerla.
Qué hacer con esto
Si eres una startup o empresa tecnológica en crecimiento, aquí tienes un marco para pensar sobre esto:
- Confía más en tu código que en tus docs cuando los dos no estén de acuerdo
- Escribe código que documente su razonamiento — nombres de variables significativos, funciones claras, comentarios que expliquen POR QUÉ, no solo QUÉ
- Trata la configuración como conocimiento institucional — esos pesos y umbrales son decisiones que vale la pena preservar
- Empieza a explorar herramientas de IA que puedan interrogar tu codebase como fuente de conocimiento
El código que escribes hoy es el conocimiento institucional de mañana. Haz que cuente.