Agentes no Origin: o que eles conseguem fazer nas suas pull requests?

A pull request deixou de ser só o lugar onde alguém revisa código e virou o lugar onde o agente trabalha

Fala aí, beleza? A Cursor anunciou no dia 17 de agosto de 2026 a sua própria hospedagem de código, o Origin, e ele já está em early beta liberado em todos os planos pagos (a exceção são organizações Enterprise cujos administradores optaram por ficar de fora)

E o ponto que separa isso de uma hospedagem de código comum não é a tela bonita de diff

É o agente estar ali dentro, na mesma superfície, podendo mexer no que você está olhando 👀

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

O que é o Origin e por que ele junta código, PRs e agentes

O Origin é a hospedagem de código da Cursor

A ideia central, segundo a documentação oficial do Origin, é colocar código, pull requests e agentes no MESMO lugar

Parece detalhe, mas não é. Pensa no fluxo normal: o código mora num lugar, a revisão acontece em outro, e a IA fica numa terceira aba que não sabe direito onde você está

O Origin junta as três coisas na mesma superfície dentro do Cursor

Onde isso vive na prática:

Os repositórios do Origin ficam na aba Codebase

A navegação acontece em cursor.com/codebase, que mostra os repositórios do time

Ao abrir um repositório, você tem acesso ao código, às pull requests e às configurações dele

Simples assim, sem instalar nada pra dar a primeira olhada

O que muda dentro de uma pull request do Origin

Todo repositório do Origin tem pull requests

Ao abrir uma PR, aparece o que você já espera de uma boa tela de revisão: timeline, commits, checks e arquivos alterados

Dali dá pra revisar o diff, deixar comentários e mergear

Até aqui, nada de outro mundo, né?

E onde entra o agente?

Aqui está o pulo do gato

Dentro de um repositório do Origin, você consegue perguntar ao Cursor sobre o código que está navegando

E ele pode:

• responder a pergunta sobre aquele código
• fazer alterações
• atualizar pull requests
• enviar (dar push) em uma branch

Tudo isso sem sair da página

É como ter o revisor e o dev na mesma cadeira: você pergunta "por que essa função tá aqui?" e a resposta pode virar commit, não só texto

E o Bugbot?

O Bugbot é o revisor automático da Cursor: ele revisa pull requests procurando bugs e problemas de qualidade de código

Ou seja, além do agente que você chama, existe uma camada que olha a PR atrás de estrago 🐛

Tome cuidado com uma coisa aqui: revisão automática não substitui a sua leitura do diff, ela reduz o volume de coisa boba que chega até você

Cloud agents e Automations: o ciclo completo de git sem você

O Origin funciona junto com as Automations e os cloud agents do Cursor

Na documentação, o que está afirmado é o seguinte: cloud agents conseguem trabalhar contra repositórios do Origin executando o ciclo completo de git

Clonar, criar branch, commitar, dar push e abrir pull requests

É o ciclo inteiro que você faz na mão todo dia, incluindo aquele momento de fazer git pull de um branch específico antes de começar a mexer

E as Automations?

Automations rodam cloud agents por agendamento ou quando eventos de controle de versão acontecem

A automação aponta para um repositório do Origin do MESMO jeito que apontaria para um repo conectado do GitHub ou GitLab

Então não tem uma configuração exótica nova pra aprender: se você já sabe apontar automação pro seu repo do GitHub, o caminho é o mesmo

O agente criando repositório sozinho:

Essa parte é insana

O agente consegue criar um repositório no Origin por conta própria: ele instala a CLI do Origin, faz login, cria o repositório, define o remote e dá push

A CLI do Origin cria e apaga repositórios sem precisar abrir a interface web:

origin repo create my-project
origin repo delete acme/my-project

E tem um detalhe que resolve metade da dor de cabeça: depois do sign in, o login configura o credential helper do git

Na prática, git push e git pull contra remotes do Origin passam a funcionar sem configuração extra

Se o teu projeto vive com mais de um destino apontado, vale rever como dar push e pull em vários remotos antes de sair adicionando remote novo no meio do fluxo

E quem já vive no GitHub? O que muda na prática

Essa é a pergunta que todo mundo faz, e é justa: ninguém vai largar o GitHub numa terça-feira

A resposta é sincronização nos dois sentidos

Pull requests de repositórios sincronizados sincronizam com o GitHub nas duas direções:

• comentário feito no Cursor é postado no GitHub
• reação ou resposta feita no GitHub aparece no Cursor em segundos

E o mais importante pra quem tem medo de perder o controle: nos repositórios sincronizados, o GitHub continua sendo a fonte da verdade e continua recebendo os pushes

Como trazer um repositório que já existe:

Na home do Codebase, o caminho não é o botão de criar novo

1. Na home do Codebase, selecione Sync from GitHub em vez de New
2. Escolha a organização
3. Escolha o repositório
4. Confirme a sincronização

O erro comum aqui é clicar em New achando que ele vai detectar o repo existente: New cria repositório novo, Sync from GitHub é que traz o que já está lá

Quem tem acesso e o que já vem junto:

Depot e Buildkite executam workflows já existentes do GitHub Actions, então o que você já tem escrito não vai pro lixo

E pra quem quer automatizar por fora da interface, existe uma página de Origin API na documentação oficial do Cursor

Agente rodando ciclo de código: bora ver em movimento?

Ler sobre agente que clona, commita e abre PR é uma coisa

Ver um agente desses trabalhando na tela é outra bem diferente, então se liga no vídeo:

Conclusão

Recapitulando: o Origin é a hospedagem de código da Cursor, anunciada em 17 de agosto de 2026, e o diferencial dela é ter código, pull requests e agentes na mesma superfície

Dentro da PR, o agente responde sobre o código, faz alterações, atualiza a pull request ou envia uma branch

Por fora dela, cloud agents e Automations conseguem rodar o ciclo completo de git contra repos do Origin, e o Bugbot revisa PRs procurando bugs e problemas de qualidade

Agora o veredito honesto: isso é early beta e foi anunciado ontem

O valor prático disso depende MUITO de como o teu time trabalha hoje

Se vocês já vivem dentro do Cursor, a economia de troca de contexto é real. Se o fluxo de review do time inteiro mora no GitHub com processo montado em cima, a sincronização existe, mas testar antes é o mínimo

Próximo passo concreto: abre cursor.com/codebase, cria ou sincroniza um repositório e observa o comportamento do agente em uma PR pequena, dessas de baixo risco

Depois que tu vir o agente atualizando a PR na tua frente, aí sim tu decide se move fluxo crítico pra lá 😀

até o próximo post!