Google Agent Smith Escreve 25% do Código Google: O Que Equipes de API Devem Saber

TL;DR

O agente interno de codificação de IA do Google, Agent Smith, agora gera mais de 25% do novo código de produção da empresa. Ao contrário de ferramentas de preenchimento automático como o Copilot, o Agent Smith trabalha assincronamente em segundo plano, escrevendo, testando e iterando o código sem interação humana. Para equipes de API, isso levanta questões sobre estabilidade de contratos, cobertura de testes, desalinhamento de documentação e fluxos de trabalho de revisão quando um quarto da sua base de código é gerado por máquina.

Introdução

Durante uma teleconferência de resultados em março de 2026, o CEO do Google, Sundar Pichai, divulgou um número que fez toda a indústria de software parar: o código gerado por IA agora responde por mais de 25% do novo código produzido no Google.

Isso não é preenchimento automático. Isso não são sugestões do Copilot aceitas por desenvolvedores. Este é um código que é enviado para produção após a geração por IA. A ferramenta por trás disso, chamada internamente de Agent Smith (uma referência ao antagonista autorreplicante de The Matrix), tornou-se tão popular entre os mais de 180.000 funcionários do Google que a empresa teve que restringir o acesso para gerenciar a sobrecarga da infraestrutura.

O Agent Smith representa uma categoria diferente das ferramentas de codificação de IA que a maioria dos desenvolvedores usa hoje. Onde Copilot e Claude Code auxiliam em tempo real, o Agent Smith funciona em segundo plano. Os engenheiros atribuem tarefas, se afastam e retornam mais tarde para revisar o trabalho concluído.

Para equipes de desenvolvimento de API, essa mudança de código “assistido por IA” para “gerado por IA” levanta questões práticas. Quando 25% da sua base de código é escrita por um agente autônomo, como você mantém os contratos de API estáveis? Como você garante que os testes cubram endpoints gerados por máquina? Como você evita que a documentação se desvie?

Este artigo detalha o que o Agent Smith faz, como ele difere de outras ferramentas de codificação de IA e o que as equipes de API devem se preparar.

O que o Agent Smith faz

Codificação autônoma assíncrona

O Agent Smith não fica na sua IDE esperando você digitar. Ele opera assincronamente em segundo plano. Veja o fluxo de trabalho:

1. Um engenheiro descreve uma tarefa em linguagem natural
2. O Agent Smith divide a tarefa em subtarefas
3. Ele escreve código em vários arquivos
4. Ele executa testes e itera sobre falhas
5. O engenheiro revisa o trabalho concluído

Isso é fundamentalmente diferente das sugestões inline do Copilot ou das sessões interativas do Claude Code. O Agent Smith é mais parecido com um desenvolvedor júnior que pega um tíquete, desaparece por algumas horas e retorna com uma solicitação de pull.

Os engenheiros podem delegar tarefas e verificar o progresso via plataforma de bate-papo interna do Google, mesmo de dispositivos móveis. A ferramenta acessa automaticamente perfis de funcionários e documentação relevante, extraindo contexto da base de conhecimento interna do Google.

Construído sobre Gemini e Antigravity

O Agent Smith opera na família de modelos Gemini do Google, aumentada com sistemas de recuperação que lhe dão acesso à vasta base de código interna e documentação do Google. Ele é construído sobre o Antigravity, a plataforma de codificação agentic existente do Google, mas a estende com decomposição e execução autônomas de tarefas.

A recuperação aumentada é fundamental. O Agent Smith não gera código isoladamente. Ele busca na base de código interna do Google por padrões semelhantes, referencia implementações existentes e segue convenções de codificação internas. Essa consciência de contexto é o que permite uma saída de qualidade de produção na escala de 25%.

O que significa "25% do novo código"

O número de Pichai precisa de contexto. "25% do novo código" refere-se a um código que:

