Como definir o critério de aprovação antes de testar o GPT-6 Astra no seu código

Fala aí, beleza? A OpenAI soltou o GPT-6 Astra em 3 de setembro de 2026, apresentado como o modelo mais capaz dela para raciocínio, código, uso de computador, pesquisa e criação de documentos

E aí acontece o de sempre: todo mundo abre uma tarefa qualquer, joga no modelo, olha a resposta e decide no olho

Só que "achei que ficou bom" não é avaliação, é impressão

A saída vem bem formatada, com comentário bonitinho, nomes de variáveis caprichados, e o teu cérebro já quer dar o sim antes de rodar qualquer coisa. Isso tem nome: você está julgando a embalagem

O jeito de escapar disso é chato e simples: escrever o critério de aprovação ANTES da primeira rodada, num arquivo, com condição verificável. Se o critério nasce depois da resposta, ele nasce contaminado

Bora montar isso na prática?

O que você precisa ter antes de rodar o teste

Antes de escrever critério, junta o material. Sem isso o teste não mede nada:

• Uma tarefa real do teu repositório, não exercício sintético. De preferência uma que você já resolveu, porque aí existe gabarito
• Uma prova automática: a suíte de teste do projeto, ou pelo menos um teste que falha hoje e precisa passar depois
• Git limpo, sem alteração pendente, pra conseguir medir o tamanho do diff sem ruído
• Acesso ao modelo na superfície que você vai usar de verdade no dia a dia

Sobre o acesso (e o que checar antes de xingar)

O rollout foi escalonado e não chegou a todos os assinantes no dia do anúncio, com pedido público de desculpas do Sam Altman pelo processo. Então se não apareceu pra você, não é bug do teu setup

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

No ChatGPT, o acesso depende do plano e da superfície: assinantes Plus alcançam o modelo pelo ChatGPT Work e pelo Codex, e não pelo chat comum, onde o topo segue sendo o GPT-5.6 Sol

Na API da OpenAI, o identificador do modelo é gpt-6-astra

No Codex CLI, o modelo é escolhido dentro da sessão interativa pelo comando /model, ou já na inicialização pela flag --model (alias -m):

codex --model gpt-6-astra
# ou, na forma curta
codex -m gpt-6-astra

E se você quiser fixar de vez: no Codex CLI o modelo é fixado por uma entrada model no arquivo config.toml

model = "gpt-6-astra"

Ainda tem uma variável escondida aqui:

O parâmetro de esforço de raciocínio da API, reasoning.effort, aceita os níveis low, medium, high, xhigh e max

O nível none não é aceito e retorna HTTP 400

Por que isso importa agora, antes do teste? Porque nível de esforço muda o resultado. Se você roda a primeira tarefa em low e a segunda em max, não comparou modelo com modelo, comparou configuração com configuração

Então o esforço entra no critério, junto com todo o resto. Se você quer o roteiro completo de montar o ambiente antes, dá uma olhada em como testar o GPT-6 Astra no seu projeto

Passo a passo para escrever o critério de aprovação antes da primeira rodada

A ideia é ter um arquivo, tipo CRITERIO.md na raiz do projeto (ou um bloco fixo no issue), preenchido com a sessão AINDA FECHADA

1. Descreva a tarefa em uma frase e diga o resultado observável

Nada de "melhorar o módulo de pagamento". Você precisa de algo que qualquer pessoa consiga verificar olhando a tela ou o terminal

## Tarefa
Corrigir o cálculo de desconto quando o cupom expira no mesmo dia

## Resultado observável
Pedido com cupom expirando hoje NÃO recebe desconto e retorna erro 422

O erro comum deste passo: escrever a tarefa como sensação ("deixar mais robusto") em vez de comportamento. Se não dá pra observar, não dá pra aprovar

2. Defina a prova automática: qual comando roda e o que precisa passar

Escreve o comando literal, não a intenção do comando

## Prova automática
Comando: npm test -- tests/desconto.spec.ts
Condição: o teste "cupom expirado no mesmo dia" passa
Condição: nenhum teste que passava antes quebra

O erro comum: colocar só "os testes passam" sem fixar o comando. Aí na hora do aperto você roda um subconjunto conveniente e chama de verde 😅

3. Defina o limite de diff e o que está fora de escopo

Número, não adjetivo

## Limite de diff
Máximo 2 arquivos alterados
Máximo 60 linhas somando adições e remoções

## Fora de escopo
Nenhuma dependência nova
Nenhuma alteração em migration
Nenhuma renomeação de arquivo

O erro comum: "diff pequeno". Pequeno pra quem? Sem número, todo diff vira pequeno depois que você já gostou da solução

4. Defina a checagem antifabricação

Esse é o passo que mais gente pula, e é o que mais dói

A regra: toda função, método, biblioteca, flag e endpoint citados na resposta precisam existir no repositório ou na documentação oficial. Verificação manual, item por item, na unha

