Como dividir uma tarefa de dias em marcos verificáveis antes de entregar ao Gemini 4 Carbon

Fala aí, beleza? O Google soltou um modelo que fica dias seguidos na mesma tarefa, e isso muda o jeito de pedir trabalho pra IA 🙂

A resposta curta é esta: antes de entregar uma tarefa de dias ao Gemini 4 Carbon, escreva o objetivo final, divida esse objetivo em marcos com um entregável e um critério de aceite cada, e defina em que ponto você confere o trabalho

O Google DeepMind anunciou o Carbon em 28/10/2026 como modelo de fronteira para problemas de engenharia difíceis e de longo horizonte, segundo o anúncio oficial do Google

Em uso interno, ele trabalhou por dias seguidos em tarefas de várias etapas, então o plano que você escreve ANTES é o que decide se você mantém o controle da execução ou só assiste de longe

Se o conceito de raciocínio de longo horizonte ainda é novo pra você, vale dar uma olhada nele antes de seguir

O que você precisa antes de planejar a tarefa para o Gemini 4 Carbon

Você precisa de três coisas: uma tarefa real com objetivo claro, acesso ao repositório ou sistema envolvido e uma forma de verificar resultados (testes, reprodução do bug, revisão de código)

Acesso ao modelo NÃO está na lista, e isso é proposital

O Gemini 4 Carbon já está disponível?

Ainda não para o público geral

O acesso inicial foi liberado para defensores de cibersegurança selecionados, por meio do Fairwind Program do Google

O Carbon não está no app Gemini, no AI Mode da Busca nem na Gemini API pública, como confirmou o 9to5Google

O Google promete ampliar o acesso para desenvolvedores, empresas e consumidores "o quanto antes", mas sem data definida

Aí vem a parte boa: o método de marcos não depende de acesso nenhum, dá pra preparar o plano hoje e deixar ele pronto pra quando a porta abrir

Tome cuidado com tutoriais que já mostram endpoint, comando ou ID de modelo do Carbon: até agora não existe nada disso confirmado publicamente

Quanto custa rodar uma tarefa longa no Carbon?

Preço importa MUITO quando a tarefa dura dias, porque o volume de tokens cresce junto

Se liga: o Google já divulgou a tabela de preço da API, mas isso NÃO significa que a API pública esteja aberta, como vimos acima, é o valor anunciado pra quando você tiver acesso

No período promocional, são US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída, com 95% de desconto em tokens de entrada em cache

Depois da promoção, o valor sobe para US$ 4 por milhão de entrada e US$ 20 por milhão de saída, ainda sem data para o reajuste, segundo a VentureBeat

Marco bem definido também ajuda aqui: cada etapa com entregável claro evita que o modelo gaste tokens rodando em círculo

Passo a passo: como transformar um objetivo amplo em marcos verificáveis

A ideia é sair de "resolve isso aí" para um plano que qualquer pessoa de fora consegue auditar

Os exemplos abaixo são planos em texto, didáticos, nada de chamada de API (até porque não existe API pública confirmada pro Carbon)

1. Escreva o objetivo final como resultado observável

Por que começar aqui? Porque um modelo que se mantém dias na tarefa precisa saber exatamente onde ela termina

O objetivo bom descreve o estado do sistema quando tudo acabar, não a vontade de melhorar

O exemplo abaixo se inspira nos casos internos citados pelo Google, como achar a causa raiz de bugs sutis e corrigi-los em codebases grandes:

## Objetivo final
O bug intermitente de timeout no serviço de pagamentos
tem a causa raiz identificada, corrigida e coberta
por teste de regressão que passa no CI

O erro comum deste passo: objetivo vago tipo "melhorar o sistema" ou "deixar o código mais estável", que não tem como ser aprovado nem reprovado

2. Quebre o objetivo em marcos sequenciais, cada um com um entregável

Marco é um ponto de chegada com algo palpável na mão, um arquivo, um teste, um relatório

Se você já tem o hábito de dividir a tarefa antes do pedido em outras ferramentas, a lógica é parecida, só que aqui a escala é de dias

## Marcos
- M1: reprodução do bug (script ou teste que falha de forma consistente)
- M2: hipótese de causa raiz com evidência (logs, trecho de código, trace)
- M3: correção aplicada (diff revisável)
- M4: teste de regressão (passa com a correção, falha sem ela)

O erro comum deste passo: escrever um marco que é atividade e não entregável, tipo "M1: investigar o bug"

Investigar não termina nunca, né? Já "script que reproduz o bug" termina quando o script existe e falha do jeito certo

3. Defina um critério de aceite binário para cada marco

Critério binário é aquele que só tem duas respostas: passou ou não passou

E ele precisa dizer QUEM confere e COMO confere

## Critérios de aceite
- M1: rodar o script 10 vezes reproduz o timeout em todas.
  Quem confere: dev responsável pelo serviço
- M2: a evidência aponta para uma linha ou componente específico.
  Quem confere: revisor técnico lendo o relatório
- M3: o diff altera só o que a hipótese de M2 justifica.
  Quem confere: code review
- M4: o teste falha no commit antigo e passa no novo.
  Quem confere: pipeline de CI

O número de execuções aí é escolha sua, é só exemplo de critério concreto

O erro comum deste passo: critério subjetivo como "código limpo" ou "correção satisfatória", que vira discussão em vez de checagem