• É gerado por IA, não preenchido automaticamente
• Passa por revisão de código (engenheiros humanos ainda revisam a saída do Agent Smith)
• É enviado em sistemas de produção
• É medido em toda a produção de engenharia do Google

Isso não significa que 25% da base de código total do Google seja gerada por IA. Significa que 25% do novo código sendo escrito hoje vem do Agent Smith. A distinção importa porque o novo código é aditivo a uma base de código existente escrita por humanos. Mas a trajetória é clara: a porcentagem está crescendo, e Pichai a destacou como uma vantagem estratégica.

Como o Agent Smith difere de outras ferramentas de codificação de IA

O espectro de ferramentas de codificação de IA

O Agent Smith se encontra na extremidade autônoma desse espectro. O único passo adiante seria a implantação totalmente autônoma sem revisão humana, o que nenhuma ferramenta principal faz ainda (e não deveria).

Por que a assincronia importa para as equipes de API

Ferramentas de codificação de IA em tempo real (Copilot, Claude Code) funcionam dentro do fluxo do desenvolvedor. O desenvolvedor vê o que a IA escreve, entende o contexto e faz correções no momento.

Agentes assíncronos mudam essa dinâmica. Quando o Agent Smith escreve um endpoint de API, o desenvolvedor o revisa depois. A revisão é separada do contexto de criação. Isso significa que:

• O desenvolvedor pode não entender por que o agente escolheu um formato de resposta específico
• Alterações no contrato da API podem não ser óbvias em uma revisão de código padrão
• Artefatos relacionados (testes, documentos, mocks) podem não ter sido atualizados
• Mudanças disruptivas podem passar despercebidas se o revisor não verificar o impacto total

O que quebra quando a IA escreve o código da sua API

Desalinhamento do contrato da API

Um contrato de API é o acordo entre seu serviço e seus consumidores: endpoints, esquemas de solicitação/resposta, códigos de status, formatos de erro. Quando um desenvolvedor humano modifica uma API, ele geralmente atualiza a especificação OpenAPI, notifica os consumidores e versiona a mudança.

Quando um agente autônomo modifica uma API, essas etapas de coordenação não acontecem automaticamente. O Agent Smith escreve código que passa nos testes. Mas os testes cobrem apenas o que foi escrito anteriormente. Se o agente altera um esquema de resposta de uma forma que passa nos testes existentes, mas quebra os consumidores downstream, a quebra aparece em produção.

Cenário de exemplo:

• O Agent Smith recebe a tarefa de "Adicionar preferências de usuário ao endpoint de perfil"
• Ele adiciona um campo preferences à resposta GET /api/users/{id}
• Os testes existentes passam porque não afirmam a ausência de campos extras
• Os tipos TypeScript da equipe de frontend não incluem preferences
• A análise JSON estrita do aplicativo móvel falha no campo inesperado

O código está correto. Os testes passam. O contrato está quebrado.

Lacunas na cobertura de testes

O código gerado por IA vem com testes gerados por IA, e os agentes de IA tendem a escrever testes que validam o que eles construíram, não testes que protegem contra regressões. Isso cria um ponto cego: os testes confirmam que o novo comportamento funciona, mas não confirmam que o comportamento existente é preservado.

Para endpoints de API, isso significa que:

• Benchmarks de tempo de resposta podem não ser testados
• Formatos de resposta de erro podem divergir do seu esquema de erro padrão
• Comportamento de limitação de taxa pode não ser validado
• Casos de limite de autenticação podem não ser cobertos
• Comportamento de paginação pode diferir dos endpoints existentes

Desalinhamento da documentação

Se sua documentação de API é gerada a partir de anotações de código ou especificações OpenAPI, o código modificado pelo agente deve se propagar para os documentos automaticamente. Mas muitas equipes mantêm a documentação separadamente. Quando o Agent Smith adiciona um endpoint ou modifica um esquema de resposta, a atualização da documentação é uma tarefa separada que o agente pode ou não realizar.

