Image generated by Google Gemini
Si le pediste a un agente de IA que refactorizara y la aplicación se rompió, si quieres transformar un sistema legacy en un entorno donde la IA pueda trabajar, si quieres convertir el presupuesto de mantenimiento legacy de las Fortune 500 en presupuesto de transformación – este artículo es esa hoja de ruta.
Memoria bloqueada
Durante la burbuja de internet, las empresas comenzaron a acumular activos digitales. Código, bases de datos, especificaciones, documentos, APIs — décadas de memoria corporativa.
Esa memoria estaba bloqueada. Imposible de buscar, imposible de verificar, inalcanzable (unreachable). La única forma era que una persona la leyera, la entendiera y la modificara a mano. Por eso el 60-80% del presupuesto IT de las Fortune 500 se gasta en mantener esta memoria bloqueada. No pueden abrirla, así que solo la custodian.
Estamos en medio de lo que se llama la burbuja de IA. El verdadero significado de esta era no es que los modelos se vuelvan más inteligentes. Es que la memoria legacy bloqueada durante años está volviéndose alcanzable (reachable).
Pero todavía no. En 2026, los agentes de IA escriben código. Uno quema millones de tokens durante 68 minutos, termina un refactoring. La aplicación queda completamente rota. Historias así aparecen en X todos los días.
¿Por qué se repite?
No porque el agente sea estúpido. Porque el entorno no está construido para que los agentes trabajen. No metes un robot en una oficina humana. Construyes una fábrica donde los robots puedan trabajar.
Para desbloquear la memoria bloqueada, primero debe transformarse en una forma que pueda abrirse. No es solo un problema de código. Bases de datos, especificaciones, documentos, APIs — todo el patrimonio digital de la empresa es opaco para los agentes.
Qué significa Agent-Operable
Para que un agente trabaje autónomamente, se necesitan tres condiciones:
1. Debe ser legible — sin ruido
Para encontrar una función en un archivo de 2,000 líneas, 1,950 líneas son ruido. Para encontrar datos de un cliente en una base de datos sin normalizar, hay que hacer join de tres tablas. Las reglas de negocio ocultas en hojas de Excel son invisibles para los agentes.
Legible no significa que una persona pueda leerlo. Significa que una máquina pueda parsearlo estructuralmente.
2. Debe ser verificable — de forma determinista
Si un agente no puede saber qué se rompió después de un cambio, cae en un doom loop. El código necesita tests. Las bases de datos necesitan constraints. Las APIs necesitan validación de schema. Las especificaciones necesitan verificación cruzada.
Que un LLM verifique a otro LLM es como preguntarle a tu amigo borracho “¿Estoy borracho?”. go test no alucina. Un CHECK constraint no miente. JSON Schema no deriva.
3. El estado debe persistir — incluso cuando el agente muere
Los agentes van a fallar. Límites de tokens, errores de red, sesiones cortadas. Si el progreso no se guarda, cada ejecución empieza desde cero.
Cuando el Agente A procesa hasta la función #200 y muere, el Agente B debe continuar desde la #201. Los agentes son desechables. El progreso debe acumularse.
Paso cero: congelar los bugs
Las tres condiciones son el destino. El punto de partida es otro. Sin documentación, sin tests, 300 archivos de 2,000 líneas cada uno. Ese es el punto de partida.
Dile a un agente que “refactorice” en ese estado. ¿Qué pasa? “Arregla” un bug de diez años. El problema es que ese bug no es un bug.
Ley de Hyrum: todo comportamiento observable de una API suficientemente antigua tiene a alguien dependiendo de él. Un error de redondeo decimal abandonado durante una década tiene la lógica de pago de un cliente VIP atada a él. Un bug de parseo de fechas generó una macro de Excel que sostiene todo el departamento de contabilidad. Los bugs viejos son especificaciones de negocio implícitas.
La primera tarea del agente no es arreglar código. Es congelar el comportamiento actual.
Pinchar la API. Registrar la respuesta. Fijar esa respuesta como un test de Hurl. Bug extraño o comportamiento intencionado — sin distinción. Congelarlo tal como está. Este es el primer diente del ratchet — bloquea al agente para que no “mejore” las cosas por su cuenta.
Los cambios los decide solo quien tiene la especificación. El agente es un ejecutor. No un juez.
Una vez completada la congelación, comienza la transición hacia las tres condiciones: legibilidad, verificabilidad, persistencia.
No solo código
“Agent-operable codebase” es el punto de partida. Los activos digitales de una empresa no son solo código.
| Activo | Estado actual | Estado Agent-Operable |
|---|---|---|
| Código | Archivos de 2,000 líneas, sin tests | Un concepto por archivo, tests para cada función |
| Base de datos | Sin normalizar, sin documentación | Gestión declarativa de DDL, migrations auto-generadas |
| Especificaciones | Wiki, transmisión oral, drift | 9 SSOTs con verificación cruzada, encadenados por un identificador único |
| Documentos | Reglas ocultas en PDFs y Excel | Extracción de schema, legible por máquinas |
| API | Sin documentar, contratos implícitos | Captura OpenAPI, validación de schema |
Visto individualmente, cada fila parece “deberíamos ordenar esto”. Visto en conjunto, forman un sistema.
Symbolic Feedback Loop
Una estructura común hace posible esta transición.
LLM genera → herramienta determinista juzga → resultado devuelto al LLM → repetir
En código, en tests, en especificaciones, en datos — el mismo loop opera:
Estructura de código: filefunc validate → feedback de violación → LLM corrige → repetir
Tests: go test + coverage → feedback de líneas sin cubrir → LLM refuerza → repetir
Consistencia de specs: yongol check → feedback de drift → LLM corrige → repetir
Reglas de usuario: rulecat evaluate → feedback de violación → LLM corrige → repetir
Lo único que hace el LLM es generar. Qué corregir, si pasó, qué sigue, si terminó — todo lo decide la máquina. El LLM no recibe autoridad de decisión.
Esto no es un invento. C. elegans dedica 60 de sus 302 neuronas (20%) a la entrada sensorial. A verificación, no a generación. Quinientos millones de años de evolución llegaron a esta conclusión: mejorar la calidad del feedback supera a agregar más neuronas para la supervivencia.
La industria está haciendo que el tren (el modelo) sea más rápido. Modelos más grandes, agentes más inteligentes, mejores prompts. Pero cuanto más rápido va el tren, más importan los raíles.
80/20
En el estado final, el sistema se divide en dos capas.
SSOT (80-90%)
├── OpenAPI, DDL, SSaC, FuncSpec, Rego, Hurl, React TSX, Mermaid, manifest
└── Generado desde specs. Drift eliminado en origen. Los agentes modifican libremente.
Custom (10-20%)
├── Reglas de negocio, lógica de dominio, cálculos legales/de políticas
└── Estructurado con filefunc, testeado con tsma. Los humanos revisan.
El código que los humanos realmente necesitan atender se comprime al 10-20%. El resto lo generan agentes leyendo specs, verificado por máquinas.
El 60% de las Fortune 500
El 60-80% del presupuesto IT de las Fortune 500 se consume en mantenimiento de legacy. El 42% del tiempo de los desarrolladores se va en deuda técnica. El 70% de las migraciones manuales de legacy fracasan.
Este presupuesto ya se está gastando. No se necesita presupuesto nuevo. Solo redirigirlo. Convertir presupuestos de mantenimiento en presupuestos de transformación.
Introduce el legacy entero y sale un sistema agent-operable. Esa es la promesa de Building Agent-Operable Systems.
Por qué las Big Tech no hacen esto
Anthropic y OpenAI construyen modelos de propósito general. Mejora un modelo un 10% y se aplica a todos los clientes. Pero construye un feedback loop de Go test y solo se aplica a desarrolladores de Go. Construye una herramienta de coverage de Python y solo se aplica a proyectos de Python.
La verificación simbólica es inherentemente específica de dominio. Cada lenguaje, cada framework, cada especificación requiere un verificador diferente. Sin generalidad, no encaja en el ROI de las Big Tech.
Por eso este espacio está vacío. Quienes construyen el tren y quienes tienden los raíles no son competidores. Son complementarios.
Preguntas
Tu agente escribe código. Pero ¿quién verifica si ese código es correcto?
¿Otro agente? ¿O go test?
¿Tu LLM realmente lee las 100,000 líneas completas?
¿O finge que las lee?
Lo que la era de los agentes necesita no son agentes más inteligentes. Son sistemas donde los agentes puedan trabajar.
Sources
- Gartner, “IT Budget and Cost Optimization” — 60–80% of enterprise IT budgets consumed by legacy maintenance
- Stripe & Harris Poll, The Developer Coefficient (2018) — 42% of developer time spent on technical debt
- McKinsey & Company, Why do most transformations fail? (2019) — ~70% of digital transformation projects fall short of goals
- Hyrum Wright, Hyrum’s Law — “With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody”
- Winters, Manshreck, Wright, Software Engineering at Google (O’Reilly, 2020) — Formal book source for Hyrum’s Law
- White et al., “The structure of the nervous system of C. elegans”, Phil. Trans. R. Soc. Lond. B 314 (1986) — 302-neuron connectome
- Inglis et al., The sensory cilia of C. elegans, WormBook (2007) — 60 sensory neurons (~20% of total)
- METR, Early-2025 AI Developer Productivity Study (2025) — AI tools made experienced developers 19% slower, yet developers perceived 24% speedup
- GitClear, AI Copilot Code Quality 2025 (2025) — 211M lines analyzed, refactoring down 60%, copy-paste code up 48%
- Mehtiyev & Assuncao, Beyond Resolution Rates (2026) — 19 agents, 9,374 trajectories; 12.4% of total compute spent on zero-yield tasks