- Dibanding kecepatan menulis kode baru, biaya pemeliharaan lebih menentukan produktivitas jangka panjang
- Dalam model contoh, setelah 2,5 tahun pemeliharaan memakan lebih dari separuh total waktu
- Jika agen AI meningkatkan output sekaligus biaya pemeliharaan, efeknya akan cepat hilang
- Bahkan jika agen dihentikan, biaya pemeliharaan tambahan dari kode yang sudah dibuat tetap ada
- Jika output menjadi dua kali lipat, biaya pemeliharaan per kode juga harus turun menjadi setengahnya
Biaya pemeliharaan menentukan produktivitas
- Semua waktu yang dipakai untuk menulis kode akan terus menimbulkan waktu pemeliharaan di kemudian hari, seperti perbaikan bug, perapian, dan upgrade dependensi
- Yang dibahas bukan fitur baru atau pekerjaan peningkatan, melainkan hanya pemeliharaan berulang setiap tahun selama kode itu masih ada
- Estimasi contoh ini mengasumsikan bahwa setiap 1 bulan penulisan kode memerlukan 10 hari waktu pemeliharaan pada tahun pertama, lalu 5 hari setiap tahun setelahnya
- Dengan pendekatan Wisdom of the Crowd, penulis menilai bahwa menanyakan biaya pemeliharaan kepada sekitar 50 pengembang dapat menghasilkan jawaban yang cukup akurat
- Menurut model spreadsheet yang dibuat dengan asumsi ini, pada awal proyek baru sebagian besar waktu dipakai untuk pengembangan fitur, tetapi seiring waktu porsi pemeliharaan kode lama makin membesar
- Dalam estimasi tersebut, setelah 2,5 tahun waktu yang dipakai untuk pemeliharaan melebihi separuh total waktu, dan setelah 10 tahun kondisinya menjadi hampir mustahil untuk mengerjakan hal lain
- Jika estimasi pemeliharaan diturunkan setengah, titik 50% bisa mundur 3 tahun; jika digandakan, produktivitas turun di bawah 50% dalam waktu kurang dari 1 tahun
- Jika ingin tim yang produktif, fokusnya harus pada biaya pemeliharaan, bukan pada kecepatan menulis kode baru
Model ini bisa saja salah, tetapi arahnya benar
- Pada startup tahap lanjut, setelah sekitar 5–9 tahun muncul masalah ketika tim tidak lagi mampu benar-benar menyelesaikan pekerjaan, dan ini mirip dengan pola yang terlihat pada grafik
- Alasan tim nyata tidak tampak seburuk grafik bisa jadi karena biaya pemeliharaannya memang lebih rendah, atau karena masalahnya ditutupi dengan cara lain
- Respons yang mungkin dilakukan adalah tidak memperbaiki semua bug atau tidak meng-upgrade semua dependensi, menambah orang saat tim melambat lalu terus menambah lagi, atau membuang semuanya dan menulis ulang dari awal
- Angka pastinya bisa diperdebatkan, tetapi arus besar bahwa produktivitas menurun seiring waktu tampak benar secara pengalaman
Efek perkalian yang diciptakan agen coding AI
- Sebagai contoh, diasumsikan framework coding berbasis agen terbaru Rock Lobster menggandakan output kode
- Pada saat yang sama, diasumsikan kode menjadi sedikit lebih sulit dipahami, tim kewalahan oleh pull request, dan kode tidak benar-benar dibaca sebelum disetujui
- Jika dalam sebulan dihasilkan kode setara dua bulan kerja, dan biaya pemeliharaan hasil tersebut juga menjadi dua kali lipat, maka biaya pemeliharaan bulan berikutnya menjadi 4 kali lebih besar
- Dalam contoh ekstrem ini, sekitar 5 bulan setelah memakai Rock Lobster, produktivitas kembali ke tingkat semula, dan beberapa bulan kemudian malah menjadi lebih buruk dibanding jika sejak awal tidak memakainya
- Ini bukan berarti AI benar-benar menggandakan produktivitas atau biaya pemeliharaan, melainkan menekankan bahwa sekalipun maintainability-nya setara dengan kode buatan manusia, keuntungan produktivitasnya tidak akan bertahan lama
Bahkan jika agen dihentikan, biaya pemeliharaan tetap tinggal
- Agen coding membutuhkan biaya, dan ketika manfaatnya lebih kecil daripada biayanya, tim mungkin ingin kembali ke cara lama
- Jika penggunaan agen dihentikan, keuntungan produktivitasnya hilang, tetapi biaya pemeliharaan tambahan dari kode yang dibuat agen akan tetap ada selama kodenya masih ada
- Dalam kondisi ini, tim bisa terjebak pada produktivitas yang lebih rendah daripada jika sejak awal sama sekali tidak memakai agen
Satu-satunya matematika yang benar-benar berlaku adalah penurunan biaya pemeliharaan
- Agar perhitungan produktivitas total masuk akal, LLM harus menurunkan biaya pemeliharaan tepat sebesar kebalikan dari rasio peningkatan output kode
- Jika output menjadi dua kali lipat dan biaya pemeliharaan hasilnya juga dua kali lipat, maka total biaya pemeliharaan menjadi 4 kali lipat
- Jika output menjadi dua kali lipat tetapi biaya pemeliharaan per hasil tetap sama, total biaya pemeliharaan tetap menjadi 2 kali lipat
- Jika output menjadi dua kali lipat, biaya pemeliharaan harus menjadi setengah; jika output menjadi tiga kali lipat, biaya pemeliharaan harus menjadi sepertiganya
- Syarat ini harus terpenuhi agar keuntungan kecepatan bisa didapat tanpa menciptakan ketergantungan jangka panjang
Kekhawatiran terhadap agen coding saat ini dan tuas lain yang mungkin
- Dari sumber seperti Hacker News, tampak banyak sinyal bahwa agen coding justru meningkatkan biaya pemeliharaan
- Sebagian orang mengatakan alat ini membantu memahami sistem berskala besar, tetapi penurunan besar pada biaya pemeliharaan yang dibutuhkan belum terlihat, malah tampaknya cenderung sebaliknya
- Model ini tidak merepresentasikan realitas secara sempurna, tetapi pesannya tetap valid: AI harus menurunkan biaya pemeliharaan sebanding dengan peningkatan kecepatan penulisan kode baru
- Bahkan jika mengejar peningkatan kecepatan coding, waktu yang sama juga harus diinvestasikan untuk memperbaiki biaya pemeliharaan
- Ini bukan argumen anti-AI; ada juga tuas lain seperti AI yang membuat pekerjaan pemeliharaan itu sendiri lebih produktif, meskipun tidak langsung meningkatkan maintainability kode
- Untuk menyesuaikan asumsi dengan situasi nyata, Anda dapat menyalin spreadsheet dan mengubah berbagai variabel dalam model
1 komentar
Komentar Hacker News
Dalam presentasi Dconf'24 Software as investment, dia mengusulkan kerangka dasar yang didasarkan pada fungsi nilai yang bisa dikomposisikan untuk tiap potongan perangkat lunak
Kerangka itu sendiri tidak benar-benar perlu berubah karena AI, dan secara terpisah kita hanya perlu memperbarui model biayanya sesuai seberapa baik AI menangani pemeliharaan
Katanya AI membuat bug 1,7 kali lebih banyak, tapi mungkin juga bisa memperbaikinya lebih cepat, jadi belum jelas
Jika perangkat lunak dilihat sebagai investasi, kita jadi berbicara tentang “nilai” alih-alih “utang teknis”, dan utang hanyalah aset dengan nilai di bawah 0
Saat perangkat lunak keluar dari dunia margin tinggi di masa lalu, kita perlu mendefinisikan dengan presisi apa itu perangkat lunak yang layak untuk ada secara ekonomi
Dalam perangkat lunak selalu ada bagian yang sebenarnya bisa ditulis lebih baik, dan itulah utang
Perspektif yang tajam, dan saya setuju
Sayangnya maintainability biasanya dimasukkan ke keranjang “kebutuhan nonfungsional”
Padahal kebutuhan nonfungsional seperti maintainability seharusnya dipandang sebagai sesuatu yang menjaga dan memungkinkan penyampaian kebutuhan fungsional di masa depan
Ini tidak seharusnya dibingkai sekadar sebagai lawan dari apa yang harus dilakukan perangkat lunak, yaitu hanya soal “bagaimana melakukannya”
Jika sebuah proyek penting karena terus menambah dan meningkatkan fitur, maka selain untuk periode yang sangat singkat, maintainability pada dasarnya lebih dekat ke kebutuhan fungsional
Begitu diberi nama terpisah, itu memberi alasan bagi orang yang tidak benar-benar paham untuk memagarinya secara terpisah dan menurunkan prioritasnya
Kualitas itu penting, dan jika tidak dijaga, dampaknya ke laporan laba rugi akan terasa sangat cepat dan keras
Jadi pentingnya setara dengan elemen lain mana pun
Pakai istilah dari Kevlin Henney: karakteristik operasional dan karakteristik pengembangan
Maintainability adalah karakteristik pengembangan yang mendasar
Mungkin mereka punya roadmap produk 1–2 tahun, tapi jujur saja roadmap seperti itu sering kali lebih dekat ke tujuan penjualan daripada rencana engineering
Saat pendapatan melambat, produk dan engineering akan berputar arah, dan semakin awal fase perusahaan, semakin sering ini terjadi
Setelah keluar dari mode startup, seharusnya situasinya lebih stabil, tetapi banyak perusahaan tidak begitu dan terus mengulang pola perencanaan jangka pendek
Akibatnya stabilitas produk tetap menjadi prioritas rendah
Pada akhirnya banyak perusahaan tampaknya tidak punya sumber daya untuk membuat software yang baik, atau memang tidak terlalu peduli
Dari pengalaman membangun proyek kami, AI memang cepat, tetapi bug yang dimasukkan AI anehnya lebih sulit ditemukan
Bukan bug yang jelas, melainkan logika yang tiga minggu kemudian merusak sesuatu di lingkungan produksi, lalu setelah ditelusuri ternyata AI salah memahami bagian yang halus
Sejujurnya AI bukan mengurangi biaya pemeliharaan, melainkan memindahkan lokasi biayanya
Waktu penulisan berkurang, waktu review bertambah
Kode AI tetap terdengar fasih dan percaya diri bahkan saat salah, jadi lebih sulit direview daripada kode manusia
Apakah hasil akhirnya menguntungkan sepenuhnya bergantung pada seberapa baik tim dalam membaca kode dibanding menulisnya
Dalam pengalaman saya, AI memang menurunkan biaya pemeliharaan
Tapi konteks mungkin penting. Saya menangani berbagai proyek yang sudah berumur puluhan tahun, dan meskipun ada banyak pengembangan fitur baru, kode lama dan proyek lama tiba-tiba menjadi jauh lebih mudah ditangani dan dimodernisasi, dan dalam banyak kasus bahkan bisa dihapus
Ketergantungan pada library lama dan alat build dalam beberapa kasus diperbarui, dalam kasus lain malah dihapus begitu saja, build menjadi lebih cepat dan lebih mudah bagi developer
Penyiapan dan otomasi end-to-end test juga jauh lebih mudah, DevOps banyak membaik, dan diagnosis masalah operasional juga meningkat besar
Ada sangat banyak log dan informasi, plus dashboard terintegrasi dan monitoring untuk menangkap hal-hal penting, tetapi sekarang kami bisa melakukan analisis jauh lebih banyak untuk sekitar 50 proyek sistem yang sudah dideploy
Argumen dasar tulisan itu adalah soal untuk tiap 1 jam pengembangan fitur yang “menambah nilai”, berapa jam pemeliharaan yang harus dilakukan
Jadi pertama, kita tidak boleh hanya mengukur biaya pemeliharaan, tetapi harus melihat rasionya, dan kedua, kode lama itu sejak awal bukan ditulis oleh AI
Tapi inti penulis tampaknya adalah bahwa kalau akses ke tool AI hilang, semua akan terasa jauh lebih berat
Ibarat memindahkan gunung dengan alat berat lalu harus kembali memakai alat tangan
Seiring jumlah baris kode yang dideploy, jumlah insiden juga bertambah, dan insidennya makin serius
Tentu saja kami banyak memperbaiki kode lama, menghapus lebih banyak kode, bisa mengotomatisasi modernisasi kode, lebih baik mendiagnosis masalah, dan punya lebih banyak opsi mitigasi
Tetapi semua itu tidak mampu menutupi skala luar biasa besar dari kode yang dideploy tanpa benar-benar dipahami siapa pun
Tim kami memang menambahkan kode dengan AI, tetapi juga memakainya untuk secara agresif menghapus kode lama yang sudah ditinggalkan
Pertanyaan seperti “apakah masih ada yang memakai ini?” atau “ini dipanggil dari mana?” jadi lebih mudah dijawab dengan melempar frontend, backend, dan seluruh codebase ke agent agar ia membuat peta proyek software
IDE sampai taraf tertentu juga bisa membantu kalau hanya satu bahasa dan biasanya satu proyek, tetapi batas seperti RPC atau REST sering merusak tool IDE
Saya sangat suka pertanyaan ini: jika bisa memilih, codebase seperti apa yang ingin kita punya?
Kalau dipikir sebentar, mungkin kita sebenarnya tidak menginginkan codebase dengan fitur yang sangat banyak
Yang diinginkan adalah codebase yang cukup mirip dengan yang sekarang, tetapi mudah dipahami, serta mudah dipelihara dan diperluas sesuai tantangan bisnis ke depan
Codebase yang “bekerja”, yaitu yang dipelihara, sedang menyelesaikan masalah dunia nyata, dan menyelesaikan masalah itu harus selalu lebih diprioritaskan daripada kerapian
Codebase yang rapi sering kali hanyalah contoh pajangan yang diletakkan di rak untuk dikagumi
Saya ingin menambahkan dua hal
Pertama, dalam software bukan hanya ada pemeliharaan teknis, tetapi juga dukungan pengguna, dan ini juga bertambah seiring software membesar
Kedua, saya tidak yakin biaya pemeliharaan meningkat secara linear
Bahkan kalau pun linear, pada akhirnya akan sampai ke titik di mana semua waktu habis hanya untuk pemeliharaan
Bisa jadi, kalau yang harus dipelihara bukan hanya tiap bagian, tetapi juga cara bagian-bagian itu saling berinteraksi
Sinyal terkuat yang pernah saya lihat soal apakah AI benar-benar menurunkan biaya pemeliharaan adalah apakah developer memperlakukan output AI sebagai draf, atau sebagai hasil akhir
Saat memakai tool AI pada codebase yang sudah ada, misalnya untuk memahami modul yang asing, menghasilkan refactor yang terarah, atau menulis skrip migrasi, beban pemeliharaan memang benar-benar turun
Karena AI bekerja pada kode yang secara arsitektural sudah saya pahami, saya bisa cepat mengevaluasi outputnya
Masalah muncul saat AI menghasilkan kode baru yang tidak dipahami secara mendalam oleh siapa pun
Kode itu harus dipelihara oleh orang yang tidak menulis maupun merancangnya
Kalau itu kode buatan orang lain, setidaknya kita masih bisa menebak niatnya dari nama, struktur, dan riwayat commit
Kode hasil AI sering kekurangan niat yang bisa dibaca seperti itu karena “penulisnya” tidak punya niat berkelanjutan yang konsisten di seluruh file
Bagian yang benar dari tulisan itu adalah bahwa kita harus mengukur bukan hanya kecepatan, tetapi juga biaya pemeliharaan
Dalam praktiknya, kita harus melacak waktu yang dibutuhkan untuk memahami kode bantu-AI versus kode tulisan manusia, serta tingkat kegagalan perubahan, selama beberapa bulan, bukan hanya beberapa hari
Hal yang sama juga berlaku untuk code review
Saya penasaran apakah AI bisa membuat code review lebih enak dilihat
Dalam review kode manusia, developer cepat belajar menghindari perubahan visual yang tidak perlu, seperti me-reflow kode atau komentar, mengubah indentasi yang tidak bisa disembunyikan tool, memindahkan fungsi, atau menghapus baris
Refactor yang tidak perlu juga sebaiknya dihindari
Mungkin review bisa dipisah menjadi dua: perubahan fungsional dan perubahan tampilan
Dengan begitu review jadi jauh lebih mudah
Review dimulai dari asumsi “tidak ada yang boleh berubah”, dan reviewer bisa melakukan pattern matching
Kalau tidak, reviewer harus mengevaluasi ulang setiap baris kode untuk memastikan memang tidak ada yang berubah, dan itu sangat sulit dilakukan dengan benar
Sistem version control yang pernah saya pakai semuanya mengizinkan antrean perubahan yang direview secara independen
Jika perlu refactor saat sedang mengembangkan fitur, buat satu commit untuk refactor, kirim untuk review, lalu rebase pekerjaan yang sedang berjalan dan lanjutkan
Jika perubahan seperti “CLEANUP:” dan “REFACTOR_ONLY:” terus dialirkan, perubahan akhirnya akan jauh lebih kecil daripada satu perubahan monster yang raksasa
Reviewer akan berterima kasih atas usaha itu
Dalam organisasi seperti itu, bahkan permainan metrik pun bisa dilakukan tanpa jadi sesuatu yang jahat
Penulis tampaknya berangkat dari asumsi bahwa manusia harus meninjau semua kode AI secara rinci, dan harus mampu memahami serta memeliharanya tanpa bantuan AI
Dari pengalaman saya, orang-orang tidak memakai AI seperti itu
Awalnya memang begitu. Sebelum percaya, dan sebelum belajar cara mem-prompt agar mendapatkan hasil yang diinginkan, mereka memakainya untuk mengotomatisasi bagian yang membosankan, sementara implementasi awal atau polanya dibuat manusia dan AI mengisi celahnya
Ini lebih mirip autocomplete yang diperkuat daripada perubahan total dalam cara menulis kode
Semakin sering orang bekerja dengan AI, semakin kecil kekhawatiran mereka terhadap kode yang sebenarnya dihasilkan AI
Ini bukan berarti baik. AI bisa membuat bug, masalah performa, dan celah keamanan
Tetapi begitulah kenyataannya. Apakah kode AI membuat bug? Suruh saja AI memperbaikinya
Apakah kode AI bengkak dan sulit dibaca? Jika itu mengganggu, suruh AI memperbaikinya. Banyak orang tidak terlalu peduli
Jika manusia sepenuhnya keluar dari pemeliharaan kode, kebutuhan akan kode yang dapat dipelihara juga hilang
Kita memang belum 100% sampai ke sana, tetapi sedang bergerak ke arah itu
Bagi banyak perusahaan, hasil yang sudah cukup lumayan sekarang ini memang layak untuk mengambil risiko dan jalan YOLO
Secara pribadi saya belum cukup percaya untuk tidak membaca kode yang dihasilkan AI, tetapi saya juga tidak membaca setiap baris
Saya meninjau test lebih teliti daripada kode yang diuji, lebih memperhatikan bagian yang sensitif terhadap performa, dan mengarahkan struktur keseluruhannya
Kalau tetap belum memenuhi standar, saya tidak memeliharanya sendiri, saya menyuruh AI memperbaikinya
Jika pemeliharaan semurah ini, maka biaya pemeliharaan tidak naik menjadi perhatian saya
Tulisan ini menyoroti dengan baik kebutuhan agar agent atau alat bantu AI membantu bukan hanya pada bagian awal “tolong buat widget baru”, tetapi juga banyak bagian lain dalam pengembangan software
Penulis menilai bahwa jika seseorang memakai agent atau alat bantu AI hanya pada tahap membuat widget baru, maka karena AI menghasilkan lebih banyak kode, jumlah kode yang harus dipelihara juga jadi jauh lebih banyak
Bahkan jika kualitas kodenya tinggi, biaya pemeliharaan akan muncul seiring waktu
Namun, masalah yang dibicarakan penulis terasa bukan sesuatu yang pasti dialami semua orang, melainkan dalam banyak hal adalah masalah yang diciptakan sendiri
Situasi startup yang disebut penulis, yaitu “ayo buat ini jalan dulu bagaimanapun caranya agar bisa memeriksa kecocokan dengan pasar dan mendapatkan pelanggan”, sejak dulu memang selalu membawa biaya pemeliharaan yang lebih tinggi di kemudian hari
Itu karena menurunkan kualitas demi kecepatan sampai tingkat tertentu memang masuk akal untuk memastikan apakah bisnisnya ada, dan kalau ada, untuk menumbuhkannya dengan cepat
Selain itu, penulis juga terasa enggan membahas bagaimana AI sebenarnya bisa membantu pada sisi pemeliharaan
AI bisa sangat berguna, dengan arahan manusia, untuk memperbaiki dependensi lama atau menyelesaikan bug yang menjengkelkan
Jenis pekerjaan seperti ini bisa terasa seperti kerja kasar bagi software engineer, dan memang jenis bantuan yang membuat orang ingin memakai AI