Claude Code ou Antigravity: qual mostra melhor o que vai mudar no seu código antes de aplicar?

Aceitar rápido demais é o jeito mais fácil de descobrir, meia hora depois, que o agente mexeu em arquivo que você nem lembrava que existia 😅

E o susto quase nunca vem do modelo escrever besteira

Vem de você não ter olhado a proposta antes dela virar arquivo salvo no disco

Tem dois momentos onde essa decisão acontece: o plano (antes de qualquer linha ser escrita) e o diff (na hora exata em que o agente quer aplicar a mudança)

É nesses dois momentos que Claude Code e Antigravity fazem escolhas bem diferentes de interface

Bora comparar exatamente esse ponto, sem prometer benchmark que ninguém mediu?

Como o Claude Code mostra o que vai mudar antes de aplicar

No Claude Code, o freio se chama modo de permissão

A documentação oficial de permission modes lista seis: default, acceptEdits, plan, auto, dontAsk e bypassPermissions

O default aparece na interface como Manual, e é o mais conservador do grupo: ele pergunta antes de editar arquivo e antes da maioria dos comandos de shell

Ou seja, cada ação vira uma parada pra você dizer sim

O ciclo do Shift+Tab:

Você não precisa reiniciar sessão pra trocar de modo

Shift+Tab alterna no meio do caminho: a partir de auto, o primeiro toque leva pro default, e daí o ciclo segue default → acceptEdits → plan → default

Dá pra voltar ao plan mode com Shift+Tab ou prefixando o próximo prompt com /plan

E Shift+Tab de novo sai do plan mode sem aprovar plano nenhum, o que é ótimo quando você só queria pensar em voz alta 🙂

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

E o auto mode, quem revisa?

Essa é a pergunta que todo mundo faz

Nos planos Pro, Max e Team, o modo inicial embutido é o auto

Nele, quem revisa não é você: um segundo modelo (um classificador) olha as ações antes de rodarem, em vez de te mandar um prompt

Esse classificador bloqueia o que escala além do que foi pedido, o que mira infraestrutura não reconhecida, e o que parece dirigido por conteúdo hostil que o Claude leu no caminho

Aprovar tudo depois, no git diff:

O acceptEdits aceita automaticamente as edições de arquivo e os comandos comuns de filesystem (mkdir, touch, mv, cp) em caminhos do working directory ou de additionalDirectories

E a própria doc posiciona esse modo pra quem prefere revisar as mudanças DEPOIS, no editor ou via git diff, em vez de aprovar cada edição inline

Se liga que isso é uma escolha de fluxo, não de preguiça: você troca dez interrupções por uma leitura só, no fim

O plano antes do código:

No plan mode, o Claude pesquisa e propõe sem fazer: lê arquivos, roda comandos pra explorar e escreve um plano, mas não edita o código-fonte

Se você quer entender melhor esse fluxo de planejar antes de executar mudanças, ele é o coração do controle aqui

O detalhe massa vem na saída: ao sair do plan mode, o Claude apresenta o plano e pergunta como proceder, com opções que incluem "Yes, and use auto mode" e "Yes, manually approve edits"

Aprovar o plano já troca a sessão pro modo descrito na opção escolhida

Uma decisão só define o resto da conversa

E se você não quer decidir toda vez, dá pra fixar um modo padrão pelas sessões com o campo permissions.defaultMode no arquivo de settings

O diff lado a lado no VS Code:

No terminal puro o texto manda

Já na extensão do Claude Code para VS Code, quando o Claude quer editar um arquivo no modo Manual, ele mostra uma comparação lado a lado do original com a mudança proposta e pede permissão, com as opções de aceitar, rejeitar ou dizer o que fazer em vez daquilo

E tem um detalhe que eu acho topzera: se você editar o conteúdo proposto direto na diff view antes de aceitar, o Claude é avisado de que houve modificação e não assume que o arquivo ficou igual à proposta original

Ou seja, a diff view não é só leitura, é lugar de intervir

Como o Antigravity mostra o que vai mudar antes de aplicar

O Antigravity ataca o mesmo problema por outro caminho: em vez de modos de permissão no centro, ele coloca artifacts

O Google anunciou o Antigravity 2.0 no Google I/O 2026, com app de desktop autônomo para macOS, Windows e Linux, suporte a comandos de voz, nova CLI e SDK

Que artifact?

Boa pergunta, porque o nome não entrega nada 😀

Um Artifact é um entregável estruturado criado pelo agente pra cumprir a tarefa e comunicar progresso e raciocínio

