Como planejar uma migração de código em larga escala antes de usar o Gemini 4 Argon

Fala aí, beleza? O Google acabou de anunciar o Gemini 4 Argon, e o foco dele é exatamente aquela tarefa que todo time empurra pra depois: migração de código grande 😀

Mas se liga numa coisa antes de sair empolgado

Modelo nenhum salva uma migração mal planejada, ele só produz diff mais rápido

O anúncio oficial do Google saiu em 30 de setembro de 2026 e descreve o Argon como o modelo mais avançado da casa, com foco em programação, tarefas longas, trabalho profissional e cibersegurança

Porém o acesso ainda é restrito, então desenvolvedor comum ainda não consegue usar

E isso é uma notícia boa, sério haha

Dá tempo de deixar o projeto pronto AGORA: recortar o escopo, definir a ordem dos módulos, montar os testes como rede de segurança e marcar os pontos de revisão humana

É isso que faz a migração sobreviver a um processo longo em vez de virar um monte de diff solto 🙂

Por que o Gemini 4 Argon muda o jeito de planejar migrações?

O ponto central é o limite de saída

O Argon pode gerar até 1 milhão de tokens de saída, contra 64 mil no limite anterior, ou seja, 16 vezes mais

Que limite de saída? É o quanto o modelo consegue ESCREVER numa resposta (código, patch, explicação), não o quanto ele consegue ler

Segundo o Google, esse limite maior foi pensado pra tarefas longas e autônomas, tipo migração de código, justamente pra reduzir desvio de rota, erros acumulados e tangentes alucinadas

E não ficou só no discurso: dentro do Google, agentes do Argon estão migrando código C/C++ para Rust

Vai de bibliotecas como re2 e libgav1, com dezenas de milhares de linhas, até o kernel Zircon do Fuchsia, com mais de 800 mil linhas

Aí vem a parte que importa pra você: um horizonte longo assim exige um plano que aguente horas de execução sem perder o fio

É como contratar um cara fodão pra reformar a casa inteira e virar as costas… se ninguém disse qual cômodo vem primeiro e qual parede não pode cair, ele vai reformar com muiiita vontade e pouca direção xD

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

O que você precisa ter antes de começar

Esses pré-requisitos são do PROJETO, não da ferramenta

Se eles não existirem, nenhum agente de código vai fazer milagre

• Código versionado em Git, com uma branch dedicada só à migração
• Suíte de testes que roda localmente e no CI, porque é ela que vai dizer se o agente quebrou algo
• Mapa de dependências entre módulos, ou pelo menos disposição pra gerar um (a gente faz isso no passo a passo)
• Critério de pronto definido: comportamento idêntico, desempenho mínimo aceitável e por aí vai
• Uma pessoa responsável pela revisão, com nome e sobrenome, não o time de forma genérica

E o acesso ao Gemini 4 Argon, como está?

Aqui vale ser honesto: a liberação começou só pra defensores cibernéticos de confiança do Programa Fairwind

A liberação ampla está planejada pra começar pelos clientes pagos da API e pelos assinantes do Google AI Ultra, sem data de disponibilidade geral divulgada

O Google também participa do processo voluntário de acesso antecipado a modelos do governo dos EUA antes de abrir o Argon de forma mais ampla

E no dia do anúncio o Argon não aparecia na documentação de modelos do Vertex AI, do Gemini CLI, do Cursor nem do GitHub Copilot, e não tinha ID de modelo publicado na API

Ou seja, ainda não existe instrução oficial de instalação nem de configuração do Argon

O que dá pra fazer agora é preparar o terreno 🙂

Passo a passo para planejar a migração de código em larga escala

Bora ver na prática? Os exemplos abaixo usam Git, testes e scripts genéricos, nada específico do Argon

Adapte as pastas e extensões pro teu projeto, beleza?

1. Inventarie e recorte o escopo

Antes de qualquer agente tocar no código, tu precisa saber o que existe e separar em três grupos: o que migra, o que fica de fora e o que só é adaptado

# cria a branch dedicada à migração
git switch -c migracao/rust

