Beyond Local Code Optimization: Multi-Agent Reasoning for Software System Optimization

Este artigo propõe um framework multi-agente que supera as limitações das otimizações locais ao integrar representações de fluxo de controle e dados com dependências arquiteturais para realizar otimização de desempenho em nível de sistema em microsserviços, alcançando melhorias significativas de 36,58% na vazão e 27,81% no tempo de resposta.

O essencial

Imagine que você tem uma equipe de especialistas tentando consertar o tráfego de uma grande cidade.

O Problema (A Abordagem Antiga):
Até agora, a inteligência artificial (IA) que escreve código funcionava como um mecânico de rua muito rápido, mas com visão de túnel. Se você mostrasse a ele um carro com o motor barulhento, ele consertaria aquele motor específico. Mas ele não sabia que o barulho do motor estava fazendo o motorista gritar, o que por sua vez estava atrapalhando o trânsito na avenida principal, ou que o sistema de freios de outro carro estava sendo afetado.

A maioria das IAs atuais olha apenas para um pequeno pedaço de código (uma função ou um arquivo) e tenta otimizá-lo. Elas não entendem como as peças do sistema conversam entre si. Em sistemas modernos, onde tudo é conectado (como microserviços, bancos de dados e nuvem), consertar uma peça isolada muitas vezes não resolve o problema real, que é como as peças interagem.

A Solução (A Abordagem do Artigo):
Os autores deste artigo criaram um "Conselho de Arquitetos e Engenheiros" (um sistema de múltiplos agentes) para olhar para a cidade inteira, não apenas para um carro.

Eles dividiram o trabalho em quatro especialistas que trabalham juntos, como se fosse uma orquestra:

1. O Cartógrafo (Agente de Resumo):

   • O que faz: Ele lê todo o código e desenha um mapa gigante. Ele não olha apenas para as linhas de texto, mas entende a "arquitetura": quem fala com quem, onde estão os dados, como o sistema é montado e qual é o ambiente (quantos processadores, qual linguagem, etc.).
   • Analogia: É como um urbanista que mapeia todas as ruas, pontes e semáforos da cidade antes de tentar mudar qualquer coisa.

2. O Detetive (Agente de Análise):

   • O que faz: Ele usa o mapa do Cartógrafo para encontrar os "engarrafamentos". Ele não olha apenas onde o carro está lento, mas pergunta: "Por que o carro está lento? É porque a ponte está estreita? É porque o semáforo está mal configurado?". Ele identifica gargalos que acontecem entre os serviços, não apenas dentro de um código.
   • Analogia: É o detetive que percebe que o trânsito não está ruim porque o carro é velho, mas porque dois semáforos estão descoordenados, fazendo todos pararem ao mesmo tempo.

3. O Engenheiro Criativo (Agente de Otimização):

   • O que faz: Com base na análise do Detetive, ele propõe mudanças reais no código. Mas ele é cuidadoso: ele sabe que não pode quebrar a "porta de entrada" do prédio (as interfaces públicas), senão ninguém consegue entrar. Ele faz ajustes precisos, como reorganizar o fluxo de dados ou mudar como as conexões são feitas.
   • Analogia: É o engenheiro que decide: "Vamos mudar o semáforo para um sistema inteligente que não para o trânsito se não houver carros, ou vamos alargar a ponte".

4. O Fiscal de Trânsito (Agente de Avaliação):

   • O que faz: Antes de aplicar a mudança na cidade real, ele testa em um simulador. Ele verifica: "Se fizermos isso, o sistema vai quebrar? Vai ficar mais rápido?". Se passar no teste, ele aplica a mudança e mede a diferença.
   • Analogia: É o fiscal que coloca o novo sistema de trânsito em um simulador para garantir que ninguém vai bater e que o tempo de viagem vai realmente diminuir.

O Resultado da Experiência:
Eles testaram esse "Conselho" em um sistema de loja online fictício (chamado TeaStore). O resultado foi impressionante:

• O sistema processou 36% mais pedidos por segundo (como se a cidade conseguisse lidar com muito mais carros ao mesmo tempo).
• O tempo de resposta caiu 27% (os carros chegaram mais rápido ao destino).

Em resumo:
Este artigo diz que para otimizar software moderno, não basta pedir para a IA "consertar essa linha de código". É preciso ter uma equipe de IAs que entenda a arquitetura completa, como as peças se conectam e como o sistema se comporta como um todo. É a diferença entre tentar consertar um carro peça por peça e redesenhar todo o sistema de trânsito de uma cidade para que todos cheguem mais rápido.

Resumo técnico

1. Problema e Motivação

O artigo aborda uma limitação crítica nas abordagens atuais de otimização de software impulsionadas por Inteligência Artificial (IA) e Grandes Modelos de Linguagem (LLMs).

