Code review com GPT-6 Astra: como pedir para ele achar bug de verdade no seu diff

Fala aí, beleza? Você cola o diff, pede uma revisão, e volta aquilo: "LGTM, código bem estruturado, boa separação de responsabilidades" 🙂

Zero bug encontrado

E o bug tá lá, quietinho, esperando a sexta-feira à noite pra aparecer

A OpenAI lançou o GPT-6 Astra em 03/09/2026, apresentado como seu modelo mais capaz para raciocínio complexo, código, uso de computador, pesquisa e criação de documentos

No teste de código DeepSWE v1.1 divulgado pela própria OpenAI, o Astra marcou 74,1% contra 70,8% do GPT-5.6 Sol

Só que benchmark não revisa o SEU diff, quem revisa é o pedido que você monta

E é isso que esse post entrega: a estrutura do pedido (intenção, dimensão, localização exata) e o filtro pra separar achado real de achado inventado antes de você abrir a discussão no time

O que você precisa antes de mandar o diff

Primeiro, o chato: acesso

O rollout do Astra é faseado. Começa por um conjunto limitado de organizações e, nos dias seguintes, chega ao ChatGPT Plus, Pro, Business e Enterprise, além da API da OpenAI e da AWS

As primeiras empresas a receber acesso são as participantes do programa de cibersegurança por inscrição da OpenAI, chamado Daybreak

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Ou seja: pode ser que na sua conta ainda não tenha aparecido, e isso é esperado

Onde escolher o modelo:

• ChatGPT e Codex: no seletor de modelos, quando ele estiver disponível pra sua conta
• Codex CLI: o comando /model troca o modelo e ajusta o nível de raciocínio dentro da sessão interativa, e dá pra escolher já na inicialização com --model (alias -m)
• API: o model id é gpt-6-astra, e ele também está disponível no Amazon Bedrock

codex --model gpt-6-astra

# ou, já dentro de uma sessão aberta:
/model

Se o seu caminho for a API, se liga nisso: modelos de raciocínio como o gpt-6-astra são usados com a Responses API, e a documentação indica que eles têm desempenho melhor nela do que em prompts de modelo de chat

Uma nota de escopo que evita frustração:

O Astra é o primeiro modelo que a OpenAI classifica no limiar "Critical" de cibersegurança do seu Preparedness Framework

Na prática isso significa uma linha bem clara: na versão lançada ele ajuda em tarefas de defesa, como revisão segura de código (secure code review) e patching, mas recusa tarefas mais avançadas como criar exploits de prova de conceito

Então monte o pedido como defesa ("onde esse diff pode ser abusado e como eu fecho isso"), não como ataque

Passo a passo: como montar o pedido de revisão do diff

O erro que atravessa TODOS os passos é o mesmo: colar o diff sem dizer qual comportamento era esperado

Sem intenção declarada, o modelo só consegue avaliar estilo. E estilo bonito é exatamente o que gera o "LGTM" inútil

Bora montar isso direito?

1. Declare a intenção da mudança:

Antes do código, duas frases: o que deveria passar a acontecer depois desse diff, e o que não pode quebrar de jeito nenhum

Intenção desta mudança:
- Passa a acontecer: cupom expirado deixa de ser aplicado no checkout e retorna erro 422
- Não pode quebrar: cupom válido continua aplicando desconto; pedido sem cupom segue igual

Revise o diff abaixo procurando lugares onde essa intenção NÃO se cumpre.

O erro comum deste passo: escrever a intenção copiando a descrição da task ("ajustes no checkout"). Isso não é intenção, é rótulo. Intenção tem comportamento observável

2. Delimite o diff e o contexto mínimo:

Mande o diff e, junto, o conteúdo (ou a assinatura) das funções que o diff chama e das que chamam ele

É o contexto mínimo pra ele não chutar. E deixe explícito que a revisão é do diff, não do repositório inteiro

Escopo: revise APENAS as linhas alteradas no diff abaixo e o efeito delas.
Código não alterado entra só como contexto, não como alvo de crítica.

<cole aqui o diff completo>
<cole aqui os arquivos vizinhos que o diff chama, na íntegra ou só as assinaturas>

O erro comum deste passo: mandar só o diff. Aí o modelo não enxerga o validador que já existe duas camadas acima e reporta "falta validação" com toda a confiança do mundo

3. Peça uma dimensão por rodada:

"Revise tudo" devolve um resumão morno

Uma dimensão por rodada devolve achado. É a mesma lógica de mandar um dev olhar concorrência com a cabeça em concorrência, e não em quatro coisas ao mesmo tempo

