Como preparar sua base de código antes de entregar uma tarefa grande ao Gemini 4 Argon

Fala aí, beleza? Entregar uma tarefa enorme para um agente sem ter como checar o resultado no fim não é engenharia, é aposta 😛

E essa aposta acabou de ficar maior: o Google anunciou o Gemini 4 Argon em 30 de setembro de 2026 como seu novo modelo de fronteira, feito para tarefas complexas e de longa duração em engenharia de software

O limite de saída dele é de 1 milhão de tokens (antes eram 64 mil)

Saída desse tamanho significa mudança GRANDE de uma vez só, e aí o seu repositório precisa estar pronto para provar se ela está certa ou não

Se liga: este post não ensina a usar o modelo hoje (já te explico o porquê)

Ele mostra como preparar a sua base para quando o acesso chegar até você

Antes de começar: acesso ao Argon e o que você já pode fazer hoje

Hoje o acesso ao Gemini 4 Argon está restrito a defensores cibernéticos de confiança do Fairwind Program

Clientes pagos da API e assinantes do Google AI Ultra entram depois, e não existe data pública para isso

E em 1º de outubro de 2026 não havia nem entrada nem ID de modelo do Argon no catálogo público ou no changelog da API Gemini

E o preço? O valor de lançamento que aparece na página do Artificial Analysis é promocional: US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída

Mas se liga: é preço introdutório, e o modelo nem está listado na API pública ainda, então trate esse número como referência e não como conta fechada

Ou seja, esperar o acesso para só então organizar o repo é perder o tempo que você tem agora 🙂

E de onde vêm as práticas deste post?

Da documentação de boas práticas do Antigravity CLI, a ferramenta para a qual o Google está migrando a experiência de terminal do Gemini CLI

Tome cuidado: isso NÃO quer dizer que o Argon já roda no Antigravity CLI

Uso a documentação só como a referência mais concreta de como o Google espera que um agente trabalhe dentro de uma base de código

Para acompanhar os passos, você precisa de:

• Um repositório versionado, para revisar a mudança como diff e voltar atrás se der ruim
• Uma suíte de testes, mesmo que pequena
• Um comando de build que funcione na sua máquina hoje

Por que versionado? Porque uma mudança gigante sem diff é impossível de revisar, e você vira refém do que o agente disse que fez

Passo 1: escreva a documentação mínima que o agente lê ao iniciar

No Antigravity CLI, a recomendação é criar um GEMINI.md ou AGENTS.md na raiz do workspace com quatro coisas: padrões de diretório, estilo de código, comandos de teste e avisos de depreciação

Por que isso importa? O agente lê esses arquivos ao iniciar, então eles são o primeiro contexto que ele recebe sobre o seu projeto

Pensa no README que você entrega para o dev novo no primeiro dia, só que escrito para alguém que vai seguir tudo AO PÉ DA LETRA

1. Crie o arquivo GEMINI.md ou AGENTS.md na raiz do repositório
2. Preencha as quatro seções com regras curtas, que dê para conferir olhando o código

# Regras do projeto

## Diretórios
- src/ código da aplicação
- tests/ testes, espelhando a estrutura de src/
- scripts/ utilitários de build e verificação

## Estilo
- Funções pequenas, uma responsabilidade por função
- Nenhuma dependência nova sem pedir antes

## Comandos de teste
- Verificação completa: ./scripts/verify.sh
- (troque pelos comandos reais do SEU projeto)

## Depreciações
- src/legacy/http_client está depreciado, use src/core/http
- Não escrever código novo em cima da API interna v1

Os caminhos e comandos aí são de exemplo, troque pelos do seu projeto

O erro comum deste passo

Transformar o arquivo numa wiki enorme, com a história do projeto, decisões de 2019 e metade desatualizada

O agente lê tudo e trata como regra, inclusive o que já não vale mais…

Regra boa é curta e verificável: "não importe X em Y" funciona, "mantenha o código elegante" não

Passo 2: garanta um comando local de verificação

Esse é o passo mais importante do post inteiro