A lista inclui planos em markdown (os Implementation Plans), code diffs, diagramas de arquitetura, imagens e gravações de navegador

O Implementation Plan é o artifact que o agente usa pra arquitetar as mudanças antes de mexer no código, com o detalhe técnico das revisões necessárias, feito pra ser revisado por você

E o Walkthrough é o oposto na linha do tempo: ele nasce quando o agente conclui a implementação, com um resumo conciso das mudanças feitas na conversa ativa

A política que segura o agente:

A Artifact Review Policy controla a aprovação dos planos antes das mudanças no código, e oferece duas opções

• Request Review (a recomendada): o agente sempre para e pede aprovação explícita
• Always Proceed: o agente nunca para pra revisão manual

Com a política em Request Review, o agente pausa a execução e te notifica quando gera um implementation plan ou um code diff, permitindo revisar, adicionar comentários inline e verificar o plano no workspace

Esse fluxo de revisão é customizado na aba Agent do painel de Settings

Onde o diff aparece na IDE:

Quando o agente começa a escrever código dentro de uma conversa, aparece a seção Review Changes na barra inferior do painel do agente

Clicando nela, abre um painel no editor pra percorrer todas as mudanças feitas naquela conversa

E dá pra comentar em qualquer um dos file diffs pra se comunicar com o agente, do mesmo jeito que se comenta nos artifacts

Vale lembrar que o Antigravity tem duas superfícies principais: a Editor view (IDE com Tab completions, comandos inline e agente no painel lateral) e o Agent Manager, que remove boa parte da UI de IDE pra focar nas conversas dos agentes, nos artifacts produzidos e na gestão de múltiplos agentes

E na CLI, como é?

No Antigravity CLI, o modo de execução padrão é o request-review: a CLI pausa antes de aplicar qualquer escrita em disco e renderiza um preview de diff inline com sintaxe destacada

No preview, três teclas resolvem:

• y aceita e salva o arquivo no disco
• n rejeita e mantém o arquivo como estava
• f abre uma revisão de diff em tela cheia e rolável, com 3 linhas de contexto e separadores de hunk

Shift+Tab também aparece aqui, trocando o modo de execução no meio da sessão e ciclando default → accept-edits → plan → default, com indicador do modo ativo na barra de status abaixo do campo de prompt

A configuração baseline vem de ~/.gemini/antigravity-cli/settings.json, lido na inicialização

E o comando /diff abre o Interactive Diff Viewer, um painel em tela cheia com três modos (VCS, Turn e Commit) e comentários linha a linha; os comentários são formatados e enviados ao agente como o próximo prompt

Isso é bem interessante: o seu comentário no diff vira o prompt seguinte, sem você reescrever nada

Claude Code x Antigravity: o momento da aprovação lado a lado

Uma coisa que salta da tabela: os dois oferecem plano antes e diff na hora, mas o Antigravity trata plano, diff e resumo como objetos de primeira classe (os artifacts), enquanto o Claude Code trata tudo como estado da sessão (o modo de permissão)

Qual escolher pelo tipo de tarefa (e pelo tamanho do susto que você já levou)

Refator grande, onde o plano vale mais que o diff

Quando a mudança atravessa vários arquivos, aprovar diff por diff é ruim: você aprova as partes e perde o desenho

Aqui o plan mode do Claude Code entrega o que interessa, porque ele lê, explora e escreve o plano sem tocar no source

Do outro lado, o Implementation Plan do Antigravity faz o papel equivalente, e com Request Review ligado o agente para e espera sua aprovação explícita antes de sair mudando

Correção pequena, onde perguntar atrasa mais do que protege

Trocar um texto, ajustar um if, renomear função

Se o agente parar em cada arquivo, tu passa mais tempo apertando enter do que programando

No Claude Code, é o caso do acceptEdits, que auto-aprova as edições e os comandos comuns de filesystem (mkdir, touch, mv, cp) dentro do working directory, com a revisão acontecendo depois no editor ou no git diff

No Antigravity CLI, o equivalente na mão é o accept-edits, um Shift+Tab de distância

Tome cuidado com um detalhe: revisar depois só funciona se você REALMENTE abrir o diff depois 😛

Trabalho visual dentro do editor

Se você acompanha melhor olhando do que lendo saída de terminal, o painel ganha

No Claude Code, a extensão do VS Code mostra a comparação lado a lado do original com a proposta e ainda deixa você editar ali antes de aceitar

No Antigravity, o Review Changes na barra inferior do painel do agente abre a passagem por todas as mudanças da conversa, com comentário em cada file diff