## Checagem antifabricação
[ ] Listei todas as funções/métodos chamados na resposta
[ ] Cada uma existe no repo (busca por nome) ou na doc oficial
[ ] Nenhuma lib nova apareceu no import sem estar no package.json
[ ] Nenhum endpoint citado sem eu abrir e confirmar

O erro comum: confiar porque o nome faz sentido. Nome plausível é justamente o formato que a invenção assume. Vale ler também sobre como validar a resposta antes de commitar, que é o outro lado dessa mesma moeda

5. Congele as variáveis da rodada

Antes de abrir a sessão, anota exatamente o setup. E não muda no meio

## Configuração congelada
Modelo: gpt-6-astra
Superfície: API da OpenAI
reasoning.effort: medium
Modo Fast: não

O erro comum: mexer em duas coisas ao mesmo tempo. Trocou o nível de esforço E reescreveu o prompt? Parabéns, agora você não sabe qual dos dois mudou o resultado

6. Escreva o critério de REPROVAÇÃO explícito

Esse é o antídoto direto contra o viés. Escreve o que te faz dizer não mesmo que a saída pareça linda

## Reprova automaticamente se:
Qualquer teste que passava antes quebrou
Diff passou de 60 linhas
Apareceu função ou lib que eu não consegui localizar
A solução mudou assinatura pública sem eu ter pedido

O erro comum: só listar o que aprova. Critério que não tem cláusula de reprovação sempre acha um jeito de aprovar

7. Salva o arquivo, commita, e SÓ ENTÃO abre a sessão

Commitar é o detalhe que fecha a porta. Com o critério versionado, você não consegue "ajustar levemente" o teto de diff depois que viu que o modelo entregou 90 linhas

O erro comum: deixar o critério aberto num rascunho editável ao lado da resposta. Aí ele vira legenda da foto, não prova

Exemplos de critério pronto para três tipos de tarefa

O critério não tem forma única, ele muda conforme o tipo de trabalho. Se liga em três moldes prontos pra copiar

Correção de bug:

Tarefa: corrigir <bug> descrito na issue #123
Prova: teste que reproduz o bug (escrito ANTES) passa
Prova: suíte completa continua verde
Diff: no máximo 2 arquivos
Restrição: nenhuma dependência nova
Reprova se: a correção mexer em código não relacionado ao bug

Repara na ordem: o teste que reproduz o bug você escreve antes de chamar o modelo. É a única forma de ter certeza que ele resolveu o problema em vez de contornar o sintoma

Refatoração:

Tarefa: extrair a lógica de X do controller para um service
Prova: suíte INTEIRA verde, sem exceção
Prova: comportamento idêntico (nenhum teste novo precisou ser escrito)
Diff: sem teto rígido, mas 100% do diff precisa ser movimentação
Restrição: zero mudança de API pública
Reprova se: apareceu comportamento novo junto da refatoração

Refatoração é o caso onde o teto de linhas atrapalha, porque mover código gera diff grande por natureza. Aí o critério muda de "quantas linhas" para "que TIPO de linha"

Feature nova:

Tarefa: adicionar exportação CSV na listagem de pedidos
Prova: teste do caminho feliz passa
Prova: teste de um caso de erro (lista vazia) passa
Restrição: nenhuma função inventada, checagem item a item
Diff: revisável manualmente em menos de 10 minutos
Reprova se: eu não consegui explicar cada bloco do diff em voz alta

Esse último critério é meu favorito de todos: se você não consegue explicar o diff, você não revisou o diff, você passou o olho 🙂

Critérios que parecem bons e não seguram nada

Tem critério que existe só pra você sentir que fez o dever de casa. Três casos clássicos

Sintoma: você aprovou e quebrou em produção

Causa: o critério era subjetivo. "Código limpo", "bem estruturado", "solução elegante". Nenhuma dessas frases pode ser marcada como atende ou não atende por outra pessoa

Solução: troca cada adjetivo por uma condição verificável. "Código limpo" vira "nenhuma função com mais de 30 linhas" ou "passa no lint sem warning novo"

Como prevenir: leia teu critério e pergunte item por item: um colega que não participou da conversa consegue marcar isso sozinho? Se não, reescreve

Sintoma: o modelo entregou 600 linhas e você não revisou de verdade

Causa: não existia teto de diff. E o problema aqui é psicológico: quando o volume assusta, a gente compensa confiando

Solução: limite numérico definido ANTES, do tipo "máximo 2 arquivos e 60 linhas". Estourou? Não é reprovação moral do modelo, é sinal de que a tarefa precisa ser quebrada em pedaços menores

Como prevenir: teto sempre no arquivo commitado. Teto que mora na tua cabeça se estica sozinho, é impressionante 😛

Sintoma: você decidiu pelo benchmark e não pelo seu repositório

Causa: usar pontuação pública como critério de aprovação

Na página viva do Artificial Analysis, o GPT-6 Astra aparece com pontuações diferentes por nível de esforço no Intelligence Index:

