"Ler o diff sem saber programar: as 3 perguntas que eu faço pra qualquer mudança que a IA propõe"

"Você terá de abrir, revisar, criticar... É quase uma troca."

Foi a resposta de alguém, num fórum brasileiro, pra quem perguntou se dá pra construir um app sem pôr a mão no código. A resposta é sim — com esse porém. E o porém assusta, porque "revisar" soa como ler código, coisa que você não sabe fazer.

Não é. Revisar a mudança que a IA propôs não é ler código. É ler uma lista do que mudou, e essa lista tem um formato próprio, pensado pra ser batido de olho. O nome dele é diff. Hoje eu te ensino a lê-lo, e as três perguntas que eu faço em cima dele — principalmente a segunda, que é onde mora a mudança que conserta uma coisa e quebra outra.

O que é um diff, em trinta segundos

Diff vem de difference, diferença. É o antes e o depois do seu app, colocados lado a lado, mostrando só o que mudou. Funciona igual ao controle de alterações do Word:

• Linha que entrou aparece marcada com um + na frente, quase sempre pintada de verde.
• Linha que saiu aparece com um - na frente, quase sempre de vermelho.
• Linha que não mudou fica cinza, só pra você se situar.

No topo vem a lista de arquivos que a mudança tocou, cada um com o nome. Essa lista é metade do trabalho, e você vai ver por quê.

Você não precisa entender o que as linhas fazem. Precisa saber se elas deviam estar ali. É uma pergunta de dono, não de programador.

Onde você vê o diff

• Código na sua máquina (Cursor, Claude Code): no terminal, dentro da pasta do projeto, o comando git diff mostra tudo que mudou desde o último ponto marcado, com os + e -. O Claude Code ainda tem um atalho, /diff, que abre essa comparação já formatada.
• No GitHub (se o seu código está lá): a aba Files changed de cada mudança mostra o mesmo, com verde e vermelho, sem terminal nenhum.
• Nas plataformas (Lovable, Replit): cada uma tem um botão de histórico que abre o diff de cada resposta da IA. O passo a passo de onde clicar, e por que isso não custa crédito, está aqui — aquele post olha o diff pelo lado do custo; este olha pelo lado da regressão, que é a quebra.

As três perguntas, nesta ordem

1. Mexeu nos arquivos que era pra mexer?

Olhe primeiro a lista de arquivos no topo, não as linhas. Conte quantos são e leia os nomes.

Você pediu um campo novo numa tela e a lista tem um arquivo só, com nome parecido com a tela? Ótimo. A lista tem onze arquivos, incluindo um com auth ou login (a entrada), payment, checkout ou stripe (a cobrança), migration ou sql (a estrutura do banco)? Pare. Você não precisa entender esses arquivos pra saber que um campo de texto não tinha por que mexer na cobrança. O tamanho errado é o aviso, e você reconhece o tamanho errado sem saber uma linha de programação.

2. O que sumiu?

Esta é a pergunta do post, e a que quase ninguém faz. Todo mundo olha o verde — o que a IA acrescentou. O que quebra o seu app costuma estar no vermelho — o que ela tirou.

Regressão é isso: pra fazer o que você pediu, a IA removeu ou reescreveu um pedaço que estava segurando outra coisa de pé. Aquele cálculo que funcionava, aquela verificação de quem pode ver o quê, some numa linha vermelha no meio do diff, sem alarde, enquanto você comemora o verde.

Então percorra as linhas vermelhas e procure, nelas, palavras que aparecem na sua tela: nome de botão, de campo, de cálculo, a palavra "total", "senha", "desconto". O código escreve essas coisas em português, do jeito que o cliente lê. Sumiu "total" numa linha vermelha e você só pediu um campo de observação? A IA mexeu no que você não mandou. Você acabou de achar a próxima quebra antes do cliente.

3. O teste rodou?

O diff diz o que mudou. Não diz se funciona. Então, depois de ler, confira com o olho: abra o app e refaça a frase que você escreveu antes de pedir — "vou saber que está pronto quando, fazendo X, eu vir Y". E rode o teste rápido dos caminhos que não podem quebrar: login, cadastro, criar o item principal, a conta B não ver o dado da conta A. São os que a pergunta 2 te avisou que talvez tenham sumido.

A folha, pra colar ao lado da tela

Antes de aprovar qualquer mudança da IA:

[ ] 1. Contei os arquivos. O tamanho bate com o que pedi?
[ ] 2. Li as linhas VERMELHAS. Sumiu alguma palavra da minha tela?
[ ] 3. Abri o app e refiz o teste do que não pode quebrar?

Qualquer "não" → não aprovo. Volto pro ponto anterior e peço de novo, menor.

Era o "N" de não aceitar sem prova

Ler o diff leva uns três minutos por resposta da IA, e é a diferença entre pegar a quebra agora, de graça, ou empilhar três pedidos em cima dela e descobrir pelo cliente. Isso é o "N" do jeito que eu trabalho: não aceitar o "pronto" sem olhar a prova.

Funciona melhor se o pedido já foi pequeno e cercado, e se existe um ponto pra onde voltar quando a pergunta 2 achar algo feio. Cada uma dessas é outra parede, e elas têm ordem. A de hoje é só esta: na próxima vez que a IA disser "pronto", antes de digitar qualquer coisa, abra o diff e leia o vermelho.

Fontes

• Git — documentação do git diff (formato unificado: + para linha adicionada, - para removida, com cabeçalho dos arquivos alterados): https://git-scm.com/docs/git-diff