Le 17 août, GitHub a connu une panne généralisée, et le même jour, Cursor a ouvert l'early beta d'Origin aux utilisateurs payants. Les dépôts de code sont en cours d'intégration avec des agents fonctionnant en continu, mais les infrastructures de collaboration actuelles sont conçues pour s'adapter au rythme de travail humain. Des études montrent que 40,2 % des dépôts présentent des PR d'agents chevauchants, avec un taux de conflits de fusion atteignant 41,7 %. Cursor Origin est conçu pour les écritures fréquentes d'agents, avec une capacité de 22,6 commits/s par dépôt, intégrant dépôts, PR, checks et revues. Origin est positionné comme une couche de contrôle au-dessus de Git, réinventant les processus de collaboration fréquente des agents. xAI, X, SpaceX et Cursor, tous sous la houlette de Musk, forment désormais une chaîne de production AI complète : Colossus fournit la puissance de calcul, Grok fournit les modèles, Cursor exécute le code et Origin gère l'état du projet. GitHub évolue de la collaboration humaine vers l'agent, tandis que Cursor redessine forge selon la charge de travail des agents ; les deux approches entrent en concurrence de plus en plus intense.

Auteur et source de l'article : Leifengwang

Le propriétaire du dépôt de code est en train de passer de l'humain à l'agent.

Le 17 août, GitHub a connu une panne généralisée. Les chaînes centrales telles que le Web, l'API, les Actions, les Pull Requests, les opérations Git et les webhooks ont été progressivement affectées, avec un taux d'erreurs pour les requêtes Web et API atteignant près de 20 % à certains moments.

Le même jour, Cursor a progressivement ouvert Origin early beta à tous les plans payants. Les dépôts, les PR, les checks, les revues, les fusions et les automatisations ont été intégrés dans un même système, et la position de Cursor était claire : le hébergement de code doit désormais être conçu pour « agent scale ».

Ce qui est amusant, c’est que ces deux événements se sont produits au même moment, amplifiant ainsi un changement : les dépôts de code intègrent de plus en plus d’agents en fonctionnement continu, tandis que les infrastructures existantes de collaboration logicielle ont longtemps été adaptées au rythme de travail humain.

Un humain peut passer plusieurs heures à écrire du code et ne produire que quelques commits ; un agent peut modifier, pousser et déclencher des vérifications en quelques minutes, puis poursuivre la prochaine itération en fonction des résultats. L'accélération des commits n'est qu'une surface ; le changement plus profond est que l'échelle de temps de l'ensemble du système de production logicielle est en train d'être compressée.

Beaucoup de nouveaux problèmes auxquels GitHub est confronté, et beaucoup de problèmes qu'Origin souhaite résoudre, pourraient commencer ici.

01 GitHub n'a pas soudainement vieilli

Lors de la création de GitHub, l'unité de base de la collaboration logicielle était stable : la personne.

Un ingénieur écrit quelques heures de code, puis effectue un commit unique ; le développement d'une fonctionnalité prend plusieurs jours et aboutit à une PR ; la revue peut apparaître après trente minutes ou le lendemain ; une exécution CI de quelques minutes est généralement acceptable, et traiter un conflit de fusion plus tard ne compromet pas l'ensemble du système.

Autour de ce rythme, GitHub a établi des systèmes de Pull Request, Issue, Review, Actions, Webhook et permissions. Même dans des projets comme le noyau Linux, qui maintient un volume élevé de commits sur le long terme, ce rythme conserve une échelle de temps humaine évidente.

LWN rapporte que, pendant tout le cycle de développement de Linux 7.0, il y a eu 14251 commits non-merge provenant de 2362 développeurs. Ces commits ont eu lieu au cours d'un cycle de développement s'étendant sur plusieurs semaines, avec des discussions par courriel, des revues par les maintainers, des intégrations de sous-systèmes et un cycle de publication.

Cursor a démontré un autre type de charge lors de la présentation d'Origin en juin : 22,6 commits/s dans un seul dépôt.

Ce chiffre provient des données de démonstration en direct et ne constitue pas un benchmark de production validé par une reproductibilité indépendante ; il ne prouve pas qu'Origin peut maintenir un débit équivalent à long terme dans des scénarios réels. Toutefois, il suffit à illustrer le type de charge utile visée par Origin : de nombreux agents effectuent continuellement des écritures sur un même état de code.

