Ago 17, nagkaroon ng malawakang service outage sa GitHub, at sa parehong araw, inilunsad ng Cursor ang Origin early beta para sa mga bayad na user. Ang code repository ay nagsasama ng Agent na patuloy na tumatakbo, at ang umiiral na infrastructure para sa pagtatrabaho ay disenyo para sa ritmo ng paggawa ng tao. Ang pag-aaral ay nagpapakita na 40.2% ng mga repository ay may overlapping Agent PR, na may rate ng merge conflict na 41.7%. Ang Cursor Origin ay disenyo para sa malaking pagkakasulat ng Agent, na sumusuporta sa 22.6 commit/s bawat repository, at nag-iintegrate ng repository, PR, checks, at review. Ang Origin ay itinuturing na control layer sa itaas ng Git, na bumubuo muli ng mga proseso para sa malalaking pagtutulungan ng Agent. Ang xAI, X, SpaceX, at Cursor ni Musk ay nabuo na ang isang kompletong AI production chain, kung saan ang Colossus ang nagbibigay ng computing power, ang Grok ang nagbibigay ng model, ang Cursor ang nagpapatupad ng code, at ang Origin ang nagpapamahala sa estado ng engineering. Habang ang GitHub ay lumalawak mula sa tao hanggang sa Agent, ang Cursor ay bumuo muli ang forge batay sa workload ng Agent—at ang dalawang landas na ito ay nagsisigalang nang mas malakas.

May-akda ng artikulo, pinagkunan: Leifengwang

Ang may-ari ng code repository ay nagiging Agent.

Ago 17, may malawakang serbisyo anomaly sa GitHub. Ang Web, API, Actions, Pull Requests, Git Operations, Webhooks at iba pang pangunahing link ay nakaapekto nang paulit-ulit, at sa ilang panahon, ang rate ng error sa Web at API ay malapit sa 20%.

Sa parehong araw, unti-unting inilabas ni Cursor ang Origin early beta sa lahat ng bayad na plano. Ang repository, PR, checks, review, merge, at Automations ay nagsimulang isama sa iisang sistema, at malinaw ang posisyon ni Cursor: ang code hosting ay dapat magsimulang disenyo para sa “agent scale”.

Kakaibang bagay ay ang dalawang pangyayaring ito ay nangyari nang sabay-sabay sa parehong oras, na nagpapakita ng isang pagbabago: ang code repository ay nag-iintegrate ng mas maraming patuloy na nagpapatakbo na Agent, habang ang umiiral na software collaboration infrastructure ay matagal nang nakakatugon sa ritmo ng paggawa ng tao.

Maaaring gumawa ng ilang oras ng code ang isang tao, ngunit maaaring magresulta lamang sa ilang commit; ang isang agent ay maaaring mag-modify, mag-push, at mag-trigger ng mga check sa loob ng ilang minuto, at patuloy sa susunod na siklo batay sa resulta. Ang pagiging mas mabilis ng pag-submit ay lamang ang panlabas na pagbabago; ang mas malalim na pagbabago ay ang pagkabawas ng panahon sa buong sistema ng paggawa ng software.

Maraming bagong problema na kinakaharap ng GitHub, maraming problema na gustong lutasin ng Origin, maaaring magsimula dito.

01 Hindi biglaang lumalang sa GitHub

Noong ipinatupad ang GitHub, ang patuloy na pangunahang yunit sa pagkakasama-samang software ay ang tao.

Iminumula ng ilang oras ang isang engineer para sa code, isumite ang isang commit; isang feature ay binubuo ng ilang araw ng pag-unlad, at bumubuo ng isang PR; ang pagrereview ay maaaring makita sa loob ng kalahating oras o maaaring magmula sa susunod na araw; ang pagpapatakbo ng CI sa ilang minuto ay karaniwang tatanggapin, at ang pag-aayos ng merge conflict ay maaaring gawin nang huli nang hindi mawala ang kahalagahan ng buong sistema.

Sa paligid ng ritmong ito, itinatag ng GitHub ang mga Pull Request, Issue, Review, Actions, Webhook, at sistema ng mga pribilehiyo. Kahit isama sa isang proyekto tulad ng Linux Kernel na patuloy na nagpapakita ng mataas na bilang ng pag-submit, ang ritmong ito ay nananatiling may malinaw na sukat ng panahon ng tao.

