Google Antigravity: quando a IDE deixa de ser o centro do desenvolvimento

💡 E se, em vez de trabalhar dentro de uma IDE com ajuda da IA, você passasse a administrar agentes que trabalham por você?

TL;DR  —  Resumo rápido do post:

• O Antigravity inverte o papel: em vez de programar numa IDE com ajuda da IA, você administra agentes que planejam, executam e verificam tarefas por você.
• O Agent Manager orquestra vários agentes em paralelo, e a revisão acontece via Artifacts — planos, screenshots, gravações do navegador.
• Spec-Driven Development: você escreve a especificação; os agentes geram o código e os testes validam contra ela. Bug? Corrige a spec, não o código.
• Skills dão conhecimento reutilizável aos agentes; MCP os conecta a ferramentas reais — banco, deploy, issues.
• O plano é aprovado antes de tocar no código, mas autonomia exige guardrails: permissões mínimas, Artifacts revisados e tarefas pequenas.

~ 8 min de leitura · 1470 palavras

Essa pergunta me acompanhou desde que comecei a usar o Google Antigravity. A plataforma foi anunciada em novembro de 2025 como uma evolução do desenvolvimento assistido por IA, e a proposta vai além de colocar um chat ao lado do editor. O desenvolvedor começa a trabalhar com agentes capazes de analisar o projeto, criar planos, executar tarefas e utilizar ferramentas. Em maio de 2026, a versão 2.0 deu mais um passo: o Antigravity virou um aplicativo desktop independente, sem IDE, focado inteiramente em administrar agentes.

Neste post, compartilho o que aprendi testando o Antigravity e refletindo sobre o que essa mudança significa para quem desenvolve software todos os dias.

O Antigravity é uma plataforma de desenvolvimento agêntica do Google. Em vez de um editor de código com um assistente embutido, é um ambiente onde agentes autônomos planejam, executam e verificam tarefas complexas sozinhos. O lema oficial deixa isso claro: as ferramentas de ontem ajudavam você a escrever código mais rápido; as de amanhã precisam ajudar você a orquestrar.

Na prática, você descreve o que quer e o agente cuida do resto: lê o projeto, monta um plano, escreve o código, roda comandos no terminal, abre o navegador para testar a aplicação e volta com o resultado. O trabalho síncrono — você digitando linha por linha — continua existindo, mas deixa de ser o modo principal.

Aqui vale esclarecer uma confusão comum. Hoje existem dois produtos:

– Antigravity IDE: o editor completo, com autocomplete, comandos inline e um agente integrado. É a experiência que você já conhece, turbinada. – Antigravity 2.0: o aplicativo desktop independente, sem IDE, onde você conversa com agentes de forma síncrona e assíncrona. É aqui que a visão agêntica aparece completa.

Os dois convivem na sua máquina, e o Google já avisou que o Agent Manager será removido da IDE em uma versão futura, transformando-a em uma IDE puramente assistida por IA. A recomendação oficial é usar os dois em paralelo: o 2.0 para orquestrar agentes e a IDE que você preferir para o trabalho manual.

O coração da mudança é o Agent Manager. É uma superfície dedicada onde você cria, orquestra e observa vários agentes trabalhando ao mesmo tempo, cada um no seu espaço.

O conceito que mais me marcou é o de Artifacts: em vez de rolar quilômetros de log de ferramentas, o agente entrega tarefas, planos de implementação, screenshots e gravações do navegador. Você revisa o resultado de forma visual, deixa comentários direto no Artifact — como quem comenta um documento — e o agente ajusta o rumo sem parar a execução. Verificação vira revisão, não auditoria.

Na versão 2.0, o Agent Manager ganhou recursos que expandem o conceito: Scheduled Tasks, que permitem agendar agentes para rodar em horários fixos (um cron para agentes), subagentes dinâmicos, que o agente principal cria conforme a necessidade para não poluir o próprio contexto, e comandos como `/goal` (executa até terminar, sem perguntar nada no meio do caminho).

O Antigravity empurra o mercado para o Spec-Driven Development: desenvolvimento orientado a especificações. Em vez do ciclo “prompt e correção”, você escreve primeiro um documento estruturado com requisitos, arquitetura e critérios de teste. Os agentes consomem essa especificação para gerar código, e os testes validam o resultado contra ela.

O ciclo tem cinco etapas: levantamento de requisitos, desenho da arquitetura, especificação (sistema e testes), geração de código pelos agentes e validação automatizada. As três primeiras continuam sendo trabalho humano; as duas últimas, dos agentes. E, como gerar código ficou rápido, o gargalo volta a ser a qualidade da especificação — não a velocidade de digitação.

Quando um bug aparece, você corrige a especificação e dispara o ciclo de novo, em vez de mexer direto no código. É o rigor do planejamento clássico, mas com automação em vez de burocracia.

