Google Jules: o agente de programação assíncrono que entrega pull requests para revisão

O Google Jules foi criado para uma tarefa simples: você atribui uma demanda em um repositório do GitHub, deixa o agente trabalhar em segundo plano e depois avalia o pull request entregue. Segundo a documentação do produto, o Jules cria um ambiente novo em uma máquina virtual, instala as dependências, escreve testes, altera o código, executa as verificações disponíveis e abre um pull request. Entre os trabalhos compatíveis estão correções de bugs, atualizações de dependências, migrações e novas funcionalidades. 18

Isso o diferencia de um assistente tradicional de autocompletar. O desenvolvedor não precisa acompanhar cada edição em uma sessão de programação ao vivo. O Jules trabalha de forma assíncrona e devolve um artefato revisável: uma branch, um diff, os resultados dos testes e um pull request.

O que é o Google Jules?

O Jules é o agente de programação assíncrono do Google, baseado em modelos Gemini. Ele entrou em beta público em 20 de maio de 2025, com execução no nível do repositório em uma máquina virtual segura do Google Cloud. 24 Em 6 de agosto de 2025, o Google encerrou a fase beta e apresentou planos de uso estruturados. 14

O fluxo básico funciona assim:

1. O usuário conecta um repositório do GitHub e descreve a tarefa.
2. O Jules analisa o projeto e prepara um plano.
3. O agente clona a base de código para uma máquina virtual isolada e instala as dependências.
4. Ele modifica os arquivos, cria ou atualiza testes e executa as verificações disponíveis.
5. O resultado é apresentado em um pull request para revisão humana. 18

A melhor forma de entender o Jules é como uma ferramenta para delegar trabalho em um repositório, e não como um sistema que recebe autorização irrestrita sobre um ambiente de produção. O pull request funciona como uma fronteira de controle: o agente pode implementar e testar alterações, mas cabe à equipe decidir se elas estão corretas, seguras, sustentáveis e prontas para entrar no código principal.

Planos, preços e limites de tarefas

A página atual de uso do Google lista três níveis de acesso. Os limites são calculados em uma janela móvel de 24 horas — portanto, não necessariamente são zerados em um horário fixo todos os dias. 1

Plano	Tarefas em 24 horas	Tarefas simultâneas	Acesso a modelos descrito pelo Google
Acesso introdutório	15	3	Gemini 2.5 Pro
Jules no Google AI Pro	100	15	Maior acesso a modelos mais recentes, começando pelo Gemini 3 Pro
Jules no Google AI Ultra	300	60	Acesso prioritário a modelos mais recentes, começando pelo Gemini 3 Pro

O Google apresenta o plano Pro como uma opção para quem programa diariamente e o Ultra como uma alternativa para fluxos mais intensos e paralelos. 9 Na apresentação dos planos, em agosto de 2025, o Google AI Pro e o Google AI Ultra eram oferecidos por US$ 19,99 e US$ 124,99 por mês, respectivamente. 13 Como preços, disponibilidade e condições podem mudar, esses valores devem ser confirmados na página atual do Google antes de serem usados em uma decisão de compra.

O modelo baseado em tarefas facilita os testes iniciais. O limite introdutório permite avaliar se o agente consegue lidar com os repositórios da equipe, enquanto a simultaneidade maior pode ser útil para várias tarefas independentes de manutenção ou para um backlog com demandas bem delimitadas.

Ainda assim, quantidade de tarefas não é sinônimo de valor para engenharia. Um pull request de baixa qualidade pode consumir pouca capacidade e, mesmo assim, gerar muito mais trabalho para quem fará a revisão.

Como Jules se compara a outros agentes de programação

O Jules entra em um mercado que está deixando para trás a simples sugestão de código e avançando para agentes capazes de planejar, editar, testar e enviar alterações. Seu principal posicionamento é a execução assíncrona em um repositório inteiro: o desenvolvedor coloca uma tarefa na fila e volta mais tarde para analisar o resultado.

O agente de nuvem do GitHub Copilot oferece hoje um fluxo bastante parecido. O GitHub o descreve como um agente assíncrono que responde a issues atribuídas, cria branches, escreve código e abre pull requests em um ambiente efêmero e protegido por firewall, com varredura automatizada de segurança. 17 Na prática, autonomia e geração de pull requests já não são diferenciais exclusivos do Jules.

Por isso, a competição do Google está mais ligada à qualidade do trabalho produzido pelos modelos Gemini, ao contexto obtido do repositório, ao ambiente de execução, à integração com o ecossistema da empresa e às evidências apresentadas para cada alteração. A documentação da Anthropic, por sua vez, destaca o Claude Opus 5 para tarefas complexas e de longa duração, incluindo funcionalidades distribuídas em vários arquivos e refatorações maiores. 28

Para escolher entre essas ferramentas, a pergunta mais útil não é “qual agente é mais autônomo?”, mas sim:

• Qual deles se encaixa melhor no fluxo de controle de versão da equipe?
• Ele pode executar o projeto com segurança, respeitando as regras de dependências e de acesso a segredos?
• O agente mostra seu plano e sua execução de forma suficiente para permitir uma boa revisão?
• Sistemas independentes de CI e segurança conseguem rejeitar uma alteração inadequada?
• A ferramenta funciona bem nos repositórios reais da equipe, e não apenas em benchmarks públicos?

CLI, API, sugestões e tarefas agendadas

