Cinco formas de usar agentes de IA para fortalecer a arquitetura de software, segundo o InfoQ

Um artigo publicado no InfoQ em 28 de setembro de 2026, escrito pelos arquitetos Pierre Pureur, Kurt Bittner e Todd Miller e revisado por Daniel Bryant, resume cinco maneiras concretas de usar agentes de codificação por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → para melhorar (e não degradar) a arquitetura de um sistema. O ponto de partida dos autores é um alerta que vale para qualquer equipe que já colocou um Claude Code, Cursor ou Copilot para trabalhar em produção: agentes geram código muito mais rápido do que qualquer ferramenta de geração automática anterior, mas essa velocidade não garante nada sobre a qualidade arquitetural do resultado. Se você alimenta o agente só com requisitos funcionais, ele não vai magicamente garantir que a arquitetura é sólida. É preciso alimentá-lo com metas arquiteturais mensuráveis, os chamados QARs (Quality Attribute Requirements), e os trade-offs que a equipe está disposta a aceitar.

1. Documentar um serviço legado que ninguém entende mais

O primeiro uso sugerido é o mais direto: apontar o agente para um serviço legado sem documentação confiável. O exemplo dado no artigo é um serviço raramente usado que lê dados de um banco IMS decadas atrás, criado para um contexto que já não existe, e que pode devolver informação errada quando usado num cenário que seus autores originais nunca previram. Esses problemas costumam aparecer tarde, em teste de aceitação ou já em produção. Um agente pode mapear o design do serviço, documentar fluxos de dados, escanear o código em busca de falhas de lógica ou segurança e sugerir correções. Se o serviço estiver ruim o suficiente, o agente pode até refatorá-lo para ficar mais compreensível e sustentável, eliminando um risco antes que ele se materialize no novo sistema.

Para equipes brasileiras que ainda sustentam integrações com mainframes de bancos, seguradoras e sistemas de folha de pagamento em COBOL↳COBOL3 conteúdosA Evolução das Linguagens de Programação: de COBOL a PythonGestão Dev & TI · set 2024Dominar Cobol é um desafio para jovens profissionais de T.IGestão Dev & TI · mar 2024Aplicações com IA como aliada na geração de códigos para desenvolvedoresAI · nov 2023Ver tudo em Dev (Back & Front) → ou linguagens legadas, esse é provavelmente o uso mais imediato do artigo. Mas ele exige uma ressalva que os autores não desenvolvem em detalhe e que cabe destacar aqui: expor dados de sistemas legados a um agente de IA implica cuidado redobrado com informação sensível, sobretudo dados pessoais sob a LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI →. Mascarar segredos e restringir o acesso do agente a arquivos aprovados, como o próprio artigo recomenda no contexto de auditoria de segurança, vale igualmente para esta primeira frente.

2. Caçar falhas arquiteturais antes que virem dívida técnica

A segunda sugestão é usar o agente para encontrar problemas que vão além de segurança: padrões arquiteturais ignorados, más práticas de código, violações de fronteira em Domain-Driven Design, APIs difíceis de usar, inseguras ou ineficientes. O artigo dá um exemplo específico: pedir ao agente para avaliar a camada de serviço e identificar se algum componente acessa diretamente o estado interno de outro domínio ou reaproveita código dele indevidamente.

Os autores fazem uma ressalva importante: há um ponto de retorno decrescente nessa avaliação, porque a IA quase sempre vai encontrar alguma melhoria possível. Cabe à equipe decidir quais achados importam e quais não importam, e isso só funciona se houver alguém experiente em arquitetura conduzindo o prompt e interpretando o resultado. Um agente que recebe apenas requisitos funcionais, sem trade-offs articulados, tende a produzir um sistema que não atende aos QARs esperados. Um efeito colateral interessante apontado no texto: o próprio exercício de escrever esse prompt força a equipe a ficar mais explícita sobre trade-offs que antes ficavam só na cabeça do arquiteto mais experiente.

3. Auditoria de segurança, dependências incluídas

