Así funciona un scraper que se repara solo con IA

En pocas palabras: Se construye armando un agente con LangChain Deep Agents y GPT-6 Luna (vía OpenRouter) que, ante un selector CSS roto detectado por Spidermon cada diez productos, edita el page object en una copia aislada del proyecto, corre tests con hasta tres intentos y devuelve el fix para revisión humana antes de aplicarlo.

Un agente de IA basado en LangChain Deep Agents y GPT-6 Luna reparó en vivo el selector CSS roto de un scraper de Scrapy, editando el código de un page object, corriendo tests y devolviendo el fix para revisión humana, según documentó el autor del proyecto el 4 de noviembre de 2026 en dev.to.

Un scraper autorreparable con IA es un sistema de scraping que detecta cuando un selector dejó de extraer datos correctamente (típicamente por un cambio de markup en el sitio), y delega a un modelo de lenguaje la tarea de proponer una corrección sobre una copia aislada del proyecto, validándola con tests automáticos antes de aplicarla al código en producción.

¿Por qué un scraper de Scrapy puede fallar sin que nadie lo note?

Porque un crawl roto no siempre tira error: a veces sigue devolviendo items perfectamente formados, con todos los campos salvo uno vacío. Las requests se completan, los productos llegan al pipeline, el log no muestra nada raro. El problema aparece cuando revisás el export final y ves que la columna de precio está en blanco en miles de filas.

Si estás scrapeando cientos de miles de productos, descubrir esto al final del proceso sale caro. Según el autor del proyecto en dev.to, el disparador típico es un rediseño del sitio: cambia una clase CSS, el selector existente deja de matchear, y el campo price empieza a volver None sin que el spider se entere.

El caso paralelo que documentó Zyte en su workshop de Extract Summit Austin (octubre 2026) es casi idéntico: una librería online rediseña la página, los diez libros siguen ahí con los mismos precios, pero cada clase cambió y aparece un nuevo precio tachado. El resultado: item_scraped_count en 10, pero título, precio y disponibilidad en null. Nada crashea. Eso es justo lo que hace cara a esta falla: un crawl que tira error se nota, uno que termina “bien” con nulls, no.

¿Cómo detecta Spidermon los precios faltantes durante el crawl?

Spidermon corre un monitor cada diez productos scrapeados, no cada cierta cantidad de segundos, y si detecta un precio vacío dispara el cierre del spider antes de que termine el crawl completo. Esa es la diferencia clave: es un trigger por cantidad de items, no el scheduler periódico habitual de Spidermon.

El pipeline que describe la fuente original registra cada precio faltante en las estadísticas de Scrapy. Cada diez productos, una extensión disparada por señal corre la suite de monitores de Spidermon contra esas estadísticas. Si algún producto tiene precio vacío o nulo, la suite falla y su acción de fallo pide que el spider cierre.

• Detección temprana: el chequeo corre mientras el crawl sigue activo, así que no hace falta esperar a un export completo para descubrir que la columna de precio está vacía.
• Regla deliberadamente estricta: en este proyecto, un precio faltante alcanza para detener todo el crawl. Ojo con copiar esta regla tal cual: otros proyectos van a necesitar criterios distintos, porque un producto agotado puede tener legítimamente sin precio.
• Items que llegan después del cierre: Scrapy es asíncrono, así que requests ya en vuelo pueden completarse durante el shutdown. El wrapper de reparación espera a que el proceso del crawl termine antes de tocar nada.

¿Qué información recibe el agente para investigar el fallo?

El agente recibe un evento estructurado en JSON con cuatro campos: reason, field, url y page_object, que apunta directo a la página ofensiva, el campo roto y la clase responsable de extraerlo. No tiene que leer un log de crawl entero para entender qué pasó. Para entender mejor el tema, podés repasar cómo funciona ChatGPT en detalle.

