O Claude Code tem um hábito irritante: quando você pergunta como algo funciona no seu projeto, ele sai rodando uma sequência de greps antes de te responder.

Você pergunta "como esse fluxo de autenticação funciona?", aí ele começa: grep por aqui, grep por ali, lê três arquivos, grep de novo, mais um arquivo... você fica olhando ele trabalhar por uns 30 segundos até ele finalmente te responder.

O que me fez perceber que isso é desnecessário foi um teste simples. Interrompi ele no meio dos GREPs e perguntei diretamente: "o que você ainda precisa encontrar pra me responder?". Ele me respondeu: "já tenho tudo o que preciso" e foi lá e me explicou exatamente o que eu tinha pedido.

Ou seja, ele já tinha a resposta antes de terminar os GREPs. Continuou rodando comandos por inércia, comendo token à toa.

Não sei se é um comportamento de "parecer mais confiante na resposta" ou se é só como o modelo foi treinado pra agir em contexto de código, mas na prática é desperdício. Especialmente quando você está num plano com limite de uso ou pagando por token.

O que eu faço agora: quando ele começa uma sequência longa de buscas pra responder algo conceitual, eu interrompo e pergunto diretamente o que quero saber. Na maioria das vezes ele responde na hora, sem precisar de mais nenhum comando.

Como vocês resolveram esse "problema"? Colocando nos arquivos de instruções pra ele não rodar "grep"? Ou rodar de alguma forma específica?

O uso mais subestimado da IA em PHP não é gerar código — é revisar o seu

Reparei uma coisa em como a maioria usa IA pra programar: quase todo mundo usa pra gerar ("escreve uma função que faz X") e quase ninguém usa pra revisar ("olha o que eu escrevi e tenta achar onde isso quebra"). Na minha experiência, é no segundo uso que está o maior ganho — principalmente em PHP, que tem várias pegadinhas clássicas esperando um descuido.

Vou compartilhar o método que eu uso. Não é nada complicado, mas a diferença de resultado entre pedir certo e pedir errado é grande.

A diferença está na pergunta

O erro mais comum é pedir review de um jeito que já vicia a resposta:

> "esse código tá bom?"

A IA tende a concordar. Ela elogia a estrutura, sugere um nome melhor aqui e ali, e te devolve uma falsa sensação de segurança. Pergunta fraca, resposta fraca.

O que eu faço é o oposto — mando ela tentar derrubar o meu código:

> "aja como um revisor implacável. tenta quebrar essa função: que entradas, tipos inesperados ou casos de borda fazem ela se comportar mal? para cada ponto, explica por que é um problema."

Esse "tenta quebrar" muda a postura da IA e libera o que ela faz bem de verdade: reconhecer o erro clássico que já viu mil vezes. E o "explica por que" no fim não é detalhe — é o que me deixa julgar cada ponto em vez de aplicar no escuro.

Onde a IA acerta fácil no PHP

Pegar erro clássico é exatamente o tipo de coisa que ela pesca rápido. Alguns exemplos do que eu peço pra ela caçar:

Comparação solta com ==. Pego toda comparação que devia ser === e não é. O PHP converte tipo sem avisar, e isso morde:

in_array("1abc", [1, 2, 3]);        // true (!) sem o terceiro parâmetro
in_array("1abc", [1, 2, 3], true);  // false — comparação estrita

A IA aponta isso na hora quando você pede pra ela revisar comparação e checagem de tipo.

Caso de borda que o teste "feliz" não mostra. Eu dou a função e peço: "lista os casos de borda que isso não trata — vazio, nulo, zero, negativo, limite". Pra um foreach em cima do retorno de uma query, ela lembra do array vazio; pra um $dados['email'], ela lembra da chave que pode não existir (isset/??). É óbvio quando alguém aponta, e fácil de esquecer quando você só quer ver funcionando.

Segurança básica. Concatenar variável direto na query ("... WHERE id = " . $id), jogar dado do usuário na tela sem htmlspecialchars, comparar token com == em vez de hash_equals(). É o tipo de coisa que ela acha numa primeira passada.

Onde ela NÃO serve — e por isso a decisão é minha

Aqui está o ponto que separa usar a IA como revisora de usar como muleta: ela é a primeira revisão, nunca a última.

Ela não conhece o contexto do meu sistema. Vai apontar como bug uma regra que eu deixei daquele jeito de propósito. Vai sugerir uma abstração que o meu caso nem precisa. E o mais perigoso: vai inventar um problema que não existe, com o mesmo tom seguro de quando ela está certa. Não dá pra confiar num "tom de dúvida"; todo apontamento dela é uma suspeita pra eu checar, não uma sentença.

Por isso eu sigo uma regra só, pra cada sugestão que ela me dá:

> só aplico o que eu consigo explicar com minhas próprias palavras.

Se eu entendo o problema e concordo, aplico. Se eu não entendo, eu não copio e cola — pergunto "por que isso é um problema?" até entender, ou descarto. "A IA falou" nunca é justificativa que eu levo pro review com um humano.

Resumindo o método

1. Eu escrevo o código (eu, não ela).
2. Dou contexto: o que a função faz, de onde vêm os dados, o que me preocupa.
3. Peço pra ela tentar quebrar, não aprovar.
4. Exijo o "por quê" de cada ponto.
5. Filtro: aplico só o que entendo; ela revisa primeiro, eu decido por último.

