Como revisar com o Claude Code o código que você gerou no DeepSeek antes de abrir o PR

O trecho que o DeepSeek te entrega parece certo

Indentado, comentado, com nome de variável bonitinho, tudo no lugar

E é justamente por parecer certo que ele passa direto pro projeto sem ninguém olhar de perto

O cenário é conhecido: você abre o chat.deepseek.com, que é gratuito, joga o problema lá, o DeepSeek-V4-Pro-0813 responde com uma função completa (o modelo tem janela de até 1 milhão de tokens de contexto e pesos abertos sob licença MIT), você copia e cola no arquivo

Só que tem um detalhe que muda tudo: aquele contexto gigante estava cheio da SUA conversa, não do seu repositório

O chat nunca viu a sua pasta src, nunca abriu o seu package.json, não sabe qual biblioteca o time decidiu banir em 2024 e não faz ideia se aquele helper que ele acabou de inventar já existe três pastas acima

Então bora montar o fluxo de conferência: o que checar no código que veio do chat e como o Claude Code entra depois, lendo o diff já aplicado no repositório, antes de você abrir o PR

O que você precisa antes de rodar a revisão

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

A revisão do Claude Code lê CÓDIGO, não conversa

Isso muda a ordem das coisas, se liga:

• O trecho do DeepSeek já aplicado em arquivos do repositório, porque a revisão trabalha em cima do diff, e não do texto que ficou na aba do navegador
• Uma branch própria com upstream configurado, já que por padrão a revisão local cobre os commits da sua branch à frente do upstream mais qualquer alteração não commitada no working tree
• Um CLAUDE.md na raiz do projeto, que é o arquivo markdown que o Claude Code lê no início de toda sessão, onde moram padrões de código, decisões de arquitetura, bibliotecas preferidas e checklists de revisão

E o que NÃO é pré-requisito, pra tirar essa dúvida logo: o /code-review roda direto no terminal, sem precisar instalar o GitHub App

Não tem etapa de configurar integração, autorizar org, esperar aprovação de admin, nada disso

Abriu o terminal no projeto, roda 🙂

Passo a passo: revisando no Claude Code o código gerado no DeepSeek

A ideia aqui é transformar isso num ritual curto, de dois comandos, que você repete antes de todo PR

1. Aplique o trecho em arquivos reais

Cola o código do chat no arquivo que ele deveria viver, ajusta imports e nomes, e deixa assim: ou commitado na sua branch, ou solto no working tree

Os dois estados entram na revisão padrão

O erro comum deste passo: deixar o código "quase aplicado", metade no arquivo e metade num rascunho .txt do lado, achando que depois organiza. O que não está no diff não é revisado

2. Escreva o CLAUDE.md com os padrões do projeto

Se você ainda não tem o arquivo, o comando /init gera um CLAUDE.md inicial baseado na estrutura atual do projeto

/init

Depois você enxuga na mão e coloca o que importa de verdade: bibliotecas preferidas, decisões de arquitetura e o checklist de revisão do time

O erro comum deste passo: escrever um calhamaço

Os arquivos CLAUDE.md são carregados por INTEIRO, independentemente do tamanho, e arquivos mais curtos produzem melhor aderência

Ou seja, aquele documento de 40 telas não deixa o agente mais obediente, deixa ele mais disperso

3. Rode o /code-review sem argumentos

/code-review

Ele pega o diff padrão (commits da sua branch à frente do upstream mais as mudanças não commitadas) e reporta bugs de correção, além de oportunidades de reuso, simplificação e eficiência

O erro comum deste passo: esperar que ele revise o texto que você colou no chat

Não é isso. Ele revisa o que está no repositório

4. Direcione a revisão quando o alvo for outro

O /code-review aceita um alvo, que pode ser um caminho de arquivo, um número de PR, um nome de branch ou um intervalo de refs

/code-review main...my-feature

Muito útil quando o trecho do DeepSeek entrou faz três dias e o diff da branch já virou uma feira

5. Passe o /security-review

/security-review

Esse checa o diff em busca de vulnerabilidades de segurança e cobre apenas as mudanças da branch atual

É o passo que eu não pularia em código que veio de chat, e o porquê está na próxima seção

6. Decida o que aplicar (lendo!)

Duas flags fazem o trabalho braçal: --fix aplica os achados no working tree depois da revisão, e --comment posta os achados como comentários inline no PR

/code-review --fix

O erro comum deste passo: mandar --fix e sair pro café

Você acabou de colar código que um modelo escreveu sem ver o repo, aí manda outro modelo consertar sem você ler nada? Aí o PR vira um telefone sem fio ✋

Vale o mesmo cuidado de sempre com revisar o que o agente escreveu antes de commitar

7. Automatize a higiene com um hook

Hooks PostToolUse disparam depois que uma chamada de ferramenta é bem-sucedida, e dá pra usar um matcher para as ferramentas Edit e Write (Edit|Write) rodando o seu linter após cada edição de arquivo

Assim o problema bobo (formatação, import não usado, regra de lint) morre na hora da edição, e a revisão sobra pro que é difícil

Os três erros que mais chegam do chat para o repositório

Erro 1: a dependência que simplesmente não existe

Sintoma: o código roda lindo na cabeça, mas o install falha, ou pior, INSTALA algo que você nunca ouviu falar

