O autor de uma plataforma de seguros com 20 anos de existência executou 108 tickets de suporte através de um pipeline de agentes de IA personalizado, e o resultado é um fluxo de trabalho que transforma uma tarefa de várias horas de um desenvolvedor sênior em apenas alguns minutos — uma mudança que pode remodelar a forma como as empresas mantêm o código legado vivo.

Por que sistemas legados importam mais do que código novo

A aplicação de seguros em questão é um monólito de 2,3 milhões de linhas de código e aproximadamente 1.000 pacotes PL/SQL. Seu tamanho, por si só, torna impossível que uma única pessoa domine toda a base de código. Some a isso um emaranhado de parâmetros de configuração específicos de clientes, documentação dispersa e um arquivo de tickets que remonta a 2017, e o verdadeiro gargalo torna-se "encontrar o contexto", não escrever o código.

O hype típico da IA moderna foca na geração de código novo para projetos greenfield. Neste caso, a parte difícil não é a sintaxe do PL/SQL, mas localizar a peça exata de lógica, a configuração relevante e o ticket histórico que descreveu o problema pela primeira vez. Um desenvolvedor experiente pode passar horas unindo pistas do GitLab, SVN, wikis e antigos tickets de suporte. O agente de IA faz o mesmo trabalho em minutos.

O fluxo de trabalho na prática

Quando um novo ticket chega, o autor executa um único comando. O agente então:

  • Extrai o texto do ticket e quaisquer arquivos anexados por meio da API do sistema de tickets.
  • Executa uma busca por palavra-chave e vetorial em todo o arquivo de tickets para trazer à tona casos passados semelhantes.
  • Consulta uma biblioteca pessoal de scripts SQL reutilizáveis.
  • Inspeciona o histórico de código nos sistemas de controle de versão (GitLab ou SVN).

Todas as descobertas são compiladas em um único arquivo que também sugere o próximo passo — geralmente uma correção de código, um rascunho de resposta ao cliente ou uma solicitação de diagnósticos adicionais.

Capacidades integradas

O autor definiu 24 “habilidades” para o agente, agrupadas em quatro categorias:

  • Acesso ao contexto – leitura de APIs, manuais e bancos de dados para extrair fatos relevantes.
  • Conhecimento de domínio – interpretação de regras de contabilidade de seguros e da arquitetura do sistema.
  • Escrita – geração de trechos de PL/SQL e empacotamento para implantação.
  • Meta – reconhecimento de padrões e criação automática de novas habilidades quando necessário.

Essas habilidades permitem que o agente atue como um engenheiro júnior que nunca dorme, trazendo à tona a linha exata de código ou configuração que um ticket referencia.

Redes de segurança integradas ao ciclo

A automação em um ambiente de produção exige salvaguardas. O autor segue duas regras simples:

  1. Validação estática – cada script gerado é executado através de um EXPLAIN PLAN contra o schema de produção. Isso verifica erros de sintaxe ou lógicos sem realmente executar o código.
  2. Confirmação por modelo duplo – um segundo agente de IA independente revisa qualquer alteração considerada de risco. Se ambos os modelos chegarem à mesma conclusão, o autor prossegue; caso contrário, o ticket é escalado para revisão manual.

Essas verificações impedem que o processo se torne uma caixa preta que possa, inadvertidamente, quebrar uma transação de seguro crítica.

Benefícios cumulativos

O resultado de cada ticket é anexado de volta ao registro do ticket, criando uma base de conhecimento viva. Quando um problema semelhante ressurge meses ou anos depois, o agente pode ler não apenas a solução anterior, mas também o raciocínio que levou a ela. Na prática, cada ticket resolvido torna-se dados de treinamento para tickets futuros, acelerando ainda mais o ciclo.

Limitações honestas

  • Testes manuais permanecem – o autor ainda valida as alterações em um ambiente de teste antes da promoção para produção.
  • Sem métricas definitivas – embora o tempo economizado pareça substancial, o autor não quantificou a redução exata em horas.
  • Configuração pessoal – a implementação atual reside em uma única estação de trabalho; escalá-la para uma equipe exigiria engenharia adicional.

Essas restrições impedem que a abordagem seja um produto pronto para uso, mas não diminuem a percepção central: a IA pode reduzir o tempo de coleta de contexto de horas para minutos.

O que observar a seguir

O experimento do autor é uma prova de conceito, e não uma oferta comercial. Os próximos passos lógicos incluem:

  • Formalização de métricas – rastrear o tempo de resolução de tickets antes e depois do pipeline de IA para construir um caso de negócio.
  • Implantação em equipe – empacotar o agente como um serviço compartilhado para que vários engenheiros possam se beneficiar da mesma base de conhecimento.
  • Integração com CI/CD – alimentar scripts validados diretamente em um pipeline de integração contínua pode fechar o ciclo do ticket à produção sem a necessidade de transferência manual.

Se essas extensões tiverem sucesso, o modelo poderá se tornar um template para outras empresas que lidam com bases de código massivas e consolidadas.

Conclusão

O real valor da IA em ambientes legados não está na escrita automática de novo código, mas em trazer instantaneamente o contexto correto à tona. Ao transformar horas de trabalho de detetive de um desenvolvedor sênior em apenas alguns minutos, um fluxo de trabalho de agente de IA pode manter sistemas antigos funcionais, reduzir custos de suporte e construir gradualmente um repositório de conhecimento que se autoalimenta. O experimento mostra que, para software legado, o maior ganho de produtividade vem de encurtar a busca por respostas, e não da geração de código novo.