For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/pt/articles/cursor-origin-is-live-what-the.md.
17 de agosto foi um dia excepcionalmente dramático para a infraestrutura de desenvolvedores. O GitHub sofreu um grande incidente global que ...
O dia 17 de agosto foi um dia excepcionalmente dramático para a infraestrutura de desenvolvedores.
O GitHub sofreu um grande incidente global que durou 7 horas e 47 minutos, desde o primeiro impacto registrado até a resolução final. Durante o incidente, os desenvolvedores enfrentaram problemas nos serviços principais do GitHub.com, APIs, pull requests, conteúdo de repositórios, sistemas relacionados à autenticação e no GitHub Copilot.
Quase ao mesmo tempo, a Cursor começou a lançar o Origin, sua própria plataforma de hospedagem Git.
O momento foi quase perfeito demais para as redes sociais.
Um lado do mundo dos desenvolvedores atualizava a página de status do GitHub. O outro compartilhava capturas de tela da nova aba Codebase da Cursor e brincava que estava na hora de migrar os repositórios.
O artigo original descreve o momento como a Cursor "derrubando o GitHub da noite para o dia". Isso funciona como um título chamativo, mas não deve ser interpretado literalmente.
O Origin não causou a interrupção, e um produto de hospedagem em beta inicial não apagou o enorme ecossistema do GitHub em um único dia.
O que realmente aconteceu é mais interessante: a Cursor deixou de ser principalmente um ambiente de codificação com IA para entrar na camada de infraestrutura de controle de versão.
O Origin agora pode hospedar repositórios por conta própria. Isso significa que a empresa não está mais satisfeita com agentes escrevendo código enquanto o GitHub continua sendo o local padrão onde esse código acaba vivendo.
A Cursor agora quer que o repositório, o pull request, o agente e o fluxo de trabalho de desenvolvimento existam em um único sistema.
A aquisição da Cursor pela SpaceX já havia sido concluída em 14 de agosto. Três dias depois, o Origin entrou em beta inicial para usuários pagantes.
O Origin não é meramente uma cópia em cache de um repositório do GitHub dentro da Cursor.
A Cursor o descreve como:
uma forja git para armazenar e compartilhar código
No Beta Inicial atual, o Origin pode:
Isso é suficiente para tornar o Origin um produto real de hospedagem Git, em vez de um
camada de visualização.
O produto ainda é explicitamente rotulado como Early Beta. O post de lançamento do Cursor afirma que ele está começando com o essencial e planeja adicionar mais recursos nativos de agentes posteriormente.
Esse limite é importante ao comparar a versão beta com a visão mais ambiciosa do Origin que a Cursor demonstrou no início do ano.
A documentação atual do Cursor lista o armazenamento de código do Origin para:
| Plano | Armazenamento de código do Origin |
|---|---|
| Gratuito | Não disponível |
| Pro | Disponível, implantação gradual |
| Teams | Disponível, implantação gradual |
| Enterprise | Disponível, a menos que desativado pelos administradores; implantação gradual |
Como a implantação é gradual, uma conta paga pode não ver o Origin imediatamente. Organizações Enterprise também podem optar por não participar.
O Origin herda o modo de privacidade do proprietário do namespace, o que significa que as equipes devem revisar sua configuração de privacidade e acesso a repositórios do Cursor antes de colocar código sensível no serviço.
A configuração básica é intencionalmente familiar.
Acesse o workspace Codebase do Cursor:
cursor.com/codebase
Selecione:
+ New
Escolha o nome do repositório.
O Cursor então exibe os comandos necessários para instalar o CLI do Origin, clonar o repositório ou enviar um projeto local existente.
Quando um usuário ou equipe cria seu primeiro repositório no Origin, o nome do codebase escolhido se torna parte da URL do repositório.
A URL segue este padrão geral:
https://cursor.com/codebase/{owner}/{repo}
Por exemplo:
https://cursor.com/codebase/acme-corp/example-repo
A documentação atual da versão beta do Cursor alerta que o namespace não pode ser renomeado durante a versão beta. Escolha-o deliberadamente.
Uma das decisões de adoção mais importantes é que o Origin não exige que os desenvolvedores abandonem o próprio Git.
Um repositório pode usar operações familiares, como:
git clone
git pull
git push
Para abrir uma solicitação de pull a partir de um novo branch, a documentação do Cursor fornece o fluxo padrão:
git checkout -b my-change
git push -u origin my-change
Quando o branch estiver no Origin, a solicitação de pull pode ser criada pela interface web.
Os Cursor Cloud Agents também podem criar branches, commits, pushes e pull requests em repositórios do Origin.
Isso é importante porque um forge compatível com Git pode ser introduzido sem substituir todas as ferramentas locais de desenvolvimento de uma só vez.
Todo repositório do Origin inclui pull requests.
A interface atual de PR apresenta quatro visões principais:
Os revisores podem inspecionar diffs, comentar em linhas, deixar revisões, solicitar
revisores, e mesclar após a revisão e os requisitos de CI serem atendidos.
A ideia maior do produto é que um desenvolvedor não precise alternar entre:
Editor Cursor
→ Site de hospedagem Git
→ Assistente de IA
→ Painel de CI
→ de volta ao editor
a cada alteração.
O Origin traz a navegação de repositórios e o trabalho com PRs para o mesmo ambiente Cursor no qual os agentes já operam.
O artigo de origem apresenta três recursos especialmente agressivos do Origin:
Essas ideias se encaixam na visão mais ampla de escala de agentes da Cursor.
No entanto, elas devem ser separadas do que a documentação atual do Early Beta realmente promete.
A Cursor documenta atualmente:
Repositórios
Clone/push/pull Git padrão
Espelhamento do GitHub
Navegação/busca de código
Pull requests
Revisões/comentários
Checks
Merge manual
Exibição de conflitos
Permissões
Apps
Automações
Cloud Agents
Origin CLI
A documentação oficial atual do Origin não lista os seguintes itens como geralmente disponíveis:
Fluxo de trabalho nativo de PRs empilhados
Fila de merge do Origin
Resolução automática de conflitos de merge com IA
API estruturada de estado de revisão específica do Origin
Origin como servidor MCP
A linguagem de lançamento da Cursor afirma explicitamente que recursos adicionais nativos de agentes virão posteriormente.
Portanto, eles devem ser tratados como conceitos de demonstração anteriores, direção de roadmap ou recursos que aguardam documentação de lançamento mais clara — não como capacidades nas quais todo usuário pagante do Origin pode confiar hoje.
A comparação também precisa de uma correção no lado do GitHub.
O GitHub não se limita a uma única lista gigante de PRs legível por humanos.
O GitHub documenta atualmente:
merge_group.Isso não torna o GitHub "nativo para agentes" no mesmo sentido de produto que a Cursor está buscando.
Mas significa que a distinção técnica não é:
O GitHub não tem nenhum desses primitivos
vs.
O Origin tem todos eles
A distinção mais plausível é a filosofia de produto.
A Cursor quer que a infraestrutura de repositórios seja diretamente incorporada em um ambiente onde frotas de agentes de codificação já são atores de primeira classe.
O recurso de migração mais prático do Origin não é uma chave dramática de substituição. É o espelhamento.
Uma equipe pode conectar
GitHub para Cursor, escolha uma organização e um repositório e crie um espelho Origin.
A sincronização documentada atualmente inclui:
| Sincronizado com Origin | Não migrado como parte do espelho |
|---|---|
| Histórico do Git | Issues do GitHub |
| Branches | Configuração dos workflows do GitHub Actions |
| Tags | Secrets do GitHub Actions |
| Código navegável/buscável | Outras configurações de plataforma específicas do GitHub |
| Pull requests, bidirecionalmente | — |
| Atualizações contínuas do repositório | — |
Para um repositório espelhado, o GitHub permanece inicialmente como a fonte da verdade.
Pushes pelo remote Origin continuam fluindo para o GitHub. Pull requests podem ser revisados pelo Origin enquanto a atividade é sincronizada de volta para o GitHub.
Isso torna o Origin mais fácil de testar, pois as equipes não precisam abrir mão da autoridade do repositório logo no primeiro dia.
O post de lançamento do Cursor afirma que pull requests em repositórios espelhados sincronizam bidirecionalmente.
O comportamento pretendido é:
Comentar no Cursor
→ aparece no GitHub
Responder ou reagir no GitHub
→ aparece no Cursor
Revisão atribuída no GitHub
→ pode ser tratada pelo Cursor
O Cursor afirma que essas atualizações aparecem em segundos.
Isso permite que os desenvolvedores avaliem a experiência do Origin enquanto os colaboradores existentes do GitHub continuam usando o GitHub.
Essa provavelmente é uma estratégia de migração mais realista do que mover imediatamente um monorepo crítico para um novo host em beta.
O passo de migração mais forte é Desanexar do GitHub.
Quando um repositório espelhado é criado pela primeira vez, a relação é:
GitHub
= fonte da verdade
Origin
= espelho sincronizado
As configurações do repositório no Cursor incluem uma ação de Zona de Perigo:
Desanexar do GitHub
Após desanexar:
Origin
= repositório hospedado de forma independente
= fonte da verdade
Pushes para o remote do Origin não fluem mais para o GitHub.
O repositório original do GitHub não é excluído nem modificado pela ação de desanexação.
Essa distinção é importante.
Desanexar altera o comportamento de sincronização; não apaga a cópia no GitHub.
Um codebase pode ter vários clones e espelhos, mas os processos de desenvolvimento geralmente precisam de um repositório autoritativo.
Essa autoridade determina questões como:
main canônico?Para repositórios Origin espelhados, essa autoridade começa no GitHub.
Após a desanexação, o Cursor documenta o Origin como a fonte da verdade para o repositório hospedado no Origin.
É nesse ponto que o Origin deixa de ser uma interface complementar e se torna o host Git principal para aquele projeto.
O Cursor também
começou a conectar a Origin ao ecossistema de implantação e CI.
As integrações oficiais atuais incluem:
Conecte a Vercel pela aba Apps do repositório.
A Cursor diz que cada pull request pode receber uma implantação de pré-visualização, permitindo que as equipes testem e comentem antes do merge.
A Depot pode executar CI para repositórios da Origin e pode reutilizar fluxos de trabalho existentes do GitHub Actions.
A Buildkite também pode executar fluxos de trabalho existentes do GitHub Actions, além do seu sistema de pipeline nativo.
Isso ajuda a reduzir um dos custos mais difíceis da migração.
Mesmo quando o armazenamento do repositório muda, as equipes não querem reescrever toda a sua stack de CI/CD ao mesmo tempo.
Há uma nuance importante.
A documentação do espelhamento do GitHub da Cursor diz que os fluxos de trabalho e segredos do GitHub Actions não são espelhados na Origin como configuração de plataforma do GitHub.
No entanto, integrações de terceiros da Origin, como Depot e Buildkite, podem executar definições existentes de fluxos de trabalho do GitHub Actions.
Essas afirmações podem coexistir:
Estado da plataforma GitHub Actions
→ não migrado pelo espelhamento do repositório
Arquivos de fluxo de trabalho no repositório
→ podem ser interpretados por integrações de CI suportadas
As equipes devem testar segredos, permissões, gatilhos de eventos, cache, credenciais de implantação e proteção de branch antes de desanexar um repositório de produção.
O argumento estratégico maior para a Origin é a integração com agentes.
Os Cloud Agents da Cursor rodam em máquinas virtuais isoladas na nuvem, com ambientes de desenvolvimento completos.
Eles podem:
Com a Origin, esses agentes podem trabalhar diretamente com repositórios hospedados na mesma plataforma.
O ciclo se torna:
Objetivo
→ agente da Cursor
→ repositório da Origin
→ branch
→ mudanças de código
→ testes
→ pull request
→ revisão
→ merge
O repositório não precisa mais ser um serviço externo no centro do fluxo de trabalho dos agentes.
A Origin também se integra com as Automações da Cursor.
A documentação atual lista eventos de repositório como:
Uma automação pode acordar um agente na nuvem em resposta a um desses eventos.
Por exemplo:
Novo PR aberto
→ executar um agente de revisão de segurança
Push para main
→ resumir a mudança
PR atualizado
→ inspecionar novos commits
Isso é uma peça concreta da história "nativa de agentes" que já está documentada hoje.
A atualização de agentes da Cursor de 19 de agosto vai além, permitindo que os Cloud Agents assinem eventos e continuem conduzindo o trabalho, como correções de CI e feedback de bots, até que o objetivo seja concluído.
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
O artigo de origem diz que a Origin "suporta MCP nativamente", para que os agentes possam conduzir a forja tão facilmente quanto uma API.
A Cursor, como produto mais amplo, definitivamente suporta MCP para conectar agentes a ferramentas e dados externos.
No entanto, não encontrei uma página atual de documentação da Origin que exponha a própria Origin como
um servidor MCP** para operações de repositório.
A documentação atual da integração Origin enfatiza:
Origin CLI
Cloud Agents
Automações
Aplicativos de terceiros
Portanto, a redação segura é:
O ecossistema de agentes do Cursor suporta MCP, enquanto a documentação atual do Early Beta da Origin ainda não anuncia claramente uma interface MCP dedicada da Origin.
Isso pode mudar à medida que o Cursor lançar os recursos adicionais nativos de agentes que prometeu.
As demonstrações anteriores da Origin pelo Cursor enfatizaram números de throughput que soam excessivos para uma equipe de desenvolvimento humana.
Os números de demonstração relatados incluíam:
| Métrica | Afirmação da demonstração do Cursor |
|---|---|
| Clones de repositório | ~296.000/hora |
| Pushes | ~81.000/hora |
| Commits em um repositório | 22,6/segundo |
| Sincronização global | <400 ms |
| Failover automático | <10 ms |
O artigo original usa esses números para fazer um ponto simples:
Desenvolvedores humanos não precisam fazer commits dezenas de vezes por segundo. Frotas de agentes podem precisar.
Esses números ainda devem ser lidos como afirmações de demonstração do fornecedor.
A documentação atual da Origin do Cursor não publica uma metodologia de benchmark completa, SLA de produção, distribuição de carga, tabela de latência percentil ou validação independente para esses números.
Uma equipe de produção deve testar suas próprias cargas de trabalho antes de tratar o throughput de demonstração de palco como capacidade de serviço garantida.
O argumento para infraestrutura Git em escala de agentes não é puramente hipotético.
A Cursor disse em fevereiro que mais de 30% dos pull requests mesclados internamente estavam sendo criados por agentes operando autonomamente em sandboxes na nuvem.
Em junho, o post de engenharia do próprio Cursor disse:
mais de 40% dos nossos PRs vêm de agentes na nuvem
O artigo original cita um número intermediário de 35%–40%.
A porcentagem exata mudou ao longo do tempo à medida que a adoção de agentes aumentou.
A tendência mais importante é clara:
Fevereiro de 2026:
>30%
Junho de 2026:
>40%
O fluxo de trabalho interno de desenvolvimento de software do Cursor já está produzindo PRs criados por agentes em volume suficiente para que a coordenação de repositórios se torne uma preocupação séria de infraestrutura.
Os fluxos de trabalho tradicionais de repositório assumem ritmo humano.
Um desenvolvedor pode:
Uma frota de agentes pode operar de forma diferente.
Dez ou cem agentes podem simultaneamente:
O gargalo muda.
Escrever o primeiro rascunho do código pode se tornar barato.
Coordenar, validar, revisar e mesclar com segurança muitas mudanças simultâneas se torna mais difícil.
Esse é o problema de infraestrutura que a Origin está abordando.
O artigo original contrasta um "fluxo de trabalho do GitHub de 2008" com uma Origin nativa de agentes.
O enquadramento histórico é útil, mas a comparação atual de produtos é mais sutil.
O GitHub continuou a adicionar
automações primitivas, incluindo:
Portanto, a questão não é se o GitHub pode automatizar o desenvolvimento.
Claramente pode.
A questão estratégica é se uma plataforma projetada em torno de repositórios e colaboração humana consegue se adaptar tão rapidamente quanto uma plataforma cuja identidade principal de produto agora é agentes de IA realizando trabalho de software.
Origin é a aposta da Cursor de que a resposta deixa espaço para uma nova forja.
A interrupção do GitHub em 17 de agosto foi real e severa.
O incidente oficial durou de:
13:28 UTC
a
21:15 UTC
totalizando:
7 horas e 47 minutos
Durante o evento, as atualizações de status relataram taxas de erro substanciais no tráfego web/API e no acesso ao conteúdo do repositório, enquanto o Copilot também foi degradado.
A coincidência do lançamento criou uma narrativa irresistível:
GitHub cai
+
Cursor lança hospedagem Git
=
Cursor substitui o GitHub
Não foi isso que aconteceu operacionalmente.
Na verdade, o caminho de espelhamento do GitHub do próprio Origin ainda depende do GitHub enquanto o GitHub permanece como fonte da verdade.
E os agentes mais amplos da Cursor também podem depender de provedores externos de controle de versão.
Uma interrupção do GitHub, portanto, não é automaticamente uma demonstração de que todos os fluxos de trabalho da Cursor continuam inalterados.
A verdadeira lição diz respeito ao risco de concentração: quando uma plataforma de controle de versão está profundamente enraizada no desenvolvimento, uma longa interrupção afeta muito mais do que a navegação em repositórios.
O artigo de origem também coloca uma captura de tela da ação da Microsoft ao lado da história da Origin, mostrando as ações em queda de aproximadamente 3,2% no dia.
Essa é uma justaposição que chama a atenção.
Não é suficiente para concluir:
Origin lançou
→ Microsoft perdeu mais de US$ 100 bilhões
Ações de tecnologia de grande capitalização se movem por muitos motivos.
Sem evidências que isolem a causa, o movimento das ações deve ser tratado como contexto de mercado do mesmo dia, e não como uma reação direta à Origin.
Este artigo, portanto, não atribui a mudança no valor de mercado da Microsoft ao lançamento da Cursor.
Para a maioria das equipes, a resposta é:
Não tudo de uma vez.
A Origin ainda está em Beta inicial.
O caminho mais seguro é avaliá-la gradualmente.
Escolha:
Não comece com o repositório que implanta toda a sua plataforma de produção.
Mantenha o GitHub como fonte da verdade.
Avalie:
Isso oferece um caminho de reversão.
Crie comentários e revisões em ambos os lados.
Verifique se:
Se você usa Vercel, Depot,
ou Buildkite, conecte-os e verifique:
Não presuma que o estado da plataforma GitHub Actions seja migrado automaticamente.
Execute Cloud Agents no repositório espelhado.
Meça:
Verifique:
O host do repositório passa a fazer parte do seu perímetro de segurança.
Use:
Configurações
→ Geral
→ Zona de Perigo
→ Desanexar do GitHub
somente quando a equipe tiver decidido intencionalmente que o Origin deve se tornar a fonte autoritativa.
Após a desanexação, pushes para o Origin não retornam mais ao GitHub.
O Origin é especialmente interessante se sua equipe já usa o Cursor intensamente.
Bons candidatos incluem equipes que:
A vantagem da integração é mais forte quando o Cursor já está no centro do fluxo de trabalho de engenharia.
O GitHub continua sendo a escolha mais conservadora para equipes que dependem de:
A própria documentação do Early Beta do Origin reconhece que alguns recursos específicos da plataforma GitHub não são transferidos com o espelhamento de repositórios.
Um host de código não é apenas armazenamento de objetos Git. É um ecossistema.
Hoje, a descrição mais precisa é:
O Origin é um host Git real
+
um espelho do GitHub
+
uma superfície de PR/revisão
+
uma camada de repositório integrada a agentes
Ainda não é:
uma substituição direta para todos os recursos do GitHub
Essa distinção importa para o planejamento de migração.
Uma equipe já pode hospedar código inteiramente no Origin.
Isso não significa que todos os seus GitHub Issues, configurações de Actions, segredos, aplicativos do marketplace, políticas, fluxos de trabalho públicos da comunidade e processos empresariais sejam movidos automaticamente.
O argumento final do artigo original é mais forte do que seu título.
O Cursor não está competindo apenas com o GitHub pelo armazenamento de repositórios.
Ele está competindo pelo lugar onde o trabalho de software se torna autoritativo.
Na stack mais antiga:
Desenvolvedor
→ IDE
→ GitHub
→ CI
→ deploy
Na stack emergente do Cursor:
Objetivo humano
→ Agente do Cursor
→ Origin
→ PR
→ verificações automatizadas
→ integração de deployment
Se
os agentes tornam-se os principais produtores de mudanças, a plataforma de repositório que coordena esses agentes pode se tornar tão estrategicamente importante quanto o editor.
É por isso que Desvincular do GitHub importa mais do que as piadas do dia do lançamento.
Um espelho é conveniente.
Uma nova fonte de verdade é uma mudança de plataforma.
O Origin é a plataforma de hospedagem Git e compartilhamento de código da Cursor. Na Beta inicial, ele pode hospedar repositórios, usar clone/push/pull padrão do Git, espelhar repositórios do GitHub, navegar e pesquisar código, abrir e mesclar pull requests, e conectar agentes Cursor e aplicativos de terceiros selecionados.
Não. A documentação atual da Cursor diz que o armazenamento de código do Origin está disponível nos planos Pro, Teams e Enterprise, e não está disponível em planos gratuitos. A implementação é gradual, então alguns usuários elegíveis podem receber acesso mais tarde do que outros.
O Origin pode se tornar a fonte de verdade para um repositório depois que você o desvincula do GitHub, mas atualmente não é uma substituição recurso por recurso de toda a plataforma GitHub. Issues do GitHub, configuração da plataforma GitHub Actions, segredos e muitas integrações do ecossistema não migram automaticamente.
Sim. O Origin pode espelhar repositórios do GitHub, incluindo histórico Git, branches, tags, código navegável e pull requests sincronizados bidirecionalmente. Enquanto o repositório permanecer espelhado, o GitHub continua sendo a fonte de verdade, e pushes através do Origin fluem de volta para o GitHub.
Ele interrompe a sincronização com o GitHub e converte o espelho do Origin em um repositório independente hospedado pelo Origin. O Origin se torna a fonte de verdade, e futuros pushes para o remoto do Origin não fluem mais para o GitHub; o repositório existente no GitHub é mantido intacto.
A documentação atual da Beta inicial da Cursor não lista um fluxo de trabalho nativo de PRs empilhados ou uma fila de mesclagem do Origin como recursos geralmente disponíveis. O lançamento diz que mais funcionalidades nativas para agentes estão chegando, então demonstrações anteriores ou alegações de roteiro não devem ser confundidas com a beta atualmente documentada.
A documentação atual de pull requests do Origin diz que o Origin exibe conflitos de mesclagem para que os usuários possam resolvê-los antes de mesclar. Coberturas públicas anteriores da demonstração Compile da Cursor descreveram ideias de resolução de conflitos com IA, mas isso não deve ser tratado como uma garantia documentada da Beta inicial.
Nenhuma evidência mostra isso. A Cursor começou a implementação do Origin em 17 de agosto, no mesmo dia em que o GitHub sofreu uma grande interrupção, criando uma coincidência altamente visível. O Origin já havia sido anunciado e demonstrado antes, então a interrupção não criou o produto da noite para o dia.
Cloud Agents](https://cursor.com/docs/cloud-agent): Agentes de codificação hospedados na nuvem que podem trabalhar diretamente com repositórios do Origin.
O Cursor Origin agora é uma plataforma real de hospedagem Git, não apenas um navegador do GitHub dentro do Cursor. Seu Early Beta pode hospedar repositórios, usar Git padrão, espelhar o GitHub, sincronizar pull requests em ambas as direções, navegar pelo código, gerenciar revisões, conectar aplicativos de CI/implantação e permitir que agentes do Cursor operem em repositórios hospedados no Origin.
O artigo original exagera ao apresentar vários recursos nativos de agentes como já implementados. A documentação oficial atual ainda não lista PRs empilhados nativos, fila de merge do Origin, resolução automática de conflitos por IA ou servidor MCP do Origin como recursos geralmente disponíveis no Early Beta. A própria Cursor afirma que mais funcionalidades nativas de agentes ainda estão por vir.
A interrupção do GitHub em 17 de agosto deu ao Origin um momento de lançamento excepcionalmente dramático, mas isso não significou que o GitHub foi substituído da noite para o dia. Para a maioria das equipes, o caminho sensato é primeiro espelhar um repositório não crítico, testar a sincronização e o CI, e só desanexar depois que o Origin provar que pode se tornar com segurança a fonte da verdade.
A mudança competitiva real não é que o Cursor "matou o GitHub"; é que o Cursor agora quer ser dono da
camada de repositório onde agentes de IA criam, revisam e publicam software.**
Comece com uma frase e tenha um site completo em minutos.