Nesta rodada, procure SOMENTE regressão de comportamento contra a intenção declarada.
Ignore estilo, nomenclatura, performance e segurança nesta rodada.

O erro comum deste passo: juntar segurança e performance no mesmo pedido. O modelo tende a entregar o achado mais fácil de escrever e abandonar o mais difícil de encontrar

4. Exija formato de achado com localização exata:

Esse é o passo que separa revisão útil de texto motivacional. Todo achado precisa de arquivo, linha, entrada que dispara e consequência

Formato obrigatório de cada achado:
- arquivo:linha (a linha PRECISA existir no diff que enviei)
- entrada concreta que dispara o problema (valor, payload ou sequência de chamadas)
- consequência observável (o que o usuário ou o sistema vê de errado)
- por que o código atual não cobre esse caso

Se você não conseguir preencher os quatro campos, não reporte o achado.

O erro comum deste passo: aceitar achado no formato "pode haver problema de validação aqui". Isso não é achado, é sensação

5. Proíba elogio e exija o "nenhum achado":

O modelo tende a preencher espaço. Se você não der uma saída válida pro caso "tá certo", ele inventa alguma coisa pra dizer

Não escreva elogios, resumo do que a mudança faz, nem sugestões de estilo.
Se não houver nenhum problema nesta dimensão, responda exatamente:
NENHUM ACHADO NESTA DIMENSÃO.

O erro comum deste passo: pedir "seja crítico". Isso não cria rigor, cria dramatização: aparecem achados de severidade alta em código que só mudou de indentação

6. Ajuste o reasoning.effort:

O gpt-6-astra aceita os níveis low, medium, high, xhigh e max, e não suporta o nível none

A orientação da OpenAI é começar no medium como ponto de partida equilibrado

"reasoning": { "effort": "medium" }

O erro comum deste passo: ir direto de medium pra max porque "é o melhor". A recomendação da OpenAI é reservar o max pro trabalho mais difícil, em que qualidade vem primeiro, e subir pra high ou xhigh quando mais raciocínio traz ganho MEDIDO de qualidade. Medido, não sentido

7. Rode uma segunda passada pedindo o que ficou de fora:

Depois da primeira leva, na mesma conversa, vire a pergunta do avesso

Revisando sua própria resposta anterior: qual parte do diff você analisou de forma superficial?
Existe algum caminho de execução que você não percorreu?
Liste apenas o que ficou de fora, sem repetir os achados anteriores.

O erro comum deste passo: perguntar "tem mais alguma coisa?". Pergunta aberta gera achado novo inventado. Perguntar o que ficou SUPERFICIAL gera lacuna real

E quando o achado virar correção, cuidado com o passo seguinte, que é onde a coisa costuma desandar: pedir o conserto sem cercar o raio de ação é receita pra corrigir o bug e quebrar outra coisa

Qual reasoning.effort usar (e quanto custa revisar um diff grande)

Primeiro a parte do esforço, com a orientação oficial traduzida pro dia a dia de revisão:

O nível none não existe aqui, então não tente

E o custo?

O preço por token do gpt-6-astra na API da OpenAI é o mesmo, independente do nível de esforço que você escolher. O que muda de fato é o tamanho do que entra e do que sai:

Olhando essa tabela, o cache é seu amigo: se você reaproveita o MESMO template de pedido a cada revisão, a parte fixa do prompt é justamente a candidata natural a ficar em cache

Tome cuidado com o diff gigante:

O gpt-6-astra tem 1.050.000 tokens de janela de contexto e até 128.000 tokens de saída

Parece que cabe o repositório inteiro, né? Cabe. Mas tem pegadinha 😀

Requisições com mais de 272 mil tokens de entrada levam sobretaxa aplicada ao request inteiro: 2x nas tarifas de entrada e de cache, e 1,5x na de saída

Ou seja: passar de 272 mil tokens não encarece só o excedente, encarece tudo. Mais um motivo pra delimitar o diff em vez de despejar a base de código

Cinco focos de revisão que rendem achado concreto

Uma dimensão por rodada, lembra? Aqui vão as cinco que costumam render achado com endereço, cada uma com a frase de pedido pronta

1. Regressão contra a intenção declarada:

Dimensão: regressão. Onde este diff faz o sistema deixar de fazer algo que ele fazia
antes e que não está na lista do que deveria mudar?

É a dimensão mais subestimada. O bug clássico de PR não é o código novo estar errado, é o código velho ter parado de rodar

2. Tratamento de erro e caminhos de falha:

Dimensão: caminhos de falha. Para cada chamada externa, timeout, retorno vazio ou
exceção possível neste diff, mostre o que acontece hoje e o que o usuário vê.

3. Concorrência e estado compartilhado:

Dimensão: concorrência. Se duas execuções entrarem neste caminho ao mesmo tempo,
qual estado compartilhado pode ser lido ou escrito fora de ordem? Descreva o intercalamento.

Exigir o intercalamento passo a passo é o que impede a resposta genérica de "pode haver race condition"

4. Borda de dados:

Dimensão: borda de dados. Liste valores concretos (nulo, string vazia, lista vazia,
zero, negativo, limite máximo) que passam por este diff e o resultado de cada um.

5. Revisão segura do código do diff:

Dimensão: segurança defensiva. Nas linhas alteradas, verifique validação de entrada,
controle de autorização e segredo exposto. Aponte arquivo, linha e a correção.

Aqui vale relembrar o limite: o Astra ajuda em secure code review e patching, mas recusa criar exploit de prova de conceito

Então peça a falha e o patch, não a arma

Bônus: a sessão longa de revisão

Revisar uma PR grande é uma sessão que enche a janela rápido, e é aí que o modelo começa a esquecer a intenção que você declarou lá no começo

Com o Astra, o Codex ganhou uma nova forma de preservar e recuperar contexto quando a janela enche, substituindo a resumarização repetida por notas pesquisáveis

É um problema que todo mundo desse mercado está atacando ao mesmo tempo, cada um do seu jeito. Quem também trabalha do outro lado da cerca vale dar uma olhada no que o Ponytail muda no Claude Code e comparar as abordagens

Como filtrar achado falso antes de levar para o time

Agora a parte que ninguém conta: nem todo achado é achado

E não tem nada mais constrangedor do que abrir uma discussão na PR do colega com um bug que não existe. Já me ferrei uma vez por causa disso 😅

Quatro padrões, com a causa e o teste antes de você apertar "comentar":

Sintoma: achado sem arquivo e linha

Causa: o pedido não tinha formato obrigatório, então o modelo respondeu em prosa

Teste: exija a reescrita no formato de quatro campos. Achado que não sobrevive à exigência de localização exata normalmente não sobrevive à leitura do código também

Sintoma: bug "de manual" que não existe no diff

Aquele clássico: "falta tratamento de erro na chamada HTTP", só que existe um wrapper que já trata

Causa: contexto insuficiente dos arquivos vizinhos

Teste: reproduza mentalmente o caminho apontado, de cima pra baixo. Se a proteção existe uma camada acima, mande a camada acima e peça a reavaliação

Sintoma: alerta de segurança sobre código que não mudou

Causa: escopo não delimitado ao diff

Teste: confira se a linha citada aparece de fato entre as linhas alteradas. Se não aparece, não é achado desta PR (pode virar issue depois, mas não trava a revisão)

Sintoma: severidade inflada

Tudo vira "crítico", inclusive log com nível errado

Causa: nenhum critério de impacto foi definido no pedido

Teste: peça ao modelo que tente refutar o próprio achado, com essa frase:

Tente REFUTAR cada achado que você acabou de reportar.
Para cada um, mostre por que ele pode NÃO ser um problema real neste código.
Se a refutação for mais forte que o achado, marque como descartado.
Classifique o que sobrar por impacto: quebra em produção, comportamento errado silencioso,
ou risco teórico.

Como prevenir tudo isso:

Template fixo

Salva os passos 1 a 5 num arquivo, reaproveita a cada revisão e muda só a intenção e o diff

A revisão fica comparável entre PRs, você para de reinventar o prompt às onze da noite, e ainda casa bem com a tarifa de entrada em cache

Conclusão

No fim, code review com GPT-6 Astra é menos sobre o modelo e mais sobre o contrato que você dá pra ele

A estrutura é sempre a mesma: intenção declarada, uma dimensão por rodada, localização exata obrigatória, e filtro de achado falso antes de qualquer comentário público

Próximo passo concreto: salva o template, roda na sua próxima PR em medium e compara lado a lado com uma revisão solta de "dá uma olhada nesse diff"

A diferença aparece na primeira PR, e é meio absurda

Duas notas honestas pra fechar: o acesso ainda é parcial por causa do rollout faseado, então pode variar por conta e região

E o corte de conhecimento do modelo é 30 de abril de 2026, ou seja, o que for lib nova ou API que mudou depois disso, você precisa colocar no contexto na mão

Bora testar? 🙂

até o próximo post!