A ilusão de "substituir por IA": por que o ROI real não tem nada a ver com hype
Toda semana alguém redescobre a AGI no X ou no LinkedIn (o que nem faz muito sentido enquanto a base ainda é predição de token) ou anuncia que um agente novo substitui cinco programadores sozinho.
O mercado comprou a ideia de que cuspir código rápido é a mesma coisa que entregar valor de verdade. Não é bem assim.
Uso IA todo santo dia e sou dos que mais puxam essa adoção no trabalho, mas de forma conservadora e sistemática: me importa o que funciona em produção, não o que o hype promete em vídeo editado.
A analogia clássica cabe aqui: a calculadora nunca extinguiu os matemáticos. Ela só tirou o trabalho braçal de fazer conta na mão para que eles pudessem focar no problema de verdade. Com IA no desenvolvimento é a mesma coisa, mas tem um detalhe estatístico que costuma ficar de fora da conta.
O perigo do erro acumulado
Independente do modelo, do raciocínio embutido ou do harness ao redor, IA continua sendo um modelo probabilístico: ela prevê o próximo token com base em estatística.
Mesmo com 99,9% de acurácia, aquele 0,01% de erro não desaparece. Em um projeto real, ele funciona como bola de neve:
[Prompt inicial] -> [Spec com desvio de 0,01%]
|
v
[Arquitetura meio torta]
|
v
[Código e testes gerados em cima do erro]
|
v
[Desvio acumulado: 1% -> 3% -> 10%]
A cada iteração a margem infla:
- A IA escreve a primeira especificação ou arquitetura e deixa passar uma linha equivocada.
- Como o texto parece coerente, ninguém percebe, e o time constrói o resto em cima dessa base.
- A cada rodada seguinte, o desvio cresce: de 0,01% para 1%, depois 3%, depois 10%.
Humanos também erram, mas costumam hesitar, desconfiar e perceber o problema depois de alguns testes. A IA erra com confiança absoluta: cospe um absurdo com a postura de quem tem certeza plena do que está fazendo.
Some um workflow saturado de código gerado por IA a uma revisão de PR preguiçosa, daquelas em que o dev só bate o olho e aprova, e a receita para a tragédia está pronta. Não demora para virar uma base de milhões de linhas de spaghetti code, que não aguenta estresse e que ninguém sabe por onde desenrolar.
O dev ainda precisa saber fazer a conta
Ver um MVP nascer a partir de um prompt é quase mágico, mas criar tela e rota básica é a parte fácil. O produto de verdade começa quando entram manutenção, escala, consistência de banco, segurança e regra de negócio complexa.
| O que o prompt resolve fácil | O que a engenharia de verdade exige |
|---|---|
| Sintaxe rápida e boilerplate | Arquitetura pensada para aguentar carga |
| Caminho feliz (happy path) | Lidar com falhas de rede, banco e filas |
| Protótipo visual para demo | Observabilidade, logs úteis e métricas reais |
| Gerar funções genéricas | Entender regras de negócio e trade-offs da empresa |
Se o dev não sabe montar o raciocínio sem a IA, se não entende a arquitetura e não consegue explicar o porquê de cada decisão, a empresa não ganhou velocidade: só contratou uma dívida técnica gigante a prazo.
O matemático precisa da teoria para notar quando a calculadora devolve um número absurdo. O dev precisa da mesma base para perceber quando a IA está inventando moda no código.
Repensar o processo, não trocar a pessoa por uma API
Casos de sucesso vendem curso e geram likes, então todo mundo posta. Os casos de fracasso, com projetos que desmoronaram porque foram feitos nas coxas com ferramentas automáticas, passam batidos e ninguém comenta. Adoção de tecnologia em produção é coisa séria: um deslize na fundação e o castelo inteiro cai.
O erro comum é achar que adotar IA é pegar um processo antigo, feito para humanos, e trocar a pessoa por uma chamada de API para cortar custo. O ponto não deveria ser "usar IA" ou "jogar IA no time", e sim repensar o fluxo integrando ela:
- Separar o determinístico do probabilístico. Se uma regra de negócio precisa de precisão estrita, um script clássico dá de dez a zero em qualquer LLM em custo, velocidade e confiabilidade.
- Tirar o atrito braçal do dev. Usar a máquina onde ela brilha sem risco: gerar massa de dados de teste, rascunhar documentação chata, adiantar código repetitivo.
- Cobrar mais visão crítica do time. A habilidade mais importante do dev deixa de ser digitar rápido e passa a ser auditar, criticar e entender exatamente o que aquele código gerado está fazendo por baixo dos panos.
Conclusão
IA é uma ferramenta indispensável e veio para ficar, mas funciona como uma lente de aumento. Se a base for boa e o time tiver maturidade técnica, ela faz a equipe voar. Se a arquitetura for frágil e as revisões forem feitas no automático, ela só ajuda o projeto a bater no muro mais rápido.