# inventário de linhas por pasta (exemplo para C/C++)
for dir in src/*/; do
  total=$(find "$dir" \( -name '*.c' -o -name '*.cpp' -o -name '*.h' \) -print0 | xargs -0 cat 2>/dev/null | wc -l)
  echo "$total $dir"
done | sort -n

Com o inventário na mão, registra a decisão num arquivo versionado junto com o código

# escopo.md
MIGRA: src/utils, src/parser, src/codec
FICA DE FORA: src/legacy_ui (vai ser descontinuado)
SÓ ADAPTA: src/bindings (muda só a interface)

O erro comum deste passo: tentar migrar o repositório inteiro numa tacada

O diff fica impossível de revisar e qualquer bug some no meio de milhares de arquivos

2. Defina a ordem dos módulos pelo grafo de dependências

Que grafo? É o mapa de quem depende de quem dentro do projeto

A regra é simples: folhas primeiro (módulos que não dependem de ninguém interno), núcleo por último

# mostra de quais módulos internos cada pasta depende
for mod in src/*/; do
  echo "== $mod"
  grep -rhoE '#include "[^/]+/' "$mod" | sort -u
done

Com isso tu monta a fila de migração

# ordem.md
1. src/utils    (folha, ninguém interno)
2. src/parser   (depende de utils)
3. src/codec    (depende de utils e parser)
4. src/core     (núcleo, depende de todo mundo)

O erro comum deste passo: começar pelo módulo mais crítico porque ele é o que mais incomoda

Se o núcleo quebra, tudo que depende dele quebra junto, e tu perde a referência de onde o problema nasceu

3. Congele o comportamento atual com testes de caracterização

Que teste de caracterização? É um teste que registra o que o código faz HOJE, certo ou errado, e não o que ele deveria fazer

A ideia é ter saídas de referência pra comparar depois

O caso público mais claro é o libgav1: lá, segundo o Google, os agentes do Argon trocaram código de baixo nível e mantiveram a saída de vídeo idêntica

Saída idêntica é o critério, e pra medir isso tu precisa da saída antiga guardada

