Novo: Eficify One em beta aberto. Crie seu primeiro ambiente sem cartão.Conhecer a plataforma →

IA não é produtividade, é julgamento, relendo Fundamentals of Software Architecture

Capa estilizada sobre arquitetura de software como infraestrutura de julgamento, com acento laranja da Eficify
CompartilharSeguir

Todo mundo quer falar de LLMs, agentes e RAG. Mas quando um projeto de IA trava em produção, o problema quase nunca é o modelo, é decisão. Reli Fundamentals of Software Architecture, de Mark Richards e Neal Ford, e cheguei a uma conclusão incômoda: o mercado está usando IA para acelerar a coisa errada. IA não é ferramenta de produtividade. É sistema de julgamento. Usada bem, melhora o líder e a organização. Usada mal, a experiência não amadurece, calcifica.

A pergunta errada que o mercado está fazendo

Existe um número que resume o estado atual da adoção de IA nas empresas. Quando se pergunta a executivos qual o maior retorno da IA, 45% dos CEOs respondem redução de custo e 37% dos VPs respondem alívio de burnout. Apenas 13% apontam o que de fato move o ponteiro: decisões melhores, mais rápidas.

O mercado inteiro está olhando para o lugar errado. IA virou sinônimo de produtividade, resumir reuniões, escrever e-mails, gerar boilerplate. Tudo isso ajuda, e tudo isso é periférico. O valor real da IA não está em fazer a mesma coisa mais rápido. Está em decidir melhor.

Foi com essa lente que reli Fundamentals of Software Architecture, de Mark Richards e Neal Ford. À primeira vista, é um livro sobre estilos, componentes e diagramas. Relido com atenção, é um livro sobre uma coisa só: como tomar boas decisões sob incerteza. Ou seja, é um livro sobre julgamento, e isso o torna surpreendentemente atual.

A primeira lei é, no fundo, uma lei sobre decisão

O coração do livro é a sua primeira lei: tudo em arquitetura de software é um trade-off. Parece técnico. Não é. Arquitetar é escolher o que sacrificar, latência por custo, simplicidade por escala, velocidade por confiabilidade, sob informação incompleta. Isso não é programação. É julgamento.

E aqui está a ponte que o livro não chega a fazer, mas deixa pronta: se a essência da arquitetura é decidir trade-offs, então uma IA que não melhora a qualidade dos seus trade-offs não está melhorando nem a sua arquitetura nem a sua liderança. Está só acelerando a digitação.

Decidir trade-offs sob incerteza é a definição de julgamento. É também a definição de arquitetura. Não é coincidência.

Comece pelo líder, não pela arquitetura enterprise

A maioria das consultorias prescreve o caminho de cima para baixo: defina a arquitetura enterprise de IA, monte o data lake, escolha a plataforma, depois desça para os times. O inverso costuma funcionar melhor, comece pela menor unidade que toma decisões: o líder.

Isso ecoa diretamente o método do livro. Richards e Ford insistem que você não começa pela tecnologia; começa pelas características de arquitetura, o que o sistema precisa ser antes do que ele vai usar. Trocar "sistema" por "líder" não muda a lógica: defina como você decide antes de comprar a ferramenta com que vai decidir.

O modelo 3T: características antes da ferramenta

A forma mais prática de aplicar isso é o que chamo de modelo 3T, Traits, Tasks, Tools (características, tarefas, ferramentas), nessa ordem. É o antídoto direto ao vício em ferramenta que tomou conta do mercado de IA.

  • Traits (características): que capacidades de decisão você precisa desenvolver? Clareza para enquadrar problemas, disciplina para avaliar trade-offs, coragem para decidir com informação incompleta.
  • Tasks (tarefas): quais decisões realmente importam? Nem toda decisão merece IA, assim como nem toda parte do sistema merece virar microsserviço.
  • Tools (ferramentas): só agora se escolhe o modelo, o agente, o copiloto.

Quem começa pela ferramenta repete o erro mais antigo da arquitetura: escolher microsserviços antes de entender o problema. O 3T é a versão de liderança da segunda lei do livro, por que importa mais do que como.

O roadmap 5-15-30 é arquitetura evolutiva

Há um roteiro simples para tirar isso do papel sem virar projeto de transformação de dois anos. Em cinco dias, redesenhe como você toma as suas próprias decisões com IA. Em quinze, compartilhe com o time o que funcionou. Em trinta, transforme os experimentos que vingaram em sistemas.

