Este artículo es la segunda entrega de una serie sobre la calidad en Powens. En esta ocasión, explicamos cómo hemos empezado a experimentar con agentes de IA para acelerar el mantenimiento de los conectores. Aviso: todavía estamos en una fase temprana y todo puede cambiar rápidamente.
Como explicamos en nuestro primer artículo, los servicios de conectividad como Powens (piensa en Zapier, pero para conectar cuentas bancarias) tienen unas limitaciones de mantenimiento muy particulares.
Imagina que tu software es, por definición, un conjunto de integraciones con sistemas externos que no controlas: eso significa que, literalmente, importas cientos de incidencias, de forma aleatoria. Los bancos actualizan sus webs. Las API cambian sin previo aviso. Cada vez que eso ocurre, un conector se rompe y alguien tiene que repararlo.
En el artículo anterior describimos cómo priorizamos qué anomalías corregir primero. Es un proceso humano tradicional, apoyado en herramientas de monitorización inteligentes. El sistema funciona bien: garantiza que las incidencias adecuadas reciban atención.
Pero no resuelve un problema más de fondo: la capacidad. Nuestro equipo de mantenimiento de conectores, X-Connectors, solo puede resolver una parte del número medio de anomalías únicas que detectamos cada mes.
Al centrarnos en las incidencias que afectan a más usuarios, podemos garantizar un servicio estable al 99 % de ellos. Pero eso significa que muchas anomalías siguen sin corregirse, aunque solo afecten a un puñado de usuarios de bancos más pequeños. Y eso, por supuesto, resulta muy frustrante para nosotros y para nuestros clientes.
Además, como algunos ya sabréis, cuando se trata de hacer scraping de datos financieros, las correcciones pueden llevar mucho tiempo. Reproducir el error suele ser ligeramente más complicado que con un bug de software típico. Nuestros protocolos de seguridad prohíben a los desarrolladores usar las credenciales de los usuarios finales para facilitar la depuración.
En su lugar, nos basamos en los registros de las sesiones de navegación y en una serie de herramientas internas que nos ayudan a localizar el problema. Pero no es perfecto y, a menudo, depurar es un proceso de prueba y error.
Así que aquí está la pregunta del millón: ¿puede un LLM hacer ese trabajo? ¿Puede ayudarnos a corregir las incidencias de menor prioridad que nuestros desarrolladores no tienen capacidad de atender y, con el tiempo, acelerar también la resolución de las de mayor prioridad?
Cuando piensas trabajar con LLM para el web scraping, te vienen a la cabeza dos enfoques radicalmente distintos. Y elegir entre ellos dice mucho de tus prioridades.
El primer enfoque consiste en meter el LLM en el circuito en tiempo de ejecución. Cada vez que haces scraping de un banco, el modelo interpreta el HTML en bruto y extrae los datos sobre la marcha. Básicamente, el LLM se convierte en el scraper.
No hay código rígido que mantener: el modelo se adapta dinámicamente a cada web bancaria y a cada sesión de navegación. Si el banco rediseña su web de la noche a la mañana, el modelo simplemente descifra el nuevo diseño. Cero interrupciones. Es elegante, y podría ser el futuro a largo plazo de la extracción de datos.
Pero, hoy por hoy, tiene dos obstáculos insalvables:
El segundo enfoque consiste en mantener conectores programados a mano, pero hacer que el LLM escriba las correcciones como lo haría un desarrollador. El modelo analiza el problema, genera el código y abre una pull request.
Un desarrollador humano la revisa y la integra. Con este método, el coste baja a entre 5 y 15 € por corrección, un gasto único. El código es determinista una vez desplegado. Y cada cambio pasa por una revisión humana antes de llegar a producción, así que tenemos más control.
Es menos vistoso, desde luego. Pero somos una empresa que gestiona millones de conexiones bancarias y opera bajo regulación financiera: el control no es un extra. Así que tomamos la decisión obvia y optamos por “el LLM corrige los conectores”.
Y aquí viene el giro: estos dos enfoques no son excluyentes. Ya podemos imaginar un modelo híbrido en el que la extracción en tiempo de ejecución sirva de respaldo para los casos límite (el 5 % de usuarios que se topan con un diseño de página poco habitual), mientras el enfoque basado en código se encarga del funcionamiento habitual. Pero eso lo dejamos para otro artículo.
La infraestructura de conectores de Powens se basa en Woob, un framework de código abierto que llevamos años desarrollando, pero del que a menudo se burlan los desarrolladores que se incorporan a Powens. Les parece arcano, rígido y, a veces, demasiado pesado para tareas sencillas.
Así que, cuando nos planteamos por primera vez que una IA escribiera código Woob, hubo escepticismo interno. Woob no es precisamente mainstream. ¿Podría un modelo de lenguaje entender un framework de nicho lo bastante bien como para producir conectores fiables?
Una primera prueba de concepto, ejecutada en directo sobre una cuenta bancaria real, zanjó el debate bastante rápido.
Resulta que un framework estructurado es una ventaja, no un obstáculo. El núcleo de Woob se encarga de todo el código repetitivo: sesiones HTTP, gestión de cookies, paginación, gestión de errores. Un conector solo contiene la lógica propia de la web del banco: qué página visitar, qué campos extraer, cómo navegar entre secciones.
Eso significa que el LLM trabaja con archivos pequeños y bien acotados, en lugar de scripts monolíticos. Y como todos los conectores siguen los mismos patrones, el modelo puede aprender las convenciones de uno y trasladarlas a otro.
Sin un framework, el modelo tiende a producir código improvisado: llamadas HTTP encadenadas, gestión de errores en línea, navegación tipo espagueti. Con Woob, produce código estructurado y mantenible que un desarrollador acostumbrado al framework puede revisar en un tiempo razonable.
Si estás valorando un enfoque similar para tu propio código, probablemente esta sea la lección más importante: ponle barreras al modelo y la calidad del resultado mejora de forma espectacular.
Al final, tardamos un par de meses en tener el primer prototipo de nuestro reparador de conectores con IA. Lo llamamos woob-autofix (qué originales, ¿eh?). Su principio de diseño es sencillo: el agente sigue exactamente el mismo flujo de trabajo que un desarrollador humano.
Y ahí se detiene. El agente nunca integra su propio código. El equipo X-Connectors revisa cada pull request exactamente igual que cualquier contribución escrita por una persona. Una vez más, nos pareció obvio tomar esta decisión de diseño tan estricta por ahora. No descartamos pasar a un enfoque más flexible en el futuro. Pero eso exigirá bastante aprendizaje y evaluación y, por supuesto, pruebas sólidas de que woob-autofix puede mantener un rendimiento de nivel humano de forma constante en el tiempo.
Por dentro, el agente funciona con Claude a través del SDK de Claude Code. Al principio ejecutamos en paralelo Claude Code y Kiro (el agente de programación de AWS). Pero Kiro no tenía un SDK nativo, lo que obligaba a lanzar el ejecutable, analizar su salida y perder contexto entre pasos. El SDK de Claude Code permitió una integración fluida en nuestro pipeline de orquestación, con continuidad total del contexto. Tomamos la decisión pragmática de consolidar, y los resultados mejoraron.
Cuando escribimos el primer borrador de este artículo, trabajábamos con Opus 4.6, pero el salto desde 4.5 no fue tan bueno como esperábamos. Nuestros prompts de 4.5 eran algo demasiado directivos para 4.6, que necesita un poco más de margen para dar buenos resultados. Tras un tedioso trabajo de reingeniería de prompts, la cosa mejoró. Desde entonces, gestionamos mejor estas actualizaciones. En el momento de publicar este artículo, ya trabajamos con Opus 5.5.
Pregunta a cualquiera que esté creando herramientas de desarrollo asistidas por IA cuál es el mayor reto, y es probable que oigas mucho “prompt engineering”. Es cierto que supone mucho trabajo, probablemente la mayor parte en términos cuantitativos. Pero no es lo más difícil.
El problema realmente difícil es saber si de verdad estás mejorando. En la mayoría de los proyectos de software, la calidad del código generado por IA se mide con tests unitarios o escenarios fijos. Pero nosotros no podemos hacerlo, ni aunque resolviéramos todos los retos de seguridad posibles.
Las webs de los bancos evolucionan constantemente. Un caso de prueba de hace tres meses puede apuntar a un diseño de página que ya no existe, con la sesión de un usuario que desde entonces ha cerrado su cuenta. Nuestra verdad de referencia tiene fecha de caducidad.
Así que tomamos prestada una idea de las finanzas cuantitativas: el backtesting. Volvemos atrás en el tiempo, tomamos un ticket de JIRA de hace dos meses, recuperamos el código tal como estaba y dejamos que el agente intente la corrección. Después comparamos su pull request con la que el desarrollador humano publicó realmente. Un juez LLM independiente evalúa ambas soluciones frente al enunciado original del problema.
Este enfoque detectó algo que los tests por sí solos nunca habrían detectado. Al principio, el agente tenía un truco favorito: “resolvía” los errores capturando las excepciones en lugar de atacar la causa raíz. Se acabaron los fallos, técnicamente. Pero también se acabaron los datos. Al compararlo con una referencia humana, el juez puede distinguir entre una corrección real y un parche.
¿En qué punto estamos hoy? El agente produce una corrección al menos tan buena como la del desarrollador en el 25-30 % de los casos, al primer intento y sin comentarios de revisión. Cuando empezamos, era alrededor del 10 %. Y tenemos motivos para pensar que nos quedamos cortos: las primeras revisiones humanas sugieren que el juez LLM es demasiado estricto en algunos casos. Ahora mismo estamos haciendo rondas de calibración con el equipo X-Connectors.
Incluso cuando la corrección no es perfecta, el ahorro de tiempo es real. El agente tarda entre 10 y 15 minutos. Un desarrollador, uno o dos días. Incluso una corrección que necesita ajustes le da al revisor una ventaja enorme. Y recordad: probablemente esas correcciones nunca se habrían hecho. Así que mejor hecho que perfecto.
Pero cuando la corrección es buena, puede ser realmente buena.
En un caso, un ticket indicaba que varias cuentas de un gran banco francés estaban mal clasificadas (es decir, confundíamos cuentas corrientes, cuentas de ahorro u otros tipos). El agente confirmó el problema y, sin que nadie se lo pidiera, hizo una búsqueda web del nombre comercial de cada cuenta para determinar su tipo correcto.
Identificó un PEA (un plan de ahorro en acciones francés), una cuenta de valores y otras, y actualizó el conector en consecuencia. Un razonamiento puramente de negocio que ninguno de nosotros había diseñado de forma explícita.
En otro caso, un conector no conseguía recuperar los movimientos de una cuenta concreta. El agente se dio cuenta de que el patrón de la URL no coincidía con el de las demás páginas. Así que empezó a experimentar: reconstruyó la URL combinando el nombre de la cuenta y el tipo de producto, probó varias variantes, encontró una que devolvía datos válidos e implementó la lógica de análisis.
Un enfoque de ingeniería por prueba y error, justo lo que haría un desarrollador con las herramientas de desarrollo del navegador abiertas.
Ninguno de estos comportamientos estaba programado. El agente los dedujo del contexto. Y eso es precisamente lo que hace prometedor este enfoque: no es un script con mil reglas. Es un modelo que razona sobre los problemas.
Todos los clientes de agregación se benefician de este desarrollo. En el último sprint dedicamos un 40 % menos de tiempo al mantenimiento y más que duplicamos la calidad de los conectores del nivel más bajo (su tasa de éxito pasó del 27 % a más del 60 %). De cara a los próximos seis meses, los clientes pueden esperar tiempos de resolución mucho más cortos para las incidencias de los conectores y una mejor calidad del servicio en el día a día. — Vincent Paredes, VP AI & Technology
Hoy, woob-autofix se ocupa de los conectores de scraping de la vertical Wealth (cuentas de ahorro e inversión, no cubiertas por las API PSD2). Hemos empezado a ampliarlo a los conectores PSD2, empezando por los problemas de tipología de cuentas. La recuperación de documentos debería llegar pronto.
El gran salto que tenemos por delante es la navegación. Actualmente, el agente solo puede trabajar con las páginas que el conector ya conoce, al menos en la mayoría de los casos. Por eso estamos desarrollando un acceso controlado al navegador para que el agente pueda descubrir nuevas páginas de forma autónoma, con restricciones estrictas.
Más adelante, queremos cerrar el círculo por completo. Hoy, el agente recoge tickets de JIRA: incidencias que ya han sido detectadas, clasificadas y notificadas por personas. Pero nuestra monitorización ya captura los fallos en tiempo real. Imagina: un banco publica un cambio que rompe el conector a medianoche. El agente detecta el error, propone una corrección y abre una PR. Un desarrollador la revisa a las 9 de la mañana. A las 10, el conector vuelve a funcionar. Hacia ahí vamos.
Por último, ya estamos experimentando con la otra cara de reparar conectores: crearlos. Imagina que cualquier petición de un cliente (o de un usuario final) para conectar un banco o una plataforma muy concretos, todavía no disponibles, pudiera atenderse en una hora. Puede que no sea tan descabellado, pero eso lo dejamos para otro artículo.
Como veis, no estamos sustituyendo a los desarrolladores por IA. Les estamos dando palanca. El equipo X-Connectors sigue revisando cada corrección, sigue siendo el responsable del código y sigue tomando las decisiones. Pero, en lugar de dedicar dos días a un cambio de parsing, pueden dedicar quince minutos a revisar una pull request bien estructurada y reorientar su experiencia hacia trabajo más complejo y de mayor valor. Y les alegra saber que, por fin, algunas incidencias de menor prioridad se van a resolver.
En nuestro sector, la confianza lo es todo. Nuestros clientes dependen de nosotros para obtener datos financieros críticos. Por eso elegimos el enfoque que mantiene a las personas al mando y usa la IA donde mejor rinde: velocidad, reconocimiento de patrones e iteración incansable. Es la misma filosofía que guía nuestro sistema de clasificación por niveles, nuestra monitorización y todo lo que construimos. Hacer el trabajo difícil. Ser transparentes al respecto. Y no ceder nunca en los controles.