4. Alinhe os marcos ao modo de trabalho do modelo

A cobertura do lançamento no MarkTechPost descreve o Carbon trabalhando assim: entende o objetivo, divide em subtarefas, usa ferramentas ou código, verifica o trabalho intermediário, se recupera de abordagens que falharam e segue até concluir

Daí sai uma pista útil: os seus pontos de checagem humana devem cair justamente nas verificações intermediárias, ou seja, na entrega de cada marco

## Pontos de checagem
- Depois de M1: humano confirma a reprodução antes de qualquer hipótese
- Depois de M2: humano aprova a hipótese antes de qualquer alteração no código
- Depois de M4: humano valida o CI antes do merge

O erro comum deste passo: só conferir no fim, depois de dias de execução, quando uma hipótese errada lá no M2 já contaminou tudo que veio depois

5. Preveja becos sem saída com condição de parada e de reporte

O Google descreve o Carbon contornando becos sem saída nas tarefas internas, o que é ótimo, mas você precisa saber QUANDO ele trocou de rota

Por isso cada marco ganha uma condição de parada: o ponto em que o modelo deve parar e te reportar, em vez de seguir tentando

## Condições de parada
- M1: se não reproduzir após 3 abordagens diferentes, parar e reportar
  o que foi tentado e o que foi observado
- M2: se surgirem duas hipóteses com evidência equivalente, parar e
  apresentar as duas, sem escolher sozinho
- M3: se a correção exigir mexer fora do componente apontado em M2,
  parar e pedir aprovação

O erro comum deste passo: não saber quando ele desistiu de uma rota, e descobrir só no relatório final que o plano original foi abandonado lá no começo

6. Monte o documento final do plano

Junte tudo numa tabela só, com uma linha por marco, e use esse documento como o pedido que você entrega ao modelo:

Marco	Entregável	Critério de aceite	Ponto de checagem	Condição de parada
M1	Script que reproduz o bug	Reproduz em todas as execuções definidas	Dev do serviço confirma	3 abordagens sem reproduzir
M2	Relatório de causa raiz com evidência	Aponta componente específico	Revisor aprova antes de editar código	Duas hipóteses equivalentes
M3	Diff da correção	Altera só o que M2 justifica	Code review	Correção sai do escopo de M2
M4	Teste de regressão	Falha no commit antigo, passa no novo	CI verde + validação humana	Teste não diferencia os commits

Checagem final: entregue o plano a alguém de fora do projeto e pergunte se ele consegue aprovar ou reprovar cada marco sem ambiguidade

Se a pessoa travar em algum marco, é ali que o plano ainda está vago 😉

Que tipo de tarefa de longo horizonte vale dividir assim

Vale para as tarefas que o próprio Google citou como alvo do Carbon: causa raiz de bugs sutis em codebases grandes, correções em sistemas de baixo nível e trabalho de cibersegurança

Fora disso, não tem evidência publicada, então nada de inventar use case

Bugs sutis em codebases grandes

É o exemplo do passo a passo, e o primeiro marco quase sempre é a reprodução

Sem um teste que falha de forma consistente, nenhuma correção pode ser aprovada com segurança

Correções em sistemas de baixo nível

Aqui o primeiro marco verificável costuma ser isolar o comportamento num cenário mínimo, com entrada e saída esperada documentadas

Como um erro nessa camada pode derrubar muita coisa acima, o ponto de checagem antes de alterar código pesa ainda mais

Trabalho de cibersegurança

É justamente o público que tem acesso hoje, via Fairwind Program

Um primeiro marco verificável seria um relatório da vulnerabilidade com o trecho afetado e o caminho de exploração descrito, que um analista confirma antes de qualquer correção

Como contexto, o Google divulgou estes resultados em benchmarks de cibersegurança:

• SEC-bench Pro: 88,2%
• ExploitGym: 54,8%
• CWE-bench: 71,0%

São números divulgados pelo próprio Google, não garantia de desempenho na sua tarefa, e é exatamente por isso que o critério de aceite por marco continua sendo seu

Vídeo: o Gemini 4 Argon, modelo anunciado antes do Carbon

O Carbon foi anunciado duas semanas depois do Gemini 4 Argon, e no canal tem um vídeo sobre o lançamento do Argon rodando projetos pesados no Gemini CLI

Bora ver:

Próximo passo: prepare o plano agora, antes do acesso abrir

Escolha hoje uma tarefa real do seu time, daquelas que ninguém quer pegar porque leva dias, e escreva o plano usando a tabela do passo 6

Depois, entregue esse plano a um revisor humano e peça pra ele aprovar ou reprovar cada marco sem te perguntar nada

Se ele conseguir, o plano está pronto para quando o acesso ao Carbon for ampliado (o Google ainda não deu data)

E se não conseguir, melhor descobrir agora do que no terceiro dia de execução haha

Até o próximo post!

Perguntas frequentes

Esse método de marcos serve só para o Gemini 4 Carbon?

A lógica de quebrar objetivo em marcos com entregável e critério de aceite funciona pra qualquer tarefa longa entregue a um agente de IA, não é exclusiva do Carbon. A diferença aqui é a escala: como o Carbon foi descrito rodando dias numa mesma tarefa, cada marco precisa ser grande o suficiente pra justificar uma checagem, sem virar microgerenciamento.

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.