Isso é arquitetura evolutiva aplicada à liderança. O livro defende decisões reversíveis e fitness functions, mecanismos que verificam, de forma contínua e objetiva, se o sistema continua saudável. O 5-15-30 é exatamente isso para o julgamento: experimentos baratos de reverter, validados na prática, promovidos a sistema só quando provam valor. Você não decreta a transformação. Você a deixa evoluir.

A inversão 80/80: estamos acelerando os 80% errados

Esse foi o ponto que mais ficou comigo. Existe uma assimetria cruel na rotina de quem lidera:

  • 80% do tempo de liderança vai para reuniões, updates, coordenação e reconstrução de contexto.
  • 80% do valor de liderança vem de enquadrar problemas, avaliar trade-offs e tomar decisões difíceis com clareza.

A promessa da IA deveria ser inverter essa equação, automatizar a coordenação para liberar tempo de julgamento. Na maioria das empresas, está acontecendo o contrário: a IA está deixando os 80% de baixo valor ainda mais rápidos, sem tocar nos 20% de tempo que carregam 80% do valor. É a métrica errada otimizada com competência.

O livro já avisava: meça as características que importam, não as fáceis de medir. Acelerar a produção de resumos é o equivalente organizacional de otimizar a métrica fácil enquanto a que importa apodrece.

Infraestrutura de julgamento: a característica que ninguém prioriza

Daqui sai a ideia mais valiosa de juntar os dois mundos. No futuro próximo, conselhos não vão perguntar se a sua empresa usa IA. Vão perguntar se a sua infraestrutura de julgamento é competitiva.

Infraestrutura de julgamento. Não dashboard. Não control tower. A capacidade de tomar decisões melhores como organização, e não só como indivíduos isolados. E essa infraestrutura se constrói com as mesmas peças que o livro ensina:

  • Decisões registradas (ADRs): o porquê de cada escolha preservado, para que o julgamento seja auditável e transferível, não preso na cabeça de uma pessoa.
  • Trade-offs explícitos: toda decisão importante documentada como uma troca consciente, não como uma preferência.
  • Fitness functions: no mundo da IA, viram evals e guardrails, verificações automáticas de que as decisões assistidas por IA continuam dentro do aceitável (qualidade, custo, risco).
  • Quanta bem cortados: isolar onde o julgamento acontece, para que um erro de decisão não se propague pelo sistema inteiro.

É isso que transforma IA de enfeite em vantagem: não a ferramenta, mas a arquitetura que torna o julgamento da organização confiável, rápido e evolutivo.

Onde os dois se encontram (veredito)

Fundamentals of Software Architecture não fala de liderança nem de IA generativa, e é justamente por isso que vale relê-lo agora. Ele entrega o método: pensar por trade-offs, definir características antes de tecnologia, manter decisões reversíveis, governar com fitness functions. A tese do julgamento entrega o porquê: IA só vira vantagem quando melhora decisões, e decisões melhores são, no fim, um problema de arquitetura.

Leia o livro como um framework de pensamento, não como receita. E, antes do próximo agente entrar em produção, troque a pergunta. Não é "qual o melhor modelo?". É "essa decisão é reversível, o trade-off está explícito, e isso fortalece a nossa infraestrutura de julgamento?".

É assim que construímos na Eficify: IA tratada como infraestrutura de julgamento, com características explícitas, evals como portão de qualidade e fronteiras que deixam as decisões baratas de evoluir. Não para fazer mais rápido o que não importa, mas para decidir melhor o que importa.

CompartilharSeguir
Henrique Chaves

SOBRE O AUTOR

Henrique Chaves

CEO · Eficify

Executivo de tecnologia, cofundador da Eficify, com ampla experiência na liderança de equipes, construção de produtos digitais e condução de estratégias de transformação tecnológica. Atua nas áreas de engenharia de software, arquitetura de soluções, cloud computing, dados, inteligência artificial, segurança da informação e governança de tecnologia. Possui formação acadêmica pela PUC Minas e uma trajetória marcada pela conexão entre tecnologia, produto e negócio, com foco em inovação, eficiência e geração de valor.

VAMOS CONVERSAR

Clareza técnica antes da próxima decisão.

Conte seu cenário e receba uma leitura externa da sua arquitetura e dos próximos passos.

Agendar um assessment