• Limitação Atual: Os métodos existentes operam predominantemente em escopos locais (funções individuais ou arquivos), focando em transformações de código baseadas em sintaxe.
• O Desafio: Em sistemas modernos, especialmente arquiteturas de microsserviços, os gargalos de desempenho raramente são isolados. Eles emergem de interações complexas entre componentes, como bancos de dados, middleware, infraestrutura compartilhada e padrões de comunicação (ex: latência de rede, contenção de recursos).
• A Lacuna: A otimização puramente local falha em capturar o comportamento do sistema como um todo e identificar gargalos transversais (cross-cutting). O problema central é: Como automatizar a identificação e o raciocínio sobre problemas de desempenho de todo o sistema, derivados da arquitetura e interações entre componentes, mantendo a correção do código?

2. Metodologia: Framework Multi-Agente

Os autores propõem um framework inovador que eleva o raciocínio de desempenho do nível de código local para o nível do sistema inteiro. O sistema é decomposto em um pipeline de quatro agentes coordenados que operam sobre representações persistentes do sistema:

A. Agentes de Sumarização (Summarization Agents)

Utilizam análise estática para extrair evidências e criar um contexto rico para o raciocínio:

1. Agente de Resumo de Componentes: Extrai a arquitetura estrutural (limites de serviço, classes, pacotes), mapeia dependências (chamadas, recursos) e interfaces expostas.
2. Agente de Resumo de Comportamento: Captura propriedades de execução, como grafos de chamadas interprocedurais, estruturas de fluxo de controle, pontos de sincronização (locks) e padrões de acesso a banco de dados.
3. Agente de Resumo de Ambiente: Extrai contexto de execução e implantação (configurações de compilador, arquitetura de hardware, dependências) que influenciam o desempenho, mas não estão no código-fonte.

B. Agente de Análise (Analysis Agent)

• Consome os resumos estruturados gerados anteriormente.
• Identifica e prioriza oportunidades de otimização analisando sinais de desempenho (ex: padrões de acesso a dados, topologia de interação).
• Gera um relatório estruturado com prioridades baseadas em evidências, localizações de origem e estimativas de impacto.

C. Agente de Otimização (Optimization Agent)

• Traduz as intenções de alto nível do agente de análise em modificações de código concretas e verificáveis.
• Aplica mudanças direcionadas (ex: padrões de design, refatoração de concorrência).
• Restrição de Segurança: Todas as modificações são não-breaking (não quebram compatibilidade), proibindo alterações em APIs públicas ou interfaces de serviço para garantir a correção funcional.

D. Agente de Avaliação de Desempenho (Performance Evaluation Agent)

• Valida a correção funcional (usando suites de testes automatizados) e mede o impacto de desempenho.
• Realiza perfilamento dinâmico sob cargas de trabalho representativas, comparando métricas (latência, throughput, uso de recursos) com a linha de base.
• O ciclo é iterativo: os resultados alimentam o sistema para refinar futuras otimizações até que não haja mais melhorias possíveis.

3. Contribuições Principais

1. Novo Framework Multi-Agente: Uma arquitetura que integra análise estática (fluxo de controle e dados) com sinais de dependência arquitetural para raciocínio de desempenho em nível de sistema.
2. Abordagem Holística: Supera a visão fragmentada de otimização local, focando em gargalos que surgem da interação entre microsserviços e infraestrutura.
3. Prova de Conceito (PoC): Implementação funcional e avaliação em um sistema real de microsserviços.

4. Resultados Preliminares

O framework foi testado em um protótipo aplicado ao TeaStore, uma aplicação de varejo online baseada em Java com seis microsserviços.

• Configuração: Utilizou o modelo LLM gpt-5.2 (SOTA em Jan/2026) e a ferramenta de análise estática CodeQL.
• Otimizações Identificadas:
  • O1: Reutilização de clientes HTTP via padrão Singleton para evitar inicialização redundante de pools de conexão.
  • O2: Remoção de contenção de locks substituindo métodos synchronized por flags volatile em caminhos críticos.
  • O3: Redução de alocação de objetos reutilizando instâncias de ObjectMapper.
• Métricas de Desempenho:
  • Aumento de Throughput: +36,58% (de 1197,79 para 1635,89 req/sec).
  • Redução no Tempo Médio de Resposta: -27,81% (de 12,84ms para 9,27ms).
  • Melhoria na Latência: Reduções significativas também observadas nos percentis P50, P90 e P99.
• Custo: O processo completo consumiu ~1,6M de tokens, custou $1,28 e levou cerca de 24 minutos.

5. Significado e Impacto

Este trabalho representa um avanço significativo na engenharia de software orientada a IA:

• Mudança de Paradigma: Demonstra que é viável automatizar a engenharia de desempenho não apenas corrigindo linhas de código, mas reestruturando a interação entre componentes do sistema.
• Escalabilidade: O uso de agentes especializados permite lidar com a complexidade de sistemas distribuídos modernos, onde o desempenho é uma propriedade emergente da arquitetura.
• Futuro: Abre caminho para ferramentas de "Engenharia de Desempenho Autônoma", onde sistemas de IA podem propor e validar refatorações arquiteturais complexas, reduzindo a dependência de especialistas humanos para tarefas laboriosas de otimização.

O artigo sugere que, ao combinar análise estática rigorosa com a capacidade de raciocínio e geração de código dos LLMs em um ciclo de feedback multi-agente, é possível alcançar melhorias de desempenho sistêmicas que métodos tradicionais ou puramente locais não conseguiriam detectar.