Arquitetura de Software e Design Assistido por IA: Quem Decide, Afinal?

Decisões de arquitetura de software sempre foram uma combinação de engenharia disciplinada, experiência acumulada e apostas estratégicas sob incerteza. A chegada dos Large Language Models e das ferramentas de diagrams-as-code adiciona um novo ator a esse palco: um assistente capaz de ler requisitos, sugerir padrões e gerar documentação em minutos — mas sem realmente "entender" o negócio. Esta discussão parte de um cenário concreto: após a priorização de requisitos (Aula 4), a equipe precisa projetar a arquitetura, agora com IA na mesa como coautora técnica, mas nunca como decisora final.

Com isso, surge uma questão fundamental: como integrar essas ferramentas sem abdicar do julgamento contextual que distingue o design e projeto arquitetura de software de mera aplicação de templates?

Pesquisas recentes como DRAFT-ing Architectural Design Decisions using LLMs (2025) indicam que modelos ajustados em milhares de ADRs conseguem produzir rascunhos de decisões mais eficazes que abordagens genéricas, sem substituir o julgamento humano. Em paralelo, plataformas como Structurizr (https://structurizr.com/) e Mermaid (https://mermaid.js.org/) tornaram viável manter modelos arquiteturais versionados junto ao código, permitindo que LLMs operem diretamente sobre representações textuais da arquitetura. A provocação central será: até onde podemos automatizar o "como" da arquitetura sem perder o "por quê" que só o arquiteto enxerga?

Decisões Arquiteturais: Ciência, Arte ou Algoritmo?

Arquitetura de software não é sobre encontrar a "melhor" solução, mas sobre navegar trade-offs inevitáveis. Cada decisão arquitetural implica ganhos em algumas dimensões e perdas em outras. O padrão de microservices oferece escalabilidade independente e isolamento de falhas, mas introduz complexidade operacional e latência de rede. O monolito proporciona simplicidade de deployment e debugging, mas limita escalabilidade e cria riscos de acoplamento ao longo do tempo.

Esses trade-offs não existem em abstrato, eles se manifestam diferentemente conforme o contexto. Uma startup com cinco desenvolvedores enfrentando mil requisições diárias opera em realidade fundamentalmente distinta de uma empresa com duzentos engenheiros processando milhões de transações por segundo. O mesmo padrão arquitetural que representa "best practice" em um contexto pode constituir sobre-engenharia catastrófica em outro.

Isso acontece porque decisões arquiteturais lidam com incerteza, múltiplos stakeholders e quality attributes conflitantes como, por exemplo, otimizar desempenho pode prejudicar manutenibilidade; maximizar disponibilidade pode explodir custos operacionais. Métodos como ATAM (Architecture Tradeoff Analysis Method) e CBAM (Cost Benefit Analysis Method) estruturam essa análise por meio de cenários e trade-offs explícitos, mas exigem esforço significativo de facilitação humana.

Pesquisas recentes sugerem que IA pode automatizar partes desse processo: gerar cenários de qualidade a partir de descrições em linguagem natural, mapear decisões recorrentes, reduzir trabalho mecânico. Porém, o contexto de negócio, maturidade da equipe e restrições políticas raramente aparecem nos datasets que treinam esses modelos. Assim, IA tende a favorecer "best practices" genéricas, frequentemente empurrando soluções complexas onde design mais simples seria suficiente.

Em arquitetura, automatizar o como é possível; delegar o por quê continua sendo, por enquanto, irresponsável.

É precisamente nessa sensibilidade ao contexto que reside tanto a promessa quanto o perigo da IA aplicada a decisões arquiteturais. LLMs treinados em vastos repositórios de código e documentação técnica absorvem padrões que funcionaram em contextos específicos — frequentemente em empresas de grande escala como Netflix, Amazon ou Google. Quando questionados sobre arquitetura, tendem a recomendar soluções sofisticadas que, embora tecnicamente corretas, podem ser completamente inadequadas para contextos menores ou distintos.

Princípio Fundamental: A adequação de uma arquitetura não é propriedade intrínseca do padrão escolhido, mas emerge da relação entre padrão, contexto de negócio, capacidades do time e restrições operacionais.

Essa tensão é ideal para debate: até que ponto seguir recomendação da IA é ciência baseada em evidências, e a partir de que ponto vira abdicação de responsabilidade técnica?

IA para Recomendação de Padrões Arquiteturais

A aplicação mais promissora de IA em arquitetura não está em substituir o julgamento do arquiteto, mas em sistematizar a análise de múltiplos critérios.

Sistemas de recomendação arquitetural evoluíram de abordagens rule-based para modelos de ML supervisionados e, mais recentemente, LLMs capazes de consumir descrições ricas de requisitos. Trabalhos descrevem pipelines onde requisitos funcionais, quality attributes priorizados e dados organizacionais alimentam um modelo que sugere padrões como monolito, microservices ou event-driven, com explicações textuais dos trade-offs.

O exemplo abaixo ilustra um motor simplificado de recomendação em TypeScript, inspirado em frameworks como ATAM mas automatizado via sistema de scoring:

/**

 * Sistema de Recomendação Arquitetural Multi-Critério

 * 

 * Implementa análise ponderada de adequação entre requisitos

 * e padrões arquiteturais, inspirado no ATAM (Architecture

 * Tradeoff Analysis Method) mas automatizado via scoring.

 * 

 * IMPORTANTE: Este sistema INFORMA decisões, não as TOMA.

 * O arquiteto deve validar recomendações contra contexto real.

 * Confidence < 0.6 indica necessidade de análise humana.

 */



interface SystemContext {

  load: {

    requestsPerSecond: number;

    projectedGrowth: 'stable' | 'moderate' | 'aggressive';

  };

  team: {

    size: number;

    distributedExperience: boolean;

    seniorityLevel: 'junior' | 'mid' | 'senior';

  };

  business: {

    timeToMarket: 'urgent' | 'moderate' | 'flexible';

    budget: 'constrained' | 'moderate' | 'flexible';

    regulated: boolean; // healthcare, finance = true

  };

  criticalAttributes: ('scalability' | 'performance' | 'availability' | 'maintainability')[];

}



interface Recommendation {

  pattern: 'monolith' | 'microservices' | 'event-driven';

  confidence: number;

  reasoning: string[];

  risks: string[];

  alternatives: Array<{ pattern: string; tradeoff: string }>;

}



function recommendArchitecture(ctx: SystemContext): Recommendation {

  const scores = {

    monolith: evaluateMonolith(ctx),

    microservices: evaluateMicroservices(ctx),

    eventDriven: evaluateEventDriven(ctx)

  };



  const sorted = Object.entries(scores)

    .sort(([, a], [, b]) => b.score - a.score);



  const [bestPattern, bestScore] = sorted[0];

  const totalScore = Object.values(scores).reduce((sum, s) => sum + s.score, 0);

  const confidence = bestScore.score / totalScore;



  return {

    pattern: bestPattern as Recommendation['pattern'],

    confidence,

    reasoning: bestScore.reasons,

    risks: bestScore.risks,

    alternatives: sorted.slice(1).map(([pattern, s]) => ({

      pattern,

      tradeoff: s.primaryTradeoff

    }))

  };

}



function evaluateMonolith(ctx: SystemContext): PatternScore {

  let score = 0;

  const reasons: string[] = [];

  const risks: string[] = [];



  // Carga baixa favorece monolito

  if (ctx.load.requestsPerSecond < 100) {

    score += 25;

    reasons.push('Carga atual não justifica complexidade distribuída');

  }



  // Time pequeno favorece monolito

  if (ctx.team.size < 10) {

    score += 25;

    reasons.push('Time pequeno se beneficia de codebase unificada');

  } else {

    risks.push('Time grande pode enfrentar conflitos de merge frequentes');

  }



  // Urgência favorece monolito

  if (ctx.business.timeToMarket === 'urgent') {

    score += 20;

    reasons.push('Menor overhead inicial acelera time-to-market');

  }



  // Crescimento agressivo é risco

  if (ctx.load.projectedGrowth === 'aggressive') {

    score -= 15;

    risks.push('Escalabilidade vertical pode se tornar gargalo');

  }



  return {

    score,

    reasons,

    risks,

    primaryTradeoff: 'Simplicidade vs. Escalabilidade horizontal'

  };

}



// evaluateMicroservices e evaluateEventDriven seguem lógica similar...

O código acima ilustra como IA pode estruturar análise de adequação arquitetural. Note que o sistema explicitamente retorna confidenceScore, quando abaixo de 0.6, sinaliza que a recomendação é inconclusiva e demanda análise humana aprofundada. Essa humildade epistêmica é muito importante: a IA deve reconhecer os limites de sua própria análise.

Pesquisas industriais relatam que empresas que introduziram assistentes similares em revisões arquiteturais observaram redução de 20–40% no tempo para preparar alternativas e análises básicas. Ao mesmo tempo, estudos apontam taxas não triviais de "over-suggestion" de complexidade, justamente por modelos terem sido treinados em corpora dominados por arquiteturas de big techs. Isso reforça a máxima: IA sugere, arquiteto decide.

Diagrams-as-Code e Geração Automatizada

Uma aplicação concreta e imediatamente útil de LLMs em arquitetura é a geração de diagramas a partir de descrições textuais ou análise de código. Ferramentas que convertem código TypeScript em diagramas C4 ou Mermaid podem economizar horas de trabalho manual. Contudo, essa automação carrega riscos que demandam atenção.

Ferramentas como Mermaid, PlantUML e Structurizr DSL permitem representar modelos arquiteturais como texto versionado em Git. Em vez de desenhar manualmente, arquitetos escrevem DSLs que descrevem sistemas, e a renderização gráfica é derivada automaticamente. Plataformas como Structurizr suportam diretamente o modelo C4 e incluem exportação para Mermaid.

Em 2024–2025 surgiram geradores de diagramas com IA que produzem Mermaid ou diagramas C4 a partir de descrições em linguagem natural. Serviços como Eraser.io e integrações em ChatGPT permitem descrever "API Gateway, três microservices, um banco PostgreSQL" e obter diagrama inicial. Estudos de caso relatam redução de 40 horas para ~5 horas por sprint em documentação arquitetural, porém com ressalvas sobre confiança.

O diagrama acima explicita que a revisão humana não é opcional, é componente crítico e obrigatório do workflow. LLMs podem "alucinar" componentes que não existem no código, omitir dependências sutis, ou simplificar relações complexas de maneiras que distorcem a realidade arquitetural. Em contextos regulados (saúde, finanças), diagramas incorretos podem ter consequências sérias.

O código abaixo ilustra um gerador simples que converte estrutura de componentes em Mermaid:

interface Component {

  id: string;

  label: string;

  type: 'service' | 'database' | 'client' | 'queue';

  dependencies: string[];

}



function generateMermaid(components: Component[]): string {

  let diagram = 'graph TD\n';

  const shapes: Record<Component['type'], (l: string) => string> = {

    service: (l) => `[${l}]`,

    database: (l) => `[(${l})]`,

    client: (l) => `[${l}]`,

    queue: (l) => `{{${l}}}`

  };



  components.forEach(comp => {

    diagram += `  ${comp.id}${shapes[comp.type](comp.label)}\n`;

  });



  components.forEach(comp => {

    comp.dependencies.forEach(depId => {

      diagram += `  ${comp.id} --> ${depId}\n`;

    });

  });



  return diagram;

}

Stakeholders não-técnicos frequentemente questionam se diagramas gerados representam fielmente o que está em produção. Isso torna central o papel do arquiteto como curador: diagramas gerados por IA são hipóteses visuais, não verdades absolutas. Um workflow robusto deve incluir validação sintática (compila corretamente?), semântica (componentes existem?) e de completude (dependências críticas representadas?).

A questão central não é se devemos usar IA para gerar diagramas, mas como estruturar processos de validação que capturem erros antes que se propaguem para stakeholders ou documentação oficial.

Um workflow robusto para diagrams-as-code assistido por IA deve incluir múltiplas camadas de verificação. Primeiro, validação sintática: o diagrama gerado compila corretamente em Mermaid/PlantUML? Segundo, validação semântica: os componentes representados existem de fato no código? Terceiro, validação de completude: dependências críticas estão representadas? Ferramentas determinísticas que extraem arquitetura diretamente do código (como Structurizr ou dependency-cruiser) podem servir como "fonte de verdade" contra a qual diagramas gerados por LLM são comparados.

Onde IA Agrega e Onde Falha?

LLMs são excepcionalmente bons em articular trade-offs como os da tabela acima. Podem explicar por que microservices oferecem isolamento de falhas (se um serviço cai, outros continuam) ou por que event-driven architecture complica debugging (eventos assíncronos criam traces não-lineares). Essa capacidade de comunicar trade-offs técnicos em linguagem acessível é valiosa para alinhar stakeholders técnicos e não-técnicos.

Contudo, LLMs falham em ponderar trade-offs para contextos específicos. A tabela indica que microservices requerem times de 20+ pessoas — mas essa regra heurística ignora fatores como experiência prévia do time com sistemas distribuídos, maturidade de práticas DevOps na organização, ou pressões específicas de compliance que podem alterar completamente o cálculo.

ADRs Assistidos por LLMs: Documentação ou Pensamento?

Architecture Decision Records (ADRs) representam caso de uso tentador para automação via LLM. Um modelo pode gerar ADRs tecnicamente corretos em segundos, documentando decisões como "PostgreSQL escolhido por garantias ACID" com justificativas válidas e trade-offs articulados.

Documentar decisões via Architecture Decision Records tornou-se prática comum, mas muitos times os veem como burocracia. Estudos recentes investigam como LLMs podem reduzir esse atrito. O trabalho DRAFT-ing Architectural Design Decisions using LLMs (2025) mostra que abordagem de few-shot tuning com recuperação de ADRs similares (RAG) em dataset de 4.911 ADRs produz decisões mais completas que LLMs genéricos.

Ferramentas de "ADR agents" integradas a IDEs conseguem hoje: (1) gerar ADR inicial ao detectar mudança relevante, (2) checar coerência com decisões anteriores, (3) conectar decisões relacionadas no histórico. Porém, avaliações indicam que justificativas geradas automaticamente tendem a ser genéricas, negligenciando contextos críticos como requisitos regulatórios.

interface AdrDraft {

  title: string;

  context: string;

  decision: string;

  consequences: string;

}



function validateAdrForDomain(

  adr: AdrDraft, 

  domainKeywords: string[]

): { missing: string[]; isComplete: boolean } {

  const fullText = Object.values(adr).join(' ').toLowerCase();

  const missing = domainKeywords.filter(k => !fullText.includes(k.toLowerCase()));



  return {

    missing,

    isComplete: missing.length === 0

  };

}



// Exemplo: validar ADR de sistema financeiro

const draft: AdrDraft = {

  title: 'Use PostgreSQL instead of MongoDB',

  context: 'We need a robust database for transactions.',

  decision: 'PostgreSQL for strong consistency guarantees.',

  consequences: 'SQL modeling, vertical scaling considerations.'

};



const validation = validateAdrForDomain(draft, ['ACID', 'auditoria', 'PCI-DSS', 'compliance']);

if (!validation.isComplete) {

  console.warn('ADR missing domain concepts:', validation.missing);

  // Output: ADR missing domain concepts: ['auditoria', 'PCI-DSS', 'compliance']

}

O ato de escrever ADRs serve duplo propósito: documentar decisões e forçar reflexão profunda. Quando o arquiteto escreve manualmente, é obrigado a articular razões, considerar alternativas, antecipar consequências. ADRs gerados por IA podem ser tecnicamente corretos mas contextualmente vazios, capturando "o quê" sem o "por quê" profundo.

Workflow Recomendado: Use LLM para gerar rascunho inicial, então revise criticamente adicionando contexto específico: por que neste projeto, com este time, neste momento. O valor está na reflexão forçada pela revisão.

Sobre-Engenharia: O Viés Sistemático de LLMs

O maior risco no uso de IA em decisões arquiteturais é a tendência sistemática à sobre-engenharia. LLMs aprendem de repositórios públicos dominados por projetos de empresas grandes, documentação de "best practices" que assume escala, e discussões técnicas onde soluções sofisticadas recebem mais atenção que soluções simples.

Quando perguntado "qual arquitetura para sistema de checkout?", um LLM tende a recomendar microservices com message queues, service mesh e distributed tracing — porque essa é a resposta "correta" no contexto de Amazon ou Shopify. Para startup processando 1.000 pedidos diários, essa recomendação é sobre-engenharia que consumirá recursos preciosos em infraestrutura em vez de features de negócio.

O arquiteto humano, conhecendo contexto real — time de três pessoas, orçamento limitado, necessidade de velocidade — pode e deve rejeitar a recomendação sofisticada. Essa capacidade de dizer "a IA está tecnicamente correta mas contextualmente errada" é precisamente o que distingue arquiteto de operador de ferramenta.

IA não substitui a responsabilidade profissional do arquiteto; no máximo, torna mais visíveis as suposições que precisam ser desafiadas.

O Arquiteto como Curador Crítico

A integração responsável de IA em arquitetura demanda reconhecer uma assimetria fundamental: LLMs são excepcionalmente bons em articular padrões, trade-offs e justificativas técnicas; são sistematicamente fracos em ponderar esses fatores para contextos específicos. Muitos requisitos não-funcionais importantes são implícitos ("não podemos correr risco de manchete negativa") e raramente aparecem como tokens nos documentos que alimentam o modelo.

O papel do arquiteto na era da IA é de curador crítico: usar IA para explorar alternativas, gerar documentação, simular trade-offs, mas sempre filtrando recomendações à luz de prioridades de negócio, maturidade da equipe e restrições sociotécnicas. Na prática, isso significa saber dizer "não" a recomendações de "best practices" que não se encaixam, ou adotar soluções "menos elegantes" mas mais alinhadas ao time e à fase do produto.

Para nós engenheiros de software, a oportunidade é aprender a dialogar com IA como um par técnico exigente: que cobra justificativas, oferece contraexemplos, mas não assina o diagrama final nem o ADR aprovado.

📚 Referências para Aprofundamento

Papers Acadêmicos

1. 
   

   Dhar, R., Kakran, A., & Kazman, R. (2025). DRAFT-ing Architectural Design Decisions using LLMs: A Retrieval-Augmented Generation Approach. arXiv preprint.

   
   
   
   
   
   • 🔗 https://arxiv.org/abs/2504.08207
     
   
   
   • 
     Por que ler: Demonstra que LLMs ajustados com RAG em dataset de 4.911 ADRs produzem decisões mais completas e contextualizadas que modelos genéricos — evidência empírica central para o debate sobre automação de ADRs.
   
   
   
   


2. 
   

   Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for Architecture Evaluation. Technical Report CMU/SEI-2000-TR-004, Software Engineering Institute.

   
   
   
   
   
   • 🔗 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5177
     
   
   
   • 
     Por que ler: Framework fundacional para análise sistemática de trade-offs arquiteturais via cenários de qualidade — base conceitual que sistemas de IA tentam automatizar.
   
   
   
   


3. 
   

   Bass, L., Klein, M., & Bachmann, F. (2001). Quality Attribute Design Primitives and the Attribute Driven Design Method. Revised Papers from PFE 2001, LNCS 2290.

   
   
   
   
   
   • 🔗 https://people.ece.ubc.ca/matei/EECE417/BASS/ch12.html
     
   
   
   • 🔗 https://www.sei.cmu.edu/library/quality-attribute-design-primitives-and-the-attribute-driven-design-method/
     
   
   
   • 
     Por que ler: Introduz análise custo-benefício (CBAM) aplicada a decisões arquiteturais — complementa ATAM com perspectiva econômica.
   
   
   
   


4. 
   

   Ahmad, A., et al. (2023). Can LLMs Generate Architectural Design Decisions? An Exploratory Empirical Study. arXiv preprint.

   
   
   
   
   
   • 🔗 https://arxiv.org/html/2403.01709v1
     
   
   
   • 
     Por que ler: Estudo exploratório sobre capacidades e limitações de LLMs na geração de decisões arquiteturais — evidências sobre vieses e lacunas contextuais.
   
   
   
   

Ferramentas e Plataformas

1. 
   

   Mermaid. Diagramming and charting tool using text definitions.

   
   
   
   
   
   • 🔗 https://mermaid.js.org
     
   
   
   • 
     Por que usar: Permite criar diagramas em Markdown versionáveis em Git, com sintaxe que LLMs conseguem gerar e manipular facilmente.
   
   
   
   


2. 
   

   Structurizr. Software architecture models as code.

   
   
   
   
   
   • 🔗 https://structurizr.com
     
   
   
   • 
     Por que usar: Implementa modelo C4 como DSL, com exportação para múltiplos formatos incluindo Mermaid — ponte entre arquitetura como código e visualização.
   
   
   
   


3. 
   

   PlantUML. Open-source tool for UML diagrams from text.

   
   
   
   
   
   • 🔗 https://plantuml.com
     
   
   
   • 
     Por que usar: Ecossistema maduro para UML e C4, ampla integração com IDEs e pipelines CI/CD.
   
   
   
   


4. 
   

   Eraser.io. AI-powered architecture diagram generator.

   
   
   
   
   
   • 🔗 https://www.eraser.io/ai/architecture-diagram-generator
     
   
   
   • 
     Por que explorar: Exemplo de ferramenta comercial que gera diagramas C4 a partir de linguagem natural — caso de uso prático de IA em documentação arquitetural.
   
   
   
   

Artigos Técnicos e Guias

1. 
   

   Atlassian. (2024). Microservices vs. monolithic architecture.

   
   
   
   
   
   • 🔗 https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
     
   
   
   • 
     Por que ler: Comparação prática e acessível entre monólitos e microservices, com critérios de decisão baseados em contexto de time e produto.
   
   
   
   


2. 
   

   DX (getdx.com). (2024). Monolithic vs microservices architecture: When to choose each.

   
   
   
   
   
   • 🔗 https://getdx.com/blog/monolithic-vs-microservices/
     
   
   
   • 
     Por que ler: Análise baseada em dados sobre quando cada arquitetura é apropriada, com ênfase em tamanho de time e maturidade organizacional.
   
   
   
   


3. 
   

   BairesDev. (2024). Architecture as a Strategic Decision: Microservices vs. Monolithic.

   
   
   
   
   
   • 🔗 https://www.bairesdev.com/blog/microservices-vs-monolithic/
     
   
   
   • 
     Por que ler: Perspectiva de consultoria com observações de campo sobre sobre-engenharia e decisões arquiteturais em contextos reais.
   
   
   
   


4. 
   

   Khan, A. (2025). Agentic AI for Living Architecture: Enhancing ADRs with LLMs. LinkedIn Article.

   
   
   
   
   
   • 🔗 https://www.linkedin.com/pulse/agentic-ai-living-architecture-enhancing-adrs-llms-decision-khan-5gpgc
     
   
   
   • 
     Por que ler: Explora conceito de "ADRs vivos" mantidos por agentes de IA conectados ao código — visão de futuro para documentação arquitetural.