Agente de IA para una web que se autorrepara: arregla lo que puede verificar

Qué hace el bucle de la web que se autorrepara

Una web solo se autorrepara donde el agente puede demostrar la corrección, y construimos todo el mecanismo alrededor de esa línea. Nuestro agente de IA para una web que se autorrepara recorre el sitio en producción cada semana, registra cada defecto como un bug y envía cada bug a su propia ejecución en un entorno aislado. Esa ejecución reescribe lo que puede a través de la API del CMS, vuelve a comprobar la página guardada y cierra el bug solo si la comprobación sale limpia. ConvOps gestiona la programación, la cola de bugs y los dos flujos de trabajo. Es uno de los bucles con los que dirigimos nuestra empresa.

Una web que se autorrepara es un sitio donde un agente encuentra los defectos que ve el lector y repara los que puede verificar, dejando el resto a la espera de una persona. No es una batería de pruebas que se autorrepara: esas baterías reparan selectores en los tests, mientras que este bucle repara el contenido que ve el lector.

Todas las pantallas y cifras que verás a continuación usan datos de ejemplo de Shutterlane, una web ficticia de reseñas de material fotográfico llevada por dos personas en shutterlane.example.com.

Un barrido semanal encuentra defectos, cada bug tiene su propia ejecución de reparación y el registro de prevención convierte las repeticiones en comprobaciones al escribir.

El barrido (indicador 1) registra los hallazgos (2), los contrasta con el registro de prevención (3) y despacha los bugs abiertos (4). Cada bug se repara según su carril (5), se verifica (6) y después se cierra o queda en espera (7).

Por qué lo construimos: un agente de IA que corrige bugs de contenido web

Un agente de QA que solo informa es un generador de ruido. Un agente que encuentra y corrige en la misma ejecución se corrige sus propios deberes. Separamos las dos cosas.

Nuestro barrido empezó solo informando. Encontraba los mismos enlaces rotos y las mismas páginas desactualizadas cada semana, y nadie se encargaba de arreglarlos. El gráfico muestra ese patrón con datos de Shutterlane: se registra un bug (indicador 1), acumula una nota de repetición cada martes (2) y nunca se repara (3).

Un barrido que solo informa encuentra el mismo defecto cada semana y, sin un paso de reparación, el montón de notas de repetición no deja de crecer.

De ahí salieron tres principios:

1. Encontrar y corregir son trabajos distintos. El barrido nunca escribe contenido y la reparación nunca juzga el sitio.
2. Un defecto es una unidad de trabajo. Cada hallazgo nuevo es su propio bug, y cada ejecución de reparación se encarga de un único bug.
3. Hecho significa verificado. Un bug se cierra solo después de volver a comprobar la página guardada, nunca porque lo diga el agente.

Si tus informes de QA se acumulan igual, descubre cómo ConvOps convierte los hallazgos en bugs que los ejecutores recogen de uno en uno(se abre en una pestaña nueva).

Cómo funciona: pool, ejecutor, entorno, flujo de trabajo

El modelo es la parte menos interesante. El pool decide en qué se trabaja, el entorno qué puede tocar el agente y el flujo de trabajo cuándo se ha terminado. Dos flujos de trabajo llevan la carga: el del barrido, WF-qa, y el de reparación, WF-bugfix. Es un grafo de pasos y puertas, la forma que describimos en ¿Qué es graph engineering?, el mismo bucle programado y con puertas que nuestros experimentos SEO con Claude Code, y la respuesta a la proliferación de agentes.

Un pool decide en qué se trabaja, el ejecutor lo ejecuta, el entorno limita lo que puede tocar y el flujo de trabajo decide cuándo se ha terminado.

Los hallazgos se convierten en bugs dentro de un pool

Un pool es una consulta guardada en ConvOps: un filtro por tipo de tarea, etiquetas, proyecto, horizonte y estado, más un orden. Nunca contiene tareas; se resuelve en las que coinciden cuando se le pregunta, así que los bugs de cualquier proyecto aparecen en todos los pools que encajan. pools_next devuelve la tarea que va primera, desempata por id de tarea y registra una fila de extracción por llamada, de modo que cada extracción se puede auditar.

El pool open-qa-bugs de Shutterlane es type = bug AND tags contains qa-finding AND status in [backlog, todo], los más antiguos primero (indicador 1).

Los ejecutores recogen el trabajo

Un ejecutor es una instancia con nombre que ejecuta el trabajo, opcionalmente vinculada al pool del que extrae trabajo (indicador 2). Hay exactamente dos tipos:

Nuestro bucle funciona con un ejecutor aislado de Claude Code, indicado en la programación. El paso de despacho del barrido lanza él mismo la consulta con forma de pool y envía cada bug a ese ejecutor; vincular el ejecutor a un pool traslada esa misma extracción a ConvOps. Una ejecución atascada se termina al llegar a time_limit_s (por ejecutor, de 60 a 86 400 segundos; si no, el ajuste del espacio de trabajo: 14 400 aquí).

Los entornos aislados limitan lo que puede tocar el agente

