# El agente que se reescribe a sí mismo no tiene especificación

El nuevo argumento de venta es el agente 'autoevolutivo' — adapta su propio comportamiento mientras se ejecuta, así nunca tienes que actualizarlo. ServiceNow y NVIDIA acaban de apuntar uno directo a tu escritorio. Pero el software en producción necesita una cosa por encima de todo: un blanco fijo contra el que puedas verificar. Un agente que reescribe su propia lógica es un sistema donde lo que probaste no es lo que estará corriendo la semana que viene. Deja que aprenda en datos que puedas leer y reiniciar — nunca en un comportamiento cuyo cambio no puedas observar.

- **Author:** Fedor Chishchin
- **Published:** 2026-07-03
- **Tags:** agents, architecture
- **Source:** https://fedorthinks.com/es/blog/the-agent-that-rewrites-itself

---

La palabra que hace mucho trabajo silencioso en el marketing de agentes ahora mismo es **autoevolutivo**. El
agente no solo ejecuta tu flujo de trabajo — reescribe cómo funciona sobre la marcha, aprendiendo de cada
ejecución para seguir mejorando sin que tú lo toques. ServiceNow y NVIDIA acaban de poner esa idea en tu
escritorio: [Project Arc](https://blogs.nvidia.com/blog/servicenow-autonomous-ai-agents-enterprises/), un
agente autónomo "de larga duración y autoevolutivo" que lee tus archivos, abre tu terminal y
"se adapta cuando las cosas no salen como se esperaba."

Suena como el sueño. También es exactamente la propiedad que hace imposible confiar en un sistema en
producción.

## La producción corre sobre un blanco que se queda quieto

Cada disciplina que usamos para lanzar software fiable asume una cosa: el comportamiento está fijo el tiempo
suficiente para comprobarlo. Escribes una prueba porque el código debajo no se moverá. Revisas un cambio
porque hay un _antes_ y un _después_. Haces rollback porque la versión de la semana pasada sigue siendo algo
que existe. Quita el blanco fijo y todas y cada una de esas herramientas dejan de funcionar.

Un agente autoevolutivo lo quita a propósito. La versión que probaste en el sandbox aprendió tres cosas
nuevas para el jueves. El comportamiento que tu equipo de seguridad aprobó no es el comportamiento corriendo
cuando ocurre el incidente. No hay un rollback limpio, porque "la versión anterior" es un punto borroso en una
deriva continua, no una release etiquetada.

> Si el sistema se reescribe entre la prueba y el incidente, tu prueba no fue del sistema que falló.
> Verificaste un fantasma.

## La automejora es solo deriva descontrolada con mejor relaciones públicas

Ya sabemos que los agentes de larga duración se degradan con la distancia — [duplica la longitud de una tarea
y la tasa de fallos aproximadamente se cuadruplica](/es/blog/doubling-the-task-quadruples-the-failure). "Autoevolutivo" no
arregla eso; elimina lo único que te permitía detectarlo. Cuando la lógica del propio agente es lo que
cambia, no puedes distinguir la mejora del deterioro hasta que está frente a un cliente. No es aprender.
Es deriva, disfrazada de característica.

Y fíjate en qué se apoya de verdad la versión seria de Project Arc: no en la autoevolución, sino en la
[gobernanza a su alrededor](https://newsroom.servicenow.com/press-releases/details/2026/ServiceNow-extends-agentic-AI-governance-from-desktops-to-data-centers-with-NVIDIA/default.aspx)
— un runtime en sandbox, una torre de control que registra cada archivo leído y cada comando ejecutado,
políticas que acotan lo que puede tocar. El argumento de venta es la autonomía. El producto es una jaula. Eso
te dice cuál de las dos mitades es la que sostiene el peso.

## Deja que aprenda donde puedas mirar

No tienes que elegir entre un agente estático y uno sin rendición de cuentas. Pones el aprendizaje en algún
lugar donde puedas verlo y deshacerlo:

- **El aprendizaje vive en los datos, no en la lógica.** Ejemplos recuperados, filas de memoria, prompts
  ajustados, una base de conocimiento — cosas que puedes leer, comparar y borrar. El procedimiento de decisión
  del agente permanece fijo y revisable.
- **Cada cambio es un cambio que puedes nombrar.** Si actualizar el comportamiento significa lanzar un nuevo
  prompt o una nueva configuración que pasa las evals, tienes una versión, un diff y un rollback. "Evolucionó"
  no es una versión.
- **La especificación es la fuente de la verdad, no el humor del agente.** [Escribe el comportamiento](/es/blog/the-spec-is-the-source)
  y haz que el sistema responda a él. Si el agente quiere hacer algo que la especificación no cubre, eso es un
  ticket, no una improvisación.
- **La mejora es una release, controlada por evals.** Aprende offline, mide contra un conjunto de pruebas fijo
  y promueve deliberadamente — el mismo bucle que usarías para cualquier cambio de modelo. La automodificación
  online se salta el único paso que atrapa una regresión.

## En resumen

Un sistema que se mejora a sí mismo en la oscuridad es indistinguible, desde fuera, de un sistema que
silenciosamente se rompe a sí mismo en la oscuridad. Todo el valor de la ingeniería es poder diferenciar esos
dos casos.

**Mantén el comportamiento del agente fijo y pon el aprendizaje en datos que puedas inspeccionar y reiniciar.
"Evoluciona por sí solo" no es una capacidad que comprar — es la historia de verificación que acabas de tirar
a la basura.**