Como pedir ao Gemini 4 Argon para separar um módulo acoplado de um sistema grande

Na maioria das vezes, o problema não está no modelo escrevendo o código, e sim no jeito como a refatoração foi pedida

Fala aí, beleza? O Google soltou o Gemini 4 Argon em 30/09/2026, apresentado como o modelo de fronteira mais avançado da empresa, e desde 13/10/2026 ele saiu do acesso restrito a parceiros de cibersegurança e ganhou disponibilidade geral (com alguns canais e planos específicos, que eu detalho mais abaixo)

No lançamento, o caso que mais chamou atenção foi o Argon separando um pedaço MUITO acoplado do código do Chrome

Neste post eu transformo esse caso num método que tu pode repetir no teu próprio sistema: mapear a fronteira, descrever o acoplamento, pedir o plano e só depois o diff 🙂

O que o Google fez no Chrome com o Gemini 4 Argon?

Segundo o anúncio do Google, o Argon ajudou o time do Chrome a separar o processamento central de páginas web de uma pasta legada de cerca de 6 milhões de linhas

E essa pasta fica dentro dos 40 milhões de linhas do código do Chromium, ou seja, não é um projetinho de fim de semana haha

O Argon entregou várias mudanças de código limpas por vez e ajudou a concluir uma refatoração arquitetural em centenas de arquivos

Pelas contas do Google, meses de trabalho viraram semanas

Por que essa separação importa pro Chrome?

Com o núcleo de processamento separado, as páginas abertas vão poder passar entre abas, painéis laterais e janelas flutuantes sem recarregar

O Google diz que isso acaba com uma categoria inteira de travamentos do navegador

No lançamento também apareceram outros casos de código em grande escala: agentes do Argon reescreveram 32.000 linhas de código crítico de desempenho no decodificador de vídeo libgav1 e passaram C/C++ pra Rust, incluindo mais de 800.000 linhas no kernel Zircon do Fuchsia

Qual é a lição pra quem não trabalha no Google?

Se liga: tudo isso é caso citado pelo Google, não é teste nosso

O Google também não publicou como o time do Chrome escreveu os prompts nem como revisou as mudanças

Mesmo assim, dá pra tirar duas pistas do que foi divulgado: a fronteira do que seria separado estava clara e o trabalho saiu em lotes de mudanças limpas, não num diff monstro único

Os passos abaixo partem dessas duas ideias e são boa prática geral de refatoração, não um guia oficial do Google

O que você precisa antes de começar:

Primeiro, onde o Argon está disponível hoje:

• API paga do Gemini
• Google AI Studio
• Antigravity
• Assinaturas elegíveis do Gemini Enterprise

No app Gemini, a liberação pra assinantes Google AI Pro e AI Ultra começou em 13/10/2026 (no mês anterior era só pro Ultra)

Tome cuidado com o Antigravity: no app desktop e no CLI, o Argon exige o plano Google AI Ultra, e o AI Pro não dá acesso a ele por lá

Que Antigravity? É o ambiente de desenvolvimento do Google baseado em agentes, em que a IA trabalha olhando o projeto inteiro, com editor, terminal e navegador

Quanto contexto e quanto custa?

A janela de contexto é de 1.048.576 tokens, o que ajuda MUITO quando o módulo acoplado está espalhado por vários arquivos

Na API, o preço promocional vale até 30/11/2026:

A entrada em cache sai 95% mais barata, o que pesa quando tu reenvia os mesmos arquivos várias vezes durante a refatoração

E do teu lado?

Duas coisas, sem negociação:

• Repositório versionado, pra conseguir voltar qualquer lote que der ruim
• Testes rodando, pra validar cada etapa antes de seguir

Sem teste, tu não está refatorando, tu está torcendo… e já me ferrei uma vez por causa disso 😛

Passo a passo para separar um módulo acoplado com o Argon:

Os exemplos abaixo são texto de pedido pro modelo, não comandos de terminal

Adapta os nomes pro teu sistema, beleza?

Passo 1: como mapear a fronteira do módulo?

Antes de mexer em qualquer linha, pede pro Argon dizer o que pertence ao módulo e o que é dependência externa

Nessa etapa ele só lê, não altera nada

Quero separar o módulo de cobrança do restante do sistema
Analise as pastas billing/ e core/legacy/ e me devolva:
1. Os arquivos, classes e funções que pertencem ao módulo de cobrança
2. As dependências externas que o módulo usa (outros módulos, banco, serviços)
3. Quem, fora do módulo, chama código de cobrança
Não proponha mudanças e não escreva código nesta resposta

O erro comum deste passo: mandar um "refatora isso" sem dizer onde o módulo começa e onde termina

Sem fronteira, o modelo decide sozinho o recorte, e aí o diff sai espalhado pelo sistema inteiro

Passo 2: como descrever o acoplamento pro modelo?

Agora tu conta o que sabe do problema: quem chama quem, o estado global compartilhado, as importações cruzadas e a pasta legada envolvida

Pensa nisso como passar o plantão pra um dev novo no time: quanto mais tu conta das gambiarras, menos ele tropeça nelas

