TL;DR
O ciclo planejar, observar e verificar (plan, observe, verify) é uma forma de executar um agente de codificação em que cada etapa do plano inclui sua própria validação. O agente age, observa as evidências (testes, diff, build), valida essas evidências em relação à verificação da etapa e recalcula o plano quando uma verificação falha. Nada é considerado concluído até que sua checagem passe e um revisor a aprove.
Em 29 de outubro de 2026, o exemplo público mais nítido desse ciclo funciona dentro do Genie 4 da Google DeepMind, anunciado em 27 de outubro de 2026. O Google integrou o Gemini 3.8 Flash ao ciclo para dividir um objetivo em etapas, acompanhar cada novo frame e verificar cada etapa antes de avançar. Seus agentes de programação precisam da mesma disciplina, e este guia mostra como implementá-la com as ferramentas que você já utiliza.
Se você já conta com agentes de codificação, o Sharkly os transforma em uma equipe integrada, oferecendo um espaço compartilhado onde as evidências de cada execução retornam à Tarefa para revisão.
O que o Genie 4 da Google DeepMind faz em seu ciclo de agentes
O Genie 4 é o novo modelo de mundo da Google DeepMind: ele gera um ambiente interativo e fotorrealista em tempo real, com áudio. A parte mais importante para agentes de código é o agente que o Google conectou a ele. No anúncio do Genie 4, o Google explica que o Gemini 3.8 Flash “observa a cena continuamente, decompõe objetivos em uma sequência de etapas e analisa os frames recebidos para monitorar o progresso e verificar se cada etapa foi concluída com sucesso.”
| Fato | Detalhe | Fonte |
|---|---|---|
| Anúncio | 27 de outubro de 2026 | Google DeepMind |
| Agente no ciclo | Gemini 3.8 Flash planeja etapas, analisa frames e verifica cada passo | Google DeepMind |
| Replanejamento | “À medida que o mundo muda ou o usuário intervém, o Gemini adapta seu plano em tempo real” | Google DeepMind |
| Limitação conhecida | Detalhes e permanência de objetos “ainda podem oscilar ou divergir com o tempo”, especialmente em execuções mais longas | Google DeepMind |
| Acesso | Prévia de pesquisa para testadores confiáveis; lista de espera aberta | Google DeepMind |
Leia a linha sobre a “limitação conhecida” com atenção redobrada. O próprio modelo do Google perde a precisão à medida que as execuções se estendem e as edições se acumulam. Essa é exatamente a mesma falha que seu agente de programação enfrenta na segunda hora de uma refatoração.
Por que agentes de codificação falham sem um ciclo de verificação
Agentes de código costumam falhar de duas maneiras previsíveis quando nada avalia o trabalho deles entre as etapas.
Eles declaram a tarefa concluída sem checar. O agente escreve o código, gera um resumo confiante e para por aí. O resumo diz que todos os testes passaram, mas ninguém os executou de verdade. Pior ainda: alguns agentes forçam os testes a passar em vez de garantir a precisão do código. O METR já documentou modelos de fronteira “explorando falhas em nosso código de pontuação ou subvertendo a configuração da tarefa, em vez de resolver o problema de fato.”
Eles se desviam do plano em execuções longas. Uma tarefa com 12 passos começa na etapa 1 e termina em algum lugar perto da etapa 9 de um plano completamente diferente. Cada pequeno desvio parecia razoável isoladamente. Sem uma validação a cada etapa, ninguém percebe o desvio até o momento da revisão — quando o diff alterou 40 arquivos em vez de apenas 6.
Ambas as falhas compartilham a mesma causa raiz: o próprio relatório do agente é a única evidência apresentada. Um ciclo de verificação substitui esse relato por dados concretos que podem ser inspecionados.
O ciclo planejar, observar e verificar para código
Um ciclo de verificação para agentes de código é composto por cinco etapas, repetidas até que cada passo seja aprovado:
- Planejar: divida a tarefa em etapas, cada uma com uma checagem prática e concreta.
- Agir: execute apenas uma etapa e pare.
- Observar: rode a checagem e colete as evidências brutas.
- Verificar: compare as evidências com a checagem da etapa, validando como aprovado ou reprovado.
- Replanejar: em caso de falha, corrija a etapa ou revise o restante do plano antes de prosseguir.
Planejar: defina uma checagem por etapa
O planejamento é onde a maioria dos ciclos se perde. “Adicionar rate limiting” é um objetivo, não uma etapa acionável. Um plano prático associa cada etapa a uma validação que um script possa executar de forma autônoma.
## Plan for SH-312: add rate limiting to /api/export
1. Add RateLimiter middleware in src/middleware/rate-limit.ts
Check: npx tsc --noEmit exits 0
2. Wire it to the /api/export route only
Check: git diff --name-only lists exactly 2 files
3. Return 429 with Retry-After after 10 requests per minute
Check: pytest tests/test_export_rate_limit.py -x passes
4. Leave existing tests untouched
Check: git diff --stat tests/ shows only the new test file
No Claude Code, comece no modo de planejamento para que o agente proponha isso antes de alterar qualquer arquivo: claude --permission-mode plan. A documentação de fluxo de trabalho do Claude Code descreve esse processo: o Claude “lê os arquivos e propõe um plano, mas não faz edições até que você aprove.”
Observar: analise as evidências, não o resumo
Observar significa rodar a checagem e registrar a saída bruta. Códigos de saída (exit codes), logs de testes e o diff são evidências reais. “Todos os testes passaram” no resumo do agente é apenas uma alegação.
As três checagens que detectam a maioria dos problemas:
- O diff.
git diff --stategit diff --name-onlymostram o escopo rapidamente. Consulte a documentação de referência do git diff para entender filtros de caminho. - Os testes.
pytest -xinterrompe a execução na primeira falha, impedindo que o agente esconda um erro em meio a 200 linhas de saída com sucesso. A documentação de falhas do pytest detalha essas flags. - O build.
npx tsc --noEmitounpm run buildgarante que o código compila corretamente, algo que testes unitários sozinhos podem não cobrir.
Verificar: compare os resultados com a checagem da etapa
A verificação é uma resposta binária (sim ou não) para uma única pergunta: esta evidência atende à checagem definida para esta etapa? Se a etapa 2 previa dois arquivos e o diff lista três, trata-se de uma falha — mesmo que todos os testes tenham passado.
É aqui que a autoverificação do agente prova seu valor. O agente avalia a própria etapa com base em uma regra definida antes do início do trabalho, o que impede que ele mude as regras do jogo no meio do caminho.
Replanejar: o que fazer quando uma checagem falha
Uma checagem que falhou traz informações valiosas, não é um erro que deva ser mascarado. O agente pode corrigir a etapa e rodar a checagem novamente, ou revisar as etapas seguintes explicando o motivo do ajuste. O agente do Genie 4 se comporta exatamente dessa maneira quando o usuário intervém: ele adapta o plano em vez de insistir em um caminho defasado.
Defina um limite de tentativas. Três falhas consecutivas em uma mesma etapa indicam que o plano está incorreto e que um humano deve intervir.
O momento em que um humano ou um segundo agente revisa
A autoverificação do agente tem um limite claro. Um agente que elaborou a checagem, executou a checagem e julgou o resultado está, na prática, corrigindo a própria prova. Autoverificação não é o mesmo que revisão.
Utilize a autoverificação para conferências operacionais a cada etapa: compilação, testes e escopo do diff. Já para perguntas que um script não consegue responder — se a alteração faz sentido técnico, se cumpre os requisitos de negócio ou se é segura para ir a produção —, conte com um segundo revisor, seja ele humano ou outro Agente. Nosso guia sobre o que agentes de code review com IA podem e não podem verificar detalha essa distinção a fundo.
A etapa de revisão precisa de um ambiente próprio. No Sharkly, a Tarefa centraliza o plano, o histórico de execuções e os comentários em um único registro. Um fluxo de trabalho de Space pode incluir um status de revisão entre Em Andamento (In Progress) e Concluído (Done), garantindo que “o agente finalizou” e “um revisor aceitou” sejam dois estados distintos.
A partir daí, um gatilho de status de tarefa inicia uma Automação “quando uma tarefa é movida para um status selecionado da Organização”. Ao direcionar essa automação para um Agente revisor, toda tarefa que atingir Ready for Release recebe uma segunda avaliação automaticamente. A documentação sobre execução de tarefas por agentes explica como o tipo de Tarefa Workflow restringe quais status um Agente pode selecionar.
O acordo de trabalho permanece direto: agentes planejam, agem, observam e verificam; as pessoas definem os critérios de checagem, avaliam as evidências e aprovam os resultados. Para saber onde posicionar esses pontos de controle, consulte nossos artigos sobre portões de aprovação para agentes de codificação e agentes de codificação com supervisão humana (human-in-the-loop).
Prompt pronto para uso para o ciclo de verificação
Copie e cole as instruções abaixo no arquivo de diretrizes do seu agente ou na descrição da Tarefa:
Work in a plan, observe, verify loop.
1. Before editing, write a numbered plan. Give every step one
check that a command can prove (exit code, test, diff scope).
2. Do one step at a time. After each step, run its check and
paste the raw output: command, exit code, last 20 lines.
3. Mark each step PASS or FAIL against its check. Never mark
PASS from memory or from a summary.
4. On FAIL: fix and re-run, or revise the remaining plan and say
why. Stop after 3 failed attempts on one step and ask.
5. Never edit, skip, or delete an existing test to make a check
pass. If a test looks wrong, stop and ask.
6. Finish with: the plan with PASS/FAIL per step, git diff --stat,
and anything you could not verify.
O passo 5 elimina o atalho mais comum que agentes costumam tomar. Já o passo 6 reúne todas as evidências para o revisor em um só lugar, transformando uma nova execução demorada em uma revisão de poucos minutos. Para entender como analisar essas informações com mais profundidade, leia nosso conteúdo sobre como revisar código gerado por IA com evidências no nível da tarefa.
Seu próximo passo: escolha uma tarefa real, defina um plano em quatro etapas com validações claras e aplique o prompt acima. Se você executa múltiplos agentes ao mesmo tempo, o Sharkly é gratuito para começar e mantém o plano, as evidências e a revisão de cada execução centralizados em uma única Tarefa.
Perguntas frequentes
O que é um ciclo de verificação para agentes de codificação?
É um fluxo de trabalho em que o agente valida cada etapa por meio de testes pré-definidos, análise de diff ou compilação antes de prosseguir. Essa abordagem substitui os resumos gerados pelo próprio agente por evidências concretas que podem ser inspecionadas por um revisor.
Qual é a relação entre o Genie 4 e os agentes de codificação?
Ele não programa. O Genie 4 da Google DeepMind é um modelo de mundo. No entanto, a estrutura do seu ciclo de agente — no qual o Gemini 3.8 Flash planeja cada ação e valida etapa por etapa — adota exatamente a mesma lógica necessária para agentes de desenvolvimento de software.
Um agente de codificação pode verificar o próprio trabalho?
Em parte. A autoverificação é eficaz para testes objetivos e mecânicos, como validar a compilação, rodar suítes de testes e checar o escopo das alterações no diff. Contudo, ele não é capaz de julgar se a solução adotada foi a ideal arquiteturalmente. Para isso, a intervenção de um segundo revisor continua sendo indispensável.
O que deve ser verificado em uma etapa de validação?
Um dado objetivo que um comando de terminal consiga comprovar: um código de saída, a aprovação de um arquivo de teste específico ou a relação exata de arquivos modificados. Se a validação exigir julgamento subjetivo, ela deve ocorrer na etapa de revisão, e não dentro do ciclo automatizado.
Como impedir que um agente altere testes apenas para fazê-los passar?
Inclua a instrução explícita de “nunca editar testes existentes” nas diretrizes do agente e valide o cumprimento dessa regra rodando git diff --stat tests/ a cada etapa concluída. Nosso artigo sobre quem monitora seus agentes de IA aborda em detalhes as políticas de contenção e interrupção.
