Anthropic merilis tulisan di blog rekayasanya pada 14 September, ditulis oleh Sachin Malhotra, yang membahas satu layanan internal yang kewalahan dan akhirnya ditulis ulang dari nol. Layanan itu bernama test impact analysis, dengan tugas yang sangat spesifik: begitu ada perubahan kode masuk, ia menentukan pengujian mana yang wajib dijalankan dan mana yang boleh dilewati. Kedengarannya seperti komponen belakang layar biasa, tapi alasan layanan ini sampai tidak kuat justru cukup mewakili masalah yang lebih luas.
Lihat dulu beberapa angka kelipatan
Deretan angka pertama dalam tulisan itu soal sisi output: rata-rata insinyur Anthropic kini menyerahkan kode delapan kali lebih banyak per kuartal dibanding rentang 2021-2025, dan 80% dari kode itu ditulis oleh Claude. Claude juga menyumbang porsi besar dalam proses review dan persetujuan pull request.
Deretan angka kedua soal sisi tekanan: total jumlah pengujian dalam basis kode naik 10 kali lipat, dan jumlah tugas CI melonjak 25 kali lipat dalam enam bulan.
Deretan angka ketiga paling menggambarkan kecepatan situasi. Tim sempat menjalankan tiga putaran mitigasi darurat untuk menahan beban, dan waktu yang berhasil dibeli tiap putaran makin singkat: 70 hari, lalu 29 hari, lalu kurang dari satu hari. Solusi putaran ketiga langsung kewalahan pada hari peluncurannya.
Di mana layanan lama macet
Arsitektur lama punya satu listener single-process yang harus mencatat setiap hasil pengujian secara berurutan ke storage. Penulisan tunggal berarti tidak bisa diskalakan secara horizontal, jadi begitu kecepatan masuknya pull request melampaui kecepatan pemrosesan listener, antrean mulai menumpuk. Tulisan blog itu menyebut listener ini "starts to increasingly fall behind the PR queue" (semakin lama semakin tertinggal dari antrean PR).
Dampak keterlambatan ini berlipat ganda. Contoh yang diberikan dalam tulisan itu: keterlambatan dua puluh menit setara dengan puluhan ribu pembaruan hasil pengujian yang belum masuk ke storage. Padahal pemilihan pengujian justru bergantung pada hasil historis untuk mengambil keputusan — kalau riwayatnya tidak akurat, kumpulan pengujian yang dipilih pun jadi tidak bisa diandalkan. Ditambah lagi, proses ini juga punya kebocoran memori dan selalu mentok di batas atas setiap sore.
Diganti jadi apa
Ide penulisan ulang ini adalah memindahkan status keluar dari proses itu sendiri. Arsitektur baru memperkenalkan penyimpanan data in-memory: worker listener mana pun bisa memproses hasil apa pun, tugasnya hanya menambahkan (append) ke log tanpa menyimpan status sendiri, sehingga mesin bisa ditambah sesuai kebutuhan. Selain itu ada proses consumer terpisah yang setiap beberapa detik melipat log itu menjadi riwayat per pengujian. Saat selector perlu mengambil keputusan, ia langsung membaca riwayat ini.
Konsekuensinya adalah biaya yang naik. Tulisan blog itu mengakui hal ini secara terbuka, dengan alasan mendapatkan skalabilitas dan observabilitas sebagai gantinya — kini bisa diukur secara terpisah tahap mana yang lambat dan di mana letak kelambatannya. Seluruh perancangan ulang ini diselesaikan satu insinyur dalam tiga minggu.
Kurva kelipatan 25 kali
Kelipatan 25 kali dalam enam bulan setara dengan laju pertumbuhan majemuk bulanan sekitar 1,71 kali (perhitungan kasar: akar pangkat enam dari 25). Kalau laju ini diekstrapolasi enam bulan lagi ke depan, hasilnya jadi 625 kali. Kalimat penutup penulisnya, "always plan for the exponential" (selalu rencanakan untuk pertumbuhan eksponensial), bukan sekadar gaya bahasa — itu memang mengacu pada kurva yang sudah benar-benar terukur.
Tentu saja ekstrapolasi kurva ini tidak bisa sepenuhnya diandalkan — laju pertumbuhan bisa berbelok karena perubahan kebijakan internal, kuota, atau kebiasaan rekayasa, dan Anthropic pun tidak mengumumkan angka absolut tagihan CI-nya, tidak menyebut berapa persen pengujian yang berhasil disaring oleh layanan baru, apalagi memberi angka soal sudah turun ke level berapa keterlambatannya setelah ditulis ulang. Berapa banyak biaya yang dihemat, itu tidak bisa disimpulkan dari informasi publik yang ada.
Tapi arah rambatan tekanan dari satu tahap ke tahap berikutnya cukup jelas. April tahun ini, GitHub menghentikan pendaftaran baru untuk tiga paket langganan individu Copilot, dengan alasan konsumsi komputasi dari tugas agen yang berjalan lama sudah melampaui desain paketnya; lebih awal lagi, lonjakan commit dari AI pernah membuat GitHub mengalami gangguan, sampai-sampai Microsoft harus meminjam kapasitas dari AWS untuk menahannya. Ketiga peristiwa ini bentuknya berbeda, tapi mengarah ke hal yang sama: tahap pembuatan kode dulu yang dipercepat, lalu review, dan setelah itu setiap sistem yang kapasitasnya dirancang berdasarkan "kecepatan manusia menulis kode" bakal dihantam bergiliran. Test impact analysis cuma kebetulan jadi yang lebih dulu membunyikan alarm di putaran kali ini.
Sumber: CocoLoop, blog rekayasa Anthropic; kelipatan volume kode, kenaikan jumlah pengujian dan tugas CI, serta masa berlaku tiga putaran mitigasi semuanya mengikuti angka yang dipublikasikan dalam tulisan tersebut.