← Diário de Construção

Quando NÃO usar IA: Identificando gargalos onde o código puro ainda vence

Nem todo problema técnico deve ser resolvido com inteligência artificial. Saiba onde as IAs falham e o código clássico continua sendo insubstituível.

A era da inteligência artificial generativa trouxe uma empolgação compreensível. LLMs (Large Language Models) conseguem escrever códigos funcionais, estruturar ideias de posts e traduzir termos técnicos complexos mantendo o tom de voz original de um autor.

Porém, essa empolgação gerou um efeito colateral comum na engenharia: a tendência de usar a ferramenta mais nova para absolutamente qualquer problema. Se a única ferramenta que você tem é um LLM, todo problema se parece com um prompt.

A febre dos LLMs em tudo

Atualmente, vemos soluções de software complexas que utilizam chamadas de API de IA para tarefas extremamente simples, como extrair uma data de uma string, validar o formato de um e-mail ou classificar um texto em três categorias fixas.

Embora um LLM consiga fazer isso de forma razoável, utilizar inteligência artificial para tarefas puramente lógicas ou matemáticas é o equivalente a contratar um consultor sênior apenas para organizar sua pasta de downloads.

Onde a IA falha

Modelos probabilísticos de linguagem operam prevendo a próxima palavra mais provável com base em padrões estatísticos. Eles não possuem um mecanismo de lógica computacional real ou consciência de regras matemáticas estritas.

  1. Subjetividade vs. Rigor: A IA é excelente para tarefas subjetivas (ex: “melhore o tom deste texto” ou “traduza mantendo a formalidade”). Ela falha quando a resposta precisa ser binária e exata (ex: “calcule se esta transação de trading infringe a gestão de risco de 2%”).
  2. Reprodutibilidade: O mesmo prompt rodado em momentos diferentes pode gerar variações na estrutura de saída. Em sistemas que dependem de contratos de dados rígidos (APIs, integrações bancárias), isso é um desastre.
  3. Alucinações estruturais: Mesmo forçando a saída em formato JSON, há momentos em que a IA quebra a estrutura sintática, invalida o JSON ou inventa chaves que não existiam no esquema solicitado.

Custos e latência: A realidade esquecida

Fazer uma chamada de API para a OpenAI, Anthropic ou rodar um modelo local (como Llama 3) exige recursos computacionais imensos. Isso se traduz em dois grandes inimigos dos sistemas eficientes:

  • Latência: Uma chamada de rede para um modelo de linguagem raramente demora menos que algumas centenas de milissegundos, chegando facilmente a segundos. Uma regex em Python executa localmente em menos de 1 milissegundo.
  • Custo financeiro: Enquanto processar 1 milhão de strings com regex custa frações imperceptíveis de centavos de energia na sua VPS, fazer o mesmo via chamada de API de IA pode custar dezenas de dólares mensais recorrentes.

A força das soluções determinísticas

O verdadeiro “Systems Builder” entende que a IA deve ser um complemento, não a fundação.

Se um problema pode ser resolvido com um algoritmo determinístico tradicional (regex, estruturas de decisão, parsing estruturado de JSON, bancos de dados relacionais), o código clássico sempre vencerá em performance, previsibilidade e custo.

Na nossa esteira de conteúdo, por exemplo, a IA é usada para gerar a tradução técnica inicial e sugerir links. No entanto, a montagem do frontmatter do Markdown, a validação dos caminhos das imagens, o cálculo do tempo de leitura e a publicação final via GitHub API são controlados por fluxos tradicionais no n8n e JavaScript.

Não tente adivinhar probabilisticamente o que pode ser calculado deterministicamente.

Fontes consultadas