Quando a IA Generativa vira martelo para todo prego: porque não devemos substituir bons algoritmos

Estamos vivendo uma fase de encantamento com as IAs Generativas. Esse encantamento é compreensível. Pela primeira vez, muitos programadores conseguem conversar com uma ferramenta em linguagem natural e receber de volta códigos, explicações, arquiteturas, testes, refatorações e sugestões de implementação. É como se uma nova camada de abstração tivesse surgido entre a ideia e o software. Por isso, podemos dizer que a IA Generativa se aproxima de uma nova linguagem de programação: não porque substitui C, Python, JavaScript ou SQL, mas porque nos permite descrever intenções, contextos e restrições em linguagem humana para produzir artefatos computacionais.

O problema começa quando confundimos essa nova linguagem de intenção com substituição da engenharia. Uma LLM, ou Large Language Model, é excelente para trabalhar com linguagem, estruturação de texto, explicação, geração de esqueleto de aplicações, criação de exemplos, apoio à documentação e exploração de caminhos que ainda não dominamos. Mas isso não significa que ela deva substituir algoritmos eficientes, matemática bem contextualizada, estruturas de dados adequadas, consultas SQL bem feitas, bibliotecas maduras ou análise estatística tradicional. No próprio material de “Inteligência Generativa na Programação”, já defendemos que a IA é um novo paradigma de trabalho, mas não substitui o pensamento crítico do desenvolvedor, que continua responsável pela decisão final sobre o código gerado.

Quando usamos uma LLM para resolver um problema que poderia ser tratado com algumas linhas de Pandas, NumPy, SQL, uma expressão regular, uma árvore de decisão simples ou uma dúzia de ifs bem organizados, estamos trocando determinismo por probabilidade. Estamos colocando uma máquina estatística de linguagem para fazer o trabalho de um algoritmo explícito. Em alguns casos isso é apenas desperdício. Em outros, é risco técnico. E em sistemas sensíveis, pode se tornar uma fonte de falsos resultados, decisões incorretas e custos computacionais desnecessários.

A boa engenharia começa pela pergunta: “qual é a natureza do problema?”. Se o problema é linguístico, interpretativo, textual, ambíguo ou comunicacional, a LLM pode ser uma excelente ferramenta. Se o problema é aritmético, estatístico, tabular, algorítmico, determinístico ou sensível à latência, provavelmente devemos começar por código convencional, matemática, bibliotecas especializadas e testes. O uso adequado de LLMs está mais próximo de ampliar nossa capacidade de raciocínio e construção do que de terceirizar nossa responsabilidade técnica.

Um exemplo simples deixa isso claro. Suponhamos que temos uma tabela com vendas por mês e queremos calcular média, desvio padrão, crescimento percentual e identificar valores fora do padrão. Podemos enviar o CSV inteiro para uma LLM, gastar milhares de tokens e pedir que ela “analise os dados”. Talvez ela retorne uma resposta bonita, com aparência convincente, mas não necessariamente auditável. A alternativa mais correta seria usar Pandas para carregar os dados, aplicar funções estatísticas, gerar métricas reprodutíveis e, depois disso, usar a LLM para explicar os resultados, redigir um relatório, sugerir hipóteses ou construir um dashboard. Nesse fluxo, a matemática calcula; a LLM comunica.

Essa diferença é essencial. A LLM não deve ser o lugar onde escondemos a lógica que deveria estar no código. Ela pode ajudar a escrever a lógica, revisar a lógica, explicar a lógica e até sugerir abordagens melhores. Mas, ao final, o algoritmo precisa existir de maneira clara, testável e verificável. Quando um cálculo é importante, ele deve estar em uma função. Quando uma regra de negócio é decisiva, ela deve estar documentada e coberta por testes. Quando uma decisão afeta o usuário, ela deve ser rastreável. Quando um modelo probabilístico participa da decisão, deve haver supervisão, registro e possibilidade de intervenção humana.

Essa preocupação não é exagero. Obras técnicas sobre LLMs em produção alertam que modelos de linguagem não são a melhor escolha para todos os tipos de problema. Em especial, há recomendações claras para evitar LLMs em cargas sensíveis à latência, projetos simples, problemas resolvidos por matemática ou algoritmos, avaliações críticas e projetos de alto risco. O ponto não é rejeitar a IA, mas colocá-la no lugar certo da arquitetura.

Também precisamos considerar custo. Em APIs comerciais, o custo geralmente é proporcional ao volume de tokens enviados e recebidos. Quanto mais contexto enviamos, mais caro fica. Quanto mais pedimos respostas longas, mais difícil fica prever o custo final. O livro “LLMs in Production” chama atenção justamente para esse desafio: limites de tokens criam gargalos, APIs cobram por tokens e saídas variáveis tornam o custo mais difícil de governar. Em outras palavras, uma análise que poderia ser feita localmente em milissegundos com uma função matemática pode se transformar em uma chamada remota, cara, lenta e não determinística.

