Os agentes de programação com IA podem ajudar as equipes de software a lidar com problemas arquiteturais que vão além da simples escrita de código, mas sua utilidade depende da clareza dos objetivos e das restrições definidos pela equipe. O artigo publicado na InfoQ, elaborado por Pierre Pureur, Kurt Bittner e Todd Miller e revisado por Daniel Bryant, alerta que fornecer ao agente apenas requisitos funcionais não garante uma arquitetura escalável, segura ou fácil de manter.
A abordagem proposta baseia-se em requisitos de atributos de qualidade (Quality Attribute Requirements ou QARs), como desempenho, segurança e escalabilidade, e no esclarecimento das compensações que o agente deve considerar. O artigo também enfatiza a necessidade de testar o que o agente produz com métricas claras, em vez de se limitar a examinar o código ou confiar em suas recomendações.
1. Documentar serviços legados antes de depender deles
Uma arquitetura moderna pode depender de um serviço legado que desempenha uma função específica, como recuperar dados de apólices de seguro de um sistema antigo baseado em um banco de dados IMS. O problema é que esses serviços podem não ter uma documentação precisa, o que dificulta compreender os fluxos de dados ou detectar defeitos lógicos e de segurança que podem surgir em fases posteriores do desenvolvimento ou após a entrada em produção.
O agente pode desenhar o projeto do serviço e documentar os fluxos de dados, além de examinar o código e sugerir correções ou uma reestruturação caso o serviço seja difícil de entender e manter. No entanto, esse uso não elimina a necessidade de uma decisão de engenharia humana sobre se o serviço pode ser mantido ou se seus riscos exigem sua substituição.
2. Procurar defeitos arquiteturais
O agente pode ser orientado a encontrar violações de padrões arquiteturais, práticas de software degradadas ou partes que precisam ser reestruturadas. Os exemplos de verificação incluem o design de interfaces de programação de aplicações, interfaces complexas, inseguras ou ineficientes e violações dos limites do design orientado a domínios (DDD).
O artigo observa que o agente provavelmente encontrará muitas melhorias; por isso, a equipe deve distinguir entre problemas importantes e sugestões de baixo valor. A qualidade dos resultados aumenta quando os engenheiros definem objetivos mensuráveis, alternativas conhecidas e compensações claras, em vez de se limitarem a descrever as funções desejadas.
3. Auditar a segurança com o isolamento do agente
O agente pode ser usado para desenhar fluxos de dados, identificar arquivos de alto risco, examinar defeitos lógicos complexos, criar testes ou scripts que simulem tentativas de exploração e, em seguida, sugerir correções para os problemas detectados. O artigo apresenta uma experiência que envolveu pacotes npm classificados como representantes de um risco de segurança; dois pacotes foram atualizados, um pacote foi substituído e outro foi mantido depois que o alerta foi considerado um falso positivo.
No entanto, esse uso exige restrições operacionais explícitas: limitar o acesso do agente aos arquivos autorizados, ocultar senhas de bancos de dados e segredos, executar os testes em uma rede isolada e exigir revisão humana antes de integrar qualquer alteração.
4. Criar uma base arquitetural para protótipos
A velocidade dos agentes permite construir rapidamente um protótipo, mas o resultado pode ser temporário e inadequado se não forem definidos objetivos arquiteturais. O artigo propõe preparar aplicações estruturais predefinidas que incluam o estilo de escrita do código, o design do banco de dados, as interfaces, as plataformas e os frameworks preferidos, além de QARs escritos em Markdown.
Também é possível usar modelos do GitHub para padronizar a estrutura inicial das aplicações e incluir os padrões da equipe desde o início. O ideal é descrever o objetivo, as restrições e a forma de verificar se foram alcançados, em vez de impor previamente ao agente uma solução detalhada.
5. Gerar arquiteturas iniciais testáveis
O artigo propõe usar o agente para criar Minimum Viable Architectures ou MVAs, que não se limitem a um código que comprove as funcionalidades, mas incluam também os testes, os dados de teste e o ambiente de execução necessários para verificar os QARs. O agente pode gerar ferramentas de teste e configurações de contêineres, mas a equipe deve assegurar que os testes realmente meçam os atributos exigidos.
Também deve ser avaliada a capacidade da MVA de acomodar cenários de mudança arquitetural, pois ampliar uma arquitetura gerada automaticamente pode se tornar caro se ela não tiver sido projetada para evoluir.
O que muda na prática?
A mensagem central do artigo é que os agentes de programação tornam a produção de código mais rápida, mas aumentam a importância da formulação de requisitos, restrições e testes. As habilidades relacionadas à escrita de código não desaparecem, mas definir o que deve ser construído, o que constitui uma qualidade aceitável e como ela será medida torna-se mais sensível. Portanto, o agente deve ser tratado como uma ferramenta sob supervisão arquitetural, e não como um substituto do julgamento de engenharia.