A documentação do Antigravity CLI aponta como a forma mais eficaz de garantir mudanças corretas de um agente autônomo: dar a ele um mecanismo local de verificação (testes unitários, comando de build, scripts de formatação) e pedir que rode o teste depois de propor o código

Sem isso, o agente só tem a própria opinião sobre se terminou, e numa tarefa longa isso não basta

3. Junte formatação, build e testes num único script do projeto

#!/usr/bin/env bash
# scripts/verify.sh: um comando só para provar que a mudança está ok
# Troque cada linha pelo comando real do seu projeto
set -e

echo "1/3 formatação"
<seu comando de checagem de formatação>

echo "2/3 build"
<seu comando de build>

echo "3/3 testes"
<seu comando de testes>

echo "Tudo verde"

O set -e faz o script parar na primeira falha, então ou sai tudo verde ou sai um erro claro, sem meio-termo

4. Registre esse comando na seção de testes do GEMINI.md ou AGENTS.md e escreva, com todas as letras, que ele deve rodar depois de qualquer mudança proposta
5. Rode você mesmo agora, antes de entregar qualquer tarefa, e só siga quando passar verde

O erro comum deste passo

Entregar a tarefa com testes já quebrados ou lentos demais

Se a suíte já está vermelha antes da mudança, o agente não tem como saber se quebrou algo ou se já estava assim

E se demora uma eternidade, ninguém roda (nem você, nem ele haha)

Conserte ou isole os testes quebrados ANTES, e deixe o sinal de sucesso confiável

Passo 3: defina fronteiras de módulo com regras por subpasta

Que fronteira de módulo?

É o limite do que cada parte do código pode fazer: o que pode importar, de quem pode depender e o que não deve ser mexido de jeito nenhum

No Antigravity, dá para colocar AGENTS.md, GEMINI.md ou um diretório .agents/rules/ em qualquer subpasta

Ao ler ou editar um arquivo, ele sobe a árvore de diretórios até a raiz do workspace e carrega as regras de cada nível

Isso é muito massa para tarefa grande, porque a regra do módulo aparece justamente quando o agente mexe nele

6. Coloque as regras gerais na raiz e as específicas dentro de cada módulo sensível

meu-projeto/
├── AGENTS.md              regras gerais do repo
├── scripts/
│   └── verify.sh
└── src/
    ├── billing/
    │   └── AGENTS.md      regras do módulo de cobrança
    ├── legacy/
    │   └── .agents/rules/ regras do código legado
    └── core/

7. Em cada arquivo de módulo, escreva o que ele pode importar, o que está proibido de tocar e as convenções locais

# Regras de src/billing

- Pode importar apenas de src/core
- NÃO alterar src/billing/gateway sem pedido explícito
- Todo valor monetário em centavos (inteiro), nunca float
- Qualquer mudança aqui exige teste novo em tests/billing

O erro comum deste passo

Escrever uma regra de subpasta que contradiz a da raiz sem dizer qual vale

Exemplo: a raiz diz "nenhuma dependência nova" e o módulo diz "pode usar a lib X"

Não conte com o agente adivinhar: escreva na regra do módulo que ela é uma exceção à regra da raiz, e para qual caso

Passo 4: escreva critérios de aceite antes de entregar a tarefa

Pedido grande e vago gera resultado grande e impossível de avaliar

A ideia aqui é transformar "migra o projeto para a nova camada de dados" numa lista de coisas que dá para checar no fim

8. Monte um bloco de critérios e cole junto do pedido

## Critérios de aceite

### Precisa passar
- ./scripts/verify.sh termina com "Tudo verde"
- Testes em tests/integration/orders passam sem alteração

### Não pode mudar
- Respostas da API pública (mesmos campos, mesmos status)
- Esquema do banco, exceto as tabelas listadas abaixo

### Fora do escopo
- src/billing/gateway
- src/legacy

### Como vai ser revisado
- Diff revisado por módulo, na ordem do plano aprovado
- Qualquer arquivo fora do plano é motivo de rejeição