Há ainda o problema da confiança. LLMs podem gerar respostas plausíveis e erradas. Isso é especialmente perigoso porque o erro nem sempre parece erro. A resposta vem bem escrita, organizada e segura. Em aplicações RAG, por exemplo, mesmo quando conectamos a LLM a bases de conhecimento, ainda precisamos lidar com alucinações, excesso de informação, filtragem inadequada, complexidade de integração e necessidade de testes rigorosos antes de entregar o resultado ao usuário final. Portanto, mesmo quando usamos Tool Calling, RAG, agentes ou integração com banco de dados, não podemos abandonar validação, logs, testes e mecanismos de auditoria.

Na prática, podemos adotar uma regra simples: a LLM deve sugerir; o algoritmo deve decidir quando a decisão exigir precisão. Isso não significa que a LLM nunca possa participar de decisões. Ela pode, desde que a arquitetura reconheça sua natureza probabilística. Foi exatamente essa a lição que tiramos ao experimentar um projeto AIoT com dashboard integrado ao Ollama e ao modelo Granite. Poderíamos ter resolvido parte das decisões com uma dúzia de ifs, cálculos matemáticos e regras explícitas. Mas, para provar o conceito, usamos uma LLM como elemento de decisão. Ainda assim, mantivemos uma interface para que o usuário pudesse intervir, revisar e desfazer uma decisão tomada pela IA. Essa é uma diferença importante entre experimentar inteligência artificial e entregar controle cego a ela.

Esse cuidado é ainda mais importante em sistemas embarcados, IoT e AIoT. Quando estamos lidando com sensores, atuadores, motores, comunicação sem fio, leitura de corrente, temperatura, vibração, presença humana, falha elétrica ou controle de processo, a decisão muitas vezes precisa ser rápida, previsível e verificável. Uma LLM pode ajudar a explicar o estado do sistema, gerar diagnósticos em linguagem natural, montar relatórios, interpretar logs e sugerir manutenção. Mas o laço de controle, a leitura de sensores, os filtros digitais, a máquina de estados, o controle PID, os alarmes críticos e as rotinas de segurança devem permanecer baseados em algoritmos determinísticos, testados e adequados ao hardware.

Esse raciocínio não diminui a IA Generativa. Pelo contrário, ele a valoriza. Quando usamos uma LLM onde ela realmente brilha, ganhamos produtividade real. Podemos pedir que ela gere o esqueleto de uma aplicação, proponha uma arquitetura inicial, escreva testes unitários, documente APIs, explique um erro de compilação, compare bibliotecas, sugira padrões de projeto, traduza requisitos confusos para uma estrutura organizada ou nos ajude a aprender uma tecnologia nova. Podemos usá-la como professora, revisora, copiloto, arquiteta auxiliar e aceleradora de protótipos. O erro está em tratá-la como oráculo matemático ou substituta universal da engenharia.

Também precisamos preservar o aprendizado real. Se toda dificuldade for delegada à IA, corremos o risco de formar programadores que sabem pedir, mas não sabem avaliar. E quem não sabe avaliar fica refém do texto gerado. Saber usar IA Generativa bem exige ainda mais conhecimento técnico, não menos. Precisamos entender complexidade algorítmica, estruturas de dados, banco de dados, estatística, testes, arquitetura, segurança e domínio do problema. Quanto mais sabemos, melhor perguntamos; quanto melhor perguntamos, melhor validamos; quanto melhor validamos, menor o risco de transformar uma resposta elegante em um erro silencioso.

Portanto, a postura madura não é “usar IA para tudo” nem “rejeitar IA por orgulho técnico”. A postura madura é engenharia. Usamos LLMs para acelerar o que é linguístico, criativo, estrutural, exploratório e pedagógico. Usamos algoritmos, matemática e código convencional para aquilo que exige precisão, desempenho, rastreabilidade e repetibilidade. Unimos os dois mundos quando a LLM ajuda a construir, explicar ou operar um sistema cujo núcleo decisório continua tecnicamente verificável.

No fim, a IA Generativa não deve ser vista como uma desculpa para abandonar fundamentos. Ela deve ser vista como uma camada superior de expressão, uma interface poderosa entre intenção humana e artefato computacional. Mas toda nova linguagem de programação exige disciplina. Assim como não escrevemos firmware seguro apenas porque sabemos C, não construiremos sistemas confiáveis apenas porque sabemos conversar com uma LLM. A diferença entre o programador encantado e o engenheiro consciente está justamente aí: o primeiro se impressiona com a resposta; o segundo pergunta como validar, medir, testar, auditar e melhorar.

Rack Inteligente: https://github.com/RapportTecnologia/rack_inteligente_workspace