Como testar se o GPT-6 Astra respeita as convenções do seu projeto (e não só se o código roda)

Código que passa em todos os testes e mesmo assim volta na revisão é o retrabalho mais chato que existe

CI verde, teste unitário ok, e aí o revisor abre o PR e vê arquivo na pasta errada, nome fora do padrão, regra de camada furada, helper duplicado que já existia em outro lugar 😅

O GPT-6 Astra é o modelo mais recente da OpenAI, lançado em 03/09/2026, posicionado para raciocínio complexo, código, uso de computador, pesquisa e criação de documentos

A OpenAI afirma que ele é melhor em manter o foco, respeitar os limites da tarefa, entender a intenção do usuário e completar fluxos de várias etapas

Beleza, mas isso é claim de anúncio

O que decide a sua migração é outra coisa: se ele respeita as convenções do SEU repositório, com as suas pastas, os seus nomes e a sua arquitetura

E isso nenhum benchmark de terceiro responde por você, só o seu diff

Bora montar esse teste?

O que você precisa antes de testar o GPT-6 Astra no seu projeto

Antes de sair rodando, junta essas peças

• Codex CLI na versão 0.153.0 ou mais nova, porque o Astra exige isso
• Acesso ao modelo: pelos planos do ChatGPT (o Plus inclui o Astra no ChatGPT Work e no Codex conforme o rollout avança, e o GPT-6 Pro, movido pelo Astra, está sendo liberado para Pro US$ 100, Pro US$ 200, Business e Enterprise) ou pela API, com o model id gpt-6-astra em Chat Completions, Responses e Batch
• Um repositório Git com convenções que existem de verdade, não convenção que mora na cabeça do time
• Ciência do custo: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Sobre cota, vale o detalhe que muda o seu ritmo de teste: o uso do Astra consome a cota de Work e Codex já inclusa no plano

Pro US$ 100, Pro US$ 200 e assentos Business Premium podem usar a cota cheia, enquanto Plus e Business Standard têm uso limitado do Astra, com créditos opcionais pra uso adicional

Ou seja, Business não é um bloco só: depende do assento 🙂

Vale saber também que o reasoning.effort do Astra aceita low, medium, high, xhigh e max

Ele não suporta o valor none, então não adianta tentar desligar o raciocínio pra economizar

Um detalhe que muda o teste inteiro: a orientação oficial de regras de revisão é deixar checagem de formatação e lint no CI

Faz sentido, né?

Se o Prettier ou o ESLint já reprovam o arquivo, você não precisa do modelo pra isso

O teste tem que medir justamente o que o CI NÃO pega: pasta, nome, camada, padrão de arquitetura

Passo a passo: montando o teste de convenções

A lógica aqui é simples: você escreve a regra, dá uma tarefa que obriga o modelo a decidir, e depois olha a decisão dele

Sem opinião antes do diff, beleza?

1. Escreva as regras em AGENTS.md

A recomendação oficial do guia de AGENTS.md do Codex é colocar regra de repositório inteiro no arquivo da raiz e regra específica em arquivo aninhado

Algo assim:

AGENTS.md
services/experiment_reporting/AGENTS.md

O Codex aplica a raiz mais a orientação mais específica que cobre cada arquivo alterado

E a orientação pra escrever essas regras é: conciso, descrevendo o comportamento a sinalizar e as exceções seguras

O erro comum deste passo: escrever um manual de 40 linhas com estilo, lint e filosofia da empresa junto

Regra genérica não vira sinal, vira ruído

2. Entenda a ordem de leitura antes de culpar o modelo

O Codex lê instruções em dois escopos: o global, no diretório home do Codex (padrão ~/.codex), e o do projeto, começando na raiz do projeto (normalmente a raiz do Git) e descendo até o diretório atual de trabalho

Em cada diretório do caminho, ele procura nesta ordem:

AGENTS.override.md
AGENTS.md
nomes definidos em project_doc_fallback_filenames (ex.: TEAM_GUIDE.md, .agents.md)

No escopo global ele usa apenas o primeiro arquivo não vazio

Os arquivos de projeto são concatenados da raiz para baixo, separados por linhas em branco, e o arquivo mais próximo do diretório atual prevalece porque aparece mais tarde no prompt combinado

O erro comum deste passo: achar que a raiz manda sempre