9. Para cada critério, anote como ele vai ser checado: pelo comando de verificação do Passo 2 ou por uma revisão humana objetiva

Se nenhum dos dois consegue checar, o critério precisa ser reescrito

E deixe esse bloco salvo num arquivo dentro do repo, não só na conversa

Sessão longa de agente pode perder pedaços do contexto no caminho, e por isso vale salvar os artefatos antes de depender deles

O erro comum deste passo

Critério vago tipo "código mais limpo" ou "melhorar a performance"

Quem decide se ficou mais limpo? Não tem teste que responda isso

Troque por algo checável: "nenhuma função de src/orders acima de X linhas" ou "o teste de carga Y continua abaixo do tempo atual"

Passo 5: peça plano antes da execução

O Antigravity CLI recomenda um fluxo em três etapas: explorar, planejar e executar

Primeiro o agente explica como a base resolve o problema hoje, depois entrega um plano com os arquivos e dependências afetados, e só aplica as edições depois da sua aprovação

Por que não deixar ele sair codando direto? Porque é muiiito mais barato corrigir um plano do que desfazer milhares de linhas de diff

10. Peça a exploração primeiro

Antes de editar qualquer arquivo, explique como o código atual
resolve <descreva o problema>. Não proponha mudanças ainda.

11. Em seguida, peça o plano com arquivos e dependências afetados, usando os critérios do Passo 4 como referência
12. Confira o plano contra as fronteiras do Passo 3: algum arquivo de módulo marcado como fora do escopo aparece na lista?
13. Confira contra os critérios do Passo 4: cada critério tem um jeito de ser verificado no fim do plano?
14. Só aprove a execução quando as duas checagens baterem

O erro comum deste passo

Aprovar o plano no automático, tipo "next, next e finish"

O plano parece razoável, você aprova, e lá no meio tem uma edição em src/legacy que você tinha marcado como intocável

Leia a lista de arquivos com calma, é ali que o desvio aparece primeiro

Onde essa preparação mais faz diferença

O Google diz que seus engenheiros já usam o Argon no dia a dia em dois tipos de trabalho: depuração e migrações de bases de código de grande porte

E cada um deles puxa mais forte um passo diferente:

Migração: comportamento igual é o critério principal

Numa migração, o sucesso não é "o código novo ficou bonito", é "tudo continua fazendo exatamente a mesma coisa"

Por isso os testes de integração que já existem valem ouro: eles precisam passar sem nenhuma alteração

Se o agente mudou o teste para fazer ele passar, a mudança não está provada, está maquiada

Depuração: o teste vem antes da correção

Antes de pedir o fix, escreva (ou peça) um teste que falha mostrando o bug

Aí a correção só está pronta quando esse teste fica verde junto com o resto da suíte

Sem isso, "corrigi" é só uma afirmação

E o benchmark?

Segundo o próprio Google, o Argon marcou 77,9% no DeepSWE v1.1, um benchmark de tarefas de engenharia de software de longo horizonte

É um número do Google, e mesmo que fosse perfeito, ele mede tarefas de outra pessoa, não as do seu repositório

A lógica é a mesma de testar o modelo na sua tarefa antes de confiar nele: quem decide se deu certo é o seu verify.sh, não a tabela do anúncio

Próximo passo: deixe o repositório pronto antes do acesso chegar

Recapitulando: ainda não existe data pública para o Gemini 4 Argon chegar na API paga nem no Google AI Ultra

Então o momento de preparar a base é agora, com calma, e não no dia em que o acesso for liberado

Os cinco passos foram:

• Documentação mínima num GEMINI.md ou AGENTS.md na raiz
• Um comando local de verificação que passa verde
• Fronteiras de módulo com regras por subpasta
• Critérios de aceite checáveis antes do pedido
• Plano conferido antes de qualquer execução

Se for fazer uma coisa só hoje, cria o arquivo de regras na raiz e garante que o comando de verificação termina verde

E o melhor: nada disso é exclusivo do Argon, a mesma preparação deixa o repo pronto para qualquer agente de código que tu for usar 😀

Até o próximo post!