Agen coding AI untuk penulisan kode harus benar-benar mengurangi biaya pemeliharaan
(jamesshore.com)- Meskipun agen coding AI dapat meningkatkan kecepatan penulisan kode, jika tidak bisa menurunkan biaya pemeliharaan dengan proporsi yang sama, maka setelah peningkatan produktivitas sementara justru akan berujung pada penurunan produktivitas permanen
- Semua kode, setelah ditulis, memerlukan pemeliharaan berkelanjutan seperti perbaikan bug, perapian, dan upgrade dependensi, dan seiring waktu pemeliharaan akan mengambil porsi terbesar dari total waktu kerja
- Jika output kode meningkat 2 kali lipat dan biaya pemeliharaan juga menjadi 2 kali lipat, maka biaya pemeliharaan nyata akan naik 4 kali lipat, sehingga dalam beberapa bulan keuntungan produktivitas akan hilang
- Bahkan jika AI dihapus, beban pemeliharaan dari kode yang sudah dibuat tetap ada, sehingga produktivitas bisa terkunci pada level lebih rendah dibanding jika AI tidak pernah digunakan
- Untuk meningkatkan produktivitas 2 kali lipat, dibutuhkan AI yang menurunkan biaya pemeliharaan tepat menjadi setengahnya, dan upaya untuk mengurangi biaya pemeliharaan harus sebesar upaya meningkatkan kecepatan coding
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 tersebut masih ada
- Estimasi contoh ini mengasumsikan bahwa untuk setiap 1 bulan penulisan kode dibutuhkan 10 hari pemeliharaan pada tahun pertama, lalu 5 hari setiap tahun setelahnya
- Penulis menilai bahwa jika biaya pemeliharaan ditanyakan kepada sekitar 50 developer dengan pendekatan Wisdom of the Crowd, hasilnya bisa 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 atas kode lama makin besar
- Dalam estimasi tersebut, setelah 2,5 tahun waktu untuk pemeliharaan melebihi setengah dari 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 menginginkan tim yang produktif, fokus utama harus pada biaya pemeliharaan, bukan kecepatan menulis kode baru
Modelnya bisa salah, tetapi arahnya benar
- Pada startup tahap akhir, setelah sekitar 5~9 tahun muncul masalah ketika tim tidak lagi mampu menuntaskan pekerjaan dengan baik, dan ini mirip dengan pola pada grafik
- Alasan tim nyata tidak tampak seburuk grafik bisa jadi karena biaya pemeliharaannya 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 mulai melambat lalu terus menambah lagi, atau membuang semuanya dan menulis ulang dari awal
- Angka pastinya bisa diperdebatkan, tetapi arus besar berupa penurunan produktivitas seiring waktu tampaknya sesuai dengan pengalaman di lapangan
Efek penggandaan yang diciptakan agen coding AI
- Sebagai contoh, diasumsikan framework coding berbasis agen terbaru Rock Lobster menggandakan output kode
- Pada saat yang sama diasumsikan kodenya menjadi sedikit lebih sulit dipahami, tim kewalahan oleh pull request, dan kode tidak benar-benar dibaca dengan baik sebelum disetujui
- Jika dalam 1 bulan dihasilkan kode setara 2 bulan kerja, dan biaya pemeliharaan hasil tersebut juga menjadi 2 kali lipat, maka biaya pemeliharaan pada bulan berikutnya menjadi 4 kali lipat
- Dalam contoh ekstrem ini, setelah memakai Rock Lobster, produktivitas kembali ke level awal hanya dalam sekitar 5 bulan, dan beberapa bulan kemudian malah menjadi lebih buruk dibanding jika tidak memakainya sama sekali
- Ini bukan berarti AI benar-benar menggandakan produktivitas atau biaya pemeliharaan, melainkan menekankan bahwa bahkan jika maintainability-nya setara dengan kode buatan manusia, keuntungan produktivitas tidak akan bertahan lama
Biaya pemeliharaan tetap ada meski agen dihentikan
- Agen coding memiliki biaya, dan jika manfaatnya menjadi lebih kecil daripada biayanya, tim mungkin ingin kembali ke cara lama
- Ketika penggunaan agen dihentikan, keuntungan produktivitasnya hilang, tetapi biaya pemeliharaan tambahan dari kode yang dibuat oleh agen akan tetap ada selama kode tersebut masih ada
- Dalam kasus ini, produktivitas bisa terjebak pada level yang lebih rendah dibanding jika agen itu sama sekali tidak pernah dipakai
Satu-satunya matematika yang masuk akal adalah penurunan biaya pemeliharaan
- LLM harus menurunkan biaya pemeliharaan sebesar kebalikan yang tepat dari rasio kenaikan output kode agar perhitungan produktivitas total tetap masuk akal
- Jika output menjadi 2 kali lipat dan biaya pemeliharaan dari output tersebut juga 2 kali lipat, maka total biaya pemeliharaan menjadi 4 kali lipat
- Jika output menjadi 2 kali lipat tetapi biaya pemeliharaan per hasil tetap sama, total biaya pemeliharaan tetap menjadi 2 kali lipat
- Jika output menjadi 2 kali lipat maka biaya pemeliharaan harus menjadi setengah; jika output menjadi 3 kali lipat maka biaya pemeliharaan harus menjadi sepertiganya
- Hanya dengan memenuhi syarat ini keuntungan kecepatan bisa didapat tanpa terjebak dalam ketergantungan jangka panjang
Kekhawatiran terhadap agen coding saat ini dan kemungkinan tuas lain
- Dari sumber seperti Hacker News, tampak banyak sinyal bahwa agen coding justru menaikkan biaya pemeliharaan
- Sebagian orang mengatakan alat ini membantu memahami sistem berskala besar, tetapi penurunan besar pada biaya pemeliharaan yang diperlukan belum terlihat, malah cenderung sebaliknya
- Model ini mungkin tidak merepresentasikan realitas secara sempurna, tetapi pesannya tetap valid: AI harus menurunkan biaya pemeliharaan sebanding dengan peningkatan kecepatan penulisan kode baru
- Bahkan saat mengejar peningkatan kecepatan coding, waktu yang sama banyaknya 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
- Jika ingin mengubah asumsi agar sesuai dengan kondisi nyata, Anda bisa menyalin spreadsheet dan menyesuaikan berbagai variabel dalam model
2 komentar
Alasan paling mendasar munculnya ketidakpercayaan terhadap AI adalah
saat ini sebagian besar orang yang mengaku ahli berteriak bahwa mereka sendiri tidak mengalami kekurangan AI yang dibicarakan orang lain, dan juga tidak ada trade-off, sambil bertingkah seperti calo.
Penipu sudah makin banyak, jadi ketidakpercayaan terhadap keseluruhan bidang ini pun menumpuk.
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