Ayon sa LWN, mayroong 14,251 non-merge commits sa buong development cycle ng Linux 7.0, mula sa 2,362 na developer. Ang mga pag-submit na ito ay nangyari sa loob ng ilang linggo ng development cycle, kasama ang mga diskusyon sa email, pagsusuri ng mga tagapangalaga, integrasyon ng subsystem, at release cycle.

Ipinakita ng Cursor sa pagpapakita ng Origin noong Hunyo ang isang iba pang anyo ng load: 22.6 commit/s sa iisang repository.

Ang numero na ito ay bahagi ng live demo data at hindi isang production benchmark na na-replicate nang independiyente; hindi ito nagpapatotoo na ang Origin ay maaaring magpanatili ng parehong throughput sa totoong negosyo. Gayunpaman, sapat ito upang ipakita kung anong uri ng workload ang tinutugon ng Origin: maraming Agent na patuloy na sumusulat sa iisang estado ng code.

Ang mga developer na tao ay may natural na limitasyon sa pagpapalabas. Ang pag-iisip, pagsusulat ng code, pagpupulong at pagsisigla ay gumagawa ng malaking puwang sa pagitan ng mga pag-submit, kaya ang mga forge na disenyo ayon sa tao ay maaaring ilipat ang maraming presyon sa sistema sa pagkakaroon ng oras.

Hindi mayroong limitasyong ito ang agent.

Maaaring magkakasabay na mag-fork ng isang base SHA ng maraming Agent, baguhin ang kaugnay na mga file sa malapit na panahon, at pagkatapos ay mag-push nang sabay-sabay, buksan ang PR, i-trigger ang mga pagsusuri, basahin ang mga review, baguhin ang code, at mag-push muli. Maaari ring mag-trigger ang isang commit sa pag-update ng index, pagsusuri ng mga pahintulot, Webhook, CI, pag-scan ng code, pag-refresh ng estado ng review, at pagkalkula ng mergeability.

Kaya ang hindi nagbabago ay ang sariling Git object model, kundi ang forge control plane sa itaas ng Git: ang API, authentication, background tasks, CI scheduling, webhooks, branch protection, review state, merge queue, at ang cascade load na nabubuo sa pagitan ng mga komponenteng ito.

Isinagawa noong Hulyo ang isang pag-aaral tungkol sa Agent PR sa GitHub na nakakita ng parehong anyo ng pagkakasunod-sunod. Sinuri ng pag-aaral ang 33,596 na Agent PR sa 2,807 na repository, at 40.2% ng mga repository ay may nagsasalungat na Agent PR sa panahon.

Sa mga parehong pagbabago na inirereplay sa sample, ang proporsyon ng text merge conflict sa pagitan ng mga Agent PR ay 41.7%, habang ang mga parehong PR na ginawa ng iisang Agent ay 19.8%.

Ang pagtatrabaho ng maraming agent ay magdudulot ng mga bagong problema sa pagkontrol ng pagkakasabay. Ang pagkabigo sa GitHub ay hindi nagpapatotoo na ang Agent traffic ay nagsabog sa umiiral na imprastruktura, ngunit ito ay nagbigay ng isang pagkakataon para makita: kapag ang produksyon ng software ay nagbabago mula sa mga pangyayari ng tao na may mababang kalikasan patungo sa mga pangyayari ng makina na may mataas na kalikasan, ang pagpaplano ng kapasidad, disenyo ng queue, pagpropaganda ng estado, at modelo ng konsistensya ay nakaharap sa isang ibang uri ng workload.

Ang disenyo ng Origin ay nagmumula rito.

02 Origin I-rewrite ang gastos sa pagtatrabaho kasama

Kung ang Origin ay nagdaragdag lamang ng isang entry point para sa pag-host ng Git repository, mahirap nito na husgahan ang mga ugnayang developer, open-source ecosystem, enterprise permission system, at toolchain na nabuo na ng GitHub.

Ang kanyang pagkakataon ay galing sa pagbabago ng mga gastos sa pagtatrabaho ng Agent. Ang stacked PR ay isang karaniwang halimbawa.

Karaniwan sa mga developer na tao na isama ang isang tampok bilang isang relatif na kompletong PR. Bawat paghihiwalay ng isang PR ay nagdaragdag ng konteksto, isang pagrereview, at isang hanay ng mga branch dependency. Kung isang pagbabago ay hihiwalay sa mga dekada ng PR, madali para sa tao na magamit ang malaking bahagi ng kanilang enerhiya sa pagpapanatili ng mga ugnayang ito.

