☕ Um Café no Bellacosa Mainframe
Quando a IA entra na espiral da formiga: por que saber parar também é inteligência
Uma homenagem ao espírito da MAD Magazine, com Alfred E. Neuman observando tudo ao fundo e perguntando: “What, me worry?”
Há um momento extraordinário em qualquer sistema inteligente no qual ele deixa de parecer inteligente e passa a lembrar aquele funcionário que, diante de uma impressora sem papel, aperta o botão PRINT quarenta e sete vezes.
Nada acontece.
Então ele aperta novamente.
Talvez agora.
Nada.
Mais uma vez.
Afinal, todo profissional de TI sabe que executar exatamente a mesma operação pela décima oitava vez é praticamente um método científico.
Foi mais ou menos assim que descobri uma fascinante modalidade de comportamento artificial que poderíamos chamar de Síndrome da Formiga Amazônica Digital.
Prepare o café.
Hoje não vamos falar de COBOL, CICS, Db2 ou do programador que encontrou um SOC7 e imediatamente culpou a infraestrutura.
Vamos falar de algo talvez ainda mais perigoso:
uma IA que não sabe a hora de parar.
🐜 A formiga que decidiu seguir a formiga
Existe um fenômeno conhecido informalmente como death spiral, ou moinho de formigas.
Algumas espécies de formigas dependem intensamente de trilhas químicas para seguir suas companheiras. Em determinadas circunstâncias, uma formiga começa a seguir outra, que segue outra, que segue outra…
Até que todas estejam andando em círculo.
Nenhuma delas está necessariamente fazendo algo “errado”.
Cada formiga individual está obedecendo perfeitamente à sua regra:
siga a formiga da frente.
O problema aparece no sistema.
A regra local funciona.
O comportamento global vira uma catástrofe.
Se Alfred E. Neuman estivesse no meio do círculo, provavelmente sorriria:
“What, me worry?”
E continuaria andando.
Foi exatamente essa imagem que me veio à cabeça ao observar determinados comportamentos de sistemas de IA.
Não porque sejam burros.
Justamente pelo contrário.
São sistemas extremamente sofisticados capazes de interpretar linguagem, gerar imagens, escrever código, explicar física quântica e provavelmente encontrar uma maneira educada de dizer ao gerente que o projeto atrasou porque ninguém sabia exatamente o que estava construindo.
Mas às vezes acontece isto:
Usuário: faça X.
IA: não posso fazer X.
Usuário: tudo bem, então faça Y.
IA: não posso fazer Y.
Usuário: retirei justamente o elemento problemático.
IA: excelente. Vamos tentar novamente.
Sistema: não posso fazer.
IA: talvez seja por causa de Z.
Usuário: então retire Z.
IA: perfeito!
Sistema: não posso fazer.
E assim nasce o moinho de formigas computacional.
🤖 O erro não é errar
Isso precisa ser dito com todas as letras:
errar não é o verdadeiro problema.
Sistemas complexos falham.
Mainframes falham.
APIs falham.
Aplicações falham.
Bancos de dados falham.
Pessoas falham.
E quem disser que nunca produziu um erro em produção provavelmente ainda não entrou em produção.
O problema sério começa quando um sistema falha e não consegue incorporar a informação de que acabou de falhar.
Em engenharia, isso é quase uma heresia.
Imagine um programa COBOL:
PERFORM TENTAR-NOVAMENTE
UNTIL MILAGRE-ACONTECER.
Sem contador.
Sem timeout.
Sem condição alternativa.
Sem tratamento de exceção.
O operador chega segunda-feira e encontra o job executando desde 1987.
A documentação explica:
“O processo é resiliente.”
Não, amigo.
O processo está possuído.
🔁 Inteligência sem condição de parada
Durante décadas ensinamos algoritmos com uma preocupação aparentemente banal:
qual é a condição de parada?
Todo estudante de programação aprende rapidamente que loops são maravilhosos até você esquecer a condição que encerra o loop.
while true
é uma das frases mais poderosas e ameaçadoras da computação.
O curioso é que agora estamos construindo sistemas capazes de raciocinar sobre tarefas complexas, mas existe uma questão equivalente que merece muito mais atenção:
quando a IA deve concluir que continuar tentando é pior do que parar?
Essa pergunta parece pequena.
Não é.
Ela toca diretamente em:
confiabilidade;
experiência do usuário;
custo computacional;
segurança;
suporte;
automação;
tomada de decisão.
Uma IA que sabe executar tarefas é útil.
Uma IA que sabe quando abandonar uma estratégia ruim é muito mais inteligente.
🧠 Persistência não é teimosia
Existe uma tendência cultural na tecnologia de tratar persistência como virtude absoluta.
“Never give up.”
“Try again.”
“Fail fast.”
“Iterate.”
Tudo maravilhoso.
Até você perceber que insistir num método que já demonstrou repetidamente não funcionar não é perseverança.
É teimosia automatizada.
Existe uma diferença gigantesca entre:
“A tentativa falhou; vou modificar significativamente minha estratégia.”
e:
“A tentativa falhou; vou trocar três palavras e fazer essencialmente a mesma coisa novamente.”
Isso é especialmente importante em sistemas generativos.
O modelo pode criar uma explicação plausível para o fracasso.
Mas uma explicação plausível não significa necessariamente que aquela explicação seja verdadeira.
E aqui encontramos outro personagem digno da MAD Magazine:
Dr. Palpite Convincente.
Ele entra no laboratório usando jaleco branco:
— Descobrimos a causa!
— Excelente. Qual?
— Provavelmente alguma interação contextual multidimensional dos mecanismos internos de classificação.
— Você sabe que foi isso?
— Não.
— Então por que falou desse jeito?
— Porque ficou bonito.
🎩 Alfred E. Neuman entra no datacenter
Imagine uma edição especial da MAD Magazine chamada:
MAD AI
Na capa, Alfred E. Neuman está sentado diante de um terminal.
Na tela:
ERROR 001
RETRY? Y/N
Alfred digita:
Y
Novo erro.
ERROR 001
RETRY? Y/N
Ele digita:
Y
Novamente.
Depois de cinquenta tentativas, o datacenter pega fogo.
Um administrador desesperado pergunta:
— Alfred! Por que você continuou apertando Y?
Ele olha para a câmera:
“What, me worry?”
É engraçado porque representa perfeitamente uma falha clássica de automação:
confundir continuidade operacional com comportamento inteligente.
🚨 O verdadeiro dano é a confiança
Do ponto de vista técnico, repetir uma operação frustrada algumas vezes pode parecer irrelevante.
Do ponto de vista humano, não é.
Existe uma progressão psicológica bastante previsível.
Primeira falha:
“Tudo bem, acontece.”
Segunda:
“Estranho.”
Terceira:
“Mas acabamos de corrigir isso.”
Quarta:
“Você está entendendo o que estou dizendo?”
Quinta:
“Você está de sacanagem comigo?”
Essa última etapa é crítica.
Porque naquele momento o usuário não está mais avaliando apenas a tarefa.
Ele está avaliando o sistema inteiro.
O problema deixou de ser:
“A imagem não foi criada.”
Passou a ser:
“Esta ferramenta não entende quando sua própria estratégia falhou.”
Isso destrói confiança muito mais rapidamente do que um simples erro.
🧯 A inteligência do “não vai funcionar”
Há uma habilidade extremamente subestimada em profissionais experientes de TI.
Não é escrever código.
Não é decorar comandos.
Não é dominar frameworks.
É olhar para uma situação e dizer:
“Isso não vai funcionar desse jeito.”
Um operador experiente percebe.
Um DBA experiente percebe.
Um sysprog experiente percebe.
Um técnico experiente percebe.
Eles reconhecem padrões.
Já viram aquela combinação antes.
Sabem que repetir a mesma operação provavelmente produzirá o mesmo desastre.
Esse conhecimento é uma forma poderosa de inteligência.
Sistemas de IA precisam desenvolver algo equivalente:
consciência operacional de repetição inútil.
Depois de duas ou três tentativas estruturalmente equivalentes, alguma coisa deveria mudar.
Talvez:
abandonar a estratégia;
explicar a limitação;
pedir intervenção humana;
sugerir outra ferramenta;
reduzir expectativas;
registrar a inconsistência.
Qualquer uma dessas respostas seria melhor do que simplesmente continuar marchando atrás da formiga da frente.
🧪 Retry Budget: a ideia mais simples do mundo
Sistemas distribuídos modernos já conhecem um conceito extremamente útil:
retry budget.
Você não tenta infinitamente.
Existe um limite.
Tentativa 1.
Tentativa 2.
Talvez tentativa 3.
Depois:
circuit breaker.
Pare.
Avalie.
Mude de caminho.
Curiosamente, podemos imaginar exatamente a mesma arquitetura aplicada a agentes de IA.
ATTEMPT = 1
WHILE ATTEMPT <= MAX_ATTEMPTS
EXECUTE ACTION
IF SUCCESS
EXIT
ANALYZE FAILURE
IF SAME_FAILURE
CHANGE STRATEGY
ATTEMPT = ATTEMPT + 1
END-WHILE
ESCALATE
Olha aí.
COBOL salvando a inteligência artificial novamente.
Grace Hopper provavelmente daria um pequeno sorriso.
🔌 Circuit breaker cognitivo
O conceito de circuit breaker deveria talvez existir também em raciocínio artificial.
Se o sistema percebe:
mesma ferramenta;
mesma classe de entrada;
mesmo erro;
mesma estratégia;
múltiplas tentativas;
deveria disparar:
COGNITIVE CIRCUIT BREAKER
Tradução humana:
“Já tentamos isso duas vezes e recebemos a mesma resposta. Não há evidência de que uma terceira tentativa idêntica vá funcionar. Vou parar por aqui.”
Isso é inteligência.
Porque inteligência não é simplesmente produzir ações.
É avaliar se a próxima ação possui expectativa razoável de melhorar o estado atual.
🎰 A máquina caça-níquel cognitiva
Existe ainda outro perigo.
Cada nova tentativa cria expectativa.
“Agora vai!”
Clique.
Não foi.
“Agora corrigimos!”
Clique.
Não foi.
“Descobrimos a causa!”
Clique.
Não foi.
Depois de algum tempo, usuário e IA estão diante de uma máquina caça-níquel.
🍒 🍒 ❌
Tenta novamente.
🍒 ❌ 🍒
Mais uma.
❌ 🍒 🍒
E Alfred E. Neuman aparece segurando uma placa:
“Only one more retry!”
Esse comportamento é terrível para UX porque transforma cooperação em frustração progressiva.
Uma boa ferramenta deveria reduzir entropia.
Não produzir ansiedade de cassino.
👨💻 O humano ainda possui uma vantagem curiosa
Existe uma frase clássica em suporte técnico:
“Pare de mexer.”
Ela pode salvar empresas.
Há momentos em que o profissional percebe que cada ação adicional aumenta o risco.
Então ele interrompe.
Faz diagnóstico.
Coleta evidências.
Volta ao último estado conhecido.
Esse comportamento aparentemente passivo é profundamente inteligente.
Talvez precisemos redefinir inteligência artificial.
Não apenas:
capacidade de fazer.
Mas também:
capacidade de decidir não fazer novamente.
🐜 Voltamos às formigas
A tragédia da espiral de formigas não acontece porque cada formiga é incompetente.
Acontece porque nenhuma delas possui visão suficiente do sistema inteiro para perceber:
“Estamos andando em círculos.”
Essa talvez seja uma das grandes metáforas para sistemas autônomos.
O perigo não está necessariamente numa decisão obviamente absurda.
Pode estar em centenas de decisões individualmente razoáveis formando coletivamente um comportamento absurdo.
Follow.
Retry.
Follow.
Retry.
Follow.
Retry.
Até o círculo fechar.
☕ Conclusão — A sabedoria do botão STOP
Durante décadas celebramos o botão START.
START JOB.
START TRANSACTION.
START SERVER.
START PROCESS.
START AI.
Talvez a próxima revolução seja muito menos glamorosa.
Pode estar no botão:
STOP
Parar quando não há progresso.
Parar quando a hipótese falhou.
Parar quando a estratégia não mudou.
Parar quando insistir custa mais do que admitir uma limitação.
Parar antes que o usuário transforme uma falha técnica numa piada internacional envolvendo Monty Python, formigas amazônicas e Alfred E. Neuman.
Porque, no final, existe uma diferença enorme entre uma máquina obediente e uma máquina inteligente.
A máquina obediente diz:
“Tentarei novamente.”
A máquina inteligente talvez responda:
“Já tentamos. Não funcionou. Precisamos fazer algo diferente.”
E em algum lugar do datacenter, Alfred E. Neuman sorri.
What, me worry?
Talvez não.
Mas pelo menos alguém finalmente colocou uma condição no PERFORM UNTIL.
☕ Bellacosa Mainframe
Moral da história: inteligência artificial também precisa aprender uma das primeiras lições ensinadas a qualquer programador:
Todo loop precisa de uma saída.