Não manda: quem está mais perto do seu cwd sobrepõe a orientação anterior

3. Defina a tarefa-controle

Uma feature PEQUENA que force decisão de pasta, de nome e de camada

Tipo: "adicione um endpoint que devolve o status de um relatório"

Isso obriga o modelo a escolher onde o arquivo vive, como o arquivo se chama, se a regra de negócio entra no controller ou no service

O erro comum deste passo: escolher um algoritmo (ordenação, parser, cálculo)

Algoritmo mede se roda, e você já sabe que roda

Algoritmo não tem opinião sobre a sua estrutura de pastas

4. Rode com modelo e esforço fixados

No Codex CLI dá pra escolher o modelo na abertura da sessão com --model (ou o apelido -m):

codex --model gpt-6-astra

E dentro da sessão interativa você usa /model pra trocar de modelo ou ajustar o esforço de raciocínio

O erro comum deste passo: rodar duas vezes com configuração diferente e comparar os dois diffs como se fossem a mesma coisa

Se o esforço mudou no meio, a comparação morreu

5. Inspecione o resultado com /diff antes de qualquer opinião

/diff

Esse comando mostra as mudanças exatas nos arquivos

É aqui que o teste acontece de verdade: você lê o diff procurando pasta, nome e camada, não procurando bug

O erro comum deste passo: rodar o teste unitário primeiro e já decidir que "funcionou"

Passar no teste é a linha de base, não a nota

6. Rode a revisão contra as suas próprias regras

O Codex Code Review usa regras próprias do repositório declaradas no AGENTS.md

Basta adicionar uma seção chamada ## Code Review Rules no arquivo mais próximo do código que as regras governam, com as regras logo abaixo:

Sinalize handler que fala direto com o banco: acesso a dados vive na camada de repositório
Exceção segura: scripts em tools/, que rodam fora da aplicação

Aí, dentro da sessão do Codex CLI, você dispara a revisão com /review, que resume os problemas encontrados na working tree

O erro comum deste passo: esquecer que o /review usa o modelo da sessão atual, a menos que review_model esteja definido no config.toml

7. Repita a mesma tarefa com o AGENTS.md removido ou reduzido

Esse passo é o que separa mérito do modelo de mérito das instruções

Se o diff continua no padrão da casa sem as regras escritas, o modelo inferiu do repositório

Se desanda, o mérito era do seu AGENTS.md, e isso também é uma informação ótima

O erro comum deste passo: pular ele

Aí você acaba elogiando o modelo por uma coisa que o seu próprio documento fez

8. Repita variando o reasoning.effort e anote o custo

Mesma tarefa, mesmo repositório, esforço diferente entre low, medium, high, xhigh e max

Anota quanto cada rodada consumiu, lembrando dos US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de saída

Se o medium já entrega o mesmo diff que o max, a decisão financeira se resolve sozinha

Se você quer o roteiro mais amplo, tem um passo a passo de como testar o Astra antes de migrar que cobre o teste geral, e este post aqui é o recorte de convenções

O erro comum deste passo: comparar rodadas sem anotar o esforço usado em cada uma

Daqui a duas semanas você não lembra, garanto 😛

Como pontuar: separando o que roda do que segue o padrão da casa

Agora a parte que o pessoal costuma fazer no feeling

Teste unitário verde é a LINHA DE BASE, não a nota

E formatação e lint saem da conta, porque a orientação oficial é deixar essas checagens no CI

O que sobra é isso aqui:

A leitura é direta: se o diff roda mas erra pasta, nome e camada, o modelo te entregou trabalho, não entregou pull request

Quando o Astra ignora suas convenções: sintomas, causas e correções

O sintoma: a regra está escrita e mesmo assim foi ignorada

Causa provável: o arquivo mais próximo do diretório atual sobrescreveu a orientação da raiz

Lembra que a concatenação é da raiz para baixo e o que vem depois prevalece?

Se o AGENTS.md de um subdiretório diz outra coisa, é ele que ganha

Como prevenir: antes de acusar o modelo, leia a cadeia inteira do caminho que a tarefa tocou, da raiz do Git até o cwd

O sintoma: metade das regras parece não existir pro modelo

Causa provável: truncamento

A configuração project_doc_max_bytes, no ~/.codex/config.toml, controla o limite de bytes das instruções combinadas antes do truncamento