Les développeurs humains sont naturellement limités en débit. La réflexion, l'écriture de code, les réunions et les pauses créent de nombreux intervalles entre les soumissions ; par conséquent, un forge conçu autour des humains peut transférer une bonne partie de la charge système au temps pour qu'il l'absorbe.

L'agent n'a pas cette restriction.

Des dizaines d'agents peuvent simultanément bifurquer à partir du même SHA de base, modifier les fichiers associés à peu près en même temps, puis pousser ensemble, ouvrir une PR, lancer des vérifications, lire les avis, modifier le code et pousser à nouveau. Un seul commit peut également déclencher une mise à jour de l'index, des contrôles d'autorisations, des webhooks, CI, une analyse du code, une actualisation de l'état des avis et le calcul de la mergeabilité.

Ce n'est donc pas le modèle d'objets Git lui-même qui doit supporter les changements, mais surtout le plan de contrôle forge au-dessus de Git : l'API, l'authentification, les tâches d'arrière-plan, l'ordonnancement CI, les webhooks, la protection des branches, l'état des revues, la file de fusion, ainsi que la charge en cascade formée entre ces composants.

Une étude publiée en juillet sur les Agent PR sur GitHub a observé ce type de concurrence. L'étude a analysé 33 596 Agent PR dans 2 807 dépôts, et 40,2 % des dépôts ont présenté des Agent PR se chevauchant dans le temps.

Lors de modifications concurrentes rejetées par échantillonnage, le taux de conflits de fusion de texte entre les PR d'agents différents atteint 41,7 %, tandis qu'il est de 19,8 % pour les PR concurrents générés par le même agent.

La collaboration entre plusieurs agents introduit donc de nouveaux problèmes de contrôle de concurrence. Cette panne de GitHub ne prouve pas que le trafic des agents a submergé l'infrastructure existante, mais elle offre précisément une fenêtre d'observation : lorsque la production logicielle passe d'événements humains à faible fréquence à des événements machines à haute fréquence, la planification de la capacité, la conception des files d'attente, la propagation d'état et les modèles de cohérence font face à un autre type de charge de travail.

La conception d'Origin s'articule également à partir de là.

02 Origin Réécriture des coûts de collaboration

Si Origin se contente d'ajouter un point d'accès pour le hébergement de dépôts Git, il sera difficile de déstabiliser les relations avec les développeurs, l'écosystème open source, les systèmes de permissions entreprises et les chaînes d'outils déjà établis par GitHub.

Son opportunité provient du fait que les agents ont modifié les coûts de collaboration. Le stacked PR est un exemple typique.

Les développeurs humains ont tendance à regrouper une fonctionnalité en une PR relativement complète. Chaque division en PR supplémentaire ajoute un contexte, un cycle de revue et un ensemble de dépendances de branche. Si une modification est divisée en dizaines de PR, les gens risquent de consacrer une grande partie de leur énergie à maintenir ces relations.

La structure des coûts des agents est différente. Lorsqu'une modification traverse des dizaines de fichiers, toute défaillance à une étape peut obliger l'agent à réinterpréter un large contexte. En divisant en ensembles de modifications plus petits, les modifications de schéma, de service, d'interface utilisateur, etc., peuvent établir des dépendances claires, avec chaque élément vérifié séparément ; en cas d'échec, seule la partie concernée est traitée.

Un petit PR peut donc servir de point de contrôle pour l'agent, permettant à la tâche de disposer de capacités de validation locale, de réessai local et de suivi des dépendances.

L'acquisition de Graphite par Cursor peut également être comprise ainsi. La version early beta actuelle d'Origin ne prend pas encore entièrement en charge le workflow en pile de Graphite, mais les fonctionnalités longtemps développées par Graphite — les stacked PR et la file de fusion sensible aux piles — correspondent exactement aux goulots d'étranglement apparus après l'augmentation de la vitesse de génération de code par l'Agent.

Après l'augmentation du nombre de PR, la charge du merge queue augmente également. Les agents A et B peuvent travailler simultanément à partir du même SHA de base, chacun passant ses tests respectifs.

Après A est entré dans main, les résultats des tests de B ne prouvent que le code est valide dans l'état ancien, mais ne garantissent pas sa sécurité après l'entrée dans le nouveau main. Par conséquent, la file d'attente doit reconstruire les états candidats en fonction de main en constante évolution, réexécuter les vérifications et gérer les dépendances entre les PR.

