Como usar o Gemini 4 Argon para projetar algoritmos: peça a solução antes do código

Pedir código pra IA antes de ter a solução desenhada é o jeito mais rápido de receber uma implementação errada, só que muito bem escrita 😛

E pelo jeito o Google pensa parecido

No anúncio do Gemini 4 Argon, feito em 30 de setembro de 2026, o Google cita o desenho de algoritmos (algorithm design) entre os usos que os engenheiros dele já fazem do modelo

Junto com depuração do dia a dia, pesquisa e grandes migrações de código

Então neste post te mostro um fluxo pra separar a etapa de desenho da etapa de implementação, e como comparar duas abordagens antes de escrever uma linha sequer 🙂

Só um aviso sem rodeio: o modelo ainda NÃO está aberto ao público

Os prompts daqui funcionam com o modelo que tu já usa hoje, e o detalhe de acesso vem logo abaixo

O que você precisa antes de começar

São duas coisas: saber como está o acesso ao modelo e ter o material do problema bem organizado

A segunda é a que mais importa, e vale pra qualquer IA

Como está o acesso ao Gemini 4 Argon hoje?

Hoje o acesso é exclusivo do Fairwind Program, liberado só pra defensores cibernéticos de confiança (equipes de segurança internas dos parceiros do Google)

Segundo relatos publicados logo depois do anúncio, em 1 de outubro de 2026 o modelo estava fora do catálogo público da API do Gemini, e uma chamada usando o ID gemini-4-argon retornava 404 NOT_FOUND

Ou seja: não existe ID público na API

A próxima etapa anunciada pelo Google começa por clientes pagos da API e assinantes do Google AI Ultra, ainda sem data de disponibilidade geral

Quanto vai custar a API do Gemini 4 Argon?

O preço anunciado serve como referência pra planejar:

• Introdutório: US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída
• Depois do período introdutório: US$ 4 e US$ 20
• Input em cache: 95% de desconto

Não tenho dado confirmado sobre quanto tempo dura o preço introdutório, então não conte com ele no longo prazo

No fluxo deste post tu vai reaproveitar o mesmo enunciado e as mesmas restrições em várias mensagens, então vale ficar de olho nesse desconto de cache quando o acesso abrir

Material do problema: o que separar antes do primeiro prompt?

Essa parte é a que faz a diferença de verdade, com qualquer modelo:

• Enunciado claro: o que entra, o que sai, o que conta como resposta certa
• Tamanho esperado da entrada: 100 itens? 10 milhões? Isso muda tudo
• Restrições de tempo e memória: limite de resposta, máquina onde roda (não precisa ser um PC da Nasa, mas precisa saber qual é)
• Linguagem alvo: Python, Rust, TypeScript e por aí vai
• Exemplos de entrada e saída: incluindo casos-limite (lista vazia, um elemento só, valores repetidos, números negativos, entrada no tamanho máximo)

É a mesma lógica de decidir antes da primeira linha num projeto novo: quanto mais claro o problema, menos a IA precisa adivinhar

Passo a passo: como pedir a solução antes de pedir o código

A ideia aqui é simples: tratar o modelo como alguém que vai desenhar a solução contigo no quadro branco, e não como uma máquina de cuspir código

O código vem só no passo 5, se liga 😀

Passo 1: descreva o problema e as restrições sem pedir implementação

Tu começa entregando o contexto inteiro e deixando claro que ainda não quer código

Vou te passar um problema de algoritmo. Ainda NÃO quero código.

Problema: dado um histórico de transações (id_usuario, valor, timestamp),
encontrar, para cada usuário, a maior janela de 24h com soma de valores
acima de um limite L.

Tamanho da entrada: até 5 milhões de transações, até 200 mil usuários.
Restrições: precisa rodar em poucos segundos, memória limitada.
Linguagem alvo: Python.

Exemplos:
- Entrada vazia -> saída vazia
- Usuário com uma única transação acima de L -> janela com essa transação
- Transações com o mesmo timestamp -> devem entrar na mesma janela

Antes de qualquer coisa, me diga se ficou alguma ambiguidade no enunciado.

Erro comum deste passo: omitir o tamanho da entrada

Sem isso o modelo fica sem critério pra escolher a complexidade, e pode te entregar uma solução quadrática linda que trava no primeiro arquivo real

Passo 2: peça duas ou três abordagens, sem código

Agora tu pede alternativas, em linguagem natural ou pseudocódigo

Proponha 2 ou 3 abordagens diferentes para esse problema.
Não escreva código ainda.
Descreva cada abordagem em linguagem natural ou pseudocódigo curto,
explicando a ideia central e por que ela resolve o problema.

Erro comum deste passo: aceitar a primeira proposta sem pedir alternativas

A primeira ideia costuma ser a mais óbvia, e nem sempre é a melhor pro seu tamanho de entrada

Passo 3: peça complexidade, invariantes e casos-limite de cada abordagem

Que invariante? É a propriedade que continua verdadeira a cada passo do algoritmo (tipo "a janela atual nunca passa de 24h")

