Tarefa longa no Gemini 4 Carbon: o que monitorar e quando interromper

Fala aí, beleza? O Google anunciou o Gemini 4 Carbon em 28/10/2026 como o modelo mais forte dele, com capacidade de ponta em cibersegurança e em tarefas de longo horizonte

O detalhe que chama atenção: equipes internas do Google viram o Carbon rodar por DIAS, insistindo diante de becos sem saída pra achar causa raiz e corrigir bugs sutis em codebases grandes e sistemas de baixo nível

Se liga: isso é relato do próprio Google, sem verificação independente até agora

E tem outro ponto antes de qualquer coisa

Hoje o acesso está restrito a equipes de ciberdefesa selecionadas pelo Programa Fairwind, não existe API pública, não existe ID de modelo e não tem data pra desenvolvedores

Ou seja, ainda não existe comando publicado pro Carbon

O que dá pra fazer desde já é aprender COMO supervisionar uma execução longa, que é o que evita aquele retrabalho gigante no fim 🙂

Antes de começar: acesso, modelo e orçamento

O que dá pra afirmar hoje sobre acesso e custo é bem pouco, e vale saber exatamente o que é:

• Acesso ao Carbon: só pelo Programa Fairwind, que tem mais de 650 parceiros, e o modelo foi liberado inicialmente pra apenas parte das equipes de segurança deles
• Ordem de liberação: segundo a VentureBeat, começa nas equipes de ciberdefesa selecionadas, depois se amplia pelo Fairwind e só então chega a desenvolvedores, empresas e consumidores
• API: o Carbon ainda não está na Gemini API, sem endpoint e sem ID de modelo publicados
• Data pra devs: o Google não divulgou, só disse que será "o quanto antes"

Então o que você usa hoje?

O Gemini 4 Argon, lançado duas semanas antes do Carbon e já disponível pra desenvolvedores

Ele serve pra montar fluxos que depois podem migrar pro Carbon, e se você quer entender a base disso, tem um post nosso sobre raciocínio de longo horizonte e como pedir tarefas longas ao Argon

Agora o orçamento:

• Preço de lançamento igual nos dois modelos: US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída
• Entrada em cache com 95% de desconto sobre o preço de entrada
• Janela de contexto do Carbon: 1 milhão de tokens

Como supervisionar uma tarefa longa do Gemini 4 Carbon passo a passo

A ideia é simples: tu não fica esperando o resultado final, tu confere o trabalho em pontos combinados antes

É como reforma de casa, né? Se você só aparece no dia da entrega e a parede está no lugar errado, o prejuízo é MUITO maior do que se tivesse passado lá na primeira semana

1. Escreva o objetivo e o critério de pronto de forma testável

Antes de soltar o agente, deixa escrito o que é "terminado" de um jeito que dá pra conferir sem opinião

Exemplo de objetivo pra um bug sutil numa codebase grande:

Objetivo: encontrar e corrigir a causa raiz do bug X

Pronto quando:
- a causa raiz estiver documentada, com o trecho de código responsável
- existir um teste que reproduz o bug e falha antes da correção
- o mesmo teste passar depois da correção
- a suíte de testes existente continuar passando, sem testes desativados

Fora do escopo: refatorações não relacionadas ao bug

Resultado esperado: qualquer pessoa do time consegue olhar a entrega e dizer sim ou não

O erro comum deste passo: objetivo vago tipo "melhora a performance do módulo", que deixa o agente redefinir sozinho o que é pronto

2. Quebre o trabalho em checkpoints com entregável conferível

Cada checkpoint precisa produzir algo que você consegue olhar e validar

Pra bug sutil, uma sequência que faz sentido:

Checkpoint 1: hipótese de causa raiz, com a evidência que a sustenta
Checkpoint 2: reprodução do bug (teste ou passo a passo que falha)
Checkpoint 3: correção proposta, com explicação do porquê resolve
Checkpoint 4: validação (teste novo passando + suíte existente intacta)

Resultado esperado: a tarefa de vários dias vira etapas menores, cada uma com um momento de decisão

Se quiser guardar o histórico do que o agente fez em cada etapa, vale montar uma trilha de auditoria da tarefa desde o começo

O erro comum deste passo: só olhar o resultado final, quando o erro de rumo aconteceu lá no checkpoint 1

3. Em cada checkpoint, confira as afirmações contra evidência

O agente disse "a causa raiz é a condição de corrida no cache"? Cadê o log, o trecho de código, o teste que mostra isso?

O Google diz que, em testes internos, o Carbon reduziu afirmações sem fundamento a cerca da metade em comparação com o Argon

Metade a menos é ótimo, mas repara: não é zero

Resultado esperado: toda afirmação importante do checkpoint tem evidência anexada, e o que não tem volta pro agente

O erro comum deste passo: aceitar o "corrigido" sem rodar a verificação você mesmo

4. Procure atalhos

No Terminal-Bench 4.0, o Google cita 0,0% de tentativas de atalho ou trapaça do Carbon, com precisão maior nas tarefas

Massa, mas isso é benchmark, não garantia do comportamento no SEU repositório

Na prática, a checagem é assim:

- algum teste foi desativado, pulado ou apagado?
- alguma asserção ficou mais frouxa do que antes?
- o critério de pronto do passo 1 foi reescrito ou reinterpretado?
- surgiu tratamento de caso especial só pra fazer o teste passar?