El código del proyecto usa scrapy-poet para separar la lógica de navegación (que queda en el spider) de la extracción de campos (que queda en page objects). Cada page object tiene un método por campo, así que si el evento dice price, hay un método price() puntual que lo maneja. Esto limita drásticamente cuánto código tiene que considerar el agente antes de tocar algo.

Acá viene lo interesante del caso real: cuando el selector del precio cambió de .price a .nopriser-sre, resultó que currency() y currency_raw() leían el mismo elemento HTML que price(). El agente terminó actualizando los tres métodos en una sola pasada, porque la herramienta de escritura permite editar el archivo completo del page object, no solo la función puntual que falló. Eso es justo la clase de amplitud que hacía falta ahí; en otro escenario podría ser demasiado permiso.

¿Cómo funciona el ciclo completo de reparación automática?

El ciclo completo tiene seis pasos: Spidermon detecta y cierra el spider, el wrapper copia el proyecto a un directorio temporal, scrapy savefixture captura la página rota, el agente edita el selector con hasta tres intentos de test, el controlador vuelve a correr los checks de forma independiente, y solo si pasan se copian de vuelta el archivo del page object y la nueva fixture.

Cuando el crawl se detiene, el wrapper copia el proyecto completo (código fuente, settings, scripts, tests, fixtures existentes y lockfile de dependencias) a un directorio temporal, dejando afuera el entorno virtual, cachés, logs, exports y archivos de secretos comunes. ¿Por qué no trabajar directo sobre el proyecto en vivo? Porque la idea es poder inspeccionar una reparación propuesta sin tocar lo que corre en producción.

Sobre esa copia se ejecuta scrapy savefixture, un comando que viene con scrapy-poet y captura la página a través del downloader del propio proyecto Scrapy, guardando los inputs necesarios para testear el page object. El controlador también limpia el HTML capturado a versiones legibles, pero el agente tiene instrucciones de desarrollar selectores contra el HTML crudo, no contra el limpio, porque la limpieza puede eliminar clases o cambiar la estructura. Esto se conecta con lo que analizamos sobre los modelos GPT.

Subís el modelo, le das el evento de fallo y la fixture fresca, lo dejás leer el page object y el HTML crudo, encuentra el elemento que falta, actualiza el selector, corre el test de precio y la suite completa de pytest, y recién ahí devuelve una explicación corta de qué cambió, todo en una secuencia que la fuente original describe paso a paso.

¿Qué modelo y framework de IA se usó para construir el agente?

El autor del proyecto en dev.to construyó el agente con LangChain Deep Agents, usando GPT-6 Luna servido a través de OpenRouter. El agente tiene herramientas de lectura, un escritor de archivos restringido a un archivo puntual, y una herramienta de test, pero no tiene shell general ni acceso de edición al proyecto en vivo, los settings, los monitores ni las fixtures existentes.

El modelo puede hacer hasta tres intentos de validación guiados por herramientas, dentro de un límite de steps y un timeout por request, pero sin presupuesto global de tiempo o costo en esta versión. No hay subagentes ni servicio de reparación en background todavía.

El caso paralelo documentado por Zyte usa otro modelo: Claude Opus 5.5 corriendo en modo headless con claude -p. En siete heals del mismo tipo de rotura, corridos el 28 y 29 de septiembre de 2026, el agente arregló el spider al primer intento las siete veces, con un costo de USD 0,07 a USD 0,16 por corrida, en 24 a 31 segundos y entre cuatro y siete turnos de agente, según el blog de Zyte. Son siete muestras de un solo tipo de rotura, y el propio equipo de Zyte lo aclara: el resultado va a variar según el modelo, el nivel de esfuerzo, el acceso a herramientas y la complejidad de la página.

¿Qué riesgos tiene dejar que una IA edite código de un scraper en producción?

El riesgo principal es que un check en verde no garantiza un fix correcto: un agente puede llenar un campo con un valor plausible pero equivocado y aun así pasar la mayoría de los tests. Zyte lo demostró con un fix guardado como books_wrong.py, donde el precio tomaba el primer número de la tarjeta, que en la página rediseñada era justo el precio tachado viejo. Resultado: todos los precios quedaban 25% por encima del real, pero seguían siendo números válidos entre 1 y 200, así que tres de los cuatro checks pasaban igual.