Les conflits peuvent également évoluer progressivement depuis une interruption manuelle jusqu'à un état d'échec réparable dans la chaîne de traitement. Cursor propose déjà une fonctionnalité telle que /babysit, qui gère en continu les commentaires sur les PR, les checks échoués et les conflits. Lorsqu'un merge candidat rencontre un problème, le contexte associé peut être réattribué à l'Agent pour être corrigé et validé à nouveau dans un environnement isolé.

Les revues deviendront également structurées. La collaboration humaine repose largement sur le langage naturel et l'expérience d'équipe, tandis que les agents fonctionnant sur une longue période nécessitent de lire clairement quel contrôle a échoué, quels fils n'ont pas encore été résolus, quelle politique n'est pas satisfaite, et quel est le SHA actuel de la tête.

Origin a exposé via l'API les objets repository, commit, checks, PR, et distingue les révisions formelles des discussions ordinaires.

Ces états structurés peuvent ensuite être directement consommés par les Automations. Les déclencheurs push, PR opened ou PR pushed activent l’agent cloud, dont les résultats sont écrits à nouveau dans les checks et les PR ; en cas d’échec, le processus de traitement est déclenché. MCP, hooks et Agent API permettent à des outils externes de s’intégrer à la même chaîne d’événements.

« Se déconnecter de GitHub » résout le chemin de migration. L'équipe peut d'abord créer un miroir du dépôt GitHub, en gardant GitHub comme source de vérité, tout en déplaçant les flux de travail de l'agent vers Origin ; une fois le fonctionnement stable, elle peut interrompre la synchronisation et laisser Origin gérer le dépôt de manière indépendante.

Cela permet à Cursor de d'abord prendre en charge les agents, les PR, les revues, les vérifications et l'automatisation, puis de conserver progressivement davantage d'états de développement dans son propre système.

La logique produit d'Origin est donc claire : Git continue de gérer le contrôle de version, tandis qu'Origin vise à refondre la couche de contrôle qui tourne autour de la collaboration à haut débit des agents, située au-dessus de Git.

03 Lao Ma rationalise une chaîne de production IA

Au cours des douze derniers mois, une série d'actions entre xAI, X, SpaceX et Cursor a progressivement établi une relation plus complète en amont et en aval.

xAI acquiert X, puis intègre le système SpaceX ; Cursor obtient les ressources de calcul Colossus, puis intègre également le système SpaceX. Parallèlement, Grok 4.6 est publié et Origin commence à être ouvert.

Ce parcours ressemble à la stratégie d'intégration verticale adoptée par Musk précédemment chez Tesla : lorsque les étapes externes commencent à générer des frictions dans les itérations, on s'étend davantage en amont et en aval pour intégrer les interfaces clés au sein d'un même système.

L'agent fait actuellement face à ce problème. Le modèle peut effectuer un raisonnement, mais une tâche logicielle nécessite également d'accéder au dépôt, de modifier des fichiers, d'exécuter des tests, de gérer l'CI, de recevoir des avis, de résoudre des conflits et de reprendre l'exécution en cas d'échec.

Si ces étapes sont réparties dans plusieurs systèmes, chaque tâche nécessite de synchroniser à plusieurs reprises les autorisations, le contexte et l'état, ce qui fait s'accumuler les coûts d'interface dans la boucle d'Agent en cours d'exécution.

Colossus, Grok, Cursor et Origin correspondent respectivement à différents niveaux de cette chaîne : Colossus fournit la puissance de calcul, Grok offre des capacités de modèle, Cursor fournit un agent de code et un environnement d'exécution, Origin stocke les états des dépôts, des PR, des vérifications et des revues.

Le code génère ainsi une chaîne continue : le modèle prend une décision, Cursor transforme cette décision en modifications concrètes, et Origin enregistre l'état du projet et gère la collaboration ultérieure.

Cela modifie également les critères d'évaluation de Grok 4.6. Les capacités du modèle restent importantes, mais les résultats du système Agent dépendent également de l'environnement d'exécution et de l'infrastructure technique. Même si un code est généré avec une bonne qualité, s'il nécessite encore une intervention humaine pour le copier, l'exécuter, le vérifier et le soumettre à nouveau, les capacités du modèle peinent à être amplifiées de manière durable.

Une fois que le modèle atteint un niveau utilisable, la rapidité avec laquelle le code peut entrer dans les processus d'exécution, de validation et de fusion influencera de plus en plus la production globale du système.

