IA é o último recurso, não o primeiro

Existe um erro que quase todo builder comete no começo.

Ele não é óbvio. Parece até certo.

O erro é este: usar IA como primeira resposta para todo problema.

Surge uma tarefa. O builder abre o Claude ou o ChatGPT. Descreve o problema. Espera a resposta.

Isso funciona para tarefas simples. Mas quando esse padrão vira arquitetura de sistema, os problemas aparecem.

O sistema fica caro. Fica lento. Fica frágil.

E a maioria não percebe por quê.

O custo que ninguém calcula

Cada chamada de IA tem um custo.

Tem custo em tokens. Tem custo em tempo de resposta. Tem custo em confiabilidade.

Quando você usa IA para resolver algo que código resolveria, você está pagando pelos três.

E pagando mais do que precisa.

Um exemplo concreto. Imagine um sistema que recebe formulários e precisa validar se os campos obrigatórios estão preenchidos.

Isso é uma validação. Uma regra simples.

Três linhas de código resolvem.

Se você chamar IA para isso, gasta tokens. Adiciona latência. E ainda corre o risco de a IA "interpretar" o campo de um jeito que você não esperava.

Não porque a IA é ruim. Mas porque essa não é a tarefa certa para ela.

A hierarquia de decisão

Builders experientes têm uma sequência clara antes de chamar IA.

Não é burocracia. É economia de sistemas.

Primeiro: existe uma regra que resolve?

Regras são determinísticas. Sempre produzem o mesmo resultado para a mesma entrada.

São baratas. São rápidas. São auditáveis.

Se uma condição, uma validação ou uma classificação fixa resolve o problema — use a regra.

Segundo: o código resolve?

Cálculos, comparações, ordenações, filtros. Qualquer lógica previsível.

Código é mais rápido que IA para esse tipo de tarefa. É mais barato. É mais confiável.

Se o problema tem uma resposta única e previsível — use o código.

Terceiro: já resolvemos isso antes?

Cache e banco de dados existem exatamente para isso.

Em um projeto de processamento de documentos, cada arquivo enviado gerava uma nova chamada de IA para extrair os dados principais. Quando o sistema passou a verificar se já havia processado aquele documento antes, o número de chamadas de IA caiu 60% no primeiro mês.

A tarefa não mudou. A arquitetura mudou.

Quarto: precisa de interpretação ou raciocínio?

Aqui entra a IA.

Contexto ambíguo. Linguagem natural. Raciocínio sobre situações novas. Síntese de informação complexa.

IA faz isso bem. Código não faz.

Quando o problema genuinamente precisa de julgamento — aí a IA é a ferramenta certa.

O fluxo na prática

Esse fluxo não é teoria. É o que separa sistemas baratos de sistemas caros.

Builders que começam por "o que a IA pode fazer aqui?" estão fazendo a pergunta errada.

A pergunta certa é: "Qual é a forma mais simples e confiável de resolver isso?"

Se a resposta envolver IA — ótimo. Use.

Se não envolver — não use.

Por que isso é contraintuitivo

IA é impressionante. Esse é um fato.

Ela resolve problemas complexos que há dois anos eram impossíveis para software comum.

É natural querer usá-la para tudo.

Mas existe uma diferença entre poder e dever.

IA pode extrair dados de um texto. Mas se o dado tem formato fixo e previsível, uma expressão regular faz isso mais rápido, mais barato e sem chance de alucinação.

IA pode classificar e-mails. Mas se as categorias são fixas e baseadas em palavras-chave simples, um filtro de texto basta.

IA pode responder perguntas frequentes. Mas se as perguntas seguem padrões repetíveis, um sistema de busca é mais confiável.

O problema não é a IA. O problema é usar uma ferramenta de interpretação para tarefas de execução.

O que acontece quando ignoramos esse princípio

Em um projeto de automação de análise de documentos jurídicos, o sistema original enviava contratos inteiros para IA e pedia que ela respondesse uma série de perguntas sobre o conteúdo.

O custo por documento era alto. O tempo de processamento era longo.

Algumas respostas variavam dependendo de como o contrato estava redigido.

A reformulação começou com uma pergunta simples: "O que nesse documento não precisa de interpretação?"

A resposta surpreendeu: quase tudo.

Data, partes, valor, número de cláusulas — tudo extraído por código. Apenas as cláusulas que genuinamente exigiam análise de contexto foram enviadas para IA.

O custo por documento caiu 70%. O tempo de processamento caiu pela metade. A confiabilidade aumentou.

A IA não foi removida. Foi colocada no lugar certo.

A armadilha do "funciona no teste"

Existe um padrão que aparece muito em projetos de IA.

O sistema funciona bem no teste. Funciona bem em produção com pouco volume. Funciona bem por algumas semanas.

Depois o volume escala. O custo mensal dobra. E alguém percebe que 40% das chamadas de IA estão sendo feitas para coisas que código resolveria.

Nesse ponto, refatorar é caro. O sistema já está estruturado em torno das chamadas de IA.

Esse é o custo de não aplicar a hierarquia desde o início.

Não é um problema de escala. É um problema de arquitetura.

Como aplicar na prática

Antes de chamar IA para qualquer tarefa, passe pelo checklist:

Existe uma regra que resolve? Pense em validações, classificações fixas, cálculos determinísticos. Se sim — use a regra.

Existe uma função de código que resolve? Pense em transformações, comparações, ordenações, filtros. Se sim — use o código.

Já fiz isso antes? Verifique cache. Verifique banco de dados. Se a resposta já existe em algum lugar — recupere ela, não recalcule.

Isso genuinamente precisa de interpretação? Se sim — chame IA. Com contexto mínimo, instrução clara e expectativa bem definida.

Esse checklist não bloqueia o uso de IA. Garante que, quando você usa IA, está usando pelo motivo certo.

A pergunta que organiza tudo

Existe uma pergunta que muda a forma de projetar sistemas com IA.

Não é "como faço isso com IA?"

É: "Estou adicionando complexidade ou estou adicionando valor?"

Se a IA não adiciona valor que código ou regra não entregaria — ela adiciona complexidade.

Complexidade tem custo. Custo de tokens. Custo de manutenção. Custo de confiabilidade.

Valor tem retorno. Retorno em capacidade que antes não existia.

A diferença entre os dois define a qualidade da arquitetura.

IA poderosa no lugar certo

Esse princípio não é contra IA. É a favor do uso correto dela.

IA é especialmente poderosa quando usada para o que código não consegue fazer: interpretar, raciocinar, lidar com ambiguidade, entender contexto.

Quando você concentra as chamadas de IA nessas tarefas — e só nessas — o sistema ganha em todos os sentidos.

Fica mais barato. Porque o custo por tarefa cai.

Fica mais rápido. Porque chamadas de código são mais rápidas que chamadas de IA.

Fica mais confiável. Porque código é determinístico onde IA não é.

Fica mais fácil de auditar. Porque as decisões de IA ficam isoladas no lugar onde fazem sentido.

E a IA, quando chamada, trabalha com menos ruído. Recebe contexto mais limpo, mais estruturado, mais relevante. As respostas ficam melhores.

O princípio em uma frase

A hierarquia é simples.

Regra → Código → Cache → IA.

Toda vez que você pular etapas, o sistema fica mais caro, mais lento e mais frágil.

Toda vez que você seguir a hierarquia, o sistema fica mais barato, mais rápido e mais previsível.

O objetivo não é usar menos IA.

É usar IA melhor.