O problema
A descoberta terminou. Você tem uma lista de requisitos mensuráveis, cada um com um dono, e sabe o que é inegociável. Agora vem a parte que separa um arquiteto profissional de alguém que só sabe montar componentes: transformar essa lista em uma arquitetura de ponta a ponta, e defender cada peça dela com um trade-off explícito.
O erro mais comum nessa etapa não é técnico — é apresentacional. Um arquiteto entrega um diagrama bonito com todas as peças certas (ingestão, processamento, saída, revisão humana) mas não consegue responder por que escolheu RAG em vez de fine-tuning, ou por que o orçamento de latência foi distribuído daquele jeito entre os componentes. Um diagrama sem justificativa não é uma arquitetura, é uma sugestão.
Esta lição trata de como montar e defender uma arquitetura completa: cada escolha rastreável até um requisito da descoberta, e cada trade-off declarado em vez de escondido.
Arquitetura de ponta a ponta é composição, não escolha única
Um sistema com Claude em produção raramente é "um modelo mais um prompt". É uma cadeia de decisões que se encaixam: como o input chega, como ele é processado, o que sai, e como o sistema aprende com o que saiu errado. Pensar nessas quatro camadas separadamente — entrada, processamento, saída, feedback — evita o erro de tratar a arquitetura como uma decisão monolítica ("vamos usar agentes") quando na verdade são quatro decisões interligadas, cada uma com seu próprio trade-off.
Um padrão de arquitetura (workflow determinístico, sistema agêntico, ou LLM aumentado com ferramentas) não é escolhido por preferência estética. Ele é a consequência de como as quatro camadas respondem às restrições da descoberta: se o processamento precisa de passos previsíveis e auditáveis, um workflow determinístico atende melhor do que um agente que decide sua própria sequência. Se a tarefa exige adaptação a situações que não foram previstas de antemão, um sistema agêntico é a escolha que sobra depois de eliminar as outras.
O trade-off precisa estar declarado, não implícito
Toda decisão de arquitetura tem um custo em troca de um ganho. RAG reduz alucinação ao ancorar respostas em documentos reais, mas adiciona latência e a complexidade de manter um índice atualizado. Um sistema multiagente pode paralelizar investigação, mas multiplica o custo por chamada e a superfície de erro. Nenhuma dessas escolhas é "certa" isoladamente — é certa em relação a uma restrição específica da descoberta.
A prática que separa um arquiteto sênior é escrever o trade-off, não só a escolha. "Escolhemos RAG com chunking semântico porque o requisito de auditabilidade jurídica exige que toda afirmação seja rastreável a um documento fonte, aceitando o custo de latência adicional de X segundos porque o SLA permite até Y segundos" é uma frase defensável. "Vamos usar RAG" não é.
Um distrator comum em cenário de prova: uma alternativa tecnicamente competente, mas que otimiza uma métrica que não estava entre as restrições descobertas — por exemplo, escolher a arquitetura de menor custo quando o requisito prioritário, explicitado na descoberta, era latência. A arquitetura correta é a que atende às restrições reais, não a mais elegante em abstrato.
Decompor sem perder a rastreabilidade
Um problema complexo de arquitetura de ponta a ponta raramente é resolvido de uma vez. Ele precisa ser decomposto em partes menores que podem ser decididas separadamente — mas cada parte decomposta ainda precisa manter o vínculo com o requisito original que a motivou.
Decompor sem esse vínculo produz um sistema tecnicamente bem construído em cada peça, mas onde ninguém consegue explicar por que uma peça específica existe. Decompor mantendo o vínculo significa que, se um requisito mudar depois (o cliente decide que confidencialidade não é mais crítica, por exemplo), fica claro exatamente quais decisões de arquitetura precisam ser revisitadas — em vez de forçar uma reavaliação de tudo.
Coloque em prática
O laboratório desta lição pede que você pegue um conjunto de requisitos vindos da descoberta e monte, a partir deles, um registro de decisões de arquitetura — cada decisão com o trade-off declarado e o requisito que a motivou — verificando que nenhuma decisão fica sem justificativa rastreável.