A primeira vez que abri o Antigravity fiz o que você provavelmente já fez: tratei-o como um Cursor com um logotipo diferente. Perguntei algo a ele, observei-o escrever o código, corrigi, repeti. Funcionou. Mas eu não estava ganhando nada com isso que qualquer outro editor de IA já não tivesse me dado.
A mudança ocorreu quando parei de pensar no Antigravity como um editor e comecei a pensar nele como o que o Google deseja que seja: uma camada de coordenação de agentes. Não é um detalhe de marketing. Isso muda completamente o tipo de trabalho que você delega e, acima de tudo, quanto do seu julgamento você precisa colocar por escrito antes de delegá-lo.
Depois de várias semanas usando-o em projetos reais (alguns da Venturest, outros de testes), esses são os casos de uso que realmente movem o ponteiro, como configurar as regras para que o agente trabalhe a seu favor e o ecossistema de habilidades e fluxos de trabalho que quase ninguém está aproveitando ainda.
O que é antigravidade (e por que a distinção é importante)
Antigravity é a plataforma de desenvolvimento de agentes do Google, lançada em novembro de 2025 junto com o Gemini 3. Tecnicamente, o editor é um fork do VS Code, então o ambiente será familiar desde o primeiro minuto. Mas permanecer com "é um IDE" perde o ponto importante.
A plataforma possui duas superfícies. O View Editor é o IDE usual com IA no topo: preenchimento automático, comandos de linguagem natural, tudo o que você já sabe. O Manager Surface é onde está o salto: uma interface dedicada para lançar, orquestrar e observar vários agentes trabalhando em paralelo, de forma assíncrona, em diferentes espaços de trabalho.
Essa é a ideia subjacente. Você vai de “conversar com a IA em uma janela” para “atribuir missões a uma equipe e revisar os resultados”. E como sabe qualquer pessoa que já gerenciou uma equipe de engenharia, isso introduz um problema antigo com uma cara nova: se você não codifica seus padrões, cada agente improvisa os seus.
Uma observação sobre os modelos: o Antigravity é gratuito para indivíduos e permite que você escolha um modelo, com Gemini 3.1 Pro como base, mas também suporte para Gemini 3.5 Flash, Claude Sonnet 4.6 e modelos abertos. A opcionalidade do modelo é mais útil do que parece: nem todos têm o mesmo desempenho dependendo da tarefa.
Os casos de uso que realmente mudam seu fluxo
1. Delegue tarefas de ponta a ponta, não fragmentos
O erro mais comum é ficar pedindo bits: “escreva-me esta função”, “corrija este bug”. A antigravidade foi projetada para missões completas. O agente pode planejar e executar uma tarefa passando pelo editor, terminal e navegador: ele escreve o código para um recurso, inicia o aplicativo a partir do terminal, abre o navegador para testar se o componente funciona e o verifica. Tudo sem você estar em cada passo.
Minha regra mental: se a tarefa se enquadra em uma frase orientada a um objetivo (“implementar o login por e-mail e verificar se todo o fluxo funciona”), ela é candidata à delegação. Se você precisar microgerenciar cada decisão, é melhor usar a Visualização do Editor.
2. Agentes paralelos: a equipe que não interrompe
O Manager Surface permite iniciar vários agentes em diferentes espaços de trabalho ao mesmo tempo. Foi aqui que parei de pensar em “uma conversa” e comecei a pensar em “tarefas simultâneas”.
O padrão que mais me serviu: um agente "júnior" lidando com refatoradores tediosos ou atualizando dependências em segundo plano, enquanto outro agente trabalha comigo em lógica complexa. Você não interrompe seu fluxo principal para atender ao que é chato. É claro (e digo isso por experiência própria), o suporte à ramificação do Git ainda não está maduro. Se você colocar vários agentes para tocar no mesmo grande repositório sem disciplina, você estará apostando. Espaços de trabalho separados e commits frequentes não são opcionais aqui.
3. Browser-in-the-loop: a verdadeira verificação
Esta é provavelmente a característica que mais diferencia a Antigravidade. O agente configura uma instância real do Chrome (o subagente do navegador) e usa o aplicativo enquanto o constrói: pressionando botões, preenchendo formulários, fazendo capturas de tela. Se algo não funcionar, ele vê, depura e corrige sem você abrir o DevTools.
Feche o ciclo entre escrever o código e validá-lo. Para desenvolvimento web, só vale a pena tentar.
4. Artefatos e orientações: revise sem ler registros
Em vez de percorrer os registros de chamadas de ferramentas, os agentes produzem artefatos: resultados legíveis, como planos de implantação, listas de tarefas, capturas de tela e gravações de sessões do navegador. E ao finalizar, eles geram um Walkthrough: um resumo do que mudou, quais arquivos foram tocados e por que determinados padrões foram escolhidos, com capturas de tela do app funcionando.
Parece um detalhe estético. Não é. É o que torna viável a revisão do trabalho de um agente. Você tem uma prova visual de que o recurso funciona antes de entrar na sintaxe. Para alguém que revisa o código de uma equipe – humano ou agente – isso é ouro.
Uma última dica de fluxo: use o modo Plano para tarefas complexas (gere um plano que você aprova antes de agir) e o modo Rápido para soluções rápidas. Aprovar o plano antes do lançamento do agente é a diferença entre corrigir o rumo em um minuto ou limpar a bagunça em três horas.
As regras: é aqui que você codifica seus critérios
Os modelos antigravidade são generalistas poderosos, mas não conhecem o seu projeto ou os padrões da sua equipe. Regras são o mecanismo para corrigir isso. E compreender sua hierarquia é o que separa configurá-lo bem de brigar com um agente que fica tomando decisões que você não deseja.
- Regras do sistema: diretrizes imutáveis do Google DeepMind. Eles definem identidade, protocolos de segurança e recursos básicos. Você não toca neles.
- Regras globais: suas preferências pessoais, aplicadas a todos os projetos. Eles ficam em seu diretório inicial, em
~/.gemini/GEMINI.md(e~/.gemini/AGENTS.mdpara o padrão de ferramentas cruzadas). Ideal para coisas como "sempre use TypeScript" ou a linguagem das respostas. - Regras do espaço de trabalho: os padrões do projeto atual. Eles ficam dentro do repositório, em
GEMINI.md,AGENTS.mdou na pasta.agent/rules/. Aqui você coloca o comando: "usamos Next.js App Router", convenções de commit, estrutura de pastas.
O interessante da última onda é o AGENTS.md, um padrão de ferramentas cruzadas compartilhado por Antigravity, Claude, Cursor e outros. A vantagem é real: você escreve suas regras uma vez e as reutiliza entre ferramentas, em vez de manter um arquivo diferente para cada fornecedor. Se você está investindo tempo nisso, opte por AGENTS.md em vez do formato proprietário.
Configurá-los é simples: no Agent Manager, os três pontos (•••) no canto superior direito → Personalizações → aba Regras → + Global ou + Workspace. E são escritos em linguagem natural, sem sintaxe estranha. Um exemplo real de regra de estilo:
# Regra de estilo Python
Sempre use os padrões PEP 8.
Ao refatorar, assume que formatamos com `preto`.
Mantenha dependências de bibliotecas de código aberto e gratuitas.Habilidades e fluxos de trabalho: o resto do ecossistema
As regras não são a única coisa. Existem mais duas peças e a confusão entre elas é comum. A distinção que funciona melhor para mim:
Uma regra é uma restrição básica: como o agente se comporta e como ele se adapta à sua pilha e ao seu estilo.
Uma habilidade é um pacote reutilizável de conhecimento que ensina ao agente como resolver uma tarefa específica. É uma pasta com um arquivo SKILL.md (e opcionalmente scripts/, examples/, resources/). O truque está na divulgação progressiva: a habilidade dorme até que o agente, lendo apenas sua descrição, decida que ela é relevante para o que você perguntou. Dessa forma, você não sobrecarrega o contexto com instruções irrelevantes.
O campo mais importante de uma habilidade é a descrição: escreva-a na terceira pessoa e com palavras-chave claras, pois é literalmente o que o agente utiliza para decidir quando ativá-la. Algo como: "Gere testes de unidade para código Python seguindo convenções pytest."
As habilidades têm escopo global (atualmente em ~/.gemini/config/skills/) ou escopo de espaço de trabalho (<project>/.agents/skills/). E seguem o padrão aberto Agent Skills, que outras ferramentas também compartilham: você escreve a habilidade uma vez e a usa entre os chicotes, sem reescrever a mesma capacidade para cada provedor.
Um fluxo de trabalho é o orquestrador. Ele é invocado como um comando de barra (/deploy, /startcycle) e orienta o agente através de um plano bem estruturado de várias etapas. É o que permite automatizar tarefas repetitivas sem perder a precisão – encadeando, por exemplo, “revisar código → gerar testes → auditar → implantar” em um único comando.
Regras, habilidades, fluxo de trabalho. Restrição, conhecimento, orquestração. Ao combinar os três, você deixa de ter um programador genérico e passa a ter um especialista que segue suas regras, sabe fazer suas tarefas e executa seus processos.
Boas práticas (algumas aprendidas através de tropeços)
O que eu gostaria que alguém tivesse me contado antes:
- Instruções focadas e orientadas para objetivos. Uma missão clara por tarefa. Não misture coisas não relacionadas no mesmo prompt: você confunde o agente e piora o plano.
- Uma pasta ou espaço de trabalho por tarefa. Isola contextos. É a melhor defesa contra um agente atrapalhar o trabalho de outro.
- Revise o plano antes de aprovar. Para tarefas grandes, o modo Plano não é burocracia: é o seu ponto de controle.
- Confirmações incrementais a partir do minuto zero. Faça uma confirmação inicial antes do primeiro prompt e deixe o agente confirmar em etapas. Se você bagunçar uma estrutura de arquivo ou quebrar uma dependência, a reversão será questão de segundos. Isso, com a ramificação ainda imatura, não é negociável.
- Tenha cuidado com a injeção de prompt. É um risco real de IDEs de agente: um invasor pode ocultar instruções em um README ou em comentários para que o agente possa vazar dados. Verifique os comentários gerados automaticamente em busca de URLs de saída suspeitos e desative a renderização de imagem Markdown nos painéis de visualização, se não precisar dela.
- Mantenha as habilidades atômicas e bem nomeadas. É tentador criar uma mega-habilidade que faça tudo. Não faça isso. As competências proliferam rapidamente e, se se sobrepuserem, o modelo faz escolhas erradas. O escopo e o específico sempre superam um blob que faz tudo.
A mudança de fundo
Há alguns meses escrevi que você não precisa de sua própria IA, você precisa usá-la bem. A antigravidade é o estudo de caso perfeito dessa ideia.
A ferramenta é gratuita e poderosa. Mas seu valor não está em escrever código mais rápido (outros já fizeram isso). É que te obriga a deixar explícito o que normalmente só vive na sua cabeça: seus padrões, seu jeito de fazer as coisas, seus processos. Regras, habilidades e fluxos de trabalho não são recursos de configuração. São o exercício de codificar seus critérios para que uma equipe de agentes os siga sem você na sua frente.
E é aí que reside o que é incômodo e interessante ao mesmo tempo: a vantagem competitiva de quem programa com agentes não é mais a rapidez com que digitam. É o quão bem você sabe delegar. Que é, aliás, exatamente a mesma habilidade que separa um bom líder de tecnologia de um bom desenvolvedor sênior.
Você já deixou seus critérios por escrito ou continua corrigindo o agente um por um?