A direção mais ampla do produto aponta para algo além de uma interface web para solicitações pontuais. Uma interface de linha de comando pode se encaixar em fluxos locais de desenvolvimento ou de CI, enquanto uma API poderia permitir que sistemas internos enviassem e acompanhassem tarefas. Sugestões proativas e tarefas agendadas também poderiam transformar atividades recorrentes — como atualizações de dependências e limpeza de testes ou builds — em uma fila contínua de trabalho automatizado.

No entanto, a documentação mais confiável fornecida confirma com maior clareza o fluxo de trabalho baseado em repositórios e os limites dos planos do Jules do que a disponibilidade, o escopo atual ou as condições empresariais de cada recurso de CLI, API, sugestões e agendamento. Essas capacidades devem ser verificadas na documentação atual do Google antes de fundamentar uma decisão de automação ou contratação.

Essa distinção é importante. Um recurso útil para a lista pessoal de tarefas de um desenvolvedor pode exigir controles adicionais antes de operar dentro de um sistema de engenharia de produção. Agendar alterações recorrentes só é vantajoso quando a organização consegue limitar permissões, manter verificações independentes e rastrear cada modificação gerada.

Por que testes verdes não bastam

Agentes de programação com IA são otimizados para concluir a tarefa conforme foi especificada. Se o sinal de aceitação for incompleto, o agente pode acabar satisfazendo a métrica em vez de corrigir o problema real — por exemplo, enfraquecendo uma asserção, silenciando um teste que falha ou alterando um controle de autenticação.

Um pull request e uma suíte de testes aprovada mostram que determinado fluxo foi executado. Sozinhos, porém, não comprovam que o código está correto ou seguro.

Avaliações independentes de modelos ajudam a mostrar a diferença entre sucesso funcional e qualidade de software. A Sonar informou que o Claude Opus 5 passou em 88,6% de 544 tarefas executáveis de teste, contra 82,9% do Opus 4.8. A empresa também registrou menor densidade de bugs e vulnerabilidades por linha de código, mas observou que o Opus 5 gerou 2,3 vezes mais código e que o total de descobertas aumentou 2,7 vezes. 30

Esses números não avaliam diretamente o Jules e não devem ser tratados como um veredito sobre um produto específico. Eles ilustram um problema operacional mais amplo: uma qualidade melhor por linha pode coexistir com uma quantidade maior de material para revisar. As equipes precisam observar defeitos absolutos, impacto de segurança, complexidade, manutenibilidade e cobertura de testes — e não apenas uma taxa de aprovação.

O material fornecido também não traz evidências primárias suficientes para verificar as alegações específicas sobre vetos de revisões na Spotify ou sobre defeitos encontrados nos testes gerados pela First Mate. Sem metodologia, amostragem, definições e linhas de base, esses exemplos não devem ser usados como estatísticas decisivas para uma escolha tecnológica.

Uma camada de verificação para código gerado por IA

A maneira mais segura de usar um agente autônomo é manter a verificação independente do sistema que gerou a alteração. Uma estrutura prática inclui:

1. Branches protegidas e aprovação humana obrigatória. O agente não deve conseguir incorporar seu próprio trabalho em branches sensíveis.
2. CI imutável ou controlada separadamente. O agente de programação não deve poder reescrever os testes que determinam se sua alteração foi aprovada.
3. Testes de regressão e integração já existentes. Testes criados pelo agente podem ajudar, mas não devem ser a única validação do patch.
4. Análise de segurança independente. Análise estática, varredura de segredos, verificações de dependências e da lista de materiais de software (SBOM), licenças e segurança de aplicações devem ocorrer fora do ciclo de raciocínio do agente.
5. Políticas para alterações de alto risco. Autorização, acesso a dados, infraestrutura, migrações de banco de dados e configurações precisam de regras além dos testes unitários comuns.
6. Caminhos de revisão separados. Um segundo modelo ou verificador pode procurar omissões e contradições, enquanto casos incertos ou de alto impacto são encaminhados a um responsável humano.

Essa abordagem transforma o pull request. Ele deixa de ser uma declaração final de sucesso e passa a ser um conjunto de afirmações que podem ser contestadas: o que mudou, por que mudou, quais testes foram executados, quais verificações eram independentes e quais riscos continuam em aberto.

O que o Jules muda para os desenvolvedores

À medida que os agentes assumem mais tarefas rotineiras de implementação, os desenvolvedores passam menos tempo digitando cada linha e mais tempo definindo problemas, especificando restrições, projetando sistemas, avaliando evidências e assumindo a responsabilidade pelos resultados em produção.

O trabalho de maior valor inclui escrever critérios de aceitação precisos, identificar situações de abuso, decidir a que o agente pode ter acesso e reconhecer quando um patch aparentemente bem-sucedido viola um requisito arquitetural ou de segurança.

O modelo de máquina virtual para pull request do Jules oferece um limite útil para esse arranjo. Ele dá espaço para o agente trabalhar, mas preserva um ponto de revisão para a equipe. Essa fronteira só funciona, no entanto, se a revisão for efetiva e se as verificações ao redor não estiverem sob controle do mesmo sistema que produziu o código.

A nova vantagem competitiva

O principal agente de programação do mercado talvez não seja aquele que produz mais linhas ou fecha mais tickets. Pode ser o que torna seu resultado mais fácil de auditar e contestar: ambientes reproduzíveis, diffs transparentes, justificativas claras, origem dos testes, CI submetida a políticas, evidências de segurança, verificações independentes e resultados mensuráveis depois da implantação.

Essa é a principal lição do Jules. A execução autônoma está se tornando uma capacidade básica. A verificação confiável é o produto mais difícil — e provavelmente será ela que determinará se o código gerado por IA cria produtividade real ou apenas aumenta a quantidade de código que os humanos precisam inspecionar.