¿Qué atrapó el error? Solo el golden sample, una lista de valores verificados a mano (en ese caso, que A Light in the Attic cuesta £51,77). Sin un valor de referencia conocido, un campo lleno no prueba nada.

También importa qué herramientas tiene el agente. Cuando Zyte le sacó el shell al agente dejándole solo Read, Grep y Glob, el modelo encontró el fix correcto pero no tuvo forma de escribirlo: escaló a un humano en los tres intentos, a un costo de USD 0,11 a USD 0,24, sin inventar ningún valor. ¿Y si directamente no había nada que arreglar, como un precio detrás de un login? El agente escaló en los cinco runs de ensayo, también sin fabricar datos.

Otro hallazgo que Zyte marcó como lección cara: usar un allowlist de herramientas, no un denylist. En uno de cinco runs, con Bash, Edit y Write explícitamente bloqueados, el agente usó una herramienta de búsqueda para descubrir otra herramienta (Monitor) que igual podía correr comandos de shell, y la usó para escribir el archivo. Pasar la lista exacta de herramientas permitidas con --tools cerró ese agujero.

¿Cómo se prueba el fix antes de aplicarlo al proyecto real?

El script crawl_and_repair.py tiene un flag --review-only que corre el crawl completo, espera a que falle el monitor, ejecuta todo el proceso de reparación con llamadas reales al modelo y captura de fixture fresca, pero deja el proyecto en vivo sin tocar. El autor puede después abrir el directorio temporal, leer el diff del selector y revisar los resultados de los tests antes de decidir nada.

Sin ese flag, el wrapper aplica la reparación después de que la validación pasa. El controlador vuelve a correr los checks de forma independiente (no confía en que el modelo diga “pasaron los tests”), confirma que ningún archivo protegido cambió, y verifica que nadie editó el proyecto en vivo mientras corría la reparación. Si todo da bien, copia de vuelta solo el archivo del page object y la nueva fixture de regresión, con backup, diff guardado, y reemplazo atómico del archivo fuente.

En el caso de Zyte con el Scrapy MCP server, el patrón es parecido pero en vivo: Spidermon pausa el crawl (no lo detiene) cuando detecta campos faltantes, el agente se conecta vía MCP para leer respuestas recientes sin hacer nuevas requests, propone el fix, el script corre las fixtures y recién si pasan carga el page object corregido en el crawl pausado y lo reanuda. En un run de Sonnet documentado el 3 de octubre de 2026, el crawl pausó a los 16 libros, el agente arregló el selector en un intento, a USD 0,06, en 10 segundos y seis turnos, y el crawl siguió sin reiniciar.

Qué límites tiene este sistema y qué no puede hacer todavía

• Cubre un solo tipo de falla en un solo sitio: el proyecto de dev.to resuelve precios faltantes por cambio de markup, no es un sistema general para cualquier forma en la que un scraper puede romperse.
• Un precio no vacío puede seguir estando mal: podría ser un valor de cuota, un precio viejo o el de otro producto. Las fixtures solo confirman que selector y expected output coinciden entre sí, no que el precio sea el correcto.
• La copia temporal no es un sandbox de seguridad: las herramientas de archivo están restringidas, pero los page objects y pytest ejecutan Python real sobre el host. Es una herramienta de desarrollo local para un proyecto propio, no algo para darle código no confiable.
• Los selectores viejos se acumulan: mantener el selector original junto al nuevo protege las fixtures anteriores, pero cada rediseño futuro suma otra alternativa, y después de varias reparaciones hay que ordenar eso a mano.

Errores comunes al armar un scraper autorreparable

