El autor de una plataforma de seguros con 20 años de antigüedad procesó 108 tickets de soporte a través de un flujo de agentes de IA personalizado, y el resultado es un flujo de trabajo que convierte una tarea de varias horas para un desarrollador senior en apenas unos minutos, un cambio que podría redefinir cómo las empresas mantienen vivo el código heredado.

Por qué los sistemas heredados importan más que el código nuevo

La aplicación de seguros en cuestión es un monolito de 2,3 millones de líneas de código y aproximadamente 1.000 paquetes PL/SQL. Su tamaño por sí solo hace que sea imposible que una sola persona sea dueña de toda la base de código. Si a esto se le suma un laberinto de parámetros de configuración específicos para cada cliente, documentación dispersa y un archivo de tickets que se remonta a 2017, el verdadero cuello de botella pasa a ser "encontrar el contexto" y no escribir código.

El auge actual de la IA suele centrarse en generar código nuevo para proyectos desde cero (greenfield). En este caso, la parte difícil no es la sintaxis de PL/SQL, sino localizar la pieza exacta de lógica, la configuración relevante y el ticket histórico que describió el problema por primera vez. Un desarrollador experimentado puede pasar horas reuniendo pistas de GitLab, SVN, wikis y antiguos tickets de soporte. El agente de IA realiza el mismo trabajo en minutos.

El flujo de trabajo en la práctica

Cuando llega un nuevo ticket, el autor ejecuta un único comando. El agente entonces:

  • Extrae el texto del ticket y cualquier archivo adjunto a través de la API del sistema de tickets.
  • Ejecuta una búsqueda de palabras clave y vectorial en todo el archivo de tickets para encontrar casos pasados similares.
  • Consulta una biblioteca personal de scripts SQL reutilizables.
  • Inspecciona el historial de código en los sistemas de control de versiones (GitLab o SVN).

Todos los hallazgos se compilan en un único archivo que también sugiere el siguiente paso, que suele ser una corrección de código, un borrador de respuesta al cliente o una solicitud de diagnósticos adicionales.

Capacidades integradas

El autor ha definido 24 "habilidades" para el agente, agrupadas en cuatro categorías:

  • Acceso al contexto – lectura de APIs, manuales y bases de datos para extraer hechos relevantes.
  • Conocimiento del dominio – interpretación de las reglas de contabilidad de seguros y la arquitectura del sistema.
  • Escritura – generación de fragmentos de PL/SQL y su empaquetado para el despliegue.
  • Meta – reconocimiento de patrones y creación automática de nuevas habilidades cuando sea necesario.

Estas habilidades permiten que el agente actúe como un ingeniero junior que nunca duerme, presentando la línea exacta de código o la configuración a la que hace referencia un ticket.

Redes de seguridad integradas en el ciclo

La automatización en un entorno de producción exige salvaguardas. El autor sigue dos reglas sencillas:

  1. Validación estática – cada script generado se somete a un EXPLAIN PLAN contra el esquema en vivo. Esto comprueba errores sintácticos o lógicos sin ejecutar realmente el código.
  2. Confirmación de modelo dual – un segundo agente de IA independiente revisa cualquier cambio considerado de riesgo. Si ambos modelos llegan a la misma conclusión, el autor procede; de lo contrario, el ticket se escala para una revisión manual.

Estas comprobaciones evitan que el proceso se convierta en una caja negra que pudiera romper inadvertidamente una transacción de seguros crítica.

Beneficios compuestos

El resultado de cada ticket se adjunta de nuevo al registro del mismo, creando una base de conocimientos viva. Cuando un problema similar resurge meses o años después, el agente puede leer no solo la solución anterior, sino también el razonamiento que condujo a ella. En efecto, cada ticket resuelto se convierte en datos de entrenamiento para futuros tickets, acelerando aún más el ciclo.

Limitaciones honestas

  • Las pruebas manuales persisten – el autor sigue validando los cambios en un entorno de prueba antes de su implementación.
  • Sin métricas de parada estricta – aunque el tiempo ahorrado parece sustancial, el autor no ha cuantificado la reducción exacta en horas.
  • Configuración personal – la implementación actual reside en una única estación de trabajo; escalarla a un equipo requeriría ingeniería adicional.

Estas limitaciones impiden que el enfoque sea un producto llave en mano, pero no disminuyen la idea central: la IA puede reducir drásticamente la recopilación de contexto de horas a minutos.

Qué observar a continuación

El experimento del autor es una prueba de concepto más que una oferta comercial. Los siguientes pasos lógicos incluyen:

  • Formalización de métricas – realizar un seguimiento del tiempo de resolución de tickets antes y después del pipeline de IA para construir un caso de negocio.
  • Despliegue en equipo – empaquetar el agente como un servicio compartido para que múltiples ingenieros puedan beneficiarse de la misma base de conocimientos.
  • Integración con CI/CD – alimentar directamente los scripts validados en un pipeline de integración continua podría cerrar el ciclo desde el ticket hasta la producción sin necesidad de una transferencia manual.

Si estas extensiones tienen éxito, el modelo podría convertirse en una plantilla para otras empresas que luchan con bases de código masivas y arraigadas.

Conclusión

El verdadero valor de la IA en entornos heredados no reside en la escritura automática de código nuevo, sino en hacer emerger instantáneamente el contexto adecuado. Al convertir las horas de labor de investigación de un desarrollador senior en unos pocos minutos, un flujo de trabajo de agentes de IA puede mantener funcionales los sistemas antiguos, reducir los costes de soporte y construir gradualmente un repositorio de conocimientos que se refuerce a sí mismo. El experimento demuestra que, para el software heredado, el mayor impulso de productividad proviene de reducir drásticamente la búsqueda de respuestas, no de la generación de código nuevo.