Mesmo com documentos gerados automaticamente, as descrições, exemplos e notas de uso exigem um contexto humano que um agente de IA não possui. O agente pode documentar o que um endpoint faz. Ele não pode documentar por que ele existe, quem o usa ou quais compromissos levaram ao seu design.

Fadiga de revisão

Quando 25% do código é gerado por IA, 25% das revisões de código são a revisão da saída da IA. O código gerado por IA é sintaticamente consistente e bem estruturado, o que o faz parecer "bom" à primeira vista. Mas parecer bom não é o mesmo que estar correto no contexto.

Os revisores enfrentam um novo desafio: o código é bem escrito, mas pode não se alinhar com decisões arquitetônicas, convenções da equipe ou requisitos não declarados que existem na cabeça do revisor, mas não na solicitação do agente. Com o tempo, a fadiga de revisão para código gerado por IA pode levar a aprovações automáticas, que é o ponto onde os bugs começam a ser enviados.

Como construir fluxos de trabalho de API "à prova de agentes"

1. Torne os contratos de API a fonte da verdade

O desenvolvimento de API com design-first é a defesa mais forte contra o desalinhamento induzido por agentes. Quando a especificação OpenAPI é a fonte da verdade, qualquer alteração de código que quebre o contrato é detectável.

Sem design-first:

Alteração de código → Testes passam → Envio → Contrato quebrado

Com design-first:

A especificação define o contrato → O código deve corresponder à especificação → A validação do contrato detecta o desalinhamento

O designer visual de API do Apidog permite definir endpoints, esquemas e formatos de resposta antes que qualquer código seja escrito. Quando o Agent Smith (ou qualquer agente) gera código, você o valida contra a especificação, não contra testes existentes que podem estar incompletos.

2. Use testes de contrato, não testes unitários

Testes unitários validam o comportamento interno. Testes de contrato validam o acordo entre serviços. Quando um agente de IA modifica sua API, os testes de contrato detectam mudanças que os testes unitários perdem.

Exemplo de teste de contrato:

// Este teste falha se a forma da resposta mudar,
// mesmo que a nova forma seja "válida"
describe("GET /api/users/:id contract", () => {
  it("returns expected schema", async () => {
    const response = await request(app).get("/api/users/123");

    expect(response.body).toMatchSchema({
      type: "object",
      required: ["id", "name", "email", "created_at"],
      properties: {
        id: { type: "string" },
        name: { type: "string" },
        email: { type: "string", format: "email" },
        created_at: { type: "string", format: "date-time" }
      },
      additionalProperties: false  // Isso detecta campos inesperados
    });
  });
});

A linha additionalProperties: false é crítica. Sem ela, um agente que adiciona campos à resposta passa em todos os testes. Com ela, qualquer alteração de esquema exige atualizações explícitas do contrato.

O Apidog automatiza os testes de contrato a partir da sua especificação de API. Defina seu esquema uma vez, e o Apidog valida cada resposta contra ele, tanto em testes manuais quanto em execuções de CI/CD.

3. Controle as implantações com validação de especificação

Adicione a validação da especificação da API ao seu pipeline de CI/CD. Antes que qualquer código (humano ou gerado por IA) seja implantado, verifique se ele corresponde ao contrato declarado:

# Etapa do pipeline de CI/CD
- name: Validar contrato de API
  run: |
    # Compare a especificação atual com a implementação em execução
    apidog run --test-scenario-id CONTRACT_TESTS
    
    # Falhe se forem encontradas violações de contrato
    if [ $? -ne 0 ]; then
      echo "Violação de contrato de API detectada. Revise as alterações."
      exit 1
    fi

Isso detecta as mudanças que quebram o contrato do Agent Smith antes que cheguem à produção.

4. Exija atualizações de especificação para alterações na API

