Pada 17 Agustus, GitHub mengalami gangguan layanan luas, pada hari yang sama Cursor membuka Origin early beta kepada pengguna berbayar. Repositori kode sedang terhubung ke Agent yang berjalan terus-menerus, infrastruktur kolaborasi saat ini dirancang untuk ritme kerja manusia. Penelitian menunjukkan 40,2% repositori mengalami PR Agent tumpang tindih, dengan proporsi merge conflict mencapai 41,7%. Cursor Origin dirancang untuk penulisan frekuensi tinggi oleh Agent, mendukung 22,6 commit/detik per repositori, mengintegrasikan repositori, PR, checks, dan review. Origin ditempatkan sebagai lapisan kontrol di atas Git, merancang ulang alur kerja kolaborasi Agent frekuensi tinggi. xAI, X, SpaceX, dan Cursor di bawah Elon Musk telah membentuk rantai produksi AI lengkap, Colossus menyediakan daya komputasi, Grok menyediakan model, Cursor menjalankan kode, Origin mengelola status teknik. GitHub berkembang dari kolaborasi manusia ke Agent, Cursor mendesain ulang forge berdasarkan beban kerja Agent, dua jalur ini semakin bersaing ketat.

Penulis artikel, sumber: Leifengwang

Pemilik repositori kode sedang berubah dari manusia menjadi Agent.

Pada 17 Agustus, GitHub mengalami gangguan layanan luas. Jalur inti seperti Web, API, Actions, Pull Requests, Operasi Git, dan Webhook secara bertahap terdampak, dengan tingkat kesalahan permintaan Web dan API mendekati 20% pada beberapa periode.

Pada hari yang sama, Cursor mulai secara bertahap membuka Origin early beta untuk semua rencana berbayar. Repository, PR, checks, review, merge, dan Automations mulai dimasukkan ke dalam satu sistem yang sama, dan posisi yang diberikan Cursor juga sangat jelas: hosting kode mulai dirancang untuk "agent scale".

Yang menarik, kedua hal ini kebetulan terjadi pada waktu yang sama, secara tepat memperbesar perubahan: repositori kode sedang mengintegrasikan semakin banyak Agent yang berjalan terus-menerus, sementara infrastruktur kolaborasi perangkat lunak yang ada telah lama beradaptasi dengan ritme kerja manusia.

Manusia mungkin hanya menghasilkan beberapa commit setelah menulis kode selama beberapa jam; Agent dapat secara berurutan memodifikasi, mendorong, memicu pemeriksaan, dan melanjutkan putaran berikutnya berdasarkan hasilnya dalam hitungan menit. Percepatan commit hanyalah permukaan; perubahan yang lebih dalam adalah skala waktu keseluruhan sistem produksi perangkat lunak sedang diperpendek.

Banyak masalah baru yang dihadapi GitHub, banyak masalah yang ingin dipecahkan oleh Origin, mungkin akan dimulai dari sini.

01 GitHub tidak tiba-tiba menjadi tua

Saat GitHub diluncurkan, kolaborasi perangkat lunak memiliki unit dasar yang stabil: manusia.

Insinyur menulis kode selama beberapa jam, lalu mengirimkan satu commit; pengembangan satu fitur memakan waktu beberapa hari, membentuk satu PR; tinjauan mungkin muncul setengah jam kemudian, atau mungkin baru dilakukan hari berikutnya; CI yang berjalan selama beberapa menit biasanya dapat diterima, dan penanganan merge conflict yang ditunda sedikit pun tidak akan membuat seluruh sistem kehilangan maknanya.

Dengan mengikuti ritme ini, GitHub membangun sistem Pull Request, Issue, Review, Actions, Webhook, dan izin. Bahkan dalam proyek seperti Linux Kernel yang terus-menerus memiliki volume commit tinggi, ritme ini tetap membawa skala waktu manusia yang jelas.