Magkakaiba ang istruktura ng gastos ng agent. Kapag isang pagbabago ay sumasaklaw sa mga dekada ng mga file, anumang pagkabigo sa anumang hakbang ay maaaring magrequire sa agent na muli pang maunawaan ang malawak na konteksto. Pagkatapos ihiwalay sa mas maliit na set ng pagbabago, ang mga pagbabago sa schema, service, UI, atbp. ay maaaring bumuo ng malinaw na pagkakasunod-sunod, at bawat node ay maaaring masuri nang hiwalay, at kapag may pagkabigo, tanging ang kaugnay na bahagi ang aabotin.

Ang maliit na PR ay maaaring maging checkpoint ng Agent, na nagbibigay sa task ng kakayahang lokal na i-verify, lokal na i-retry, at masundan ang mga dependency.

Ang pagkuha ni Cursor sa Graphite ay maaari ring maintindihan dito. Ang kasalukuyang early beta ni Origin ay hindi pa buo ang pagtatanggap sa stacked workflow ng Graphite, ngunit ang matagal nang pagsisikap ng Graphite sa stacked PR at stack-aware merge queue ay direktang tumutugon sa susunod na bottleneck na lumabas pagkatapos ng pagtaas ng bilis ng paggawa ng code ng Agent.

Pagkatapos ng pagtaas ng bilang ng PR, lalaki rin ang responsibilidad ng merge queue. Maaaring magtrabaho ang Agent A at Agent B nang sabay-sabay mula sa parehong base SHA, at pareho ang nakakapasa sa pagsubok.

Pagkatapos mabuksan ang main, ang resulta ng pagsubok ni B ay nagpapatotoo lamang na ang code ay tumutugon sa lumang estado, at hindi nagpapatotoo na ligtas pa rin ito pagkatapos mabuksan ang bagong main. Kaya kailangan ng queue na muling bumuo ng mga kandidatong estado batay sa patuloy na nagbabagong main, muling i-execute ang mga checks, at tratuhin ang mga dependensya sa pagitan ng mga PR.

Ang mga konflikto ay maaaring maging isang maaaring mabawi na estado ng pagkabigo sa pipeline mula sa manu-manong pagpapahinto. Binibigyan na ng Cursor ang /babysit tulad ng kakayahan, patuloy na pagtrato sa feedback ng PR, nabigo ang mga checks at mga konflikto. Pagkatapos makita ang isyu sa candidate merge, maaaring ibalik ang kaugnay na konteksto sa Agent para sa pagkorekta at pagpapatotoo sa isang isolated na kapaligiran.

Ang pagsusuri ay magiging struktural din. Ang malawakang pagkakasundo ng tao ay nakadepende sa likas na wika at karanasan ng grupo, habang ang mga agent na nagtatrabaho nang matagal ay kailangang malinaw na basahin kung anong check ang nabigo, anong thread ay hindi pa nalulutas, anong patakaran ang hindi natutupad, at ano ang kasalukuyang head SHA.

Nilabas na ng Origin ang repository, commit, checks, PR at iba pang mga objekto sa pamamagitan ng API, at hinati ang formal review mula sa karaniwang diskusyon.

Maaaring direktang gamitin ng Automations ang mga structured state na ito. Ang push, PR opened o PR pushed ay nagpapalabas ng cloud agent, at isinusulat ang resulta pabalik sa checks at PR, at kung may pagkabigo, papasok sa proseso ng pagtrato. Ang MCP, hooks, at Agent API ay nagpapahintulot sa mga panlabas na tool na sumali sa parehong event chain.

Ang “Detach from GitHub” ay naglutas ng migration path. Maaari ngang mag-mirror ang team sa GitHub repository, habang pinapanatili ang GitHub bilang source of truth, samantalang inililipat ang Agent workflow sa Origin; pagkatapos ay, matapos maging stable ang pagpapatakbo, pipigilin ang pag-sync at isasagawa ng Origin ang independiyenteng pamamahala sa repository.

Nagpapahintulot ito sa Cursor na unang makuha ang Agent, PR, review, checks, at Automation, at pagkatapos ay unti-unting panatilihin ang higit pang engineering state sa sarili nitong sistema.

Kaya malinaw ang produkto logika ng Origin: patuloy na magtatanggol ang Git sa version control, at ang gustong i-rebuild ng Origin ay ang kontrol na layer sa itaas ng Git na nakabatay sa pagtatrabaho ng mga高频 Agent.

03 Si Lao Ma ay nagpapalapit sa isang AI production chain