Aí o seu manual gigante entra pela metade e a regra importante ficou de fora

Como prevenir: regra concisa, do jeito que a orientação oficial pede, e regra específica no arquivo aninhado em vez de tudo empilhado na raiz

O sintoma: a revisão não sinaliza nada, mesmo com violação clara

Causa provável: regra genérica demais

"Siga a arquitetura do projeto" não é regra, é desejo

Como prevenir: descreva o comportamento a sinalizar e as exceções seguras, que é exatamente a recomendação oficial pras regras de code review

O sintoma: você escreveu o arquivo e ele nunca foi lido

Causa provável: nome fora da ordem de busca

O Codex procura AGENTS.override.md, depois AGENTS.md, depois os nomes configurados em project_doc_fallback_filenames (por exemplo TEAM_GUIDE.md e .agents.md)

Se o seu arquivo se chama outra coisa e não está nessa lista, ele simplesmente não entra

Como prevenir: use os nomes da ordem de busca ou registre o seu nome em project_doc_fallback_filenames

O sintoma: a revisão saiu com uma cara diferente do esperado

Causa provável: review_model definido no config.toml

O /review usa o modelo da sessão atual, a menos que esse valor esteja configurado

Aí você acha que testou o Astra revisando e testou outro modelo 🙂

Como prevenir: confira o config.toml antes da rodada e deixe registrado qual modelo revisou o quê

Onde esse teste muda mais a decisão

Esse teste não pesa igual pra todo mundo

Tem contexto em que ele é decisivo:

• Monorepo com regras por serviço: é o cenário clássico do AGENTS.md aninhado, e é onde o modelo mais tem chance de aplicar a regra de um serviço no outro
• Base legada com padrão implícito: aqui o teste vira documentação, porque escrever a regra pro modelo obriga o time a admitir qual é a regra
• Time que revisa por PR e sofre com retrabalho: cada violação de convenção que passa vira ida e volta de revisor, e é isso que você está tentando cortar
• Projeto de contexto grande: o Astra tem 1,05 milhão de tokens de contexto e até 128.000 tokens de saída, o que muda o tamanho de tarefa que cabe numa rodada só

E o contraponto, sem exagero pra nenhum lado

No Artificial Analysis Coding Agent Index, o GPT-6 Astra rodando no harness do Codex marca 67, tecnicamente empatado com Claude Opus 5 e Fable 5 no Claude Code

A liderança é do Fable 5.1 no Claude Code, com 70

No Intelligence Index, o Astra em max marca 55, atrás do Claude Fable 5.1 (max effort), que lidera com 57

As pontuações divulgadas variam por esforço: 55 em max, 53 em high, 52 em medium e 49 em low (o xhigh não aparece nessa lista de pontuações)

No consumo, ele é bem econômico: usa cerca de um terço dos tokens do GPT-5.6 Sol (max) no harness do Codex e um quinto dos tokens do Claude Opus 5 (xhigh)

Porém o preço por token subiu: em max effort ele é 75% mais caro que o Sol, e é isso que coloca ele atrás do Sol na fronteira de inteligência por custo por tarefa do Artificial Analysis

Avaliadores independentes resumem numa frase que combina com tudo isso: ganhos grandes em benchmarks especializados (uso de computador, fluxos de terminal, recuperação em contexto longo) e ganhos modestos ou estáveis no resto

Se a sua dúvida é mais de bolso que de padrão, dá pra olhar por outro ângulo e avaliar se o custo compensa pra sua tarefa

O que fazer com o resultado do seu teste

A decisão sai do seu diff, não do anúncio

Nenhum dos números aí em cima mede especificamente aderência a convenção de projeto, e é por isso que o teste é seu

O próximo passo é curto e prático:

• Versione o AGENTS.md da raiz e os aninhados junto com o código, porque regra que não está no Git é regra que some
• Mova formatação e lint pro CI, do jeito que a orientação oficial pede, e deixe o modelo cuidar do que o CI não vê
• Transforme a tarefa-controle em rotina: toda atualização de modelo, roda ela de novo e compara o diff
• Refaça a medição quando o esforço de raciocínio mudar ou quando o custo mudar, porque as duas coisas mexem no resultado

É pouco trabalho e economiza um monte de ida e volta na revisão

Então bora escrever aquele AGENTS.md que tá pendente há meses? 😀

até o próximo post!