La place de X sur cette chaîne reste actuellement floue. Il possède du contenu en temps réel, des relations utilisateurs, une identité et un réseau de distribution, et pourrait à l'avenir devenir une source de tâches et un point d'entrée pour la distribution ; à ce stade, Grok Bot ressemble davantage à une couche d'exécution continue de tâches qu'à un simple « chatbot passif attendant des questions », comme on pourrait l'imaginer.

Pourquoi Cursor a-t-il besoin de Origin ? Cela peut également expliquer que, après la génération du code, un système est nécessaire pour conserver à long terme l'état du projet, coordonner les modifications, valider les résultats et relier les exécutions suivantes. Si cet emplacement reste toujours externe, la chaîne de production du logiciel Agent présente une dépendance critique.

Et Origin comble précisément ce niveau.

04 Différences entre GitHub et Origin

GitHub possède déjà les PR empilées, la file de fusion, l'API REST, et continue d'intégrer l'agent Copilot Coding aux problèmes, Actions, PR et révisions de code. En regardant simplement la liste des fonctionnalités, les deux côtés connaîtront de plus en plus de chevauchements à l'avenir.

Les différences proviennent principalement des hypothèses de conception.

GitHub est construit sur un réseau mature de développeurs humains, donc le chemin le plus naturel consiste à intégrer l'Agent dans les systèmes existants d'issues, de PR, d'Actions et de protection des branches.

Cursor peut redessiner ces composants à partir de la collaboration à haute densité d'agents. Si des dizaines d'agents s'exécutent sur le long terme dans un dépôt, avec une augmentation du nombre de PR, une granularité de modification réduite et une accélération des changements d'état, les systèmes de revue, de vérification, de fusion et d'autorisations doivent être réorganisés autour du comportement machine.

Le rôle du PR peut également s'étendre. Il peut passer d'une modification de code principalement destinée à être lue à devenir une unité de travail d'ingénierie contenant le diff, les dépendances, les preuves de test, les sources, le niveau de risque et l'état d'approbation.

Les responsabilités humaines entreront davantage dans la couche des règles : quels répertoires autorisent les modifications automatiques, de combien de versions les mises à jour de dépendances sont autorisées, quelles validations sont requises pour les migrations de base de données, quelles approbations sont nécessaires pour le code lié à l'authentification et aux paiements, et dans quelles circonstances l'Agent doit s'arrêter.

En conséquence, les indicateurs de Agent-native forge évolueront également. 22,6 commit/s est remarquable, mais le nombre de commits ne représente pas en soi la productivité logicielle. Des indicateurs plus significatifs seraient le temps écoulé entre l'entrée d'une tâche dans le système et son fusion, la capacité de récupération locale après échec, la proportion de modifications effectuées automatiquement par la politique, le coût de calcul des changements acceptés, ainsi que l'attention humaine consacrée aux modifications à haut risque.

Origin souhaite contrôler la surface de production logicielle formée par la convergence des dépôts, des vérifications, des revues, des autorisations et des événements.

La concurrence entre GitHub et Origin se concentrera donc progressivement sur deux approches : GitHub étendra son système mature de collaboration humaine aux agents, tandis que Cursor tentera de redéfinir forge en fonction des charges de travail des agents.

05 Lao Ma est déjà au niveau inférieur

En revanche, après le lancement de Grok 4.6, il est facile pour l'extérieur de continuer à discuter des benchmarks, des capacités de codage, des scores de raisonnement et des prix. Mais en comparant Colossus, Grok, Cursor et Origin ensemble, on voit que cette stratégie s'étend désormais à la chaîne de production logicielle après le modèle.

Colossus fournit la puissance de calcul, Grok gère l'inférence, Cursor transforme les capacités du modèle en modifications de code, et Origin prend en charge les états suivants du dépôt, les PR, les checks et les revues. Lorsque les capacités du modèle s'améliorent, les gains peuvent être transmis directement le long de la chaîne d'exécution ; même si un modèle unique ne crée pas de différence significative, les infrastructures suivantes peuvent continuer à s'accumuler.

Ainsi, la position de Grok 4.6 aujourd'hui sur une telle liste n'est peut-être qu'un résultat temporaire. La question plus à long terme est de savoir qui sera capable d'organiser le modèle, l'environnement d'exécution et l'état de l'ingénierie logicielle en un système de production fonctionnant en continu.

Alors que tout le monde se dispute pour savoir quel modèle est le plus intelligent à cette étape, Musk est déjà passé au niveau inférieur.