Sa nakalipas na isang taon, ang mga hakbang na ginawa ng xAI, X, SpaceX, at Cursor ay unti-unting nagbuo ng mas kompletong ugnayan sa iba’t ibang antas ng supply chain.

Kinuha ng xAI ang X, sumunod ay pumasok sa sistema ng SpaceX; kinuha ng Cursor ang mga mapagkukunan ng computation na Colossus, at sumunod ay pumasok din sa sistema ng SpaceX. Samantala, inilabas ang Grok 4.6, at nagsimula na ang Origin na magbigay ng pag-access.

Kapareho ng estratehiya ng vertical integration na ginamit ni Musk sa Tesla: kapag ang mga eksternal na bahagi ay nagsisimulang magdulot ng friction sa pag-iterate, patuloy na umiiwas sa pataas at pababa upang isama ang mga mahahalagang interface sa isang magkakaugnay na sistema.

Ang problema na kinakaharap ng agent ay ang ganitong uri. Ang modelo ay makakapagtapos ng reasoning, ngunit kailangan pa ng isang software task na mag-access sa repository, baguhin ang mga file, jalurin ang mga pagsubok, tratuhin ang CI, tanggapin ang review, lutasin ang mga konflikto, at muling i-correct ang pagpapatupad pagkatapos ng pagkabigo.

Kung ang mga bahaging ito ay nakalat sa maraming sistema, ang bawat siklo ng gawain ay nangangailangan ng paulit-ulit na pag-sync ng mga pahintulot, konteksto, at estado, at ang mga gastos sa interface ay magkakaroon ng patuloy na akumulasyon sa patuloy na tumatakbo na Agent loop.

Ang Colossus, Grok, Cursor, at Origin ay maaaring makatugma sa iba’t ibang antas ng chain na ito: ang Colossus ay nagbibigay ng computing power, ang Grok ay nagbibigay ng model capability, ang Cursor ay nagbibigay ng code agent at execution environment, at ang Origin ay nag-iimbak ng repository, PR, checks, at review status.

Ang paggawa ng code ay bumubuo ng isang tuloy-tuloy na link: ang modelo ay gumagawa ng desisyon, ang Cursor ay isinasalin ang desisyon sa mga aktwal na pagbabago, at ang Origin ay nag-iimbak ng estado ng proyekto at nagtataglay ng kontrol sa susunod na pakikipagtulungan.

Nagbago rin ito ang pamantayan sa pag-evaluate ng Grok 4.6. Mahalaga pa rin ang kakayahan ng modelo, ngunit ang output ng Agent system ay nakadepende rin sa execution environment at engineering infrastructure. Kahit magandang kalidad ang isang code, kung kailangan pa rin ng tao na kopyahin, i-execute, i-check, at i-submit muli, mahirap palawakin ang kakayahan ng modelo.

Pagkatapos ay makamit ng modelo ang antas ng paggamit, ang bilis ng pagpapasok ng code sa proseso ng pagpapatupad, pagsusuri, at pagpapagsama ay lalong magdudulot ng epekto sa output ng buong sistema.

Ang posisyon ng X sa chain ay kasalukuyang hindi pa malinaw. Mayroon ito ng real-time na nilalaman, ugnayan ng mga user, identity, at network ng pagpapalaganap, at maaaring maging pinagkukunan at entry point ng mga gawain sa hinaharap; sa kasalukuyan, mas malapit ang Grok Bot sa antas ng patuloy na pagsasagawa ng mga gawain kaysa sa isang “pasibong naghihintay sa tanong na purong chatbot” na imahinasyon ng marami.

Bakit kailangan ng Cursor ang Origin, at maaari dito ipaliwanag: Pagkatapos ng paggawa ng code, kailangan ng isang sistema na magpanatili ng estado ng proyekto nang matagal, magcoordinating ng mga pagbabago, at i-verify ang mga resulta, at i-connect ang mga susunod na pagpapatupad. Kung ang posisyong ito ay palaging nasa labas, mayroong isang mahalagang pagkakasalalay sa chain ng paggawa ng Agent software.

At ang Origin ay nagpapuno sa antas na ito.

04 Ang pagkakaiba ng GitHub at Origin

Mayroon na ang GitHub sa stacked PR, merge queue, at REST API, at patuloy na pinapalalim ang integrasyon ng Copilot coding agent sa Issue, Actions, PR, at code review. Kung titingnan lang ang listahan ng mga tampok, lalalo pang magkakasabay ang dalawang plataporma sa hinaharap.

