Era ketika kode pengujian menjadi moat baru
(saewitz.com)-
Paradoks kesuksesan: semakin sebuah proyek berkembang, semakin besar pula bebannya berupa kompatibilitas mundur dan codebase raksasa (The Ship of Theseus). Sementara itu, pesaing dapat melatih AI dengan spesifikasi API, dokumentasi, dan kode pengujian dari proyek yang sudah ada, lalu mengekstrak hanya nilai intinya untuk membuat 'versi yang lebih ringan dan modern' dalam sekejap.
-
Kasus Cloudflare vs Vercel: Cloudflare memanfaatkan dokumentasi Next.js yang sangat luas dan test suite yang dibangun Vercel selama bertahun-tahun untuk membangun runtime kompatibel Next.js yang ramping berbasis Vite hanya dalam satu minggu. (Saat ini juga diterapkan di situs pemerintah AS cio.gov)
-
Kode pengujian sebagai aset: dahulu kode itu sendiri yang paling penting, tetapi kini 'kontrak perangkat lunak (Contract)' dan 'test case' telah menjadi aset termahal. Membukanya ke publik sama saja dengan memberikan cetak biru presisi yang memungkinkan pesaing menyalin layananku apa adanya.
-
Visi jauh ke depan SQLite: SQLite membuka kodenya, tetapi menjaga test suite yang sangat besar—590 kali ukuran source code-nya (92 juta baris)—tetap tertutup. Inilah yang menjadi 'moat' mereka, sehingga mereka dapat mempertahankan ekosistem open source sekaligus memiliki daya tahan komersial.
-
Kesimpulan: perusahaan open source komersial di era AI kini menghadapi saat untuk mengambil keputusan antara 'altruisme penuh (open source)' dan 'kelangsungan hidup bisnis'. Ke depan, banyak proyek kemungkinan akan mengikuti SQLite dengan menjadikan kode pengujian tertutup dan membangun penghalang teknologi mereka sendiri.
19 komentar
Dari sudut pandang ini, mungkin saja dokumen seperti ADR(Architecture Decision Records) atau CIR(Change Intent Records) akan diperlakukan lebih berharga daripada kode itu sendiri.
Cukup mengesankan. Meskipun tulisannya singkat, saya langsung bisa memahaminya. Keamanan kode pengujian mungkin malah bisa lebih penting daripada kode sumber.
Bagi saya, ini terdengar seperti pesan untuk tidak melewatkan pengujian e2e. Saya penasaran bagaimana pendapat yang lain.
Saya benar-benar bukan developer... tapi karena seru utak-atik AI, saya menyuruhnya coding sedikit, dan ternyata ia membuat dan menyimpan banyak sekali kode pengujian yang bahkan tidak saya minta—jadi memang ada alasan seperti ini rupanya.
Waktu saya tanya kenapa itu diperlukan, dia bilang itu dibutuhkan saat membuat kode dan menyuruh saya untuk tidak menghapusnya.
Oh... sepertinya benar.
Pendekatan SQLite memang sangat mengesankan. Menjaga suite pengujian yang besarnya mencapai 590 kali kode tetap tertutup pada akhirnya berarti bahwa "nilai sesungguhnya dari perangkat lunak ada pada spesifikasi perilakunya".
Faktanya, belakangan ini kalau mencoba membangun proyek dengan alat AI coding, selama ada README + dokumentasi API + kode pengujian dari proyek yang sudah ada, fitur intinya bisa direplikasi dengan sangat cepat, sampai tingkat yang mengejutkan. Ini saya rasakan sendiri sambil menjalankan 7 proyek; ironisnya, semakin baik pengujiannya, semakin mudah pula proyek itu direplikasi.
Namun, ada bagian yang terlewat dalam kasus Cloudflare vs Vercel, yaitu bahwa "mereplikasi" dan "mengoperasikan" adalah dua hal yang sepenuhnya berbeda. Untuk mereproduksi edge case Next.js, ekosistem plugin, sampai ketergantungan pada komunitasnya, kode pengujian saja tidak cukup. Pada akhirnya, saya merasa moat itu adalah kombinasi dari kode pengujian + komunitas + know-how operasional.
Sebagai pengembang solo, saya mengelola 7 proyek, dan tulisan ini benar-benar terasa menohok.
Berkat alat AI coding, kecepatan pengembangan awal memang jadi luar biasa cepat, tetapi kode yang ditumpuk cepat tanpa pengujian pada akhirnya berubah menjadi neraka refactoring. Terutama saat harus menjalankan beberapa layanan sekaligus, proyek tanpa pengujian terasa menakutkan untuk disentuh karena setiap kali mengubah satu fitur, selalu ada rasa khawatir hal lain akan ikut rusak.
Analogi "pengujian = moat" memang tepat. Pesaing mungkin bisa menyalin kode, tetapi sulit untuk menyalin seluruh test suite yang mencakup ribuan edge case. Terlebih lagi, meski AI sudah sangat baik dalam menghasilkan kode, membuat skenario pengujian yang benar-benar bermakna masih merupakan wilayah yang membutuhkan pengetahuan domain dari manusia.
Tetapi tergantung bidangnya, ada juga kasus di mana test code hampir tidak memiliki coverage, jadi itu memang membuat saya berpikir. Rasanya di area tersebut mereka juga masih belum terlalu mampu membuat kode yang bagus dibandingkan bidang lain.
Boleh tahu bidang apa yang dimaksud? (Bukan untuk memancing debat, saya benar-benar sekadar penasaran.)
Bidang yang saya kerjakan juga tidak sampai se-ekstrem itu, tetapi saya melakukan riset dan pengembangan di bidang AI.
Selain framework yang umum dipakai, kadang lingkungan target tempat model benar-benar dideploy berbeda dengan lingkungan saat model dilatih.
Ada juga kasus ketika operation tertentu tidak didukung, sehingga kami harus membuat custom operation untuk tiap platform. Dalam kasus seperti ini, sering kali tidak bisa langsung dites di lingkungan pengembangan.
Kadang saya juga memodelkan modelnya secara langsung; meskipun kita bisa menulis kode uji dengan data tertentu, nilainya bisa berubah secara probabilistik tergantung dataset, dan fenomena seperti nilai yang meledak pada titik tertentu sulit dicakup dengan kode uji.
Sepertinya ada cukup banyak lingkungan yang pengujiannya bahkan lebih sulit daripada yang saya hadapi.
Menurut saya pribadi, mungkin bidang-bidang seperti yang sering memakai Notebook, atau ranah AI yang hasilnya bersifat probabilistik, maupun bidang game client.
Saya juga sering membicarakan hal ini dengan orang-orang di sekitar saya, dan pada akhirnya nanti akan sulit untuk meninjau semua kode satu per satu, jadi saya pikir kalau logika yang benar-benar penting tidak diuji, itu bisa berakibat besar.
Ini juga ditambahkan di bagian bawah tulisan, ada cerita bahwa tldraw juga menjalankan pengujian secara privat (ternyata cuma bercanda).
https://github.com/tldraw/tldraw/issues/8082
Kalau melihat Bagaimana SQLite diuji,
SQLite sepenuhnya terbuka, tetapi memiliki kode pengujian 590 kali lebih banyak daripada kode sumber, dan ini sepenuhnya tertutup.
Ada 100% branch coverage dengan ratusan juta test case, dan menjalankan lebih dari 1 miliar mutation test.
Saya masuk ke isu itu dan membacanya, ternyata katanya "ini cuma joke".
Ternyata itu tes Joke, ya.
Wah, begitu ya. Aku cuma lihat bagian atasnya saja hehe
Inti dari "tes lebih penting daripada source" tampaknya memang sangat tepat. Namun saya tidak yakin apakah strategi membuka open source tanpa membuka pengujiannya akan tetap efektif. Rasanya mereka juga akan cukup mahir mengekstrak item-item pengujian dari source..
Saya juga melakukannya dengan salah.
Cloudflare, AI로 Next.js를 1주일 만에 Vite로 재구현한 vinext 공개
Sepertinya terkait dengan tulisan ini. Saat melakukan open source, sepertinya sekarang kita juga bisa menjadi lebih konservatif dalam memublikasikan kode pengujian.