É ela que te ajuda a entender POR QUE a solução funciona, e não só que ela parece funcionar

Para cada abordagem proposta, me diga:
1. Complexidade de tempo e de espaço, considerando o tamanho de entrada informado
2. As invariantes que garantem que o resultado está correto
3. Como ela se comporta em cada caso-limite que listei e em outros que você identificar
4. Um argumento curto de por que a solução está correta

Erro comum deste passo: não pedir o raciocínio de por que a solução está correta

Só a complexidade não basta, um algoritmo rápido e errado continua errado

Passo 4: peça que o modelo critique a própria proposta

Esse é o passo que quase todo mundo pula

Agora atue como revisor cético das suas próprias propostas.
Tente encontrar um contraexemplo que quebre cada abordagem.
Aponte as suposições que você fez e que podem não valer
no meu cenário real.

Erro comum deste passo: tratar a primeira resposta como prova

Explicação convincente não é demonstração, e IA é muiiito boa em soar convincente

Passo 5: escolha a abordagem e só então peça a implementação

Com a abordagem escolhida, tu trava a decisão no prompt e pede os testes junto

Vamos seguir com a Abordagem B.
Implemente em Python seguindo exatamente essa abordagem,
sem trocar de estratégia no meio do caminho.
Se encontrar um problema na abordagem, pare e me avise antes de mudar.

Inclua testes para todos os casos-limite levantados nos passos anteriores.

Erro comum deste passo: deixar o modelo trocar de abordagem no meio do código

Aí tu revisa achando que é a Abordagem B e na verdade é uma mistura das duas… Já vi isso acontecer mais de uma vez

Passo 6: valide fora do modelo

Aqui não tem prompt, tem trabalho:

• Rodar os testes dos casos-limite
• Medir o tempo com entrada no tamanho real
• Conferir se a complexidade bate com o que o modelo disse

E por que isso é obrigatório?

A Artificial Analysis mediu uma taxa de alucinação de 15% do modelo no AA-Omniscience

Não é zero, então a revisão humana continua sendo parte do fluxo, não um extra

Como comparar duas abordagens que o modelo propôs

Pra não decidir no feeling, use uma tabela-modelo e preencha com as respostas do passo 3

As colunas abaixo mostram O QUE observar em cada critério, os valores quem coloca é você:

Depois tu pode pedir pro próprio modelo preencher a mesma tabela:

Preencha esta tabela comparando a Abordagem A e a Abordagem B,
usando as análises que você fez antes.
Critérios: complexidade de tempo, complexidade de espaço,
casos-limite, facilidade de implementar e testar,
risco de erro sutil, adequação ao tamanho real da entrada.
No final, diga qual você escolheria e justifique.

Só que a decisão final é sua, beleza?

A tabela do modelo é ponto de partida, quem bate o martelo é o teste com dado real

Quando faz sentido usar o Gemini 4 Argon no desenho de algoritmos

O Google posiciona o modelo pra fluxos longos e complexos: coding de horizonte longo, trabalho de conhecimento corporativo (ex.: jurídico e finanças) e defesa cibernética

Desenho de algoritmo em problema difícil casa bem com isso, porque é uma conversa longa com várias idas e vindas

O exemplo do decodificador de vídeo

Segundo o Google, o modelo ajudou a otimizar um software de decodificação de vídeo

O resultado divulgado foi uma implementação em Rust 2,7 vezes mais rápida que uma versão em Rust existente, com saída de vídeo idêntica

É dado do Google, não experiência minha, mas mostra bem o tipo de problema onde pensar a solução antes de codar faz diferença

Por que o contexto grande ajuda nesse fluxo?

O modelo tem 1M de tokens de contexto, e o limite de saída passou pra 1M de tokens (antes era 64K)

Na prática, isso permite colocar bastante código de referência na conversa enquanto tu discute as abordagens, sem precisar ficar cortando contexto

No anúncio, o Google também informa 77,9% no DeepSWE v1.1, um benchmark de tarefas reais de engenharia de software de horizonte longo (de novo: dado do anúncio)

Quando esse fluxo é exagero?

Nem tudo precisa de seis passos haha

Problema trivial (ordenar uma lista pequena, filtrar um array, somar uns campos) vai direto pro código

O fluxo compensa quando errar a abordagem custa caro: entrada grande, restrição de desempenho apertada ou lógica cheia de caso-limite

Próximo passo: treine o fluxo agora e leve para o Argon depois

Separar desenho de implementação reduz retrabalho e deixa a revisão MUITO mais objetiva, porque tu sabe exatamente o que o código deveria fazer

Como o Argon ainda não está aberto ao público, o caminho é:

• Aplicar os prompts do passo a passo num problema real do seu projeto, com o modelo que você já usa
• Guardar a tabela de comparação como template
• Acompanhar a liberação anunciada, que começa por clientes pagos da API e assinantes do Google AI Ultra, ainda sem data

Quando o acesso abrir, o fluxo já vai estar no automático 😀

Até o próximo post!