Skills são o mecanismo do Antigravity para dar conhecimento reutilizável aos agentes. Uma skill é uma pasta com um arquivo `SKILL.md` — instruções, boas práticas, scripts e templates — que o agente carrega quando o contexto pede.

O funcionamento segue o padrão de progressive disclosure: na abertura da conversa, o agente vê só os nomes e descrições das skills disponíveis. Quando uma é relevante, ele lê o conteúdo completo e segue as instruções. Quem escreve a skill controla o que o agente vai fazer em determinado tipo de tarefa.

O detalhe que acho mais elegante: cada skill definida na linha de comando vira automaticamente um comando de barra. Criou uma skill chamada `deploy-staging`? A partir daí, `/deploy-staging` está disponível no prompt. Conhecimento vira comando.

O Antigravity adota o Model Context Protocol (MCP), o padrão aberto que conecta agentes a ferramentas externas: bancos de dados, APIs, serviços de deploy, ferramentas de gestão. Em vez de colar schema de banco ou log de build no prompt, o agente busca o contexto vivo direto da fonte.

Exemplos práticos da documentação: ao escrever SQL, o agente inspeciona o schema real do Supabase ou Neon; ao depurar um deploy, ele puxa os logs recentes do Netlify; ao terminar uma tarefa, ele abre uma issue no Linear sozinho. Existem MCP Store nos dois produtos — você navega, escolhe e instala servidores prontos — e é possível configurar servidores customizados por arquivo, global ou por projeto.

Para mim, MCP é onde o agente deixa de ser um assistente de código e passa a ser um membro do time com acesso às ferramentas do time.

Aqui está a mudança mais profunda no dia a dia. No Agent Manager, você pode ter vários agentes simultâneos: um refatorando a lógica de autenticação, outro escrevendo testes para uma API nova, um terceiro pesquisando uma biblioteca em segundo plano.

Cada agente tem seu contexto isolado, seus Artifacts e seu histórico. Você alterna entre eles como quem alterna entre abas de revisão de código. Tarefas longas — reproduzir um bug, gerar um caso de teste, implementar a correção — podem rodar em background enquanto você cuida de outra coisa.

Na versão 2.0, o conceito de workspace (um agente por repositório) foi substituído por projetos, que podem abranger várias pastas com permissões próprias. Isso deixa os agentes enxergarem mais contexto — e exige que você pense em guardrails com mais cuidado.

Um dos comportamentos que mais me convenceu no Antigravity é o planejamento obrigatório. Antes de tocar em qualquer linha, o agente converte o pedido em um plano de implementação e pede sua aprovação. Você revisa, ajusta a direção, comenta — e só depois o trabalho começa.

Durante a execução, o agente continua transparente: quando precisa rodar um comando no terminal, ele pede permissão. Quando termina uma parte, ele mostra o resultado nos Artifacts. O controle não desapareceu; ele mudou de nível. Você não aprova mais cada chamada de ferramenta, mas aprova cada plano — e é aí que o valor do seu julgamento fica concentrado.

Autonomia tem preço, e é importante ser honesto sobre isso:

– O plano não é garantia. Um agente pode aprovar um plano coerente e executar mal. Os Artifacts ajudam a verificar, mas exigem que você olhe de verdade — não é revisão de tapa no olho. – Contexto é o gargalo. Tarefa grande demais enche a janela de contexto e o agente começa a alucinar. As boas práticas do próprio Google recomendam quebrar o trabalho em módulos pequenos e bem definidos. – Permissões precisam de config. Com agentes acessando terminal, navegador e MCP servers, quem não configura o Review Policy e as permissões por projeto está delegando sem supervisão. A configuração padrão manual existe por um motivo. – Confiança calibrada vem com o tempo. Comecei delegando tarefas pequenas e observando o comportamento. Só depois passei a soltar trabalhos mais longos. Esse ritual importa.

O antídoto para todos esses riscos é o mesmo: especificações claras, Artifacts revisados e permissões mínimas. Autonomia sem verificação é só velocidade de cometer erros.

🧠 Talvez o futuro não seja programar mais rápido. Talvez seja aprender a administrar quem programa.

Quando a IA era um autocomplete, a habilidade importante era digitar bem e revisar rápido. Com agentes que planejam, executam e testam sozinhos, a habilidade que sobe de valor é outra: descrever problemas com precisão, desenhar especificações que a máquina consiga executar e revisar trabalho que você não fez.

O Antigravity é a materialização mais clara que já vi dessa transição. Não é uma ferramenta para escrever código — é uma ferramenta para gerenciar o trabalho de quem o escreve. E isso muda a profissão muito mais do que qualquer autocomplete mudou.