Contexto do acoplamento que eu conheço:
- core/legacy/utils.py tem um dicionário global CONFIG que o módulo de cobrança lê e escreve
- billing/invoice.py importa funções de checkout/cart.py, e cart.py importa de volta billing/discount.py
- Os relatórios chamam direto as queries internas de billing/
Compare isso com o mapeamento que você fez e me diga que outros pontos de acoplamento aparecem no código

O erro comum deste passo: esconder o acoplamento feio por vergonha do código

É justamente essa parte que precisa ser cortada, então ela tem que estar na mesa

Passo 3: quanto contexto mandar pro Argon?

A janela grande permite incluir bastante arquivo, e isso é ótimo

Mas contexto bom é contexto com foco: os arquivos do módulo, os pontos de contato que apareceram nos passos 1 e 2 e os testes que cobrem essa área

Objetivo: isolar o módulo de cobrança atrás de uma interface própria, sem mudar o comportamento atual
Segue o conteúdo de:
- billing/ (inteiro)
- core/legacy/utils.py
- checkout/cart.py
- reports/billing_queries.py
- tests/billing/
Use só esses arquivos como base e me avise se faltar algum para entender o acoplamento

O erro comum deste passo: despejar o repositório inteiro sem dizer o objetivo

Caber na janela não quer dizer que tudo ali é relevante, e o pedido perde o foco no meio de tanto arquivo

Passo 4: por que pedir o plano antes do diff?

Esse é o passo mais importante do método todo

Tu pede as etapas, a ordem, as interfaces novas e os riscos, e proíbe código nessa resposta

Com base no mapeamento e no acoplamento, monte um plano de refatoração com:
1. Etapas numeradas, cada uma pequena o bastante para virar um commit
2. A ordem das etapas e por que essa ordem
3. As interfaces novas que o módulo de cobrança vai expor
4. Os riscos de cada etapa e quais testes provam que nada quebrou
Não escreva código nesta resposta, só o plano

Com o plano em mãos, tu revisa como revisaria a proposta de um colega: a ordem faz sentido? A interface ficou enxuta? Algum risco ficou de fora?

O erro comum deste passo: aceitar o diff gigante de primeira

Diff enorme sem plano é impossível de revisar direito, e aí sobra aprovar no next, next e finish xD

Passo 5: como executar a refatoração em lotes?

Aqui entra a inspiração direta no caso do Chrome, que saiu em várias mudanças limpas por vez

Uma etapa do plano por pedido, nada mais

Execute apenas a etapa 1 do plano aprovado
Mostre o diff completo dessa etapa e liste os testes que devo rodar para validar
Não avance para a etapa 2

O erro comum deste passo: pedir tudo de uma vez

Além de virar um diff impossível de revisar, tu ainda corre o risco de estourar a saída

Se liga na diferença: uma fonte cita saída máxima padrão de 65.536 tokens por resposta, e o limite unificado de até 1 milhão de tokens de entrada e saída que o Google menciona depende do protocolo de continuação, pensado pra tarefas muito pesadas

Como o cenário normal é o padrão, lote pequeno é o caminho seguro

Passo 6: como validar cada lote antes de seguir?

Rodou a etapa? Roda os testes, revisa o diff e só depois pede a próxima

Se algo quebrou, devolve o erro pro modelo com o contexto do que mudou

Apliquei a etapa 1 e o teste tests/billing/test_invoice.py falhou com este erro:
[cole aqui a saída do teste]
Explique a causa e proponha a correção só para esta etapa, sem mexer nas próximas

O erro comum deste passo: acumular lotes sem rodar teste

Quando o erro aparece três etapas depois, ninguém sabe mais qual mudança causou o problema, nem tu nem o modelo

Quando vale usar o Argon numa refatoração arquitetural?

O método encaixa melhor quando o problema é de estrutura, não de uma linha errada

Alguns cenários onde ele faz sentido:

• Extrair um módulo de dentro de uma pasta legada: é exatamente o desenho do caso do Chrome, um núcleo útil preso dentro de um código antigo
• Isolar regras de negócio da camada de interface: quando a regra de cálculo mora dentro do controller ou da tela, a fronteira do passo 1 deixa isso visível
• Preparar uma migração de linguagem: antes de reescrever C/C++ em Rust, como no caso do Zircon, o módulo precisa estar isolado atrás de uma interface clara

Se tu está pensando se faz sentido fora de empresa grande, tem um post só sobre o Argon para dev solo e freelancer

E quando NÃO vale?

Mudança pequena e local não pede plano em seis passos

Renomear uma função, corrigir um bug pontual ou ajustar uma validação se resolve com um pedido direto, sem cerimônia

Pra esse tipo de tarefa, vale ler sobre o Argon no debugging do dia a dia 😉

Vídeo: modelos de fronteira criando sistemas na prática

Se tu quer ver um modelo de fronteira criando vários sistemas do zero, este vídeo do canal mostra o GPT-5.6 sendo testado nisso

Próximo passo: escolha o primeiro módulo

Recapitulando os seis passos do método: fronteira, acoplamento, contexto, plano, lotes e validação

O próximo passo é escolher no teu sistema um módulo acoplado pequeno e rodar só os passos 1 a 4

Avalia a qualidade do plano antes de aceitar qualquer diff, porque é ali que tu descobre se o modelo entendeu teu código ou só está chutando

E se tu vai usar via API, lembra que o preço promocional vai até 30/11/2026

Bora testar no teu projeto? Até o próximo post! 😀