O Google adicionou um novo comando ao seu ambiente de desenvolvimento Antigravity chamado /boost. Ao acioná-lo, inicia-se um pipeline de raciocínio multiagente em vez de um único assistente de programação: um orquestrador lê o problema e o divide em tarefas, distribui essas tarefas para agentes especializados que trabalham em escopos isolados e, em seguida, submete o resultado a rodadas de verificação independentes que realmente executam os testes antes que qualquer coisa chegue até você. A manchete não é que a IA escreve código mais rápido. É que as ferramentas de programação começaram a incorporar a verificação na própria ferramenta.

O que o Google realmente anunciou

De acordo com a documentação oficial do Antigravity, o /boost foi projetado especificamente para engenharia de software difícil: bugs de concorrência e condições de corrida, otimização algorítmica, regressões sutis que aparecem e somem e refatorações intricadas em vários arquivos. São exatamente os problemas em que um assistente convencional de turno único falha, porque resolvê-los exige experimentação e retrocesso, e não geração direta.

O comando é executado em três fases claras:

  • Planejamento: um orquestrador principal recebe seu prompt, inspeciona o contexto do workspace, formula uma estratégia de execução e decompõe o desafio em subtarefas discretas e verificáveis.
  • Execução distribuída: o orquestrador distribui essas subtarefas para agentes especializados. Os fluxos de trabalho de implementação escrevem código e testes unitários. Os fluxos de trabalho de investigação fazem depuração de causa raiz e rastreiam grafos de chamadas sem modificar nenhum arquivo. Os agentes de verificação local executam alvos de build e suítes de testes para validar hipóteses antes de reportar.
  • Verificação antes da entrega: o orquestrador consolida as descobertas e executa checagens de regressão contra as suítes de testes completas e os casos extremos. Se uma asserção falhar, o diagnóstico do erro alimenta a próxima iteração para correção automática, e você só recebe um resumo das alterações verificadas quando tudo passa.

Tudo isso roda dentro de worktrees efêmeras e isoladas, o que significa que os agentes não estão experimentando na sua cópia de trabalho do projeto.

Três modos, não um

O Google documenta três modos de execução distintos, e a diferença entre eles é a parte útil na prática:

  • Agente padrão: programação interativa, navegação pelo código e refatoração geral. Horizonte de tarefa de segundos a minutos, um loop de agente único, verificação em uma única passada. Disponível em todos os planos.
  • /boost: raciocínio profundo e bugs persistentes. Horizonte de tarefa de segundos a horas, uma hierarquia de três fases, verificação independente em várias rodadas. Disponível nos planos pagos.
  • /teamwork-preview: equipes de agentes trabalhando por dias em grandes migrações ou na construção de subsistemas inteiros, com papéis nomeados como Explorer, Worker, Critic e Auditor, além de portões de verificação que tentam deliberadamente quebrar o código antes de um marco ser aprovado.

Repare na gradação: quanto maior a tarefa, mais o investimento vai para a revisão em vez da velocidade. É um sinal que merece atenção de qualquer pessoa que conduza um projeto de software.

Por que isso importa para um empresário, e não só para um desenvolvedor

Nos últimos dois anos, a conversa sobre IA na programação foi uma conversa sobre velocidade: quantas linhas são geradas por minuto. O problema é que a velocidade não é o gargalo em projetos reais. A confiança é. Esse código realmente funciona nos casos que ninguém testou?

O que a arquitetura do /boost diz implicitamente é que o setor chegou à mesma conclusão. Código que chega mais rápido não vale nada se custar duas semanas de depuração depois da entrega. Por isso a ferramenta é construída em torno de três regras que se aplicam a qualquer equipe técnica, com ou sem IA:

  • O autor não avalia o próprio trabalho: quem verifica é separado de quem implementou. Esse tem sido o princípio da revisão de código há décadas. Agora ele é imposto dentro da ferramenta.
  • Evidência significa execução, não afirmação: os testes são realmente executados e sua saída real é verificada, em vez de aceitar a alegação de que passaram.
  • O isolamento protege o original: a experimentação acontece em uma cópia separada, então tentativas fracassadas nunca vazam para o projeto.

Se você contrata desenvolvimento de software, essas são exatamente as três perguntas a fazer ao seu fornecedor: quem revisa, qual é a evidência de que os testes passaram e onde acontece a experimentação?

O que não muda

É fácil ler uma notícia como esta como o anúncio de que engenheiros não são mais necessários. A documentação diz o contrário com bastante clareza: os agentes herdam as regras de acesso a arquivos e as políticas de permissão de comandos configuradas para o seu workspace, e qualquer comando protegido ou edição fora dos escopos confiáveis gera um pedido de autorização ao usuário. Há um humano responsável no fim da cadeia.

E as permissões são a metade menor da questão. Um agente resolve o problema que você descreveu. Ele não tem como saber que a própria descrição estava errada. Ele não sabe que o seu ciclo de faturamento fecha no dia 25 e não no dia 30, que este campo nunca deve ficar visível para um vendedor, ou que, quando o seu cliente diz "pedido", ele quer dizer algo diferente do que você quer dizer. Definir requisitos, entender o domínio e responder pela decisão continuam sendo trabalho inteiramente humano.

Como enxergamos isso na Origami

Tratamos as ferramentas multiagente como tratamos qualquer ferramenta de produtividade: elas aceleram a execução, não transferem a responsabilidade. Um projeto aqui continua passando por especificações escritas, revisão humana, uma suíte de testes e um ambiente de staging antes da produção, seja o código escrito por uma pessoa ou gerado por um agente. Uma ferramenta que executa os próprios testes é uma adição bem-vinda a essa cadeia, mas é um elo dela, não um substituto.

A conclusão prática para um empresário: espere que os prazos de entrega encurtem especificamente em trabalhos complexos, mas não aceite uma entrega sem testes, sem documentação e sem um responsável humano. Ferramentas que revisam a si mesmas elevam o teto da qualidade possível. Elas não eliminam sua necessidade de alguém que garanta que o que foi construído é o que você pediu.

Fontes