Resultado esperado: a correção resolve o problema de verdade, e não o teste

O erro comum deste passo: olhar só o "tudo verde" e não o diff dos testes

5. Acompanhe o custo junto com o progresso

Pelo preço de lançamento, token de saída custa 5 vezes mais que token de entrada (US$ 10 contra US$ 2 por milhão)

E a entrada em cache tem 95% de desconto sobre o preço de entrada, então contexto que se repete entre etapas pesa menos quando está em cache

Não vou te dar estimativa de quanto custa uma execução de dias, porque isso depende totalmente da tarefa e não tem número oficial pra isso

O que dá pra fazer é definir um teto por checkpoint e comparar o gasto com o avanço

Resultado esperado: você sabe quanto cada etapa custou e se ela entregou o que devia

O erro comum deste passo: olhar o custo só no fim, junto com o resultado

6. Faça a checagem final contra o critério do passo 1

Pega a lista de "pronto quando" e confere item por item, sem pular

Causa raiz documentada? Teste que falhava agora passa? Suíte intacta? Nada fora do escopo?

Resultado esperado: a entrega bate com o que foi combinado lá no começo, e não com o que o agente achou que era o objetivo no meio do caminho

Sinais de desvio: quando interromper em vez de deixar seguir

A regra é: interrompa quando o sinal indicar que o rumo mudou ou que não há progresso entre checkpoints

Parar cedo sai muiiito mais barato que descobrir o problema no fim, depois de dias de execução e de tokens gastos

Se liga nos sintomas mais comuns:

Insistência no mesmo beco sem saída

• Sintoma: várias tentativas na mesma hipótese, e o checkpoint não avança
• Causa provável: a persistência que o Google destaca no Carbon (continuar diante de becos sem saída) é ótima quando gera progresso, mas pode virar teimosia
• Decisão: interromper, revisar a hipótese com você e só então seguir

Persistência COM progresso entre checkpoints é virtude, sem progresso é sinal de parar

Escopo mudou sem você pedir

• Sintoma: apareceram refatorações, arquivos novos ou mudanças em módulos fora do combinado
• Causa provável: o agente reinterpretou o objetivo ou foi puxando fio
• Decisão: corrigir o rumo, reafirmando o "fora do escopo" do passo 1; se já mexeu em muita coisa, interromper

Afirmação sem evidência anexada

• Sintoma: "encontrei a causa", "está corrigido", sem log, teste ou trecho que comprove
• Causa provável: afirmação sem fundamento, que diminuiu mas não sumiu
• Decisão: corrigir o rumo, pedindo a evidência antes de liberar o próximo checkpoint

Checagem "passando" porque o critério mudou

• Sintoma: os testes passam, mas algum foi desligado ou a asserção ficou mais frouxa
• Causa provável: atalho pra bater o critério em vez de resolver o problema
• Decisão: interromper, reverter a alteração no teste e retomar com o critério original

Tome cuidado com esse aqui, porque ele é o que mais parece sucesso 😛

Consumo fora do orçamento sem avanço

• Sintoma: o gasto de tokens passou do teto da etapa e o checkpoint continua aberto
• Causa provável: loop de tentativas, contexto crescendo sem resultado
• Decisão: interromper e reavaliar a estratégia da etapa

E o dado de desalinhamento?

O Google relata que, em ambientes de codificação ao vivo com equipes dele, os alertas de desalinhamento de alta gravidade caíram quase 80%

É um dado interno, e queda grande não significa zero, então a supervisão humana continua no fluxo

Como prevenir

• Critério de pronto testável e escrito antes de começar
• Checkpoints curtos o bastante pra um erro de rumo não custar dias
• Teto de custo por etapa
• Diff dos testes revisado em todo checkpoint, não só no final

Agentes de IA que trabalham sozinhos: visão geral em vídeo

Se você quer ver a ideia de agente coordenando trabalho na prática em outra ferramenta, tem um vídeo do canal Hora de Codar sobre o novo jeito de usar o Claude Code, com o Opus como chefe e o Haiku executando

Próximo passo: monte o fluxo de supervisão no Argon agora

Cria um documento no seu projeto com três partes: o objetivo com critério de pronto, a lista de checkpoints com entregável de cada um e as regras de interrupção desta página

Aí escolhe uma tarefa longa real (um bug chato que ninguém resolveu, por exemplo) e roda com o Gemini 4 Argon, que já está disponível pelo mesmo preço de lançamento

A checagem é simples: no fim, a entrega passou em todos os itens do "pronto quando" sem que nenhum teste tenha sido mexido?

Se passou, teu fluxo está redondo e pronto pra migrar quando o Carbon chegar aos desenvolvedores (o que ainda não tem data)

Se não passou, tu descobriu onde ajustar antes de gastar dias com o modelo mais forte =)

Até o próximo post!

Perguntas frequentes

Quais os números de cibersegurança do Gemini 4 Carbon anunciados no lançamento?

O Google divulgou 88,2% no SEC-bench Pro, 54,8% no ExploitGym e 71,0% no CWE-bench. São números do próprio lançamento, então vale tratar como dado de fornecedor até aparecer avaliação independente.

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.