Em 17 de agosto, o GitHub sofreu uma falha de serviço em larga escala; no mesmo dia, o Cursor abriu o Origin early beta para usuários pagantes. Os repositórios de código estão sendo integrados a Agentes em funcionamento contínuo, mas a infraestrutura de colaboração atual foi projetada para o ritmo de trabalho humano. Estudos mostram que 40,2% dos repositórios apresentam PRs de Agentes sobrepostos, com uma taxa de conflito de merge de 41,7%. O Cursor Origin foi projetado para escritas frequentes de Agentes, suportando 22,6 commits/s por repositório, integrando repositórios, PRs, checks e revisões. O Origin é posicionado como uma camada de controle acima do Git, redesenhando fluxos de colaboração frequente de Agentes. A xAI, X, SpaceX e o Cursor, todos sob o controle de Musk, já formam uma cadeia de produção de IA completa: o Colossus fornece poder computacional, o Grok fornece modelos, o Cursor executa código e o Origin gerencia o estado da engenharia. Enquanto o GitHub expande da colaboração humana para Agentes, o Cursor redesenhou o forge com base na carga de trabalho dos Agentes — os dois caminhos estão se tornando cada vez mais competitivos.Autor e fonte do artigo: LeiFeng.com
O proprietário do repositório de código está sendo transformado de um ser humano em um Agente.
Em 17 de agosto, o GitHub experimentou uma falha generalizada de serviço. As principais cadeias, incluindo Web, API, Actions, Pull Requests, Operações Git e Webhooks, foram afetadas sequencialmente, com taxas de erro em requisições Web e API chegando a cerca de 20% em alguns períodos.
No mesmo dia, o Cursor começou a liberar gradualmente o Origin early beta para todos os planos pagos. Repositórios, PRs, checks, revisões, merges e automações começaram a ser integrados em um único sistema, e a posição definida pelo Cursor foi clara: a hospedagem de código agora será projetada para “agent scale”.
Curiosamente, ambos os eventos ocorreram ao mesmo tempo, exatamente amplificando uma mudança: o repositório de código está sendo integrado a um número crescente de Agentes em execução contínua, enquanto a infraestrutura existente de colaboração de software foi historicamente adaptada ao ritmo de trabalho humano.
Um humano pode escrever horas de código e gerar apenas algumas commits; um agente pode modificar, fazer push, acionar verificações e iniciar a próxima rodada em minutos. A aceleração das commits é apenas superficial; a mudança mais profunda é que a escala de tempo de todo o sistema de produção de software está sendo comprimida.
Muitos dos novos problemas enfrentados pelo GitHub, muitos dos problemas que o Origin deseja resolver, talvez comecem aqui.
01 GitHub não envelheceu subitamente
Quando o GitHub foi criado, a unidade básica de colaboração em software era estável: a pessoa.
Um engenheiro escreve código por algumas horas e faz um commit; o desenvolvimento de uma funcionalidade leva dias e resulta em um PR; a revisão pode ocorrer meia hora depois ou no dia seguinte; a execução do CI por alguns minutos é normalmente aceitável, e lidar com conflitos de merge mais tarde não torna todo o sistema sem sentido.
Em torno desse ritmo, o GitHub estabeleceu os sistemas de Pull Request, Issue, Review, Actions, Webhook e permissões. Mesmo em projetos como o Linux Kernel, que mantém um alto volume de commits por longos períodos, esse ritmo ainda carrega uma clara escala de tempo humano.
LWN estatisticou que, durante todo o ciclo de desenvolvimento do Linux 7.0, houve 14.251 commits não de mesclagem, provenientes de 2.362 desenvolvedores. Esses commits ocorreram ao longo de ciclos de desenvolvimento que duram semanas, com discussões por e-mail, revisões de mantenedores, integração de subsistemas e ciclo de lançamento.
O Cursor apresentou outro tipo de carga na demonstração de lançamento do Origin em junho: 22,6 commits/s em um único repositório.
Este número pertence aos dados de demonstração ao vivo e não é um benchmark de produção reproduzido independentemente; não prova que o Origin possa manter o mesmo throughput de forma sustentada em cenários reais. Mas é suficiente para ilustrar o tipo de workload que o Origin visa: muitos Agentes realizando escritas contínuas no mesmo estado de código.
Desenvolvedores humanos têm naturalmente limites de taxa. Pensar, escrever código, participar de reuniões e descansar criam grandes períodos em branco entre envios, portanto, um forge projetado em torno de humanos pode transferir boa parte da pressão do sistema para o tempo absorver.
O agente não tem essa limitação.
Diversos Agentes podem bifurcar simultaneamente a partir do mesmo SHA base, modificar arquivos relacionados em momentos próximos, e depois fazer push, abrir PR, invocar verificações, ler revisões, modificar o código e fazer push novamente. Um único commit pode ainda acionar atualizações de índice, verificações de permissão, Webhooks, CI, varredura de código, atualização do status de revisão e cálculo de mergeabilidade.
Portanto, o que precisa suportar as mudanças não é o próprio modelo de objetos do Git, mas sim o plano de controle da forge sobre o Git: API, autenticação, tarefas em segundo plano, agendamento de CI, Webhooks, proteção de branch, estado de revisão, fila de merge e a carga em cascata formada entre esses componentes.
Um estudo publicado em julho sobre Agent PRs no GitHub já observou esse padrão concorrente. O estudo analisou 33.596 Agent PRs em 2.807 repositórios, e 40,2% dos repositórios apresentaram Agent PRs com sobreposição temporal.
Em modificações concorrentes reproduzidas por amostragem, a proporção de conflitos de merge de texto entre PRs de diferentes Agentes foi de 41,7%, enquanto entre PRs concorrentes gerados pelo mesmo Agente foi de 19,8%.
A colaboração entre múltiplos agentes traz, portanto, novos problemas de controle de concorrência. O incidente do GitHub não prova que o tráfego de agentes já superou a infraestrutura existente, mas fornece exatamente uma janela de observação: quando a produção de software passa de eventos humanos de baixa frequência para eventos máquinas de alta frequência, o planejamento de capacidade, o design de filas, a propagação de estado e os modelos de consistência enfrentam um tipo diferente de carga de trabalho.
O design do Origin também se desenvolve a partir daqui.
02 Origin Reescrever custos de colaboração
Se o Origin apenas adicionar uma entrada de hospedagem de repositório Git, será difícil desafiar as relações de desenvolvedores, o ecossistema de código aberto, o sistema de permissões corporativas e a cadeia de ferramentas já estabelecidos pelo GitHub.
Sua oportunidade vem do agente que alterou os custos de colaboração. O stacked PR é um exemplo típico.
Desenvolvedores humanos tendem a organizar uma funcionalidade em um PR relativamente completo. Cada vez que um PR é dividido, aumenta-se o contexto, o ciclo de revisão e as dependências de branch. Se uma alteração for dividida em dezenas de PRs, as pessoas facilmente gastam grande parte de sua energia mantendo essas relações.
A estrutura de custos do agente é diferente. Quando uma modificação abrange dezenas de arquivos, qualquer falha em um passo pode exigir que o agente reinterprete um grande contexto. Ao dividir em conjuntos de alterações menores, as modificações no schema, serviço, UI, etc., podem formar dependências claras, com cada nó verificado separadamente e, em caso de falha, apenas as partes relacionadas são tratadas.
Um pequeno PR pode, portanto, servir como checkpoint do Agente, permitindo que a tarefa tenha capacidades de validação local, retenção local e rastreamento de dependências.
A aquisição do Cursor pelo Graphite também pode ser entendida aqui. A versão early beta atual do Origin ainda não incorpora completamente o fluxo de trabalho empilhado do Graphite, mas o investimento de longo prazo do Graphite em PR empilhados e fila de merge consciente de pilhas corresponde exatamente ao gargalo posterior que surge após o agente aumentar a velocidade de geração de código.
Após o aumento da quantidade de PRs, a responsabilidade da fila de merge também aumenta. O Agente A e o Agente B podem trabalhar simultaneamente a partir do mesmo SHA base, passando nos testes separadamente.
Após A entrar no main, os resultados do teste de B só comprovam que o código é válido no estado anterior, mas não garantem que ainda seja seguro após entrar no novo main. Portanto, a fila precisa reconstruir os estados candidatos com base no main em constante mudança, reexecutar os checks e lidar com as dependências entre PRs.
Conflicts can also gradually evolve from manual interruptions into recoverable failure states within the pipeline. Cursor already provides /babysit capabilities to continuously handle PR feedback, failed checks, and conflicts. When a candidate merge encounters issues, the relevant context can be reassigned to an Agent to correct and revalidate it in an isolated environment.
A revisão também será estruturada. A colaboração humana depende fortemente de linguagem natural e experiência da equipe, enquanto agentes em execução prolongada precisam ler claramente qual check falhou, quais threads ainda não foram resolvidas, qual política não foi atendida e qual é o SHA atual do head.
Origin já expôs por API os objetos repository, commit, checks, PR, etc., e distingue revisão formal de discussão comum.
Esses estados estruturados podem ser consumidos diretamente pelas Automations. O push, PR aberto ou PR enviado aciona o cloud agent, cujos resultados são gravados nos checks e PR; em caso de falha, segue-se para o processo de tratamento. MCP, hooks e Agent API permitem que ferramentas externas se integrem à mesma cadeia de eventos.
“Desvincular do GitHub” resolve o caminho de migração. A equipe pode primeiro fazer o mirror do repositório GitHub, mantendo o GitHub como source of truth, enquanto transfere os fluxos de trabalho do Agent para o Origin; após a operação estar estável, pode desconectar a sincronização e deixar o Origin gerenciar o repositório independentemente.
Isso permite que o Cursor primeiro assuma o agente, PR, revisão, verificações e automação, e gradualmente mantenha mais estados de engenharia em seu próprio sistema.
A lógica do produto do Origin é, portanto, clara: o Git continua a assumir o controle de versão; o que o Origin deseja reinventar é a camada de controle que gira em torno da colaboração de Agentes de alta frequência sobre o Git.
03 Lao Ma está consolidando uma cadeia de produção de IA
Nos últimos mais de um ano, uma série de ações entre xAI, X, SpaceX e Cursor foi gradualmente formando uma relação mais completa de cadeia de suprimentos.
xAI adquire X, em seguida integrando-se ao sistema SpaceX; Cursor obtém recursos de computação Colossus e também entra no sistema SpaceX. Ao mesmo tempo, Grok 4.6 é lançado e Origin começa a ser aberto.
Esse caminho é semelhante à abordagem de integração vertical que Musk adotou anteriormente na Tesla: quando os elos externos começam a aumentar a fricção de iteração, continua-se a se expandir para montante e jusante, incorporando as interfaces-chave em um único sistema.
O agente atualmente enfrenta exatamente esse problema. O modelo pode realizar o raciocínio, mas uma tarefa de software também exige acesso ao repositório, modificação de arquivos, execução de testes, processamento de CI, recebimento de revisões, resolução de conflitos e recuperação da execução após falhas.
Se essas etapas estiverem dispersas em vários sistemas, cada tarefa exigirá sincronização repetida de permissões, contexto e estado, e os custos de interface se acumularão continuamente no loop de Agent.
Colossus, Grok, Cursor e Origin podem corresponder a diferentes níveis nesta cadeia: Colossus fornece poder de processamento, Grok fornece capacidade de modelo, Cursor fornece agente de código e ambiente de execução, Origin armazena repositórios, PRs, status de checks e revisões.
O código gera uma cadeia contínua: o modelo toma uma decisão, o Cursor converte essa decisão em alterações reais e o Origin salva o estado do projeto e gerencia o controle colaborativo subsequente.
Isso também alterou a métrica para avaliar o Grok 4.6. As capacidades do modelo ainda são importantes, mas a saída do sistema Agent também depende do ambiente de execução e da infraestrutura de engenharia. Um código, mesmo com boa qualidade de geração, dificilmente terá sua capacidade do modelo amplificada continuamente se ainda exigir cópia, execução, verificação e reenvio manuais.
Depois que o modelo atingir um nível utilizável, a velocidade com que o código pode entrar nos processos de execução, validação e integração passará a afetar cada vez mais a produção do sistema inteiro.
A posição do X nessa cadeia ainda permanece relativamente nebulosa. Ele possui conteúdo em tempo real, relações de usuários, identidade e rede de distribuição, podendo vir a se tornar uma fonte de tarefas e ponto de entrada para distribuição no futuro; atualmente, o Grok Bot se assemelha mais à camada de execução contínua de tarefas do que ao simples “chatbot passivo que aguarda perguntas” que muitos imaginam.
Por que o Cursor precisa do Origin? Isso também explica: após a geração do código, é necessário um sistema que mantenha permanentemente o estado do projeto, coordene modificações, valide resultados e conecte as execuções subsequentes. Se esse ponto permanecer sempre externo, a cadeia de produção de software do Agent terá uma dependência crítica.
E o Origin preenche exatamente esse nível.
04 Divergência entre GitHub e Origin
O GitHub já possui PR empilhados, fila de merge, API REST, e continua integrando o agente de codificação Copilot ao Issue, Actions, PR e revisão de código. Olhando apenas a lista de funcionalidades, os dois lados terão cada vez mais sobreposição no futuro.
A diferença vem principalmente das premissas de design.
O GitHub é construído sobre uma rede madura de desenvolvedores humanos, portanto, o caminho mais natural é permitir que o Agente entre nos sistemas existentes de Issues, PRs, Actions e proteção de branches.
O Cursor pode redesenhar esses componentes a partir da colaboração de agentes de alta densidade. Se dezenas de agentes forem executados por longos períodos em um repositório, com aumento no número de PRs, diminuição da granularidade das alterações e aceleração das mudanças de estado, os sistemas de revisão, verificações, mesclagem e permissões precisam ser reorganizados em torno do comportamento das máquinas.
O papel do PR também pode se expandir. Pode evoluir de uma alteração de código principalmente destinada à leitura humana para se tornar uma unidade de trabalho de engenharia que inclui diff, dependências, evidências de teste, origens, níveis de risco e status de aprovação.
As responsabilidades humanas passarão a estar mais no nível das regras: quais diretórios permitem modificação automática, até que versão a atualização de dependências é permitida, quais validações são necessárias para migrações de banco de dados, quais aprovações são exigidas para código relacionado a autenticação e pagamento, e em quais situações o Agent deve ser interrompido.
Consequentemente, as métricas do Agent-native forge também mudarão. 22,6 commits/s é notável, mas o número de commits por si só não representa a eficiência da produção de software. Métricas mais significativas seriam o tempo gasto desde a entrada da tarefa no sistema até o merge, a capacidade de recuperação local após falhas, a proporção de modificações concluídas automaticamente pelo policy, o custo computacional das mudanças aceitas e a atenção humana consumida por modificações de alto risco.
O que o Origin deseja controlar é exatamente a superfície de controle de produção de software formada pela convergência de repository, checks, review, permissões e events.
A competição entre GitHub e Origin, portanto, tenderá a se concentrar em dois caminhos: GitHub expandindo-se a partir de um sistema maduro de colaboração humana para Agentes, enquanto o Cursor tenta redesenhar o forge com base na carga de trabalho dos Agentes.
05 Lao Ma já está no próximo nível
Por outro lado, após o lançamento do Grok 4.6, é fácil para o público continuar discutindo sobre benchmarks, capacidade de código, pontuações de raciocínio e preço. Mas ao considerar juntos Colossus, Grok, Cursor e Origin, na verdade esse planejamento já se estendeu para a cadeia de produção de software após o modelo.
Colossus fornece poder de processamento, Grok realiza inferência, Cursor transforma a capacidade do modelo em alterações de código e Origin gerencia o estado posterior do repositório, PRs, checks e revisões. À medida que a capacidade do modelo melhora, os ganhos podem ser transmitidos diretamente ao longo da cadeia de execução; mesmo que um único modelo não apresente diferenças significativas, a infraestrutura subsequente ainda pode continuar acumulando avanços.
Então, a posição do Grok 4.6 hoje em uma determinada lista pode ser apenas um resultado temporário. A questão mais prolongada é quem conseguirá organizar o modelo, o ambiente de execução e o estado da engenharia de software em um sistema de produção em funcionamento contínuo.
Enquanto todos ainda discutem qual modelo é mais inteligente nesta rodada, ninguém percebe que o velho Ma já chegou ao próximo nível.