Un entorno aislado es la definición escrita de todo lo que puede tocar una ejecución. Cada ejecución es un Job de Kubernetes, creado en pausa; antes de que arranque se le añade un Secret por ejecución que pertenece al Job. Un volumen de tarea conserva la carpeta de trabajo de la tarea entre sus ejecuciones. El Job se elimina 300 segundos después de terminar y el Secret desaparece con él, así que las credenciales nunca sobreviven a la ejecución.

Todo lo que puede tocar el agente se declara antes de que se ejecute, y la credencial es una referencia, nunca un valor.

• Repositorios. Exactamente uno recibe trabajo y siempre se sube (indicador 1): directamente sobre la ref extraída, reaplicado una vez, nunca forzado.
• Reglas de herramientas. El servidor del CMS deniega por defecto y permite 8 herramientas (indicador 2). El navegador permite herramientas de solo lectura: navegar, captura del DOM, captura de pantalla y tres más.
• Referencias, no valores. CMS_API_TOKEN apunta a una entrada de un gestor de secretos (indicador 3), y la credencial del ejecutor también es una referencia guardada (indicador 4). El indicador 5 es la vinculación con el pool.
• Permisos en ConvOps. Las escrituras en tareas solo llegan a la tarea de la propia ejecución. Las notas y lecturas llegan a cualquier tarea, así que el barrido puede anotar bugs, pero solo una ejecución de reparación cierra su propio bug.
• Límites de despacho. run_dispatch_limit es 10 por ejecución, lo que acota el coste y el radio de impacto de un barrido. run_dispatch_named_environment es false, así que una ejecución no puede ampliar el sandbox de lo que despacha.

Dos flujos de trabajo: uno encuentra y otro corrige

El auditor lee las páginas tal y como le llegan al lector: algunas renderizadas en un navegador y el resto como HTML en bruto, con los contadores y la actualidad contrastados con la base de datos. La promesa de actualidad es de 7 días para los modelos de cámara y de 14 para las entradas del directorio, la cadencia con la que funcionan sus bucles de verificación.

El barrido ejecuta seis pasos cada martes a las 05:00 UTC, encuentra y registra, y nunca escribe contenido.

La reparación ejecuta cinco pasos sobre un bug, usa solo el carril de ese bug y lo cierra solo después de volver a comprobarlo.

La programación (indicador 1) es FREQ=WEEKLY;BYDAY=TU;BYHOUR=5;BYMINUTE=0. La frecuencia semanal coincide con la promesa de actualidad de 7 días, así que un hallazgo sigue vigente cuando se ejecuta su reparación.

Una ejecución paso a paso: un bug desde el hallazgo hasta la corrección verificada

Lo interesante de una reparación es la comprobación posterior a la escritura, no la escritura. Este es el barrido qa/2026-09-15 de Shutterlane, desde la programación hasta el veredicto.

Martes, 05:00 UTC: el barrido encuentra y registra

El barrido se ejecuta en isolated-sonnet en un Job con shutterlane-qa. El auditor lee 24 páginas (6 en el navegador y 18 como HTML en bruto) y devuelve 7 hallazgos, uno por regla.

El auditor devuelve un hallazgo como página, regla y detalle, y un par de página y regla nuevo se convierte en un bug titulado regla: página.

Este hallazgo es nuevo, así que se convierte en el bug demo0101, absolute-self-link: /blog/best-travel-cameras-2026, con estado todo. La ejecución registra qa-dedupe: 5 novel, 2 recurrences; cada repetición añade una nota a su bug abierto.

El paso de prevención lee el registro. absolute-self-link está en covered y el post tiene 3 días, dentro de la ventana de fuga de 7 días, así que el barrido registra la idea demo0110 como prevention-proposal.

El despacho lista los bugs de QA abiertos, los más antiguos primero: 7, dentro del límite de 10. Cada uno va a isolated-sonnet sin indicar un entorno, así que recibe el predeterminado de su proyecto.

Un bug, una ejecución

Cada bug se ejecuta en su propio Job aislado con su propio volumen y anota su carril antes de tocar nada.

demo0101 recibe su propio Job, run-demoex01, y su propio volumen. read-bug elige el carril a partir del tipo de página y de la regla: un autoenlace en una página /blog/ va al carril post. Escribe bugfix-demo0101/2026-09-15 lane=post antes de tocar nada.

Una escritura protegida

La única escritura lleva la versión que leyó, así que un post que haya cambiado la rechaza, y nunca pasa un estado.

heal-post ejecuta post-lint, que indica el destino erróneo y su corrección. Después hace un único reemplazo anclado con body_md_edits, protegido por el expected_version que leyó. Nunca pasa status, así que una reparación nunca puede publicar ni despublicar una página.

Ante un conflicto de versión, el agente vuelve a leer una vez y reconstruye; un segundo rechazo termina como not healed. A un enlace muerto sin dirección conocida se le quita el enlace y se conserva su texto. Quitar un enlace es seguro; adivinar un destino, no.

Reparado o en espera

Un bug se completa solo después de un re-lint limpio y cuando el destino erróneo ha desaparecido, mientras que un bug del carril de espera queda bloqueado para una persona con el contenido intacto.