# gera as saídas de referência com o binário ANTES da migração
mkdir -p golden
for f in fixtures/*.in; do
  ./build/app_antigo "$f" > "golden/$(basename "$f" .in).out"
done
git add golden fixtures
git commit -m "testes: saídas de referência pré-migração"

E o script que compara a versão nova com a referência

#!/usr/bin/env bash
# scripts/compara_golden.sh
falhas=0
for f in fixtures/*.in; do
  nome=$(basename "$f" .in)
  if ! ./build/app_novo "$f" | diff -q - "golden/$nome.out" > /dev/null; then
    echo "DIVERGIU: $nome"
    falhas=1
  fi
done
exit $falhas

O erro comum deste passo: escrever os testes DEPOIS da migração

Aí o teste valida o comportamento novo, bug incluso, e ninguém percebe que algo mudou

4. Estabeleça métricas de pronto além de compila

Compilar é o mínimo, não é o critério

Define antes o que significa pronto pra cada módulo: testes verdes, saída igual à referência e desempenho medido

# 1) testes verdes
make test

# 2) saída igual à referência
./scripts/compara_golden.sh

# 3) desempenho: compara antigo x novo com a mesma entrada
time ./build/app_antigo fixtures/grande.in > /dev/null
time ./build/app_novo fixtures/grande.in > /dev/null

Pra desempenho de verdade, usa o profiler que teu time já conhece, não só o time

No libgav1, o Google conta que os agentes trabalharam em rodadas de experimentos guiados por profiling e análise da saída do compilador, então medição faz parte do processo, não é enfeite

O erro comum deste passo: aceitar o diff só porque compila

Código que compila e devolve resultado diferente é pior que código que não compila, porque passa despercebido

5. Fatie em lotes pequenos com checkpoints de revisão humana

Um módulo, um commit (ou PR), uma revisão

O agente pode até trabalhar por horas, mas o diff precisa chegar em pedaços que uma pessoa consegue ler

# um lote = uma branch a partir da branch da migração
git switch -c migracao/rust-utils migracao/rust

# ... o agente trabalha SÓ em src/utils ...

make test && ./scripts/compara_golden.sh
git add src/utils
git commit -m "migra src/utils para Rust"
git push -u origin migracao/rust-utils
# abre o PR e PARA aqui até a revisão humana aprovar

O erro comum deste passo: deixar o agente acumular um diff gigante sem pontos de parada

Com saída longa disponível, a tentação é deixar rodar tudo de uma vez, e é aí que o erro do módulo 2 contamina o módulo 7 sem ninguém ver

6. Escreva o briefing da tarefa para o agente

O agente não adivinha teu plano, então o plano vira texto

É a mesma lógica do Plan Mode do Claude Code: planejar antes de executar, só que aqui o plano é teu e vai pronto pro agente

# briefing.md
OBJETIVO: migrar src/utils de C para Rust, sem mudar comportamento

ESCOPO: só src/utils. NÃO tocar em src/parser, src/codec, src/core

ORDEM: este é o lote 1 de ordem.md

REGRAS:
- não alterar arquivos em golden/ nem fixtures/
- não mudar a interface pública sem registrar em NOTAS.md
- sem dependências novas sem justificar

COMO TESTAR:
- make test
- ./scripts/compara_golden.sh

SE UM TESTE FALHAR:
- parar, registrar o teste e a diferença em NOTAS.md
- não editar o teste para passar
- não seguir para outro módulo

PRONTO QUANDO: testes verdes + golden idêntico + medição registrada

O erro comum deste passo: instrução vaga, tipo migra tudo pra Rust e deixa bonito

Instrução vaga é convite pra tangente, e numa tarefa longa a tangente vira refatoração que ninguém pediu

7. Planeje a auditoria antes de produção

O agente terminou? Ótimo, agora começa a parte séria

O Google diz que as próprias reescritas em larga escala passam por auditoria automatizada e manual, testes de emulação e revisão antes de ir pra produção

O fluxo detalhado que eles usaram não foi divulgado, mas a estrutura serve de espelho pro teu projeto

• Automatizada: CI completo, testes de caracterização, análise estática e as ferramentas de segurança que teu time já usa
• Manual: revisão por lote feita pela pessoa responsável, olhando principalmente interfaces e código de baixo nível
• Ambiente próximo do real: rodar a versão nova contra entradas de produção (ou o mais perto disso que tu tiver) antes do deploy

Se quiser aprofundar o hábito de validar a resposta da IA antes de confiar nela, o raciocínio é o mesmo, só que aqui em escala de repositório

O erro comum deste passo: tratar a migração como pronta quando o agente disse que terminou

O agente terminar é o começo da auditoria, não o fim do projeto

8. Estime o custo antes de soltar o agente

O preço introdutório do Argon na API é de US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída

Tome cuidado: é preço INTRODUTÓRIO, e o valor depois desse período não está confirmado na fonte oficial

Numa migração, o agente escreve muito código, então a saída (que é a parte mais cara) pesa bastante na conta

# estimativa simples por lote, com o preço introdutório
PRECO_ENTRADA = 2.00   # US$ por milhão de tokens de entrada
PRECO_SAIDA = 10.00    # US$ por milhão de tokens de saída

def custo_lote(tokens_entrada, tokens_saida):
    entrada = tokens_entrada / 1_000_000 * PRECO_ENTRADA
    saida = tokens_saida / 1_000_000 * PRECO_SAIDA
    return entrada + saida

# preencha com a SUA medição de um lote piloto
print(custo_lote(tokens_entrada=0, tokens_saida=0))

O jeito honesto de estimar é migrar o primeiro módulo folha, medir os tokens desse lote e só então projetar o resto

O erro comum deste passo: subestimar o custo da saída numa tarefa de horizonte longo

Se o agente reescreve, testa, falha e reescreve de novo, cada volta é saída cobrada

Que tipo de migração se beneficia desse planejamento?

Nem toda migração precisa desse ritual todo

Os casos públicos que o Google divulgou mostram bem onde ele faz diferença

O caso do libgav1 é o mais didático: além de manter a saída de vídeo idêntica, o decodificador ficou 2,7x mais rápido que o port anterior em Rust, segundo o Google

Repara que isso só dá pra afirmar porque existia saída de referência e medição de desempenho, exatamente os passos 3 e 4 ali de cima 😀

Quando esse esforço não compensa?

Migração pequena, que cabe numa revisão só, não precisa de grafo de dependências nem de oito passos

Se é um módulo isolado, com testes já existentes e um diff que tu lê numa tarde, vai direto: branch, testes, revisão e pronto

O método vale quando o tamanho da mudança passa do que uma pessoa consegue revisar de uma vez

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

Enquanto o Argon não tem liberação geral, o trabalho que dá retorno é o de preparação

Inventário, grafo de dependências, testes de caracterização e checkpoints de revisão: nada disso depende de ter acesso ao modelo

E o melhor, quando a migração de código com Gemini 4 Argon finalmente for possível pro teu time, tu já começa com o plano rodando em vez de começar pelo planejamento

O próximo passo concreto é simples: roda o inventário e escreve os testes de caracterização do primeiro módulo folha ainda esta semana

E se liga: esse preparo vale pra qualquer agente de código, não só pro Argon

O modelo muda, o projeto bem preparado continua sendo teu 🙂

Até o próximo post!