A terceira frente é a auditoria de segurança, com um roteiro de quatro passos descrito no artigo: mapear o design do sistema rastreando fluxos de dados e limitando o acesso do agente só a arquivos aprovados; escanear o código em busca de falhas de lógica complexas entre arquivos, mascarando senhas e segredos nos prompts; testar vulnerabilidades gerando scripts no estilo de ataque para forçar as defesas do sistema, mantendo o agente numa rede isolada para que não ataque servidores em produção por acidente; e finalmente gerar patches de correção, com revisão humana obrigatória antes de qualquer merge.

Os autores citam um caso concreto da própria prática: um cliente reportou que vários pacotes npm em uso haviam sido sinalizados como risco de segurança. Usando um agente de codificação, a equipe avaliou os riscos, produziu um relatório detalhado das implicações e, como resultado, atualizou dois pacotes, substituiu um terceiro e manteve o quarto porque o alerta era um falso positivo. Todo esse trabalho foi feito com apoio do agente. É um exemplo direto do tipo de triagem de cadeia de suprimentos que qualquer time JavaScript no Brasil já enfrentou depois de um npm audit alarmante, só que aqui automatizado e documentado.

4. Dar aos devs uma fundação arquitetural para prototipar

A quarta sugestão ataca um problema comum: agentes liberam a equipe para experimentar e mostrar um protótipo quase instantâneo a um usuário, mas, sem direcionamento arquitetural, esse protótipo tende a ser descartável porque não atende aos QARs do sistema. A saída proposta é transformar metas arquiteturais, estilos de código, design de banco, APIs, plataformas e frameworks preferidos em documentos Markdown que alimentam o agente, que então gera aplicações-esqueleto prontas como base para protótipos.

O artigo dá um exemplo prático: numa aplicação React pequena, pedir ao agente para avaliar a estrutura de pastas contra as práticas modernas da comunidade e, se estiver fora de alinhamento, aplicar ajustes, sempre com a ressalva de checar se a recomendação faz sentido para o problema em questão. Outra sugestão é usar o recurso de template do GitHub para fixar a estrutura comum de aplicações da equipe, com padrões de código já embutidos, permitindo que times comecem projetos de forma arquiteturalmente sólida desde o primeiro commit.

O argumento central dos autores aqui é o mais provocador do artigo: descrever o que se quer alcançar produz resultados melhores do que descrever a solução que o agente deve gerar. Isso inverte a hierarquia de habilidades que devs cultivaram por anos. Escrever código, o que sempre foi o ofício central, fica menos crítico. Entender e articular requisitos e restrições, tarefa que muitos desenvolvedores historicamente evitam, se torna a habilidade mais importante do dev que trabalha com IA.

5. Gerar MVAs testáveis em vez de código solto

A última frente é usar o agente para gerar uma Minimum Viable Architecture (MVA), o conjunto mínimo de código que prova que um sistema atende tanto aos requisitos funcionais quanto aos QARs. O artigo é claro sobre o limite dessa abordagem: parte do que o agente gera vai estar errado, então inspecionar o código não basta, é preciso avaliá-lo por testes mensuráveis. Se a equipe já forneceu QARs e trade-offs nos prompts anteriores, o agente tem a informação necessária para gerar também os testes: harnesses, dados de teste e configuração de ambiente, incluindo containers.

Os autores apontam um risco que a equipe precisa monitorar: o agente pode não conseguir gerar uma MVA que satisfaça plenamente os QARs, exigindo extensão manual. Para não descobrir isso tarde demais, o time pode incluir casos de mudança arquitetural na avaliação de quão adequada é a MVA gerada, antes de assumir que ela está pronta para virar base do sistema real.

O que ainda fica em aberto

Os próprios autores classificam o uso de agentes para arquitetura resiliente, escalável e segura como uma prática em estágio inicial: não há um processo consolidado, apenas sugestões testadas por eles mesmos, na tentativa e erro. O artigo não é um livro de receitas, é ponto de partida. Para quem lidera arquitetura no Brasil, o recado prático que atravessa as cinco frentes é sempre o mesmo: revisão humana antes de qualquer merge não é opcional, e o tempo que a equipe achava que estava economizando ao não escrever requisitos detalhados agora precisa ser investido justamente ali, porque é isso que separa um agente que fortalece a arquitetura de um agente que só produz código rápido e frágil.

Fonte: InfoQ