Pada 9 Februari, larut malam waktu Beijing, jutaan pengembang di seluruh dunia membuka GitHub dan melihat halaman yang sama.
Bukan 404, tapi lebih mengkhawatirkan dari 404—itu adalah bilah peringatan kuning yang membuat semua insinyur merinding, ditambah deretan lampu indikator di status page yang berubah dari hijau menjadi merah.
github.com down.
API down.
GitHub Actions down.
Operasi Git down—bahkan Copilot pun tidak luput.
Malam itu, pipeline CI/CD seseorang macet di titik kritis, deployment otomatis seseorang tertahan di tengah jalan, dan seseorang menunggu PR yang tak kunjung bisa digabungkan—di belakangnya adalah fitur yang menunggu untuk diluncurkan, menunggu pengguna sungguhan.
Setelahnya, GitHub merilis laporan insiden. Penyebab utamanya, dalam bahasa teknis, adalah "kelebihan beban pada kluster database inti yang bertanggung jawab atas autentikasi dan manajemen pengguna." Namun di balik kata-kata ini tersembunyi rantai pemicu yang mencengangkan—
Dua hari sebelumnya, tim engineering, untuk segera mendorong model baru kepada pengguna, mengubah waktu refresh "cache pengaturan pengguna" dari 12 jam menjadi 2 jam. Hanya satu perubahan angka konfigurasi ini.
Hasilnya, penulisan ulang cache yang seharusnya tersebar dalam 12 jam, dipadatkan ke dalam 2 jam, membentuk "badai penulisan ulang cache" yang intens, antrian tugas asinkron meledak dalam sekejap, komponen infrastruktur bersama crash, efek domino menyebar ke layanan yang bertanggung jawab untuk operasi Git HTTPS proxy, dan akhirnya menghabiskan koneksi seluruh platform.
Satu angka, dari 12 diubah menjadi 2.
GitHub, ditembus oleh satu konfigurasi yang mereka ubah sendiri.
Tapi jika Anda hanya melihat perubahan konfigurasi ini, Anda mungkin melewatkan bagian terpenting dari cerita ini.
01 Bukan Satu Kecelakaan, Tapi Sepuluh Kecelakaan
Insiden 9 Februari bukanlah peristiwa yang terisolasi.
Faktanya, dalam tiga bulan pertama tahun 2026, GitHub mengalami setidaknya 8 insiden besar. Bulan Februari saja ada 37 catatan gangguan besar kecil. CTO GitHub Vlad Fedorov kemudian mengakui dalam blognya bahwa dua bulan ini GitHub gagal mempertahankan "three nines"—99.9% ketersediaan—yang dijanjikannya kepada pelanggan perusahaan.
Membuka arsip gangguan dua bulan ini, Anda akan menemukan pola aneh: setiap insiden, tampaknya memiliki penyebab yang berbeda.
2 Februari: Penyedia komputasi Azure bermasalah, GitHub Actions macet hampir 4 jam, agen pengkodean Copilot, CodeQL, Dependabot semuanya terkena dampak.
9 Februari: Badai penulisan ulang cache, database autentikasi kelebihan beban.
5 Maret: Gangguan kluster Redis, 95% alur kerja GitHub Actions tidak dapat dimulai dalam 5 menit, rata-rata penundaan 30 menit.
18 Maret: Penundaan Webhook melonjak hingga 32 kali level normal.
Setiap kali tampak "kecelakaan", setiap kali penyebab langsungnya berbeda. Namun penjelasan Fedorov merangkainya menjadi cerita yang sama. Dia mengatakan, di balik insiden-insiden ini ada tiga penyebab struktural bersama: "pertumbuhan beban yang cepat, kopling ketat antar layanan yang menyebabkan penyebaran kegagalan lokal, dan kurangnya kemampuan sistem untuk melindungi lalu lintas dari klien abnormal."
Dalam bahasa engineer, fondasi GitHub, sudah mulai retak di bawah tekanan beban baru.
Dan "beban baru" ini, memiliki nama yang spesifik.
02 275 Juta Komit Per Minggu
Data Kunci
Total commit sepanjang 2025: sekitar 1 miliar
Volume commit per minggu 2026: 275 juta
Dengan kecepatan ini, perkiraan sepanjang 2026: 14 miliar (peningkatan 14 kali lipat tahun-ke-tahun)
Volume komputasi GitHub Actions: 2023 per minggu 500 juta menit → 2025 1 miliar → awal 2026 suatu minggu 2,1 miliar menit
Jika Anda adalah engineer infrastruktur GitHub, membandingkan dashboard monitoring tahun 2025 dan 2026 mungkin akan membuat Anda tercengang.
Sepanjang 2025, GitHub memproses sekitar 1 miliar commit kode. Angka ini sendiri sudah sangat besar, merupakan hasil akumulasi bertahun-tahun platform GitHub. Namun pada 2026, volume commit dalam satu minggu saja mencapai 275 juta. Konversi—jika berjalan dengan kecepatan ini sepanjang tahun, total commit 2026 akan mendekati 14 miliar, tepat 14 kali lipat dari total 2025.
Ini bukan kurva pertumbuhan yang mulus, melainkan tanjakan yang curam. Perubahan volume komputasi Actions GitHub lebih menjelaskan masalah: tahun 2023 mengonsumsi 500 juta menit per minggu, 2025 berlipat ganda menjadi 1 miliar, lalu pada suatu minggu di awal 2026, langsung melonjak ke 2,1 miliar menit.
Apa yang sedang mengirimkan kode dengan gila-gilaan?
Bukan pengembang manusia.
Data GitHub menunjukkan, AI Agent sedang menjadi "pengguna" paling aktif di platform ini. Claude Code sendiri, sebuah alat, kini menyumbang 4.5% dari semua commit di repositori publik GitHub. 2,6 juta commit per minggu, padahal pada akhir September 2025, angka ini hanya 100.000—meningkat 25 kali lipat dalam tiga bulan.
Jumlah PR yang dibuka oleh AI Agent juga meledak. September 2025, PR yang dihasilkan AI sekitar 4 juta per bulan, pada Maret 2026, angka ini melonjak menjadi 17 juta—lebih dari empat kali lipat, dalam setengah tahun.
Ada sebuah gambaran yang dapat membantu Anda memahami apa artinya ini.
Dulu, "pengguna" GitHub terutama adalah programmer manusia. Mereka bekerja siang, tidur malam, istirahat akhir pekan, setiap commit akan berpikir, akan ragu, kecepatan tangan ada batasnya. Beban sistem mengikuti ritme manusia, ada puncak dan lembah, dapat diprediksi.
Sekarang, semakin banyak "pengguna" adalah AI Agent. Mereka tidak tidur, tidak istirahat, tidak ragu, satu tugas dapat membuka beberapa Agent paralel sekaligus, setiap Agent setiap jam jumlah commitnya, dengan mudah melebihi minggu kerja seorang engineer sungguhan. Yang lebih penting, mereka tidak hanya melakukan commit kode, tetapi juga terus membuat repositori baru—memperlakukan repositori sebagai "produk output" alur kerja, bukan "ruang kerja" manusia.
Para engineer infrastruktur GitHub, yang dihadapi bukan lagi masalah sejenis dengan lalu lintas yang lebih besar, melainkan masalah yang sifatnya sama sekali berbeda.
03 Uang Copilot Tidak Cukup untuk Dibakar
Gangguan yang sering terjadi hanyalah satu sisi masalah, GitHub memiliki masalah lain yang lebih menyebalkan—saat menghitung ternyata merugi.
Logika harga awal Copilot, dibangun berdasarkan asumsi yang masuk akal: pengguna terutama menggunakan secara "asisten pelengkapan", setiap interaksi singkat, volume komputasi dapat diprediksi. Versi pribadi $10 per bulan, versi bisnis $19 per bulan, biaya per kursi, model ini berjalan baik dalam beberapa tahun terakhir.
Kemudian, Agentic AI datang.
Alur kerja Agentic dan pelengkapan tradisional adalah dua spesies berbeda. Pelengkapan kode standar, permintaannya linear, dapat diprediksi, siklus komputasi singkat. Sementara sesi pengkodean Agentic, dapat berjalan berjam-jam, sekaligus meluncurkan beberapa thread paralel, melakukan penalaran multi-langkah, koreksi diri sendiri, refaktor lintas repositori—jumlah token yang dikonsumsi satu sesi, dengan mudah melebihi biaya berlangganan sebulan seorang pengguna biasa.
Situasi yang dihadapi GitHub adalah, sedikit pengguna Agentic berat, sedang menggunakan biaya bulanan beberapa dolar untuk mengonsumsi sumber daya komputasi setara ratusan dolar.
Menghadapi situasi ini, reaksi GitHub langsung—kontrol aliran dulu, lalu ubah harga.
Awal tahun ini, GitHub meluncurkan dua mekanisme pembatasan paralel untuk Copilot: batas durasi sesi dan batas penggunaan mingguan, kedua dimensi dihitung berdasarkan konsumsi token dikalikan bobot komputasi model. Sementara itu, pendaftaran pengguna baru untuk beberapa paket Copilot pribadi ditangguhkan.
1 Juni, GitHub menyelesaikan reformasi harga yang lebih mendasar: Copilot sepenuhnya beralih ke pembayaran berdasarkan penggunaan, mengganti biaya paket sebelumnya dengan "AI Credits", 1 AI Credit sama dengan 1 sen, penggunaan dihitung real-time berdasarkan konsumsi token.
Era biaya per kursi, di hadapan Agentic AI, telah sampai pada akhirnya.
Perubahan ini bukan hanya kekhawatiran GitHub. Ini adalah krisis penetapan harga kolektif yang sedang dialami seluruh industri alat AI pada tahun 2026—ketika AI mulai menggantikan manusia untuk menjalankan alur kerja lengkap, bukan hanya "membantu" manusia bekerja, semua logika berlangganan berbasis "per orang per bulan" akan gagal.
04 30 Kali, Bukan 10 Kali
Kembali ke masalah infrastruktur. Bagaimana sebenarnya GitHub bersiap menghadapi "pertumbuhan 14 kali lipat" ini?
Ada satu detail di sini, yang dapat menjelaskan tingkat keseriusan masalah:
Pertengahan Desember 2025, alur kerja Agentic tiba-tiba mulai berakselerasi. Engineer-engineer GitHub menyadari, 10 kali lipat tidak cukup. Pada Februari 2026, yaitu setelah gangguan parah itu, GitHub mengumumkan perlu mendesain ulang arsitektur sesuai skala 30 kali lipat dari hari ini.
Bukan sekadar menambah kapasitas, tapi mendesain ulang.
Perbedaan kedua kata ini besar. Menambah kapasitas adalah membuat mesin yang ada lebih banyak, menambah memori database yang ada—arah tidak berubah, hanya skalanya yang membesar. Mendesain ulang berarti, asumsi arsitektur yang ada akan gagal secara sistemik pada skala 30 kali lipat, harus memikirkan kembali cara pemisahan layanan, aliran data, isolasi kegagalan dari dasar.
Arah spesifik yang diungkapkan GitHub termasuk, memisahkan layanan kunci untuk mencegah kegagalan berantai, memperkenalkan mekanisme backpressure dan kemampuan degradasi lalu lintas, menerapkan host independen untuk layanan hot spot, menghilangkan single point of failure, serta manajemen perubahan yang lebih baik—menghindari operasi seperti "mengubah TTL cache dari 12 jam menjadi 2 jam" langsung diluncurkan tanpa pengujian beban yang memadai.
Patut dicatat, GitHub tidak sendirian.
Stripe sudah menghadapi masalah pembuatan akun massal oleh AI Agent, AWS sedang membangun sistem identitas khusus Agent, sistem log, dan mekanisme kontrol produksi. Tindakan ini bukan antisipasi, melainkan sinyal yang sudah muncul di dashboard monitoring yang harus mereka selesaikan.
GitHub hanyalah yang pertama ditembus—karena ia berada di inti terpenting rantai alat AI.
05 Repositori Kode, Sedang Menjadi Pipa Pembuangan AI
Berhenti sejenak dan pikirkan sifat keseluruhan hal ini.
GitHub itu apa? Jawaban paling intuitif adalah, tempat programmer menyimpan kode. Tapi lebih dalam lagi, ia adalah infrastruktur kolaborasi perangkat lunak manusia—catatan commit adalah jejak kolaborasi, PR adalah wadah diskusi, Issues adalah penyimpanan niat, Action adalah pipa eksekusi. Seluruh sistem, dirancang untuk ritme kerja, cara berpikir, dan mode kolaborasi manusia.
AI Agent mengubah semua ini.
Saat seorang AI Agent dapat melakukan ratusan commit kode dalam sehari, setiap "commit" di belakangnya tanpa pemikiran dan pertimbangan manusia, hanya langkah kemajuan dari satu siklus tugas—apakah repositori kode masih "wadah kolaborasi"?
Saat alat AI secara otomatis membuat repositori, secara otomatis membuka PR, secara otomatis menjalankan CI, secara otomatis merge—apakah pengembang masih subjek dalam proses ini, atau apakah mereka sudah merosot menjadi "pengawas" atau bahkan "penonton"?
CTO GitHub dalam menggambarkan krisis ini, menggunakan kata "pertumbuhan beban yang cepat". Tapi kata ini kemungkinan meremehkan sifat masalah—ini bukan hanya pertumbuhan kuantitas, ini adalah perubahan kualitatif dalam cara penggunaan. Dalam model lama, GitHub adalah "alat pengembang"; dalam model baru, GitHub sedang menjadi "pipa pembuangan AI", saluran output dari alur kerja otomatisasi.
Apa artinya ini bagi GitHub, sebenarnya belum ada jawabannya. Penambahan kapasitas 30 kali lipat dapat menyelesaikan masalah lalu lintas, tetapi tidak dapat menyelesaikan definisi ulang model bisnis, juga tidak dapat menyelesaikan masalah identitas "siapa pengguna sejatiku".
Baru-baru ini ada fenomena yang cukup bermakna: GitHub setelah gangguan membuka banyak blog engineering, menggambarkan akar penyebab setiap insiden dengan sangat rinci, hampir mencapai tingkat transparansi yang mengejutkan. Beberapa orang menganggap ini sebagai GitHub secara aktif membangun kepercayaan, yang lain menganggap ini sebagai upaya menukar transparansi dengan kesabaran komunitas pengembang—karena periode rekonstruksi berikutnya, akan ada lebih banyak ketidakstabilan.
Sebuah platform, setelah ditembus oleh keberhasilannya sendiri, perlu membongkar dan membangun dirinya kembali—dan proses ini sendiri, juga merupakan ujian apakah bisa bertahan.
Malam 9 Februari itu, engineer yang menunggu PR digabungkan, mungkin akhirnya mendapatkan lampu hijau. Tapi mungkin dia tidak menyadari, gangguan yang membuatnya menunggu itu, bukanlah satu kecelakaan GitHub, melainkan suara dentuman seluruh industri pengembangan perangkat lunak memasuki era baru.
Artikel ini dari WeChat Official Account "Geek Park" (ID: geekpark), penulis: Yuhang Yuan