LWN melaporkan bahwa selama siklus pengembangan Linux 7.0, terdapat 14.251 non-merge commits dari 2.362 pengembang. Commit-commit ini terjadi selama siklus pengembangan yang berlangsung beberapa minggu, dengan disertai diskusi melalui email, tinjauan oleh maintainer, integrasi sub-sistem, dan siklus rilis.

Cursor menunjukkan bentuk beban lain dalam demo Origin pada Juni: 22,6 commit/s per repositori.

Angka ini merupakan data demo langsung, bukan benchmark produksi yang telah direplikasi secara independen, dan tidak dapat membuktikan bahwa Origin dapat mempertahankan throughput yang sama dalam bisnis nyata dalam jangka panjang. Namun, angka ini cukup untuk menunjukkan jenis workload yang ditujukan oleh Origin: banyak Agent yang terus-menerus menulis ke status kode yang sama.

Pengembang manusia secara alami mengalami pembatasan laju. Berpikir, menulis kode, rapat, dan istirahat menciptakan banyak waktu kosong di antara pengiriman, sehingga forge yang dirancang mengelilingi manusia dapat menyerap sebagian besar tekanan sistem melalui waktu.

Agen tidak memiliki batasan ini.

Puluhan Agent dapat secara bersamaan bercabang dari base SHA yang sama, mengubah file terkait dalam waktu yang hampir bersamaan, lalu mendorong secara bersamaan, membuka PR, memicu pemeriksaan, membaca ulasan, mengubah kode, dan mendorong kembali. Satu commit bahkan dapat terus memicu pembaruan indeks, pemeriksaan izin, Webhook, CI, pemindaian kode, penyegaran status ulasan, dan perhitungan kemampuan merge.

Oleh karena itu, yang perlu menanggung perubahan bukanlah model objek Git itu sendiri, tetapi lebih penting lagi adalah control plane forge di atas Git: API, otentikasi, tugas latar belakang, penjadwalan CI, webhook, perlindungan cabang, status tinjauan, antrian merge, serta beban kaskade yang terbentuk di antara komponen-komponen ini.

Sebuah penelitian terhadap Agent PR di GitHub yang diterbitkan pada Juli telah melihat pola konkuren ini. Penelitian tersebut menganalisis 33.596 Agent PR dari 2.807 repositori, di mana 40,2% repositori mengalami Agent PR yang tumpang tindih dalam waktu.

Dalam modifikasi paralel yang direproduksi secara sampling, proporsi konflik merge teks antar Agent PR mencapai 41,7%, sedangkan pada PR paralel yang dihasilkan oleh Agent yang sama adalah 19,8%.

Kolaborasi Multi-Agent karena itu akan membawa masalah kontrol konkurensi baru. Kegagalan GitHub ini tidak membuktikan bahwa lalu lintas Agent telah melampaui infrastruktur yang ada, tetapi secara kebetulan memberikan jendela pengamatan: ketika produksi perangkat lunak berubah dari peristiwa manusia berfrekuensi rendah menjadi peristiwa mesin berfrekuensi tinggi, perencanaan kapasitas, desain antrian, penyebaran status, dan model konsistensi menghadapi jenis workload yang berbeda.

Desain Origin juga dimulai dari sini.

02 Origin Menulis ulang biaya kolaborasi

Jika Origin hanya menambahkan entri hosting repositori Git, sulit bagiannya untuk menggoyahkan hubungan pengembang, ekosistem open source, sistem izin perusahaan, dan rantai alat yang telah dibangun oleh GitHub.

Peluangnya berasal dari Agent yang mengubah biaya kolaborasi. Stacked PR adalah contoh khas.

Pengembang manusia biasanya cenderung mengelompokkan fitur menjadi PR yang relatif lengkap. Setiap pemisahan PR menambahkan konteks tambahan, siklus tinjauan, dan ketergantungan branch. Jika satu perubahan dibagi menjadi puluhan PR, manusia mudah menghabiskan banyak energi untuk memelihara hubungan-hubungan ini.