Causa: alucinação de pacote

Um estudo publicado em março de 2025 analisou 576 mil amostras de código Python e JavaScript geradas por LLMs e encontrou que em cerca de 20% dos casos os pacotes recomendados não existiam

Desses nomes inventados, 38% pareciam inspirados em pacotes reais, 13% eram erro de digitação e o restante era completamente inventado

E tem o recorte que interessa aqui: a taxa é pior em modelos open source, com o DeepSeek citado entre eles, enquanto ferramentas comerciais como o ChatGPT-4 alucinaram a uma taxa de cerca de 5%

Só que o problema não para no erro de instalação

O mesmo estudo registrou mais de 200 mil nomes de pacotes alucinados únicos, sendo que 43% se repetiam de forma consistente em prompts similares e 58% reapareciam pelo menos uma vez em dez execuções

Nome inventado que se repete deixa de ser acidente e vira ENDEREÇO

É o que sustenta o slopsquatting: atacantes publicam pacotes maliciosos em índices como PyPI e npm usando os nomes que os modelos costumam inventar

Diferente do typosquatting, não depende de você digitar errado, depende do modelo sugerir certinho o nome errado

Já teve caso confirmado: o pacote unused-imports executava scripts de post-install desenhados para roubar credenciais e chaves de API

Solução: confira cada import novo no registro oficial antes de instalar qualquer coisa, e passe o diff pelo /security-review

Como prevenir: fixe as bibliotecas permitidas no CLAUDE.md, na seção de bibliotecas preferidas

Erro 2: arquivo, função ou caminho que não existe no projeto

Sintoma: o trecho importa um utils/formatDate que ninguém nunca criou, ou chama um método do seu service com uma assinatura levemente diferente da real

Causa: o chat não enxerga o seu repositório

Ele não está adivinhando mal, ele está PREENCHENDO, com o que costuma existir em projetos parecidos

Solução: rodar o /code-review sobre o diff já aplicado

A diferença é que agora o código está no contexto real, ao lado dos arquivos que existem de verdade, então a checagem é contra o seu projeto, não contra a média da internet

Como prevenir: aplicar primeiro, revisar depois. Nunca o contrário

Erro 3: padrão diferente do resto do repositório

Sintoma: funciona, passa no teste, e mesmo assim o PR volta cheio de comentário do time

Tratamento de erro num estilo, nomenclatura noutro, uma camada de abstração a mais que ninguém pediu

Causa: o chat entregou o padrão dele, não o seu

Solução: manter o CLAUDE.md como fonte dos padrões da sessão (ele é lido no início de toda sessão) e usar a revisão pra pegar as oportunidades de reuso, simplificação e eficiência

Muita coisa que veio do chat é helper novo pra fazer o que já existia

Como prevenir: checklist de revisão curto dentro do próprio CLAUDE.md

Esse ponto pesa ainda mais quando o repositório não é seu, tipo em projeto de cliente, onde o padrão da casa é lei

Quando usar /code-review local e quando chamar o modo ultra

Tem dois tamanhos de revisão e a escolha é bem prática

Pra trecho pequeno colado no dia a dia, o /code-review local resolve: roda no terminal, é imediato e não exige o GitHub App

Agora, quando a branch cresceu, virou refatoração ampla ou é aquele PR que vai direto pra produção, existe o /code-review ultra (o ultrareview), que roda uma revisão multiagente na infraestrutura do Claude Code na web, lançando uma frota de agentes revisores em sandbox remoto pra caçar bugs na branch ou no pull request

Sobre o ultra, alguns detalhes que valem antes de apertar o botão:

Sem argumentos, ele revisa o diff entre a branch atual e a branch padrão, incluindo mudanças não commitadas e staged

A revisão leva tipicamente de 5 a 10 minutos, então não é comando de "rodar e ficar olhando"

Depois das execuções gratuitas, o custo por revisão fica tipicamente entre US$ 5 e US$ 25 em créditos de uso, dependendo do tamanho da mudança, e o diálogo de lançamento mostra a estimativa antes de cada execução (dá pra desistir ali mesmo)

E a ressalva de disponibilidade, que é importante em ambiente corporativo: o ultrareview NÃO está disponível no Claude Code com Amazon Bedrock, Google Cloud Agent Platform ou Microsoft Foundry, nem para organizações com Zero Data Retention habilitado

Ah, e se você viu /review por aí: hoje ele é um alias de /code-review. Em versões anteriores à v2.1.223 era um comando separado, que rodava uma revisão read-only de um pull request do GitHub

Conclusão

A divisão de trabalho aqui é bem clara, e ela funciona

O DeepSeek escreve rápido, no chat gratuito, com contexto de sobra pra você despejar o problema inteiro

O Claude Code confere contra o repositório de VERDADE, aquele com os seus arquivos, os seus padrões e as suas dependências reais

Um gera, o outro checa. O que não dá é pedir pro mesmo texto que nunca viu o seu projeto garantir que ele encaixa no seu projeto…

Próximo passo concreto, pra rodar hoje: dispara o /init, enxuga o CLAUDE.md até sobrar só o que o time realmente segue, e transforma /code-review mais /security-review no ritual fixo antes de todo PR

Dois comandos, um minuto, e o PR que você abre deixa de ser aposta

até o próximo post! 😀