Repara que a variação entre o topo e a base existe, mas não é abissal. E tem um detalhe mais importante que os números: o Artificial Analysis Intelligence Index v4.2 é composto por 10 avaliações, entre elas Terminal-Bench v2.1, SciCode, GDPval-AA v2 e Humanity’s Last Exam

Ou seja, é uma média de provas sintéticas. Não é o teu repositório, não é o teu legado de cinco anos, não é o teu padrão de teste esquisito que só existe na tua empresa

O mesmo vale pro uso de computador: a OpenAI reporta 72,6% no OSWorld 2.0, número informado pela própria OpenAI. É uma informação útil, mas ela não valida o diff que caiu no teu branch

Solução: benchmark serve pra você escolher O QUE testar e onde apostar tua primeira hora, não pra aprovar teu diff. A prova do teu código é o teu teste rodando

Como prevenir: proíbe o nome de qualquer benchmark dentro do arquivo de critério. Se o número não pode ser reproduzido no teu terminal, ele não entra na lista de aprovação

Como registrar o resultado da rodada sem se enganar

Acabou a rodada? Calma, ainda não é hora de ter opinião

1. Marque cada item do critério como atende ou não atende, ANTES de comentar qualquer coisa

Sem "quase", sem "praticamente". É binário. A opinião vem depois da marcação, nunca antes, porque opinião formada primeiro contamina a marcação

O erro comum: começar pelo parágrafo de impressão geral. Aí os itens viram justificativa da impressão

2. Anote custo e configuração da rodada

Comparação justa exige saber o que você gastou e com qual setup. O preço padrão do GPT-6 Astra na API da OpenAI é de US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

## Registro da rodada
Data: __
Modelo: gpt-6-astra
Superfície: API da OpenAI
reasoning.effort: medium
Modo Fast: não
Tokens entrada: __
Tokens saída: __
Itens atendidos: __/__

Atenção em duas coisas que mexem na conta:

• O modo Fast na API entrega até 2x a velocidade do processamento padrão, por 2x o preço padrão
• Requisições com mais de 272 mil tokens de entrada têm preço majorado: 2x nas taxas de entrada e de cache, e 1,5x na saída, para a requisição inteira

O erro comum deste passo: comparar uma rodada em modo padrão com outra em modo Fast e concluir coisa sobre qualidade. Você comparou preço e velocidade, não capacidade

3. Cuide do tamanho do pacote de teste

A janela de contexto do modelo é de 1,05 milhão de tokens, com saída máxima de 128 mil tokens

Parece infinito, e é bastante mesmo. Mas repara na fronteira dos 272 mil tokens de entrada: dá pra jogar o repositório inteiro dentro, só que a conta muda de patamar quando você passa dessa linha

Então monta o pacote de teste com o que a tarefa exige, não com tudo que existe. "Joguei o projeto todo" também é uma variável que você precisa congelar

O erro comum: mandar contexto diferente em cada rodada e achar que a diferença de resultado veio do modelo

4. Repita a MESMA tarefa com o MESMO critério antes de mudar qualquer coisa

Uma rodada é anedota. Roda a mesma tarefa de novo, com a configuração idêntica, e vê se o resultado se mantém

Só depois disso você troca UMA variável: sobe o reasoning.effort de medium pra high, por exemplo, e mede de novo com a mesma régua

O erro comum: mudar o nível de esforço e o prompt na mesma tentativa. É o erro do passo 5 lá de cima voltando, e ele volta sempre, é impressionante como a gente cai nele

Vídeo: erros de iniciante que um bom critério pegaria

Muita coisa que passa despercebida na revisão de código não é sofisticada, é erro básico mesmo. E critério escrito é justamente o filtro que pega básico

Pra começar do zero com a ideia de olhar código procurando armadilha conhecida, este vídeo do canal mostra cinco erros clássicos de iniciante no React.js e por que cada um deles atrapalha:

Conclusão

O critério escrito antes é o que separa avaliação de impressão

Depois que a resposta aparece na tela, teu cérebro já escolheu um lado. Escrever a régua com a sessão fechada é a única forma barata de manter honestidade no processo

Próximo passo bem concreto pra hoje: cria o CRITERIO.md, escolhe uma tarefa real que VOCÊ já resolveu (porque aí existe gabarito de verdade), preenche os sete campos, commita e só então abre a sessão com as variáveis congeladas

E lembra que o acesso ainda depende do plano e da superfície por causa do rollout escalonado, então parte do teste pode ser só esperar a tua vez chegar

Uma última: o GPT-6 Astra é o primeiro modelo da OpenAI classificado no nível Critical de capacidade em cibersegurança dentro do Preparedness Framework, com as capacidades cyber mais avançadas liberadas de forma restrita a um grupo de testadores. Vale saber disso antes de montar expectativa sobre o que vai estar disponível pra você

Critério primeiro, opinião depois… até o próximo post! 😀