Struktur biaya agen berbeda. Ketika sebuah perubahan melintasi puluhan file, kegagalan pada langkah apa pun dapat menyebabkan agen harus memahami kembali konteks dalam cakupan luas. Dengan membaginya menjadi set perubahan yang lebih kecil, modifikasi schema, service, UI, dll. dapat membentuk ketergantungan yang jelas, dan setiap node dapat diverifikasi secara terpisah; jika gagal, hanya bagian terkait yang perlu ditangani.

PR kecil karena itu dapat menjadi checkpoint untuk Agent, memungkinkan tugas memiliki kemampuan verifikasi lokal, percobaan ulang lokal, dan pelacakan dependensi.

Pengambilalihan Graphite oleh Cursor juga dapat dipahami di sini. Early beta Origin saat ini belum sepenuhnya mengadopsi alur kerja stacked Graphite, tetapi stacked PR dan stack-aware merge queue yang telah lama dikembangkan oleh Graphite secara tepat menangani hambatan berikutnya yang muncul setelah Agent meningkatkan kecepatan produksi kode.

Setelah jumlah PR meningkat, tanggung jawab antrian merge juga akan bertambah. Agent A dan Agent B dapat bekerja secara bersamaan dari SHA dasar yang sama, masing-masing melewati pengujian.

Setelah A masuk ke main, hasil pengujian B hanya dapat membuktikan bahwa kode berfungsi dalam keadaan lama, tetapi tidak dapat membuktikan bahwa tetap aman setelah memasuki main yang baru. Oleh karena itu, queue perlu membangun ulang status kandidat berdasarkan main yang terus berubah, menjalankan ulang check, dan menangani ketergantungan antar PR.

Conflict juga dapat secara bertahap berubah menjadi state kegagalan yang dapat dipulihkan dalam pipeline. Cursor telah menyediakan kemampuan seperti /babysit, yang secara berkelanjutan menangani umpan balik PR, check yang gagal, dan konflik. Setelah merge kandidat mengalami masalah, konteks terkait dapat dikembalikan ke Agent untuk diperbaiki dan diverifikasi ulang dalam lingkungan terisolasi.

ulasan juga akan menjadi terstruktur. Kolaborasi manusia sangat bergantung pada bahasa alami dan pengalaman tim, sedangkan Agent yang berjalan dalam jangka panjang memerlukan pembacaan yang jelas tentang check mana yang gagal, thread mana yang belum terselesaikan, kebijakan mana yang tidak terpenuhi, dan SHA head saat ini adalah apa.

Origin telah mengekspos objek repository, commit, checks, PR melalui API, serta membedakan tinjauan formal dengan diskusi biasa.

Status terstruktur ini selanjutnya dapat langsung dikonsumsi oleh Automations. Push, PR opened, atau PR pushed memicu cloud agent, hasil eksekusi ditulis kembali ke checks dan PR, kegagalan akan masuk ke proses penanganan. MCP, hooks, dan Agent API memungkinkan alat eksternal bergabung ke dalam rantai peristiwa yang sama.

“Lepas dari GitHub” menyelesaikan jalur migrasi. Tim dapat terlebih dahulu mirror repository GitHub, menjaga GitHub sebagai source of truth, sambil memindahkan alur kerja Agent ke Origin; setelah berjalan stabil, baru putuskan sinkronisasi dan biarkan Origin mengelola repositori secara mandiri.

Ini memungkinkan Cursor untuk terlebih dahulu mengambil alih Agent, PR, review, checks, dan Automation, lalu secara bertahap menyimpan lebih banyak status teknis di dalam sistemnya sendiri.

Logika produk Origin karena itu sangat jelas: Git terus memikul kendali versi, yang ingin direvisi oleh Origin adalah lapisan kendali di atas Git yang berputar di sekitar kolaborasi Agent frekuensi tinggi.