Ang pagkakaiba ay pangunahing nagmumula sa mga ipinagpalagay na disenyo.

Batay sa matatag na network ng mga human developer ang GitHub, kaya ang mas natural na landas ay ang pagpapasok ng Agent sa umiiral na Issue, PR, Actions, at branch protection system.

Ang Cursor ay maaaring muling disenyo ang mga komponenteng ito mula sa mataas na densidad na pagtatrabaho ng Agent. Kung mayroong ilang dosenang Agent na tumatagal sa isang repository, tumataas ang bilang ng PR, nagiging mas maliit ang laki ng pagbabago, at mas mabilis ang pagbabago ng estado, kailangan ng pagrereview, mga checks, pag-merge, at sistema ng pagsasakop na muling organisado batay sa pagkilos ng machine.

Ang papel ng PR ay maaari ring magpalawak. Maaari itong maging isang engineering artifact na naglalaman ng diff, mga dependency, ebidensya ng pagsubok, pinagmulan, antas ng panganib, at estado ng pag-apruba, mula sa isang pagbabago sa code na pangunahing para sa pagbabasa.

Ang mga tungkulin ng tao ay mas maraming pumasok sa antas ng patakaran: aling mga direktoryo ang pinapayagan na ma-automatic na baguhin, kung gaano kalaki ang bersyon na pinapayagan para sa pag-upgrade ng mga depensiyang, anong mga pagsusuri ang kailangan para sa database migration, anong mga pagsasapilitan ang kailangan para sa code na may kinalaman sa pag-authenticate at pagbabayad, at kailan dapat huminto ang Agent.

Kaya magkakaroon ng pagbabago ang mga tukoy ng Agent-native forge. Ang 22.6 commit/s ay nakakatangi, ngunit ang bilang ng mga commit ay hindi makakapagpapakita ng produktibidad sa paggawa ng software. Mas may kahulugan ang mga tukoy tulad ng oras mula sa pagpasok ng gawain sa sistema hanggang sa pag-merge, ang kakayahan sa lokal na pagbabalik pagkatapos ng pagkabigo, ang proporsyon ng mga pagbabago na natapos nang awtomatiko sa loob ng policy, ang kalkulasyong gastos ng mga tinanggap na pagbabago, at ang tulong na pansin na ginugol sa mga mataas na panganib na pagbabago.

Ang gustong kontrolin ng Origin ay ang software production control plane na nabubuo ng pagkakasama ng repository, checks, review, permissions, at events.

Kaya ang kompetisyon sa GitHub at Origin ay magiging sa dalawang landas: ang GitHub ay magsisimula mula sa matatag na sistema ng tao na pakikipag-ugnayan patungo sa Agent, habang ang Cursor ay subukang muli nang disenyo ang forge batay sa workload ng Agent.

05 Ang Lao Ma ay nasa susunod na antas na

Ngunit sa pagkakasunod-sunod, pagkatapos ng paglalabas ng Grok 4.6, madali para sa labas na patuloy na magdiskutso tungkol sa benchmark, code capability, reasoning scores, at presyo. Ngunit kapag tingnan ang Colossus, Grok, Cursor, at Origin nang magkasama, ang ganitong pagkakabuo ay nagsasabing nagsasabuhay na sa software production chain pagkatapos ng model.

Ang Colossus ay nagbibigay ng computing power, ang Grok ay nagdedeclare ng pag-iisip, ang Cursor ay binabago ang mga kakayahan ng model sa pagbabago ng code, at ang Origin ay tumatanggap ng susunod na estado ng repository, PR, checks, at review. Kapag tumataas ang kakayahan ng model, ang benepisyo ay direktang ipapadala sa chain ng pagpapatupad; kahit na ang isang generasyon ng model ay hindi malinaw na nagkakaroon ng pagkakaiba, ang mga susunod na imprastruktura ay maaari pa ring magpatuloy sa pagkolekta.

Kaya ang posisyon ng Grok 4.6 sa listahan ngayon ay maaaring pansamantalang resulta lamang. Ang mas mahabang panahong tanong ay sino ang makakapag-organisa ng model, execution environment, at software engineering state sa isang patuloy na gumagana na production system.

Habang patuloy pa ang pagkukumpetensya ng mga tao kung alin sa mga modelo ay mas matalino sa round na ito, hindi nila alam na ang Lao Ma ay nasa mas pababang antas na iyon.