A palestra Modern Software Architecture in the AI Era: New Patterns for Intelligent Platforms, apresentada no palco Stadium do TDC São Paulo, propôs uma provocação direta a quem acredita que IA generativa vai resolver os problemas crônicos da engenharia de software.
O ponto de partida foi histórico: a evolução do Java, do EJB clássico com "seis, sete arquivos em Java, mais um file de XML", passando por Annotations, até chegar — segundo os slides — a soluções com apenas duas classes usando Jakarta Data. A pergunta que ficou no ar: essa redução de boilerplate realmente resolveu o problema do software? Segundo a apresentação, não. Citando Gartner e Forbes, o material afirma que os problemas de décadas continuam os mesmos: alinhamento entre produto e engenharia, gestão de mudança e complexidade.
"Nós estamos gastando muito tempo em complexidade e não estamos atingindo os objetivos, mesmo usando AI."
Arquitetura como resposta ao "porquê"
A tese central, reforçada nos slides com a frase "WHY > HOW", é que a IA acelera o como construímos software, mas não responde ao porquê. Para isso, a apresentação recorreu ao Domain-Driven Design estratégico — metodologia de 2003 — como ferramenta para transformar intenção de negócio em fronteiras de sistema coerentes (domínios, subdomínios, bounded contexts), evitando o risco de "construir a coisa errada mais rápido", também citado como falha.
Dois usos de IA no dia a dia do desenvolvedor
A apresentação dividiu o uso prático de IA em duas frentes: IA no desenvolvimento (geração de código, testes, refatoração, documentação, análise) e IA dentro do produto (integrações com LLMs, RAG e agentes). Para a primeira frente, os slides detalharam níveis de integração, do mais simples — Prompt-and-Paste, com contexto local e temporário — até níveis com IA operando diretamente sobre o repositório, com maior consciência de testes, convenções e arquitetura.
Um alerta prático: gerar código só tem valor quando alguém consegue avaliar o resultado. Nas palavras do palestrante:
"Não devemos confundir a habilidade de gerar código com a habilidade de validar o código."
Revisão de código, segundo a apresentação, continua obrigatória — cobrindo correção, arquitetura, segurança, testes e manutenibilidade — e regras rígidas demais podem virar "outra forma de rigidez" num software desenhado para acomodar mudança.
Agentes e padronização com MCP
A parte final tratou do espectro de autonomia de agentes de IA (de 1 a 7, do mais controlado ao totalmente autônomo), usando como exemplo um agente de e-commerce que decide cancelar um pedido chamando APIs de pagamento e atualizando status no banco. Para evitar integração customizada e frágil entre agentes e ferramentas, os slides apresentaram o MCP (Model Context Protocol) como fronteira padronizada — "padronizar a fronteira de integração, não a capacidade de negócio".
A mensagem final resume o tom da palestra: como engenheiros, é possível usar IA, mas ela não vai facilitar o trabalho de arquitetura — apenas tornar as decisões arquiteturais ainda mais determinantes.