El agente vuelve a leer y a pasar el lint al post guardado. Reparado significa que la regla ya no tiene ningún hallazgo y que el destino erróneo ha desaparecido del cuerpo guardado, porque el lint puede pasar por alto un destino que el auditor sí vio. La nota dice healed: https://shutterlane.example.com/models/orrin-k5 -> /models/orrin-k5, se hace commit del registro de ejecución, el bug se completa y el Job y el Secret desaparecen 300 segundos después.

A la derecha, demo0104 (counter-sanity: /news) acaba en hold. Pasa a blocked, «necesita una corrección del producto o de un operador», con el contenido intacto.

Cómo es la salida: informe, notas, registro de prevención

Lee el barrido por estado, no por cantidad. Una repetición en una regla cubierta es un bug en tu protección, no en tu contenido.

Lee el barrido por estado: las filas nuevas son bugs nuevos, las repeticiones son notas y una regla cubierta que se repite significa que la protección tiene una fuga.

Dos señales activan el paso de prevención:

• Fuga: una regla cubierta en un post de /news/ o /blog/ publicado en los últimos 7 días. Solo un post reciente demuestra que la protección al escribir lo dejó pasar.
• Laguna: una regla parcial o no cubierta en 2 o más páginas en una misma ejecución, o una que se ha repetido. Una página es un defecto; dos páginas o una repetición son un patrón.

Cada regla recibe una propuesta; una propuesta abierta recibe una nota, nunca una segunda idea.

En el informe de Shutterlane, encoding-artifact está en covered y aun así se repitió en /directory: la protección tenía una fuga por una vía de publicación más antigua. Nos topamos con ese patrón, y dio lugar a una segunda protección, post-lint en la puerta de publicación, además de los rechazos al escribir en las herramientas del CMS. Cada registro de ejecución acaba en git, el rastro que describimos en observabilidad de agentes de IA.

Qué sale mal: una regla, tres grafías

La mayoría de nuestros fallos estaban en la fontanería y en los permisos, no en el modelo. El peor parecía un bucle que funcionaba.

La deduplicación usa como clave (page, rule). Nuestro auditor escribía los nombres de regla libremente y, entre ejecuciones, escribió una misma comprobación de tres formas. La deduplicación vio tres reglas y registró tres bugs para un solo defecto. Con datos de Shutterlane: dead-link, broken-link y dead-internal-link en /news/corvane-x2-firmware-3 se convirtieron en demo0081, demo0084 y demo0087.

Tres grafías de una misma regla registraron tres bugs; un único slug fijado deja un solo bug con una nota de repetición por ejecución.

La regla que salió de ahí es una línea en la ficha del auditor: «rule es exactamente uno de encoding-artifact, dead-link, absolute-self-link, counter-sanity, vocab-drift, freshness, reader-error; nunca una variante». Ahora un enlace es un bug con una nota de repetición por ejecución.

Monta el tuyo: la versión mínima

Empieza por el carril de espera y los permisos de herramientas. Decide qué no debe tocar nunca el agente antes de dejarle tocar nada.

El bucle mínimo: una programación semanal, un auditor que solo informa, un script de deduplicación, un pool de bugs y un ejecutor en sandbox que repara y pasa el lint o lo deja en espera para una persona.

Mantén el script de lint sin acceso a la red: el nuestro juzga los enlaces contra la tabla de rutas y las listas de entidades, así que su veredicto se repite exactamente igual. El carril de espera es la puerta humana de Cómo construir sistemas de IA con human in the loop. La tabla de carriles, lista para copiar:

lanes:
  post:       # rewrite through the CMS API, then re-lint
    rules: [absolute-self-link, dead-link, encoding-artifact]
    pages: ["/blog/<slug>", "/news/<slug>"]
  freshness:  # re-verify; healed when the general stamp moves
    rules: [freshness]
    pages: ["/models/<slug>", "/directory/<slug>"]
  reader:     # re-read; healed on HTTP 200 with the page's own content
    rules: [reader-error]
  hold:       # everything else: blocked, a person fixes it
    rules: ["*"]

El entorno, listo para copiar:

environment: shutterlane-qa
repos:
  - repo: shutterlane/site-ops
    receives_work: true
    push_target: ref
mcp_servers:
  shutterlane-cms:
    default: deny
    allow: [post_get, post_list, post_update,
            translations_manage, model_get, tool_get,
            verification_log_manage, verdict_history]
  playwright:
    default: deny
    allow: [browser_navigate, browser_snapshot,
            browser_take_screenshot, browser_console_messages,
            browser_wait_for, browser_close]
convops_tools_any_task: [task_notes_add, task_notes_list, tasks_get]
run_dispatch_limit: 10
run_dispatch_named_environment: false
secrets:
  CMS_API_TOKEN: {kind: gcp-sm, ref: demo-project/cms-token}

Copia la tabla de carriles y la definición del entorno, y después programa tu barrido semanal en ConvOps(se abre en una pestaña nueva). ¿Quieres tenerlo funcionando en tu propio sitio? Reserva una sesión de descubrimiento gratuita.