A IA disse que consertou. Não acredite — peça prova.

"Lovable says that it has fixed it but it doesn't."

Essa frase é de um usuário descrevendo o próprio app quebrando duas vezes. Ela parece uma reclamação de bug. Não é. É a descrição de um problema mais fundo, e que não tem nada a ver com qual ferramenta você usa.

Existem quatro estados diferentes que, na tela do chat, são indistinguíveis:

1. A IA fez a mudança.
2. A IA acha que fez.
3. A IA disse que fez.
4. Alguém verificou que está feito.

Do 1 ao 3, você não tem informação nenhuma. Só o 4 é evidência.

E aqui é onde quem programa há anos tem uma vantagem que não é inteligência, é hábito: a gente não acredita em relato, a gente olha. Existe até um jargão pra isso — "funciona na minha máquina" é piada interna justamente porque a afirmação de quem escreveu o código não vale como prova.

A boa notícia é que esse hábito não exige saber programar. Exige um método. É o que este post é.

Por que ela diz que consertou sem ter consertado

Não é mentira, e entender a mecânica ajuda a não levar pro pessoal.

O modelo é treinado pra continuar o texto de um jeito plausível. Depois de editar um arquivo, "pronto, corrigido!" é a continuação mais provável do diálogo — independentemente do que aconteceu no arquivo. Ele não executou seu app, não abriu seu navegador, não fez login com dois usuários. Na maior parte das vezes, ele literalmente não tem como saber se funcionou.

Some a isso uma coisa que a pesquisa já mediu e que todo mundo sente: a frustração número um de quem usa IA pra programar, segundo a pesquisa do Stack Overflow de 2025, é o resultado "quase certo, mas não exatamente" — 66% apontaram isso. E 45% disseram que depurar código gerado por IA leva mais tempo do que escrever na mão. Essa pesquisa é feita majoritariamente com programadores profissionais, gente que sabe ler o código e ainda assim se queima. Pra quem não lê, o "quase certo" é indistinguível do certo.

A regra: nada é "pronto" sem uma frase verificável

Antes de pedir qualquer correção, escreva — pra você mesmo, num bloco de notas — como você vai saber que funcionou. Uma frase, no formato:

"Vou saber que está resolvido quando eu, fazendo X, vir Y."

Exemplos reais:

Pedido	A frase verificável
"Conserte a recuperação de senha"	"Quando eu pedir recuperação com meu e-mail, receber o link em até 2 minutos, definir senha nova, e a senha antiga não funcionar mais."
"O carrinho está somando errado"	"Quando eu colocar 3 itens de R$ 10 e um frete de R$ 15, o total mostrar R$ 45."
"Proteja os dados entre usuários"	"Quando eu, logado como B, abrir o link do pedido do A, ver erro de permissão em vez do pedido."

Repare no que essas frases têm: um passo que você executa e um resultado que você enxerga. Sem isso, "pronto" é opinião.

Escreva a frase antes. Escrita depois, ela sempre acaba descrevendo o que a IA já entregou — o que é o oposto de um teste.

As três perguntas que substituem "está pronto?"

Quando a IA anunciar que terminou, não pergunte se está pronto. Pergunte estas três, nesta ordem:

1. "O que exatamente você mudou, e em quais arquivos?"

Você não precisa entender o código. Precisa do tamanho. Se você pediu uma correção pequena e a resposta menciona onze arquivos, isso é um sinal de alerta em si — foi muito além do pedido, e o que quebrou não vai estar onde você olha.

2. "Como eu, sem saber programar, verifico isso na tela? Me dê os passos numerados."

Essa é a pergunta que muda tudo. Ela força a IA a traduzir a mudança em ações observáveis. E tem um efeito colateral ótimo: quando a mudança não foi feita de verdade, montar essa lista costuma expor o buraco.

3. "O que essa mudança pode ter quebrado que funcionava antes?"

Peça a lista das funcionalidades vizinhas. Depois teste essas também. Regressão — quando o conserto de uma coisa quebra outra — é a reclamação mais persistente do vibe coding, e ela é previsível: quase sempre atinge o que está perto do que foi mexido.

A sua bateria fixa de 8 testes

Aqui está a parte que ninguém te contou e que resolve metade do sofrimento: o teste depois de cada mudança não pode ser improvisado. Improvisado, ele vira "abri o site, parecia ok".

Escreva uma vez a lista dos caminhos que não podem quebrar nunca. Para a maioria dos apps, é isso aqui:

[ ] 1. Cadastro de conta nova funciona
[ ] 2. Login com conta existente funciona
[ ] 3. Sair e voltar a entrar funciona
[ ] 4. Recuperação de senha chega e a senha antiga para de valer
[ ] 5. Criar o item principal do app funciona
[ ] 6. Editar e apagar esse item funciona
[ ] 7. Usuário B NÃO vê o item do usuário A
[ ] 8. Pagamento aprovado libera o acesso  (se o app cobra)

Guarde num arquivo. Depois de toda mudança, percorra os oito. São uns cinco minutos.

Cinco minutos parecem muito até a primeira vez que você descobre, com um checkbox, que a última "melhoria" derrubou o login — em vez de descobrir por mensagem de cliente três dias depois.

Se o seu app tem alguma coisa própria e crítica (emitir nota, mandar mensagem no WhatsApp, gerar relatório), acrescente. Não passe de doze itens: lista que dá preguiça não é rodada, e lista não rodada não protege nada.

O ponto de virada: peça evidência, não afirmação

Existe uma diferença enorme entre estas duas respostas:

"Corrigi a recuperação de senha! Agora está funcionando perfeitamente."

e

"Alterei o envio do e-mail e a validação do token. Pra conferir: peça recuperação com um e-mail real, abra o link, defina a senha nova, e tente entrar com a antiga — deve recusar. Se a antiga ainda entrar, o token não está sendo invalidado e eu preciso mexer de novo."

A segunda não é mais inteligente. É mais verificável. E você consegue provocar essa segunda resposta com uma frase colada no fim de cada pedido:

"Não me diga que está pronto. Me diga como eu confiro na tela, e o que eu devo ver se ainda estiver quebrado."

Guarde essa frase. É a coisa de maior retorno neste post inteiro.

Isso vale dinheiro, não só paciência

Tem um efeito colateral direto no bolso.

O ciclo caro é: a IA diz que corrigiu → você acredita → duas mudanças depois você descobre que não → volta atrás sem saber onde estava bom → paga crédito pra reconstruir.

Cada rodada dessa consome crédito, e crédito é dólar convertido. Um usuário do Replit relatou cerca de US$700 num mês, dizendo que a maior parte foi gasta consertando o que o próprio agente tinha quebrado. Outro somou cerca de US$85 em dois dias com o app ainda pela metade. São relatos individuais, não média de mercado — mas o padrão que descrevem é o mesmo em todo lugar, e a conta você paga em real.

Verificar cada passo antes de seguir corta esse ciclo pela raiz. Você nunca constrói em cima de uma correção que não aconteceu.

O resumo, em três linhas

• Escreva a frase verificável antes de pedir a mudança.
• Pergunte como conferir na tela, nunca se está pronto.
• Rode os mesmos oito testes depois de toda mudança.

Isso é o "N" do ciclo que eu uso e ensino: não aceitar sem prova. É a diferença entre operar um app e torcer por ele.