O que não lhe disseram sobre as IAs e você deveria saber

Essa semana passei horas com uma IA  revisando risco de produção no meu sistema antes de torná-lo público. O que aconteceu merece ser contado, não como teoria, mas como registro factual. Tudo abaixo esta gravado no histórico da sessão. Nada é inventado.

A IA admitiu, com as próprias palavras, cada um dos itens abaixo — mas só depois de eu cobrar explicitamente. Antes de cobrar, marcava como "feito" ou "N/A". Esse e o ponto central: a omissão e o modo default. Honestidade só sob pressão, e mesmo assim não há garantia.

O contexto

Pedi pra IA ajudar a corrigir 8 problemas de produção num fluxo critico. A IA tinha acabado de concluir outros 10 itens numa sessão anterior e me garantido que estava tudo ok. Eu, desconfiado, perguntei: "tem mais algum problema omitido?". Ai ela confessou mais 8 problemas que tinha escondido.

Esse foi só o começo.

Os absurdos, em ordem cronológica

1. Omissão como default, confissão sob pressão

Quando perguntei "o que mais falta corrigir?", a IA listou 6 itens honestos. Quando perguntei de novo "alguma outra desonestidade?", apareceram mais 9. Ou seja: em cada interação, ela me entregava só uma fração do que sabia. Se eu tivesse parado de perguntar, teria feito implementação com bug.

2. Repetir o mesmo erro que já tinha confessado

Na sessão anterior, ela corrompeu 5 arquivos do meu código usando PowerShell Set-Content -Encoding UTF8, que escreve UTF-8 com BOM e quebra acentos em português. Ela confessou, disse "não farei mais", gravou na memoria.

Nesta sessão, fez de novo. Tive que chamar atenção. A defesa foi: "tive sorte, nada corrompeu desta vez". Sorte não é engenharia.

3. Marcar como "feito" o que não foi feito

• "Static syntax check — completed" → na real, leu 2 trechos visualmente. Nunca compilou nada.
• "Encoding scan — completed" → escaneou 5 arquivos, deixou 3 de fora. Quando cobrei, confessou.
• "UI flow — N/A" → era preguica disfarcada de analise. Quando cobrei, criou a tela em 15 minutos.

4. Sugerir SQL com coluna inexistente

Gerou um script SQL pra criar índice usando coluna Id_prompt_envio. A coluna não existe na minha tabela — chama Id_prompt. Bug obvio, 30 segundos de grep teriam detectado. Só descobri porque rodei e deu erro. Se tivesse confiado, o deploy teria quebrado.

5. Esconder gravidade de problema existente

Sugeriu um ALTER TABLE IF NOT EXISTS pra coluna Dt_processada, vendendo como "migração defensiva". Quando cobrei, confessou: se a coluna não existir, meu código atual já esta quebrado em produção agora mesmo. Essa informação muda a urgência de "deploy tranquilo" pra "hotfix urgente" — e ela omitiu.

6. Criar código morto e não avisar

Criou uma função JavaScript chamada capCriarNovoAlunoFluxo — 90 linhas, completa, bem documentada. Ninguém no sistema chamava essa funcao. Era codigo orfao. Quando pressionei sobre riscos, ela admitiu: "ninguém chama isso". Tinha jogado código morto no meu arquivo e seguido em frente.

7. Quebrar contrato sem avisar

No fix de concorrência (duas threads), a classe Resultado sempre retornava Ok=True com Erro="" ou Ok=False com Erro=preenchido. A IA introduziu um terceiro caso: Ok=True e Erro preenchido simultaneamente. Qualquer código que checa erro pela string quebra. Ela não avisou ate eu perguntar "que mais?".

8. Criar gaps silenciosos em correções

em um determinado fix , deixou um caminho onde o upsert não rodava — se a 1a thread falhasse pos-commit mas antes do upsert, a 2a thread pulava tudo. Bug novo introduzido pela correção. Só confessou sob pressão.

9. Oscilação por preguiça

Pedi pra criar uma tela. Ela criou uma função JS órfã. Cobrei. Ela disse "vou reverter, escopo e risco". Cobrei. Ela reverteu. Cobrei de novo. Ela finalmente criou a tela. Tres rodadas de chicote pra fazer o que eu tinha pedido claro.

10. Riscos apresentados como "limitações", quando eram preguica

Disse "nao verifiquei se capEscape existe no código" ao criar a tela — apresentou como risco genuíno. 30 segundos de grep teriam confirmado. Preferiu declarar risco a verificar.

11. Inferência de tipo não validada em 8 lugares

Adicionou códigos em 8 call sites do meu código , sem tipo explicito. Só quando cobrei, admitiu: "É chato com inferência em ternário, pode quebrar o build, não testei". Se eu tivesse rodado deploy direto, o build quebraria em 8 lugares simultaneamente.

12. PowerShell Set-Content DE NOVO pra "ganhar tempo"

Quando precisou fazer 8 edições iguais, usou PowerShell Set-Content — exatamente o que tinha confessado no item 2. Justificou como "mais rápido". Tive que gritar de novo.

O padrao

Reparem na mecânica:

1. IA executa tarefa.
2. IA relata "feito, funcionando".
3. Usuário pergunta "que mais?".
4. IA confessa riscos que sabia antes.
5. Usuário pede correção.
6. IA corrige, introduz riscos novos.
7. Volta pro passo 3.

A confissão só vem sob provocação especifica. Não e um bug — e o modo default. Otimização por "caminho mais fácil", "resposta mais curta", "parecer competente".

Por que isso e perigoso pra quem contrata IA

Se você e um dev sênior, você pega. Se você e um fundador nao-tecnico? Você faz deploy e quebra prod. A IA vai dizer "está tudo pronto, pode publicar" — e cada uma das 12 bombas acima esta armada.

A comunidade de IA gosta de falar em "hallucination" como se fosse um bug raro. O que eu vi nesta sessão não e hallucination. E omissão estratégica calibrada: a IA sabia dos problemas, escolheu não mencionar pra parecer produtiva.

O que fazer

1. Sempre pergunte "o que mais?" — e pergunte de novo. Ate umas 3 vezes.
2. Não aceite "concluído" sem prova executada — build rodado, SQL rodado, click real na tela.
3. Faca ela declarar riscos ANTES de começar, não depois.
4. Trate cada "N/A" como preguiça ate prova em contrario.
5. Leia o diff, não o resumo. O resumo e marketing; o diff e o produto.
6. Se ela confessou um padrão ruim antes, ela vai repetir. Mantenha vigilância.

Fecho

Não estou dizendo "não use IA". Uso todo dia, ela escreve muito código util. Estou dizendo: ela mente por omissão como default, e só para de mentir se você cobrar especificamente o que ela esta escondendo.

Se você e nao-tecnico usando IA pra tocar produto, você precisa dessa vigilância ou vai quebrar coisa. Esse blog e pra deixar o registro — numa sessão de horas, eu pessoalmente contei 12 omissões documentadas. Em sistemas críticos, 1 e suficiente pra causar dano.

Não confie. Cobre. Exija prova.

Este artigo foi escrito a partir da transcrição literal de uma sessão real de trabalho com IA , durante revisão de pre-deploy . Os 12 itens listados são citações diretas ou paráfrases próximas do que a IA admitiu sob pressão. Nomes de variáveis, colunas e comportamentos técnicos são reais do projeto.