Cursor Origin: A Aposta Que Deixou o Hosting de Código Interessante de Novo

Vamos ser sinceros: por dezoito anos, "onde a gente hospeda nosso código?" foi a pergunta mais sem graça da tecnologia. Você escolhe o GitHub, talvez o GitLab ou Bitbucket, configura sua equipe e pronto. Hosting de código é encanamento de infraestrutura—essencial, confiável e absolutamente sem graça.

O Cursor acabou de apostar que isso mudou.

A Sorte Estava do Lado Deles

Na segunda-feira de manhã, o Cursor começou a liberar o Origin para usuários paying. Mais ou menos três horas e meia depois, o GitHub saiu do ar—taxas de erro subindo para quase 20% em pull requests, issues e API, com downloads de arquivos brut e archives falhando quase metade das vezes. SSO enterprise caiu junto: SAML, OIDC, SCIM, tudo. Até o Copilot foi embora.

A comunidade dev fez o que a comunidade dev faz de melhor: memes.

O CEO da Vercel, Guillermo Rauch, postou que agora você podia hospedar repos no Cursor Origin e fazer deploy na Vercel via Cursor Origin—que por sua vez roda na Vercel. "E diferente do GitHub, está online," completou com um sorriso. O engenheiro do Cursor, Matt Palmer, quote-tweetou o próprio lançamento da empresa com a melhor frase do dia: "Íamos lançar isso antes, mas o GitHub estava fora do ar."

Foi orquestrado? Quase certamente não. Lançamentos ficam travados semanas antes. Mas às vezes o universo te dá uma mãozinha, e o Cursor agarrou.

O Que o Origin Realmente É (e O Que Não É)

Vamos separar o marketing do produto. O Origin fica dentro do editor do Cursor como uma nova aba Codebase. Você dá um nome ao projeto, recebe uma URL, faz push pela linha de comando, e pronto—tem a experiência completa de um forge: repositórios, pull requests, timelines, commits, checks, merges. O básico está lá.

Mas o que torna o Origin interessante é isso: o agente de IA vive na mesma superfície que o código e os pull requests que ele modifica.

Você pode perguntar sobre o arquivo que está olhando. Pode passar um comentário de review para um agente e pedir que revise o pull request ali mesmo. Pode pedir para ele fazer push de um branch—tudo sem sair do editor onde você escreve código. O agente não está grudado como um serviço separado. Ele está entrelaçado no próprio fluxo de trabalho.

Essa é a aposta real do Cursor. Eles não estão construindo mais um host Git. Estão apostando que, quando agentes de IA estiverem mexendo no seu código, você quer que eles operem no mesmo espaço que os humanos fazendo code review—não alternando entre abas e serviços.

A Estratégia de Integração é Cirúrgica

O Origin chegou com três integrações no day one: Vercel, Depot e Buildkite. As escolhas mostram exatamente quem o Cursor está mirando.

A Vercel cuida de preview deployments para cada pull request e manda para produção no merge—disponível em beta público para clientes Pro e Enterprise. A Depot e a Buildkite executam integração contínua, e aqui vem o ponto crítico: ambas rodam workflows existentes de GitHub Actions sem nenhuma alteração. A Buildkite ainda adiciona pipelines nativos por cima disso.

Leia de novo: workflows existentes de GitHub Actions sem nenhuma alteração.

O Cursor não está pedindo para times reescreverem seu sistema de build, reaprenderem seus engenheiros ou arrancarem seu pipeline de deploy. Eles estão pedindo para times experimentarem uma segunda janela para o código que já têm. Isso é um sales motion completamente diferente de "migre tudo para nossa plataforma."

A Decisão de Design Mais Esperta: Não Deixe o GitHub

Aqui está a decisão que deveria fazer líderes de engenharia prestarem atenção.

O Origin não exige que você abandone o GitHub. Conecta uma organização do GitHub, escolhe repositórios, e eles aparecem junto com os nativos do Origin. Pushes continuam indo para o GitHub, que permanece como fonte de verdade para qualquer coisa que começou lá. Permissões espelham as configurações existentes de read e write do GitHub. Conversas de pull request sincronizam em ambas as direitações—comenta no Cursor e aparece no GitHub; responde no GitHub e surge no Cursor em segundos.

Isso é uma estratégia de cunha clássica, bem executada.

Migração rip-and-replace de controle de código fonte está entre os projetos mais arriscados que uma organização de engenharia pode enfrentar. Ela mexe com integração contínua, evidências de compliance, trilhas de auditoria, regras de proteção de branch, toda integração da toolchain e a memória muscular de cada engenheiro. Quase nenhum CTO aprova isso para um produto em beta inicial.

Mas um espelho read-mostly que mantém o GitHub como autoritativo? Esse se aprova sozinho. Não custa nada experimentar, não exige migração nenhuma, e te dá um gostinho de como é uma experiência de hosting de código AI-native.

O Que Isso Significa para a Indústria

O GitHub tem sido a resposta padrão para "onde devemos hospedar nosso código" por quase duas décadas. Isso não muda da noite para o dia, e o Cursor sabe disso. O Origin não está tentando substituir o GitHub—está tentando se tornar o lugar onde o desenvolvimento com ajuda de IA acontece, com o GitHub permanecendo como o backend autoritativo para tudo que importa.

A pergunta não é se o Origin vai desplacar o GitHub. A pergunta é se o Origin pode se tornar a interface que os desenvolvedores realmente usam enquanto o GitHub cuida do encanamento por baixo.

Se agentes de IA vão escrever, revisar e modificar código em escala—and they are—então onde esses agentes vivem e trabalham se torna estrategicamente importante. O Cursor está fazendo uma jogada deliberada para dominar essa superfície.

Para líderes de engenharia avaliando o cenário, as implicações são diretas: acompanhe de perto, teste o produto, e preste atenção em quais integrações e workflows parecem naturais no contexto AI-native. A experiência tradicional do forge nos serviu bem. Mas "bom o suficiente para humanos" e "bom o suficiente para times com ajuda de IA" podem ser perguntas diferentes.

E isso talvez seja a coisa mais interessante que aconteceu com hosting de código fonte em dezoito anos.