03 Lao Ma sedang mengintegrasikan satu rantai produksi AI

Dalam lebih dari satu tahun terakhir, serangkaian tindakan antara xAI, X, SpaceX, dan Cursor secara bertahap membentuk hubungan hulu-hilir yang lebih lengkap.

xAI mengakuisisi X, lalu bergabung dengan sistem SpaceX; Cursor mendapatkan sumber daya komputasi Colossus, kemudian juga bergabung dengan sistem SpaceX. Sementara itu, Grok 4.6 dirilis, dan Origin mulai dibuka.

Jalur ini mirip dengan pendekatan integrasi vertikal yang pernah digunakan Musk di Tesla: ketika tahap eksternal mulai menimbulkan gesekan iterasi, terus perluas ke hulu dan hilir, serta masukkan antarmuka kunci ke dalam sistem yang sama.

Agen saat ini menghadapi masalah seperti ini. Model dapat menyelesaikan penalaran, tetapi tugas perangkat lunak juga memerlukan akses ke repositori, mengubah file, menjalankan pengujian, menangani CI, menerima tinjauan, menyelesaikan konflik, dan memulihkan eksekusi setelah gagal.

Jika tahapan-tahapan ini tersebar di beberapa sistem, setiap siklus tugas memerlukan sinkronisasi berulang-ulang terhadap izin, konteks, dan status, biaya antarmuka akan terus menumpuk dalam loop Agent yang berjalan terus-menerus.

Colossus, Grok, Cursor, dan Origin masing-masing dapat dikaitkan dengan tingkatan berbeda di rantai ini: Colossus menyediakan daya komputasi, Grok menyediakan kemampuan model, Cursor menyediakan Agent kode dan lingkungan eksekusi, Origin menyimpan status repository, PR, checks, dan review.

Kode produksi membentuk rantai berkelanjutan: model membuat keputusan, Cursor mengubah keputusan tersebut menjadi perubahan nyata, Origin menyimpan status proyek dan mengendalikan kolaborasi selanjutnya.

Ini juga mengubah skala penilaian Grok 4.6. Kemampuan model tetap penting, tetapi hasil sistem Agent juga bergantung pada lingkungan eksekusi dan infrastruktur teknis. Meskipun kode yang dihasilkan berkualitas baik, jika masih memerlukan intervensi manusia untuk menyalin, menjalankan, memeriksa, dan mengirim ulang, kemampuan model sulit untuk diperbesar secara berkelanjutan.

Setelah model mencapai tingkat yang dapat digunakan, seberapa cepat kode dapat memasuki proses eksekusi, verifikasi, dan penggabungan akan semakin memengaruhi output keseluruhan sistem.

Posisi X dalam rantai ini saat ini masih cukup kabur. Ia memiliki konten real-time, hubungan pengguna, identitas, dan jaringan distribusi, dan berpotensi menjadi sumber tugas dan pintu masuk distribusi di masa depan; pada tahap ini, Grok Bot lebih mirip lapisan eksekusi tugas berkelanjutan, bukan sekadar “robot obrolan pasif yang menunggu pertanyaan” seperti yang dibayangkan banyak orang.

Mengapa Cursor memerlukan Origin, hal ini juga dapat dijelaskan: setelah kode dihasilkan, diperlukan sistem yang secara permanen menyimpan status proyek, mengoordinasikan perubahan, memverifikasi hasil, dan menghubungkan eksekusi selanjutnya. Jika posisi ini selalu berada di luar, maka rantai produksi perangkat lunak Agent akan memiliki ketergantungan kritis.

Dan Origin mengisi lapisan ini.

04 Perbedaan antara GitHub dan Origin

GitHub telah memiliki stacked PR, merge queue, dan REST API, serta terus mengintegrasikan agen coding Copilot ke dalam Issue, Actions, PR, dan code review. Hanya dengan melihat daftar fitur, keduanya akan semakin banyak tumpang tindih di masa depan.