E você, já testou delegar um projeto inteiro para agentes? Conta aqui nos comentários como foi.

— Fontes: Google Developers Blog (anúncio de nov/2025), Antigravity Blog (versão 2.0, mai/2026), documentação oficial de Skills e MCP, e codelabs oficiais de Spec-Driven Development.

💡 E se, em vez de trabalhar dentro de uma IDE com ajuda da IA, você passasse a administrar agentes que trabalham por você?

Essa pergunta me acompanhou desde que comecei a usar o Google Antigravity. A plataforma foi anunciada em novembro de 2025 como uma evolução do desenvolvimento assistido por IA, e a proposta vai além de colocar um chat ao lado do editor. O desenvolvedor começa a trabalhar com agentes capazes de analisar o projeto, criar planos, executar tarefas e utilizar ferramentas. Em maio de 2026, a versão 2.0 deu mais um passo: o Antigravity virou um aplicativo desktop independente, sem IDE, focado inteiramente em administrar agentes.

Neste post, compartilho o que aprendi testando o Antigravity e refletindo sobre o que essa mudança significa para quem desenvolve software todos os dias.

O que é o Google Antigravity

O Antigravity é uma plataforma de desenvolvimento agêntica do Google. Em vez de um editor de código com um assistente embutido, é um ambiente onde agentes autônomos planejam, executam e verificam tarefas complexas sozinhos. O lema oficial deixa isso claro: as ferramentas de ontem ajudavam você a escrever código mais rápido; as de amanhã precisam ajudar você a orquestrar.

Na prática, você descreve o que quer e o agente cuida do resto: lê o projeto, monta um plano, escreve o código, roda comandos no terminal, abre o navegador para testar a aplicação e volta com o resultado. O trabalho síncrono — você digitando linha por linha — continua existindo, mas deixa de ser o modo principal.

Antigravity e Antigravity IDE

Aqui vale esclarecer uma confusão comum. Hoje existem dois produtos:

• Antigravity IDE: o editor completo, com autocomplete, comandos inline e um agente integrado. É a experiência que você já conhece, turbinada.
• Antigravity 2.0: o aplicativo desktop independente, sem IDE, onde você conversa com agentes de forma síncrona e assíncrona. É aqui que a visão agêntica aparece completa.

Os dois convivem na sua máquina, e o Google já avisou que o Agent Manager será removido da IDE em uma versão futura, transformando-a em uma IDE puramente assistida por IA. A recomendação oficial é usar os dois em paralelo: o 2.0 para orquestrar agentes e a IDE que você preferir para o trabalho manual.

Agent Manager

O coração da mudança é o Agent Manager. É uma superfície dedicada onde você cria, orquestra e observa vários agentes trabalhando ao mesmo tempo, cada um no seu espaço.

O conceito que mais me marcou é o de Artifacts: em vez de rolar quilômetros de log de ferramentas, o agente entrega tarefas, planos de implementação, screenshots e gravações do navegador. Você revisa o resultado de forma visual, deixa comentários direto no Artifact — como quem comenta um documento — e o agente ajusta o rumo sem parar a execução. Verificação vira revisão, não auditoria.

Na versão 2.0, o Agent Manager ganhou recursos que expandem o conceito: Scheduled Tasks, que permitem agendar agentes para rodar em horários fixos (um cron para agentes), subagentes dinâmicos, que o agente principal cria conforme a necessidade para não poluir o próprio contexto, e comandos como `/goal` (executa até terminar, sem perguntar nada no meio do caminho).

Desenvolvimento orientado a especificações

O Antigravity empurra o mercado para o Spec-Driven Development: desenvolvimento orientado a especificações. Em vez do ciclo “prompt e correção”, você escreve primeiro um documento estruturado com requisitos, arquitetura e critérios de teste. Os agentes consomem essa especificação para gerar código, e os testes validam o resultado contra ela.

O ciclo tem cinco etapas: levantamento de requisitos, desenho da arquitetura, especificação (sistema e testes), geração de código pelos agentes e validação automatizada. As três primeiras continuam sendo trabalho humano; as duas últimas, dos agentes. E, como gerar código ficou rápido, o gargalo volta a ser a qualidade da especificação — não a velocidade de digitação.

Quando um bug aparece, você corrige a especificação e dispara o ciclo de novo, em vez de mexer direto no código. É o rigor do planejamento clássico, mas com automação em vez de burocracia.

Uso de Skills

Skills são o mecanismo do Antigravity para dar conhecimento reutilizável aos agentes. Uma skill é uma pasta com um arquivo `SKILL.md` — instruções, boas práticas, scripts e templates — que o agente carrega quando o contexto pede.