Código sensível, com pausa obrigatória em todo diff

Aqui não tem meio termo

No Claude Code, é o modo default (Manual), de preferência fixado em permissions.defaultMode pra não depender da sua memória no começo da sessão

No Antigravity, é a Artifact Review Policy em Request Review, configurada na aba Agent do Settings, e o request-review na CLI (que já é o padrão dela)

O que eu vi usando o Claude Code no dia a dia

Quando testei o Claude Code do zero num projeto novo, ele estava configurado pra perguntar antes de agir

Resultado: cada arquivo que ele ia editar virava um pedido de permissão na minha tela

Antes disso, ainda precisei conceder permissão explícita pra ele atuar naquele diretório

E eu comecei pequeno de propósito: rodei um prompt simples de inspeção da pasta, só pra confirmar que a ferramenta estava respondendo, antes de pedir qualquer alteração

O efeito de confirmar tudo é real: o desenvolvimento fica pausado, com o agente voltando a perguntar a cada nova ação que precisa executar

É chato? Um pouco

Mas é exatamente esse atrito que te faz LER o que vai mudar

No meio do caminho eu alterno os modos pela própria interface ou pelo atalho de teclado, sem sair do fluxo, e é isso que salva a sessão: aperta o freio na parte delicada, solta na parte repetitiva

Também abri a visualização do raciocínio do agente pra acompanhar como ele planejou cada funcionalidade antes de escrever o código, e isso muda muito a sensação de estar no controle

No fim da tarefa, o agente entregou um resumo do que precisou executar pra criar o projeto, e eu usei esse resumo pra conferir o que tinha sido feito

Depois pedi uma funcionalidade nova em cima do que já existia, e o ciclo de pedido e aprovação se repetiu do mesmo jeito

Comecei no terminal puro e depois passei pro editor com a extensão: a interface integrada fica bem mais amigável pra acompanhar o que o agente faz

Se você ainda está montando o ambiente, esse caminho de primeiros passos com o Claude Code ajuda a chegar aqui sem tropeço

Minha conclusão prática: em projeto de equipe ou de empresa, mantenha os modos mais pausados, que pedem confirmação antes de mexer, pra entender o que está acontecendo antes de sair mudando tudo

Quem trabalha sozinho, em vibe coding puro, pode deixar no automático e revisar depois

No vídeo abaixo eu mostro esse ciclo inteiro na prática: o pedido de permissão a cada arquivo, a troca de modo no meio da sessão e o resumo do agente no final

Veredito: quem dá mais confiança para soltar o agente

Não dá pra eleger vencedor absoluto aqui, e eu não vou fingir que dá

Minha experiência de primeira mão é só com o Claude Code; o Antigravity eu descrevo pela documentação dele, não por teste meu

Dito isso, o critério é bem claro

Se o que te dá paz é aprovação inline com contexto visual dentro do ambiente, o Antigravity organiza isso de forma bem redonda: plano, code diff e Walkthrough são artifacts explícitos, o Request Review para o agente nos dois momentos críticos, o Review Changes junta as mudanças da conversa num painel só e o comentário no diff volta pro agente como próximo prompt

Se o que te dá paz é decidir uma vez, no plano, e revisar depois no git diff, o Claude Code encaixa melhor: o plan mode propõe sem editar, a aprovação do plano já define o modo de permissão da sequência, e o acceptEdits existe justamente pra esse fluxo de revisar depois

E tem o meio termo dos planos Pro, Max e Team, onde o auto é o modo inicial e um classificador revisa as ações no seu lugar, barrando o que escala além do pedido

Gosto do desenho, mas ele muda a natureza da confiança: você não está lendo o diff, está confiando em quem lê por você

Dá pra viver bem assim em projeto pessoal… em código de cliente, eu penso duas vezes

Conclusão

O comparativo Claude Code vs Antigravity, no fim, não é sobre qual modelo escreve código melhor

É sobre onde cada um coloca o botão de sim, e quanta informação ele te dá antes de você apertar

O próximo passo é bem concreto e leva dois minutos: escolha o modo padrão ANTES da próxima sessão

No Claude Code, fixe isso em permissions.defaultMode no arquivo de settings, em vez de descobrir o modo ativo no susto

No Antigravity, deixe a Artifact Review Policy em Request Review pela aba Agent do Settings, e lembre que a CLI já nasce em request-review

E aí, a parte que nenhuma configuração faz por você: leia o diff antes de dizer sim 🙂

Qualquer painel bonito vira enfeite se a gente aperta y no automático

até o próximo post!