Perbedaan utama berasal dari asumsi desain.

GitHub dibangun di atas jaringan pengembang manusia yang matang, sehingga jalur yang lebih alami adalah memungkinkan Agent masuk ke dalam sistem Issue, PR, Actions, dan perlindungan branch yang sudah ada.

Cursor dapat mendesain ulang komponen-komponen ini dari kolaborasi agen berdensitas tinggi. Jika puluhan agen berjalan dalam jangka panjang di dalam satu repositori, jumlah PR meningkat, tingkat perubahan menjadi lebih halus, dan perubahan status mempercepat, maka sistem tinjauan, pemeriksaan, penggabungan, dan otorisasi perlu diorganisasi ulang mengikuti perilaku mesin.

Peran PR juga dapat diperluas. Dari perubahan kode yang terutama dibaca oleh manusia, ia secara bertahap dapat berubah menjadi unit transaksi teknik yang mencakup diff, ketergantungan, bukti pengujian, sumber, tingkat risiko, dan status persetujuan.

Tanggung jawab manusia akan lebih banyak masuk ke lapisan aturan: direktori mana yang diizinkan untuk dimodifikasi otomatis, seberapa besar versi yang diizinkan untuk dinaikkan tergantung, verifikasi apa yang diperlukan untuk migrasi database, persetujuan apa yang diperlukan untuk kode otentikasi dan pembayaran, dan dalam situasi apa Agent harus berhenti.

Dengan demikian, metrik dari Agent-native forge juga akan berubah. 22.6 commit/s sangat mencolok, tetapi jumlah commit sendiri tidak dapat mewakili efisiensi produksi perangkat lunak. Metrik yang lebih bermakna adalah waktu yang dibutuhkan dari masuknya tugas ke sistem hingga merge, kemampuan pemulihan lokal setelah kegagalan, proporsi perubahan yang diselesaikan secara otomatis oleh policy, biaya komputasi untuk change yang diterima, serta perhatian manusia yang dikonsumsi oleh perubahan berisiko tinggi.

Origin ingin mengendalikan permukaan kontrol produksi perangkat lunak yang terbentuk dari penggabungan repository, checks, review, izin, dan events.

Persaingan antara GitHub dan Origin karena itu akan secara bertahap berfokus pada dua jalur: GitHub mengembangkan sistem kolaborasi manusia yang matang menuju Agent, sementara Cursor mencoba merancang ulang forge berdasarkan beban kerja Agent.

05 Lao Ma sudah di lantai berikutnya

Namun, setelah peluncuran Grok 4.6, pihak luar cenderung terus membahas kemampuan kode, skor inferensi, dan harga berdasarkan benchmark. Namun, jika melihat Colossus, Grok, Cursor, dan Origin secara bersamaan, sebenarnya strategi ini telah meluas ke rantai produksi perangkat lunak setelah model.

Colossus menyediakan daya komputasi, Grok bertanggung jawab atas inferensi, Cursor mengubah kemampuan model menjadi perubahan kode, dan Origin menangani status repositori, PR, checks, dan review selanjutnya. Setelah kemampuan model meningkat, manfaatnya dapat ditransmisikan langsung sepanjang rantai eksekusi; bahkan jika model generasi tunggal tidak menunjukkan perbedaan signifikan, infrastruktur berikutnya tetap dapat terus berkembang.

Jadi, posisi Grok 4.6 hari ini di daftar tertentu mungkin hanya hasil sementara. Pertanyaan jangka panjang yang lebih besar adalah, siapa yang dapat mengorganisasi model, lingkungan eksekusi, dan status rekayasa perangkat lunak menjadi satu sistem produksi yang berjalan terus-menerus.

Saat orang-orang masih berdebat model mana yang lebih cerdas di putaran ini, tak disadari Lao Ma sudah sampai di lantai berikutnya.