Pedir a um agente que “melhore a arquitetura” deixa em aberto o que deve melhorar e como conferir o resultado. Uma tarefa mais útil delimita uma decisão, seus riscos e a evidência necessária para aceitá-la. Este artigo propõe um registro de avaliação para uma arquitetura mínima viável, sem tratar código gerado como comprovação de qualidade.
A proposta dos autores
Em Five Ways to Use AI Coding Agents to Improve Your Software Architecture, Pierre Pureur, Kurt Bittner e Todd Miller discutem documentação de legado, identificação de problemas arquiteturais, segurança, fundações reutilizáveis e arquiteturas mínimas viáveis. O argumento é fornecer requisitos de qualidade mensuráveis e executar testes para avaliá-los. Os autores relatam experiências próprias, inclusive com dependências de um cliente. Essas experiências são deles, não de Anderson Damasio. O texto traz sugestões e exemplos; não constitui um estudo comparativo que comprove ganhos universais.
Exemplo: consulta síncrona ou projeção local?
Considere um sistema hipotético que mostra a disponibilidade de um recurso. Há duas alternativas: consultar o serviço responsável a cada pedido ou manter uma projeção local atualizada por eventos. O objetivo do experimento é escolher como responder durante uma indisponibilidade curta, não construir o produto inteiro.
Antes de gerar código, o responsável pelo produto precisa dizer quão antiga uma informação pode ser e quando a interface deve recusar apresentá-la. O agente não deve inventar esse limite. Tampouco deve transformar uma consulta de disponibilidade em promessa de reserva: confirmar uma operação continua exigindo a regra de negócio definida para ela.
Registro mínimo da decisão
- Pergunta
- Qual alternativa atende à tolerância a dados desatualizados e ao tempo de resposta aceitos para esta consulta?
- Limites a preencher
- Idade máxima do dado, latência permitida, volume esperado e comportamento quando não há informação confiável.
- Alternativas
- Consulta síncrona com falha explícita; projeção local com informação de atualização e recusa após o limite acordado.
- Evidências
- Versão do código, configuração, massa de teste, resultados por cenário e divergências encontradas.
- Decisão
- Aceita, rejeitada ou inconclusiva, com justificativa e responsável. Ausência de uma medição não conta como aprovação.
Os ensaios que diferenciam as alternativas
- Operação normal: usar a mesma sequência de alterações de disponibilidade e consultas nas duas implementações. Conferir a resposta com o estado de referência.
- Fonte indisponível: interromper somente o serviço simulado. Verificar se a resposta segue a regra definida, sem apresentar dado antigo como atual.
- Eventos duplicados ou atrasados: no protótipo com projeção, conferir se a sequência final corresponde ao estado esperado. Registrar explicitamente situações que o desenho não suporta.
- Retomada: medir quando cada alternativa volta a responder corretamente após a fonte retornar, e não apenas quando os processos ficam ativos.
- Mudança de requisito: alterar a tolerância a atraso e identificar código, configuração e testes afetados. Isso expõe o custo de evolução que o primeiro cenário pode esconder.
O agente pode preparar os dois protótipos e o executor, mas o oráculo do teste e os limites de aceite precisam de conferência independente. Se a mesma suposição equivocada aparecer no código e no teste gerado, uma execução verde não resolve a dúvida arquitetural.
Como usar o resultado
Esse roteiro é uma proposta, ainda não executada. Não há aqui benchmark, validação de produto real ou afirmação de economia. Um protótipo aprovado para consulta também não fica automaticamente aprovado para operações que alteram estado.
A questão complementar de como preservar conceitos e regras no código está na análise sobre código como modelo de domínio. Aqui, o foco é decidir entre alternativas mediante evidências.