Hay una gran cantidad de conocimiento especializado que no está en Internet. Tampoco está en ningún libro o base de datos. Se distribuye a través de cerebros humanos, codificado en sistemas de funcionamiento, e incrustado en procesos que nadie entiende completamente.
Friedrich Hayek lo articula en 1945 mejor que nadie desde entonces:
“Hay más allá de la cuestión un cuerpo de conocimiento muy importante pero no organizado que no puede ser llamado científico en el sentido del conocimiento de las reglas generales: el conocimiento de las circunstancias particulares del tiempo y del lugar.” [1]
Estaba escribiendo sobre economía, pero la observación es mucho más general. Gran parte del mundo se ejecuta en el conocimiento local, tácito, distribuido. Piense en el coordinador de logística que gana la vida al saber sobre la capacidad de backhaul temporalmente no asignada en un carril de camiones. El agente de bienes que encuentra oportunidades fugaces antes de que alguien más lo haga. El árbitro que se beneficia de las diferencias de precios locales nadie ha notado todavía. Cada uno tiene conocimiento de que, como lo dijo Hayek, “por su naturaleza no puede entrar en estadísticas y por lo tanto no se puede transmitir a ninguna autoridad central en forma estadística”.
Este es el problema del conocimiento. No es una escasez de información, sino un reconocimiento de que la información más importante resiste a la centralización.
También describe, casi perfectamente, lo que sucedió dentro de los sistemas de software más grandes del mundo.
El conocimiento bloqueado en código de ejecución
Mainframe Sistemas de COBOL procesar trillones de dólares en transacciones todos los días. Fueron construidos a lo largo de décadas por miles de desarrolladores, cada uno respondiendo a sus propias circunstancias particulares: un cambio regulatorio, un incidente de producción el martes por la noche, una queja del cliente acerca de un error de redondeo en interés trimestral.
Nadie diseñó estos sistemas en su conjunto. Crecieron. Capa por capa, parche por parche, cada desarrollador contribuyó al conocimiento local a una base de código compartida. Las normas comerciales que rigen las aprobaciones de transacciones, los cálculos de intereses, la tramitación de excepciones y las transiciones estatales de cuentas rara vez fueron escritas de forma limpia. Estaban incrustados en códigos, diseños de datos, convenciones, hábitos operativos y correcciones de producción. Mientras los autores originales se retiran, gran parte de ese conocimiento se retira con ellos.
Este es el problema del conocimiento de Hayek, hecho ejecutable.
El conocimiento está demasiado distribuido en millones de líneas de código, demasiado implícitas en las interacciones del programa, y demasiado dependiente de datos específicos y estado para ser capturado limpiamente por cualquier persona o documento. Nadie lo entiende por completo. El sistema sí. Y aún así funciona. Cada día procesa las transacciones correctas, aplica las reglas correctas y produce los resultados correctos.
Por qué el enfoque estándar falla
El enfoque convencional de la modernización de mainframe es, en términos Hayekian, una forma de planificación central. Contratar un gran equipo de consultoría. Lea el código. Documenta las reglas del negocio. Reescribir el sistema de la documentación.
Esto falla por la misma razón que la planificación central falla. La abstracción pierde los detalles que importan.
Un consultor leeIF WS-FICO-SCOREy escribe "las puntuaciones de la OFICA debajo de 300 son rechazadas". Pero el verdadero conocimiento no está en esa frase. Está en el comportamiento del sistema en condiciones reales. ¿Qué pasa cuando ese cheque falla en la mitad de una transacción? ¿Qué sucede cuando el área de comunicación contiene un estado particular? ¿Qué sucede cuando un cursor se coloca en un registro específico y una ruta de excepción se activa dos programas más tarde? Ahí es donde vive la verdadera regla.
El conocimiento vive en parte en código, pero más importante en el comportamiento del sistema de funcionamiento bajo restricción.
Una respuesta común pero ingenua es: ¿no puedes apuntar un LLM fronterizo en el COBOL y preguntar qué hace? Un LLM fronterizo apunta a un archivo COBOL a menudo puede decirle lo que un párrafo parece hacer en aislamiento. No puede decirle con confianza qué sucede cuando diecisiete programas interactúan a través de búferes de byte compartidos, áreas de comunicación entre programas, límites de transacción y datos en forma de producción. La lectura no es suficiente. El conocimiento importante se expresa mediante la ejecución.
Construir el medio ambiente, dejar que AI explore
Así que la alternativa es replicar el ambiente en el que se expresa ese conocimiento.
En lugar de pedir a los humanos que lean el código y reconstruyan las reglas, construyen una réplica fiel e instrumentada del sistema legado: uno que se comporta como el original pero que se ejecuta en un ambiente donde cada rama, cada mutación, cada estado intermedio, y cada interacción se puede observar. Luego dejas que la IA funcione dentro de ese entorno, formando hipótesis, realizando experimentos, observando resultados y revisando su comprensión.
Esta es una orientación fundamentalmente diferente. Deja de tratar la comprensión como una tarea de lectura. En lugar de eso, construyes un mundo en el que el entendimiento puede ser descubierto a través de la interacción.
En unensayo anterior, Argumenté que Rich Sutton's Bitter Lesson [6] se aplica a la comprensión del código. Los métodos generales que aprovechan la computación tienden a superar los métodos construidos alrededor de abstracciones humanas. Summarization, RAG, ontologías diseñadas manualmente, gráficos de conocimiento: todos estos son intentos de comprimir comprensión a través de heurísticas que trabajan hasta un punto y luego rompen a suficiente escala y complejidad. Esta es la Lección Bitter aplicada a la modernización.
No construya esquemas de compresión cada vez más claros para el conocimiento tácito. Construir el entorno en el que se expresa ese conocimiento y dejar que la exploración —utilizando métodos generales como búsqueda y aprendizaje— haga el trabajo.
En la práctica, eso significa construir un gemelo conductual del sistema legado y dar a los agentes de inteligencia artificial las herramientas para interactuar con él: navegar pantallas, enviar entradas, inspeccionar datos, observar trazas de ejecución, comparar resultados y probar conjeturas sobre la lógica empresarial contra el comportamiento real del sistema.
¿Esto solo prueba en ropa de fancier? En realidad no. La prueba comienza con una especificación y comprueba si el sistema lo satisface. Esto comienza sin una especificación y trata de descubrir uno. La dirección es invertida. Es más cercano al método científico que al QA.
¿Por qué construir el gemelo en lugar de leer el código?
A primera vista, construir una réplica fiel suena incluso más difícil que entender el código directamente. En un sentido, lo es. Pero es un tipo diferente de duro.
Leer un gran sistema legado y reconstruir su verdadero comportamiento es un problema de juicio. Depende de la interpretación, el contexto tácito y el esfuerzo humano heroico. La construcción de un gemelo fiel es un problema de ingeniería. El objetivo es hacer de la fidelidad una propiedad del sistema que construyes, no un subproducto de la intuición de alguien.
Eso significa traducir el sistema legado en una representación cuyo comportamiento puede ser revisado sistemáticamente, luego endurecer la equivalencia a través de métodos formales y validación diferencial continua. Ejecute las mismas entradas a través del sistema original y el gemelo. Compare salidas, trazas y efectos secundarios. Donde se divierten, cierra la brecha. Con el tiempo, conviertes la fidelidad en algo mensurable.
Esto importa porque una vez que la infraestructura existe, cada nuevo sistema se vuelve explorable por la construcción. Intercambiamos un proceso breve, manual, irreductiblemente contextual para uno basado en ingeniería repetible.
Los laboratorios AI ya entienden el patrón
Una de las lecciones más claras de la IA moderna es que los entornos superan los conjuntos de datos estáticos.
DeepMind no logró superhumano Construye una base de datos gigante de comentarios de expertos. Construyeron un motor de juego y dejaron que el agente aprenda actuando dentro de él. Cuando AlphaGo Zero [2] removió completamente los datos del juego humano y aprendió a través del auto-juego, superó el sistema anterior. El medio ambiente era el plan de estudios.
El mismo patrón aparece en otra parte. SWE-bench [4] evalúa los agentes de codificación dentro de repositorios reales donde pueden inspeccionar código, hacer ediciones y realizar pruebas. WebArena [5] evalúa agentes web dentro de las aplicaciones web que funcionan en lugar de conjuntos de datos estáticos de trazas del navegador. Los grandes laboratorios se han movido hacia sistemas de uso de ordenadores donde el modelo opera una interfaz real con capturas de pantalla, movimientos de ratón y acciones de teclado. En cada caso, la capacidad viene no sólo de más datos, sino de actuar dentro de un mundo estructurado que produce retroalimentación.
El patrón ya es visible: si desea que un sistema domina un dominio, las descripciones son a menudo un pobre sustituto del dominio en sí.
Ese principio se aplica tanto al software empresarial como a los juegos, repositorios de código o navegadores.
Si desea que AI entienda un sistema bancario de cuarenta años, no sólo le dé los archivos fuente y pida un resumen. Dale un ambiente para operar.
Fidelity es todo el juego
Por supuesto, esto sólo funciona si la réplica es fiel. Si el gemelo se zambulle del sistema real, el entendimiento extraído será incorrecto.
Es por eso que la verificación no es sólo un buen juego, sino todo el juego.
El gemelo debe ser validado continuamente contra el sistema original mediante ejecución paralela. Las mismas entradas deben producir las mismas salidas, las mismas transiciones estatales clave y el mismo comportamiento observable. Cada discrepancia es útil. Se revela donde el modelo del sistema es incompleto y donde el medio ambiente debe ser más preciso.
Hecho correctamente, el medio ambiente se convierte en un instrumento progresivamente más afilado para extraer la comprensión.
Esto es lo que estamos construyendo en Hypercubic: no herramientas de documentación, no plataformas de análisis de códigos estáticos, pero ambientes fieles y explorables donde AI puede descubrir el conocimiento que nunca fue escrito.
Tendremos mucho más que decir acerca de los detalles pronto.
Referencias
- Hayek, F.A. (1945).El uso del conocimiento en la sociedad. American Economic Review, 35(4), 519-530.
- Silver, D. et al. (2017).Dominar el juego de Go sin conocimiento humano.Naturaleza550, 354-359.
- Open Ended Learning Team, DeepMind. (2021).Aprendizaje abierto conduce a agentes generalmente Capibles.
- Jiménez, C.E. et al. (2023).SWE-bench: ¿Pueden los modelos de lenguaje resolver problemas GitHub en el mundo real?
- Zhou, S. et al. (2023).WebArena: Un entorno Web realista para construir agentes autónomos.
- Sutton, R. (2019).La lección del bitter.