O efeito colateral bom é que isso me deixa melhor, não mais dependente. Pedir o "por quê" toda vez faz você guardar o padrão — com o tempo, seu próprio olho começa a pegar a mesma coisa antes de você nem abrir o chat. A ferramenta devia estar te ensinando a enxergar, não enxergando no seu lugar.

É o contrário de pedir código pronto e colar sem entender. Mesma IA, resultado oposto.

---

Ando escrevendo sobre utilização de IA pra estudar/programar. Se interessar:

Utilização de IA para estudo: https://hdfreitas.github.io/ia-como-professor/

Utilização de IA para revisão de código: https://hdfreitas.github.io/ia-como-revisor/

O uso mais subestimado da IA em PHP não é gerar código — é revisar o seu

Reparei uma coisa em como a maioria usa IA pra programar: quase todo mundo usa pra gerar ("escreve uma função que faz X") e quase ninguém usa pra revisar ("olha o que eu escrevi e tenta achar onde isso quebra"). Na minha experiência, é no segundo uso que está o maior ganho — principalmente em PHP, que tem várias pegadinhas clássicas esperando um descuido.

Vou compartilhar o método que eu uso. Não é nada complicado, mas a diferença de resultado entre pedir certo e pedir errado é grande.

A diferença está na pergunta

O erro mais comum é pedir review de um jeito que já vicia a resposta:

> "esse código tá bom?"

A IA tende a concordar. Ela elogia a estrutura, sugere um nome melhor aqui e ali, e te devolve uma falsa sensação de segurança. Pergunta fraca, resposta fraca.

O que eu faço é o oposto — mando ela tentar derrubar o meu código:

> "aja como um revisor implacável. tenta quebrar essa função: que entradas, tipos inesperados ou casos de borda fazem ela se comportar mal? para cada ponto, explica por que é um problema."

Esse "tenta quebrar" muda a postura da IA e libera o que ela faz bem de verdade: reconhecer o erro clássico que já viu mil vezes. E o "explica por que" no fim não é detalhe — é o que me deixa julgar cada ponto em vez de aplicar no escuro.

Onde a IA acerta fácil no PHP

Pegar erro clássico é exatamente o tipo de coisa que ela pesca rápido. Alguns exemplos do que eu peço pra ela caçar:

Comparação solta com ==. Pego toda comparação que devia ser === e não é. O PHP converte tipo sem avisar, e isso morde:

in_array("1abc", [1, 2, 3]);        // true (!) sem o terceiro parâmetro
in_array("1abc", [1, 2, 3], true);  // false — comparação estrita

A IA aponta isso na hora quando você pede pra ela revisar comparação e checagem de tipo.

Caso de borda que o teste "feliz" não mostra. Eu dou a função e peço: "lista os casos de borda que isso não trata — vazio, nulo, zero, negativo, limite". Pra um foreach em cima do retorno de uma query, ela lembra do array vazio; pra um $dados['email'], ela lembra da chave que pode não existir (isset/??). É óbvio quando alguém aponta, e fácil de esquecer quando você só quer ver funcionando.

Segurança básica. Concatenar variável direto na query ("... WHERE id = " . $id), jogar dado do usuário na tela sem htmlspecialchars, comparar token com == em vez de hash_equals(). É o tipo de coisa que ela acha numa primeira passada.

Onde ela NÃO serve — e por isso a decisão é minha

Aqui está o ponto que separa usar a IA como revisora de usar como muleta: ela é a primeira revisão, nunca a última.

Ela não conhece o contexto do meu sistema. Vai apontar como bug uma regra que eu deixei daquele jeito de propósito. Vai sugerir uma abstração que o meu caso nem precisa. E o mais perigoso: vai inventar um problema que não existe, com o mesmo tom seguro de quando ela está certa. Não dá pra confiar num "tom de dúvida"; todo apontamento dela é uma suspeita pra eu checar, não uma sentença.

Por isso eu sigo uma regra só, pra cada sugestão que ela me dá:

> só aplico o que eu consigo explicar com minhas próprias palavras.

Se eu entendo o problema e concordo, aplico. Se eu não entendo, eu não copio e cola — pergunto "por que isso é um problema?" até entender, ou descarto. "A IA falou" nunca é justificativa que eu levo pro review com um humano.

Resumindo o método

1. Eu escrevo o código (eu, não ela).
2. Dou contexto: o que a função faz, de onde vêm os dados, o que me preocupa.
3. Peço pra ela tentar quebrar, não aprovar.
4. Exijo o "por quê" de cada ponto.
5. Filtro: aplico só o que entendo; ela revisa primeiro, eu decido por último.

O efeito colateral bom é que isso me deixa melhor, não mais dependente. Pedir o "por quê" toda vez faz você guardar o padrão — com o tempo, seu próprio olho começa a pegar a mesma coisa antes de você nem abrir o chat. A ferramenta devia estar te ensinando a enxergar, não enxergando no seu lugar.

É o contrário de pedir código pronto e colar sem entender. Mesma IA, resultado oposto.

---

Ando escrevendo sobre utilização de IA pra estudar/programar. Se interessar:

Utilização de IA para estudo: https://hdfreitas.github.io/ia-como-professor/

Utilização de IA para revisão de código: https://hdfreitas.github.io/ia-como-revisor/