Conoces esa versión que programas para el jueves por la noche. No porque el jueves sea cómodo, sino porque si algo se rompe tienes el viernes para arreglarlo antes de que los clientes lo noten. Un ingeniero tiene que estar conectado. Es el único que entiende qué hace el módulo de facturación cuando se cancela una suscripción a mitad de ciclo. Nadie ha tocado ese archivo en dieciocho meses y nadie quiere ser el primero.
Entonces Meta anuncia Muse Code, un agente de IA diseñado para trabajar sobre bases de código grandes. Y alguien de tu consejo, o tu propio director de producto, hace la pregunta obvia. ¿No podría esto entrar y limpiarlo todo?
Entiendo el atractivo. Es la respuesta más barata posible a un problema caro. También es la forma más rápida que conozco de convertir un sistema lento y frágil en un sistema rápido y frágil.
Qué hace realmente un agente sobre un repositorio grande
Si quitas el marketing, todas estas herramientas funcionan igual. El agente indexa tu repositorio. Construye algún tipo de mapa consultable: embeddings, grafos de símbolos, jerarquías de llamadas, historial de git. Cuando le das una tarea, recupera las partes del código que cree relevantes, planifica un cambio, edita archivos y luego intenta verificar su propio trabajo ejecutando tu build y tus pruebas.
Cada paso de esa cadena depende de tu base de código, no del modelo.
La recuperación depende de si tu código está nombrado y organizado de forma que la intención se pueda encontrar. La planificación depende de si en tu sistema hay una manera evidente de hacer las cosas, o cinco. La verificación depende por completo de si tu suite de pruebas falla de verdad cuando algo se rompe.
El modelo es el mismo, lo apuntes a un servicio limpio o a un monolito de diez años. El resultado no se parece ni de lejos. Esta es la parte que los proveedores se saltan. Ya escribí sobre los límites de fondo en El problema de la ventana de contexto en la IA.
Tu base de código es el prompt
Piensa en tu repositorio como el verdadero conjunto de instrucciones. La tarea que escribes es una nota al pie.
Un agente trabaja buscando precedentes. Mira cómo se hizo algo parecido en otro sitio y sigue ese patrón. Es una estrategia razonable en un sistema con un patrón claro por problema. Es un desastre en un sistema con cuatro.
La mayoría de los sistemas heredados han acumulado capas. Está la forma original de comprobar permisos. Está la forma que adoptó el equipo tras la refactorización de 2021. Está la forma que usó el contratista para la API móvil. Está el caso especial de los clientes empresariales, que vive en un middleware que nadie documentó. Las cuatro están en el repositorio. Las cuatro parecen igual de válidas para un sistema de recuperación.
El agente encontrará una de ellas. No tiene manera de saber cuál es el estándar actual, cuál está obsoleta y cuál es una mina antipersona que sigue viva por un único contrato con un cliente. Así que elige la que mejor encaja con tu consulta en el espacio vectorial y la copia. Ahora tienes cinco patrones en lugar de cuatro, y el más nuevo lo añadió algo que produce código más rápido de lo que tu equipo puede leerlo.
El código muerto lo empeora. Cada función sin usar, cada bloque comentado, cada directorio "v2" que se abandonó a medias: todo eso es señal válida para un sistema de recuperación. Los humanos aprenden a ignorarlo. Saben que utils_old.py es un cementerio. El agente no. Lo lee con la misma confianza que tu mejor módulo.
El cuello de botella se mueve, no desaparece
Esta es la aritmética que se ignora en toda presentación de IA para programar.
Escribir código nunca fue la restricción en un sistema maduro. Entender las consecuencias de un cambio, sí. Los agentes atacan la parte que ya era barata.
Si un agente produce un cambio que toca treinta archivos en cuatro módulos, alguien tiene que decidir si es seguro. Esa revisión es más lenta que revisar trabajo humano, porque no puedes preguntarle al autor qué estaba pensando. No hay pensamiento que interrogar. Tienes que reconstruir el razonamiento a partir del diff.
Así que la cola se acumula en la revisión. Los equipos reaccionan de dos maneras. O bajan el ritmo y la velocidad prometida nunca aparece, o empiezan a aprobar cosas que no entienden del todo. Lo segundo es lo habitual, porque alguien con galones prometió una cifra de productividad al consejo.
Así se consigue daño más rápido. No código malo: código plausible. Código que se lee bien, pasa las pruebas que tienes y cambia el comportamiento en silencio justo en el camino que nunca cubriste. Señalé este patrón en Por qué el 'AI slop' es la señal de alarma que exige una Auditoría y Recuperación ya, y los agentes que operan a escala de repositorio suben mucho la apuesta.
Hay un efecto de segundo orden que merece nombre. Los pull requests humanos son pequeños en parte porque los humanos somos perezosos. Nadie quiere refactorizar cuarenta archivos a mano. Esa pereza era una medida de seguridad accidental: mantenía pequeño el radio de daño de cualquier error. Los agentes eliminan la fricción, y con ella ese límite accidental sobre cuánto puede salir mal a la vez.
La parte a contracorriente: no empieces con un piloto en terreno virgen
El consejo habitual dice que pruebes los agentes de IA en algo de bajo riesgo. Un microservicio nuevo. Una herramienta interna. Un proyecto desde cero, sin lastre heredado.
Creo que es el sitio menos informativo posible para hacer la prueba. El código nuevo no tiene historia, ni acoplamientos ocultos, ni patrones en conflicto. Por supuesto que el agente rinde bien. No aprendes nada sobre el entorno donde de verdad necesitas la palanca: el sistema viejo que se come el 60% de tu presupuesto de ingeniería.
El experimento útil es más estrecho y más duro. Elige un módulo real del sistema heredado, idealmente uno doloroso pero no existencial. Dedica dos semanas a preparar solo ese módulo para el agente. Luego ejecuta el agente sobre él y mide.
Es una inversión pequeña y acotada, con una respuesta clara al final. También te dice algo que el piloto nunca te dirá: cuánto trabajo cuesta hacer que tu sistema sea legible para una máquina. Multiplica eso por el número de módulos y tienes un presupuesto real, no la estimación de un proveedor.
Qué significa de verdad "estar listo para agentes"
Cuatro cosas, ordenadas por importancia.
1. Pruebas que fallan por los motivos correctos
El porcentaje de cobertura es una métrica de vanidad. Lo que importa es si la suite detecta un cambio de comportamiento en los caminos por donde circulan el dinero y los datos. Perseguir el 80% de cobertura en un sistema heredado es un año de trabajo con beneficio incierto. Escribir pruebas de caracterización alrededor de los seis flujos que te traerían la llamada de un abogado lleva un par de semanas.
Las pruebas de caracterización no afirman lo que el código debería hacer. Fijan lo que hace hoy, errores incluidos. Ese es el punto: estás construyendo un cable trampa, no una especificación.
# Lock in current behaviour before letting anything touch this. # We are not claiming this proration logic is correct. # We are claiming it must not change without a human deciding it should. def test_midcycle_cancellation_refund_is_unchanged(): sub = build_subscription(plan="pro", start="2026-01-01", price_cents=9900) result = cancel(sub, on="2026-01-18") assert result.refund_cents == 4620 # observed today assert result.access_until == "2026-01-18" assert result.invoice_status == "credited"
Un agente que puede ejecutar esta suite tiene un bucle de retroalimentación real. Sin ella, "las pruebas pasan" no significa nada.
2. Límites que la máquina pueda ver
Si los límites de tus módulos solo existen en un diagrama de arquitectura, no existen. Hazlos exigibles por herramientas, para que una violación rompa el build en lugar de sobrevivir a la revisión de código.
// eslint.config.js — boundaries as a build failure, not a convention { "rules": { "no-restricted-imports": ["error", { "patterns": [{ "group": ["**/billing/internal/**"], "message": "Billing internals are private. Use billing/api." }] }] } }
Esto le da al agente un muro duro. Intenta el atajo, el build falla, se corrige. Ese bucle vale más que cualquier cantidad de documentación.
3. Contexto legible por máquinas, no documentos en prosa
Casi toda la documentación interna está escrita para un recién contratado que la leerá una vez. Los agentes necesitan otra cosa: las restricciones actuales, dichas con claridad, en un archivo que viva junto al código.
# AGENTS.md ## Canonical patterns - Auth: use `lib/auth/session.ts`. `legacy/authCheck.php` is deprecated and only kept alive for the on-prem client. Do not extend it. - DB access: repository classes only. No raw SQL outside `db/queries/`. ## Do not touch without a human decision - `billing/proration.py` — contractual behaviour, audited annually. - Any migration in `db/migrations/` older than 2024. ## Definition of done - `make verify` passes (lint + types + tests + boundary checks). - No new dependencies without approval.
Ese archivo es gobernanza en un formato sobre el que una máquina puede actuar. Las normas que solo viven en una página de Notion o en una presentación son invisibles para lo que escribe tu código. Es el argumento que planteé en Tu agente de IA no leyó el manual.
4. Un comando, una señal honesta
Si arrancar el proyecto requiere tres días de conocimiento tribal, un agente no puede verificar nada de lo que escribe. Necesita un único comando que compile, revise tipos, ejecute pruebas y haga cumplir los límites. Si ese comando sale en verde, deberías poder desplegar. Si no, todo lo que viene después es adivinar.
La medición que te mantiene honesto
Registra cuatro números antes de adoptar un agente, y otra vez noventa días después. Cuánto tarda un cambio desde el inicio hasta producción. Con qué frecuencia un despliegue causa un problema. Cuánto se tarda en recuperarse. Cuánto retrabajo genera cada cambio.
Si la tasa de fallos por cambio sube mientras el tiempo de entrega baja, no has ganado velocidad. Has movido coste de ingeniería a soporte, y aparecerá como bajas de clientes un trimestre después. Ese es el intercambio que nadie pone en la diapositiva del ROI.
Dónde te deja esto
Muse Code y las herramientas que vendrán después son reales. Los agentes que razonan sobre un repositorio completo cambiarán cómo trabajan los equipos de ingeniería, y prefiero llegar temprano que tarde. Pero un agente no tiene opinión sobre la calidad. Reproduce la disciplina que encuentra en tu sistema, a una velocidad que tu equipo no puede igualar.
Si tu base de código tiene límites claros, pruebas honestas y una manera evidente de hacer las cosas, un agente vuelve a un buen equipo bastante más rápido. Si no los tiene, el agente industrializará fielmente tu desorden.
Primero estabilizar. Después mejorar. La IA al final. El orden no es conservadurismo: es la única secuencia en la que pagas una sola vez.
Reserva una Auditoría Gratuita