O funcionamento segue o padrão de progressive disclosure: na abertura da conversa, o agente vê só os nomes e descrições das skills disponíveis. Quando uma é relevante, ele lê o conteúdo completo e segue as instruções. Quem escreve a skill controla o que o agente vai fazer em determinado tipo de tarefa.

O detalhe que acho mais elegante: cada skill definida na linha de comando vira automaticamente um comando de barra. Criou uma skill chamada `deploy-staging`? A partir daí, `/deploy-staging` está disponível no prompt. Conhecimento vira comando.

Integração com MCP

O Antigravity adota o Model Context Protocol (MCP), o padrão aberto que conecta agentes a ferramentas externas: bancos de dados, APIs, serviços de deploy, ferramentas de gestão. Em vez de colar schema de banco ou log de build no prompt, o agente busca o contexto vivo direto da fonte.

Exemplos práticos da documentação: ao escrever SQL, o agente inspeciona o schema real do Supabase ou Neon; ao depurar um deploy, ele puxa os logs recentes do Netlify; ao terminar uma tarefa, ele abre uma issue no Linear sozinho. Existem MCP Store nos dois produtos — você navega, escolhe e instala servidores prontos — e é possível configurar servidores customizados por arquivo, global ou por projeto.

Para mim, MCP é onde o agente deixa de ser um assistente de código e passa a ser um membro do time com acesso às ferramentas do time.

Execução de múltiplos agentes

Aqui está a mudança mais profunda no dia a dia. No Agent Manager, você pode ter vários agentes simultâneos: um refatorando a lógica de autenticação, outro escrevendo testes para uma API nova, um terceiro pesquisando uma biblioteca em segundo plano.

Cada agente tem seu contexto isolado, seus Artifacts e seu histórico. Você alterna entre eles como quem alterna entre abas de revisão de código. Tarefas longas — reproduzir um bug, gerar um caso de teste, implementar a correção — podem rodar em background enquanto você cuida de outra coisa.

Na versão 2.0, o conceito de workspace (um agente por repositório) foi substituído por projetos, que podem abranger várias pastas com permissões próprias. Isso deixa os agentes enxergarem mais contexto — e exige que você pense em guardrails com mais cuidado.

Planejamento antes da alteração do código

Um dos comportamentos que mais me convenceu no Antigravity é o planejamento obrigatório. Antes de tocar em qualquer linha, o agente converte o pedido em um plano de implementação e pede sua aprovação. Você revisa, ajusta a direção, comenta — e só depois o trabalho começa.

Durante a execução, o agente continua transparente: quando precisa rodar um comando no terminal, ele pede permissão. Quando termina uma parte, ele mostra o resultado nos Artifacts. O controle não desapareceu; ele mudou de nível. Você não aprova mais cada chamada de ferramenta, mas aprova cada plano — e é aí que o valor do seu julgamento fica concentrado.

Limites e riscos da autonomia

Autonomia tem preço, e é importante ser honesto sobre isso:

• O plano não é garantia. Um agente pode aprovar um plano coerente e executar mal. Os Artifacts ajudam a verificar, mas exigem que você olhe de verdade — não é revisão de tapa no olho.
• Contexto é o gargalo. Tarefa grande demais enche a janela de contexto e o agente começa a alucinar. As boas práticas do próprio Google recomendam quebrar o trabalho em módulos pequenos e bem definidos.
• Permissões precisam de config. Com agentes acessando terminal, navegador e MCP servers, quem não configura o Review Policy e as permissões por projeto está delegando sem supervisão. A configuração padrão manual existe por um motivo.
• Confiança calibrada vem com o tempo. Comecei delegando tarefas pequenas e observando o comportamento. Só depois passei a soltar trabalhos mais longos. Esse ritual importa.

O antídoto para todos esses riscos é o mesmo: especificações claras, Artifacts revisados e permissões mínimas. Autonomia sem verificação é só velocidade de cometer erros.

Reflexão final

🧠 Talvez o futuro não seja programar mais rápido. Talvez seja aprender a administrar quem programa.

Quando a IA era um autocomplete, a habilidade importante era digitar bem e revisar rápido. Com agentes que planejam, executam e testam sozinhos, a habilidade que sobe de valor é outra: descrever problemas com precisão, desenhar especificações que a máquina consiga executar e revisar trabalho que você não fez.

O Antigravity é a materialização mais clara que já vi dessa transição. Não é uma ferramenta para escrever código — é uma ferramenta para gerenciar o trabalho de quem o escreve. E isso muda a profissão muito mais do que qualquer autocomplete mudou.

E você, já testou delegar um projeto inteiro para agentes? Conta aqui nos comentários como foi.

— Fontes: Google Developers Blog (anúncio de nov/2025), Antigravity Blog (versão 2.0, mai/2026), documentação oficial de Skills e MCP, e codelabs oficiais de Spec-Driven Development.