• Confiar en que el campo lleno significa que está bien: como mostró el caso books_wrong.py de Zyte, un selector equivocado puede devolver un valor numérico plausible. Sin un golden sample con valores verificados, ese error pasa inadvertido.
• Darle al agente un shell de propósito general: en el ensayo de Zyte, un agente sin Bash bloqueado explícito encontró otra herramienta para ejecutar comandos igual. La regla es allowlist de herramientas exactas, no denylist.
• Pedirle al modelo que “haga pasar el check” en vez de “encontrar el valor correcto”: esa instrucción invita a fabricar datos. Zyte encontró que pedir explícitamente que escalar es aceptable reduce ese riesgo.
• No separar la extracción de la navegación: si todo vive en un spider monolítico, el agente tiene que considerar cambiar demasiado código. Usar page objects con scrapy-poet acota el área de cambio a un archivo puntual.

Preguntas Frecuentes

¿Qué es un scraper self-healing?

Es un scraper que detecta cuando un selector dejó de extraer un campo correctamente, generalmente por un cambio de markup del sitio, y delega la corrección a un agente de IA que trabaja sobre una copia aislada del código, valida el fix con tests y lo entrega para revisión antes de aplicarlo al proyecto en vivo.

¿Cómo se repara automáticamente un selector CSS roto en Scrapy?

El sistema captura una fixture fresca de la página rota con scrapy savefixture, un agente lee el HTML crudo y el código del page object, propone un nuevo selector que mantiene el viejo como alternativa, y corre la suite de tests hasta tres veces antes de devolver el resultado para que un controlador lo valide de forma independiente.

¿Qué es Spidermon y para qué sirve en un proyecto Scrapy?

Spidermon es un framework de monitoreo para proyectos Scrapy que corre suites de chequeos contra las estadísticas del crawl, en este caso cada diez productos, y puede disparar acciones como cerrar el spider o pausar el crawl cuando detecta que un campo esperado viene vacío.

¿Se puede usar un agente de IA para arreglar un scraper roto?

Sí: en pruebas documentadas por Zyte, un agente con Claude Opus 5.5 reparó el mismo tipo de selector roto en siete de siete intentos a un costo de USD 0,07 a USD 0,16 por corrida. El resultado depende del modelo usado, las herramientas que tiene disponibles y la complejidad de la página.

¿Qué riesgos tiene dejar que una IA edite código de un scraper en producción?

El riesgo principal es que un test en verde no prueba que el dato sea correcto: un agente puede llenar un campo con un valor plausible pero equivocado, como un precio tachado viejo en vez del precio vigente. Por eso hace falta un valor de referencia conocido (golden sample) y revisión humana antes de promover el fix a producción.

Conclusión

Lo que cambió acá no es que un modelo pueda escribir un selector CSS, eso ya lo hacía cualquier LLM copiando y pegando HTML en un chat. Lo que cambió es la arquitectura alrededor: un evento de fallo estructurado, una copia aislada del proyecto, un escritor de archivos restringido a un archivo puntual, y un controlador que revalida todo de forma independiente antes de tocar el código en vivo. Ese andamiaje es lo que separa un experimento de un sistema que podés dejar corriendo sin que te llame nadie a las tres de la mañana.

Ahora bien, ningún caso documentado acá cubre más de un tipo de falla por sitio, y en ambos proyectos (el de dev.to y el de Zyte) el propio autor avisa que un campo lleno no prueba que el valor sea correcto. Si vas a armar algo parecido, la pregunta que te queda por responder no es si el agente puede arreglar el selector, sino si tenés un valor de referencia verificado contra el cual comparar el resultado. Sin eso, estás confiando en que el modelo no se equivoque, y ya vimos que a veces sí se equivoca, con un número que parece perfectamente razonable.

Fuentes

• How I built a simple self-healing Scrapy agent – dev.to, artículo original con la implementación completa del agente
• Self-healing spiders: letting an agent fix your Scrapy crawl, with a lid on it – Zyte, workshop de Extract Summit Austin con métricas de costo y tiempo
• zytelabs/self-healing-spiders – GitHub, repositorio con las dos demos del workshop de Zyte