Crie uma regra de desenvolvimento: qualquer PR que modifica o comportamento da API deve incluir uma atualização correspondente da especificação OpenAPI. Para PRs gerados por IA, isso significa que o agente deve atualizar a especificação, ou um humano deve fazê-lo antes de mesclar.

No Apidog, as alterações de especificação propagam-se automaticamente para:

• Documentação da API
• Respostas do servidor de mock
• Asserções de teste
• Tipos de SDK do cliente

Essa cascata garante que nenhum artefato se desvie quando o contrato muda.

5. Monitore o comportamento da API em produção

Mesmo com testes de contrato e validação de especificação, o monitoramento de produção captura o que os testes de pré-produção perdem. Acompanhe:

• Violações de esquema de resposta: Registre quando as respostas não correspondem ao esquema declarado
• Novos campos aparecendo: Alerte sobre campos de resposta que não estão na especificação
• Alterações na taxa de erro: Endpoints gerados por IA podem ter distribuições de erro diferentes
• Mudanças na latência: Código escrito por agentes pode ter características de desempenho diferentes
• Alterações no padrão de tráfego: Novos endpoints podem receber padrões de tráfego inesperados

6. Separe a revisão da API da revisão do código

A revisão de código padrão pergunta: "Este código funciona?" A revisão de API pergunta: "Esta mudança afeta os consumidores?"

Para alterações de API geradas por IA, crie uma lista de verificação de revisão separada:

• Essa alteração quebra algum consumidor existente?
• A especificação OpenAPI está atualizada?
• As alterações incompatíveis com versões anteriores estão versionadas?
• As respostas de erro são consistentes com o formato de erro existente?
• Novos endpoints estão documentados com exemplos?
• As equipes downstream foram notificadas?

A trajetória: para onde a codificação autônoma está indo

Agent Smith hoje vs. amanhã

O Agent Smith em 25% é o ponto de partida. Sergey Brin chamou os agentes de IA de um "grande foco" durante uma reunião de vendas em março de 2026. O número de 25% crescerá à medida que a ferramenta melhorar, as restrições de acesso diminuírem e os fluxos de trabalho se adaptarem.

Outras empresas estão construindo sistemas semelhantes:

• KAIROS do Claude Code (vazado no código-fonte): daemon sempre ativo com assinaturas de webhook do GitHub e trabalhadores em segundo plano
• Modo Agente do GitHub Copilot: tarefas de codificação em várias etapas com edição autônoma de arquivos
• CodeWhisperer da Amazon: expandindo de preenchimento automático para fluxos de trabalho de agente

A tendência da indústria é clara: as ferramentas de codificação de IA estão passando de "assistente" para "colaborador autônomo" para "infraestrutura em segundo plano". Dentro de alguns anos, a questão não será se a IA escreve seu código de API, mas sim quanto dele.

O que as equipes de API devem preparar agora

Design-first não é mais opcional. Quando os agentes escrevem código, a especificação da API é o único artefato estável. Torne-a a fonte da verdade agora, antes que a adoção de agentes a torne urgente.

Invista em infraestrutura de teste de contrato. Testes unitários não são suficientes quando o autor do código não entende suas convenções não escritas. Os testes de contrato codificam essas convenções explicitamente.

Escolha ferramentas que mantenham os artefatos sincronizados. Ferramentas desconectadas (cliente de API separado, executor de teste separado, servidor de mock separado, gerador de documentos separado) criam oportunidades de desalinhamento que os agentes exploram. Plataformas integradas como o Apidog mantêm tudo sincronizado.

Construa processos de revisão para código gerado por IA. A revisão de código padrão não detecta violações de contrato de API. Crie listas de verificação e validação automatizada especificamente para alterações de API.

Experimente o Apidog gratuitamente para construir fluxos de trabalho de API que permaneçam consistentes, quer sua próxima mudança de código venha de um desenvolvedor humano, do Agent Smith ou de qualquer ferramenta de codificação autônoma que surja a seguir.

FAQ

O que é o Google Agent Smith?

Agent Smith é o agente de codificação de IA interno do Google construído sobre a família de modelos Gemini e a plataforma Antigravity. Ele funciona assincronamente em segundo plano: engenheiros atribuem tarefas, e o Agent Smith escreve, testa e itera código sem interação humana em tempo real. Ele gerou mais de 25% do novo código de produção do Google em março de 2026.O Agent Smith está disponível fora do Google?

Não. O Agent Smith é uma ferramenta interna restrita aos funcionários do Google. O Google não anunciou planos para um lançamento público. A tecnologia é semelhante ao Copilot Agent Mode e Claude Code, mas está mais profundamente integrada aos sistemas internos de base de código e documentação do Google.

O código gerado por IA quebra contratos de API?

Pode. Agentes de IA escrevem código que passa nos testes, mas os testes podem não cobrir todos os aspectos do seu contrato de API. Alterações de esquema, novos campos de resposta, diferentes formatos de erro e modificações comportamentais podem passar despercebidos nos testes, quebrando os consumidores downstream. Testes de contrato e desenvolvimento design-first evitam isso.

As equipes de API devem se preocupar com o Agent Smith?

Não com o Agent Smith especificamente, já que é interno do Google. Mas com a tendência que ele representa, sim. Ferramentas de codificação autônomas semelhantes (Copilot Agent Mode, KAIROS e outras) chegarão à sua equipe. Preparar seu fluxo de trabalho de API agora, com desenvolvimento design-first, testes de contrato e ferramentas integradas, posiciona você para adotar agentes autônomos com segurança.

Como faço para impedir que agentes de IA quebrem minhas APIs?

Use desenvolvimento design-first com a especificação OpenAPI como fonte da verdade. Adicione testes de contrato com additionalProperties: false para detectar alterações inesperadas de esquema. Controle as implantações com validação de especificação. Use uma plataforma integrada como o Apidog que sincroniza especificações, testes, mocks e documentos automaticamente.

Qual a diferença entre código assistido por IA e código gerado por IA?

O código assistido por IA (sugestões do Copilot, sessões do Claude Code) é escrito em tempo real com supervisão humana. O desenvolvedor vê e aprova cada mudança. O código gerado por IA (Agent Smith) é produzido assincronamente sem envolvimento humano em tempo real. O desenvolvedor revisa o trabalho concluído posteriormente. Essa diferença altera a dinâmica da revisão e aumenta o risco de violações de contrato não detectadas.

Os agentes de IA substituirão os desenvolvedores de API?

Não. O Agent Smith ainda exige definição de tarefas humanas, revisão de código e aprovação de implantação. Um estudo do MIT de março de 2026 confirmou que a IA aumenta a produtividade do desenvolvedor, mas não substitui o julgamento, a consciência de contexto e o pensamento arquitetônico que os humanos fornecem. O papel muda de escrever código para definir tarefas, revisar a saída e manter a coerência do sistema.

Principais conclusões

• O Agent Smith do Google gera 25% do novo código de produção através de operação assíncrona e autônoma
• Isso representa uma mudança de código assistido por IA para código gerado por IA, alterando a dinâmica de revisão para equipes de API
• O desalinhamento do contrato da API é o risco principal quando agentes autônomos modificam endpoints e esquemas
• O desenvolvimento design-first com especificações OpenAPI como fonte da verdade previne a quebra de contratos
• Testes de contrato com validação de esquema rigorosa detectam mudanças que os testes unitários perdem
• Plataformas integradas como Apidog sincronizam especificações, testes, mocks e documentos para evitar o desalinhamento
• A tendência em direção a agentes de codificação autônoma está acelerando; prepare seus fluxos de trabalho de API agora

O Agent Smith em 25% é o começo. As empresas que construírem fluxos de trabalho de API "à prova de agentes" hoje serão as que adotarão ferramentas de codificação autônoma com segurança amanhã.