- Penggunaan alat coding AI berarti menambah "utang kode"
- Dari dua perusahaan dengan produk dan pendapatan yang sama, perusahaan yang berjalan dengan 100 ribu baris kode jauh lebih cepat dipahami dan dimodifikasi daripada perusahaan dengan 1 juta baris kode
- Artinya, semakin banyak kode, semakin besar utang yang menumpuk; pembuatan kode dengan AI memang meningkatkan produktivitas, tetapi pada saat yang sama juga dapat dipahami sebagai tindakan yang menambah utang
- Utang memiliki dua sisi: positif dan negatif
- Positif: memungkinkan pertumbuhan cepat dalam jangka pendek
- Negatif: dalam jangka panjang, jika gagal dikelola, dapat menimbulkan risiko keruntuhan proyek
- Jadi, utang bisa baik atau buruk, bisa berbunga atau tidak, dapat memungkinkan pertumbuhan cepat tetapi juga bisa membuat proyek runtuh
- Yang penting bukanlah apakah alat itu digunakan, melainkan sikap untuk mengelolanya secara bertanggung jawab
- Sambil menjamin akses yang mudah ke alat, kita juga perlu mempertimbangkan kualitas kode yang dihasilkan dan biaya jangka panjangnya
5 komentar
Kalau kode sangat panjang sekalipun tetapi bisa dengan mudah dijelaskan "melakukan apa", itu bukan utang.
Maksudnya, penggunaan AI secara serampangan membuat hal itu menjadi sulit, sehingga menciptakan utang.
https://github.com/kelseyhightower/nocode
Memang tidak dijelaskan secara jelas di isi tulisannya, tetapi mungkinkah maksudnya bahwa jika kode ditulis dengan AI, karena lebih tidak familier dibanding yang ditulis langsung oleh manusia, itu bisa menjadi utang?
Pendapat Hacker News
Secara permukaan, mengukur segalanya hanya dengan jumlah baris kode (LOC) terasa terlalu sempit. Jika Company A memiliki 1 juta baris kode yang jauh lebih bersih, tertata, dan terdokumentasi dengan baik, maka itu bisa jadi kondisi yang lebih baik daripada Company B dengan 100 ribu baris kode yang ditulis dengan buruk. Intinya, masalahnya bukan pada kodenya melainkan pada kompleksitasnya, dan jumlah baris hanya indikator kasar untuk mengukur kompleksitas. Kode adalah aset. Itu adalah output sekaligus aset dari perusahaan perangkat lunak. Tentu, semakin banyak aset maka kompleksitas juga meningkat, tetapi itu hal yang terlalu jelas. Sama seperti jaringan jalan raya di Amerika Serikat tidak bisa dinilai sepenuhnya negatif hanya karena sulit dirawat dan rumit. Bahkan jika isu AI dikesampingkan, pada akhirnya argumen penulis hanya bermuara pada kesimpulan dasar yang semua orang sudah tahu: "semakin sedikit kompleksitas, semakin baik". Jadi, poin terpenting dari tulisan ini bisa dipadatkan menjadi: "pastikan alat coding AI tidak menambahkan kompleksitas yang tidak perlu ke kode akhir"
Menurut saya justru kompleksitas bukan isu inti di sini. Kalau dibalik dan diasumsikan sudah ada bisnis software yang berhasil bertahan, maka semua biaya (pembelian, gaji, dan lain-lain) pada prinsipnya sebaiknya ditekan semaksimal mungkin. Memang kompleksitas dikatakan lebih buruk daripada kesederhanaan, tetapi itu karena kalau benar-benar kompleks maka biayanya lebih mahal. Namun yang pada akhirnya penting adalah biaya itu sendiri, baik jangka pendek maupun jangka panjang, baik modal maupun operasional. Pertanyaan sebenarnya adalah apakah kode hasil LLM menurunkan biaya atau justru menaikkannya. Ukuran kode, kompleksitas, dan tak terhitung banyaknya variabel lain yang tidak disebutkan oleh OP maupun kamu, semuanya penting
Saya biasanya melihat kompleksitas fungsi saya dengan cyclomatic complexity. Saya mengukur kompleksitas dengan SwiftLint dan menandainya jika melewati ambang batas. Kadang saya memang memecahnya secara agak kasar, tetapi biasanya saya berusaha keras mencari cara agar bisa dibuat lebih sederhana. File-file saya cukup panjang, tetapi saya berusaha menjaga rasio komentar dan kode sekitar 50:50. Kalau memberi prompt ke LLM untuk mengurangi kompleksitas dan menambah komentar, sepertinya ia bisa melakukannya dengan cukup baik
Kode itu seperti bahan kimia volatil: ia bisa menjadi aset sekaligus utang. Jika digunakan dengan benar dan cepat, ia bisa menghasilkan uang, tetapi jika dibiarkan atau tumpah, ia menjadi liabilitas. Source code tidak membusuk dengan sendirinya, tetapi seiring tujuan dan proses organisasi berubah, 'kesesuaian terhadap tujuan' juga terus berubah
Topik "mengapa kita tidak bisa membuat software yang sederhana?" terasa menarik. Tentang kompleksitas, saya terkesan dengan poin bahwa "kompleksitas muncul ketika sistem saling berinteraksi. Sistem yang kompleks bisa melenceng secara tidak rasional, dan juga menghasilkan kreativitas yang tak terduga"
Saya merasa software itulah asetnya, bukan kodenya. Sama seperti aset dari jalan raya bukanlah beton, melainkan infrastruktur yang sudah jadi. Kualitas beton memengaruhi depresiasi nilai aset dan biaya pemeliharaan, dan itu pada gilirannya memengaruhi nilai aset. Perspektif manajemen risiko juga wajib dipertimbangkan di sini
Di awal karier saya, saya pikir menulis banyak kode itu penting. Setelah 20 tahun, sekarang saya justru bangga karena bisa menghapus lebih banyak kode. Dari sudut pandang engineer keamanan, kode bukan cuma utang tetapi juga risiko. Terutama dependensi pada library eksternal adalah risiko besar. Baru-baru ini saya dan seorang rekan menulis init system Linux kecil dengan kurang dari 600 baris, hanya memakai standard library Rust, dan sekarang dipakai di production di beberapa organisasi. Tanpa dependensi, dan boot selesai dalam kurang dari 1 detik. Rasanya jelas bahwa server Linux bergaya appliance bisa dibuat tanpa systemd dan tanpa jutaan baris kode C. Kalau dibuat sendiri, jumlah kodenya jauh lebih sedikit dan kita bisa benar-benar memahami seluruh sistem
Saya rasa skenario terburuk dari kode yang dihasilkan AI lebih jelas terlihat bukan dari sudut pandang perusahaan, melainkan pada proyek yang lebih personal. Saya bisa menulis sendiri 10.000 baris kode yang sangat bagus dan benar-benar saya pahami, atau saya bisa jauh lebih cepat menghasilkan 20.000 baris kode yang bermasalah. Saya pribadi berusaha mencari keseimbangan di antaranya. Jika saya terus mencoba memperluas pengembangan, saya merasa waktu yang dihabiskan pada kasus pertama pada akhirnya bisa menjadi kerugian
Saya rasa selalu ada titik tengah. Dalam kasus saya, saya hanya pernah menyerahkan generasi kode nyata ke AI untuk kode yang mandiri seperti skrip Bash dan Python. Skrip seperti ini hanya berinteraksi dengan command line, jadi batasnya jelas dan mudah dikelola. Kode seperti ini biasanya saya tulis sekali lalu tidak pernah saya lihat lagi. Namun menghasilkan kode domain bisnis inti dengan AI tidak banyak artinya, jadi saya tidak melakukannya. Toh saya tetap harus melakukan code review, dan yang benar-benar saya butuhkan adalah situasi di mana saya bisa memverifikasi maintainability kode tersebut. Jika bukan situasi di mana kodenya bisa langsung dibuang atau hanya perlu ditinjau secara ringan, maka tidak perlu memakai alat pembuat kode. Ceritanya akan berbeda kalau AI bisa berperan sebagai product owner, memahami kerugian bisnis nyata, dan bahkan memperbaikinya, tetapi saat itu saya malah akan khawatir soal risiko pengguna menjadi tidak dibutuhkan lagi
Saya juga setiap kali terlalu percaya dan menyerahkan terlalu banyak kode ke AI, pada akhirnya selalu harus membayar mahal dengan produktivitas yang hilang. Kalau semua aplikasi dibuat dengan vibe coding, kemampuan yang paling dibutuhkan mungkin adalah menilai, “apa fitur ini memang benar-benar diperlukan?” Membayangkan harus men-debug spaghetti code sambil tidak paham sama sekali peran tiap baris terasa benar-benar menyakitkan
Kamu bilang kasus pertama kehilangan waktu, tetapi kasus kedua juga pada akhirnya kehilangan waktu, hanya saja lewat jalur lain: kode lebih buruk, waktu lebih cepat. Esensinya tetap ada pada mencari titik tengah
Kode yang ringkas tetapi penamaan variabelnya buruk atau terlalu pintar justru jauh lebih buruk dibanding kode yang lebih panjang, terdokumentasi baik, dan kaya nama variabel yang jelas. Utang pada akhirnya sebanding dengan waktu yang dibutuhkan untuk memahami, mengubah, dan memperluas kode. Jumlah baris kode juga bukan metrik yang bisa mengukur utang secara sempurna. Jika semua kondisi benar-benar sama, mengurangi jumlah kode justru bisa mengorbankan keterbacaan dan membuat utang bertambah. Karena itu, saya merasa klaim bahwa 'ketiadaan teori adalah utang' lebih tepat. Bahkan kode yang pendek itu sendiri bisa menjadi utang dari sudut pandang LLM. Alasannya, penggunaan LLM meminimalkan pembangunan teori, dan ini terutama relevan dalam kondisi saat ini ketika AI belum mampu membangun teori tentang keseluruhan proyek dengan sendirinya lalu menyampaikannya dengan benar kepada engineer
Saya suka melihat pemrograman sebagai proses membangun teori. Khususnya untuk program bisnis, teori itu harus berpusat pada bisnis. Misalnya, menurut saya sudut pandang seperti "apakah mudah merekrut developer untuk codebase ini", "seberapa stabil model bisnisnya", dan "seberapa penting secara bisnis tiap fitur" harus masuk dalam pertimbangan
Tiba-tiba saya mendapat ide. Saya penasaran apakah AI bisa dipakai untuk menanyakan arti nama variabel atau penjelasan fungsi di dalam kode. Selama ini saya hanya memakai AI untuk generasi kode
Ada perusahaan tempat saya bekerja cukup lama yang tidak punya aset kode internal sendiri, tetapi bisnis intinya bergantung pada layanan enterprise pihak ketiga eksternal. Pertanyaan saya, dalam kasus seperti ini sebenarnya bagaimana kita mengukur berapa banyak kode yang benar-benar kita miliki? Misalnya, jika kita bergantung pada penyedia SaaS legacy, apakah jumlah baris kode di pihak mereka juga harus dianggap sebagai utang kita?
Menurut saya, risiko terbesar dari bergantung pada layanan pihak ketiga adalah jika mereka bangkrut atau syarat layanannya berubah karena merger dan akuisisi. Sering kali kita terpaksa memakai layanan dari startup yang modalnya besar tetapi bisnisnya sendiri belum benar-benar berdiri kokoh
Saya sangat setuju soal ini. Di perusahaan lama saya, kami memakai SaaS email marketing, dan meskipun kode integrasi yang kami buat cuma 500 baris, kami sangat kewalahan memadamkan masalah karena layanannya sendiri bermasalah. Pada akhirnya kami mengimplementasikan ulang hanya fitur yang kami butuhkan dan membawanya in-house; hasilnya kami menghemat banyak biaya dan penderitaan, meskipun jumlah baris kode bertambah sekitar 3 ribu
Saya kurang paham.
Kode jelas memang aset, tetapi seperti hardware, nilainya juga terdepresiasi karena berbagai penyebab (cacat, perubahan industri software/hardware, dan sebagainya). Semakin banyak kode software, semakin besar biaya depresiasi tahunan yang harus ditanggung. Jika pengelolaannya tidak cukup baik (misalnya jumlah kodenya terlalu banyak dibanding jumlah developer), maka biaya untuk memperbaiki masalah nantinya bisa meningkat secara eksponensial. Seolah ada 'bunga' yang menempel pada konsep depresiasi. Jadi saya paham mengapa istilah 'utang' dipakai, tetapi konsepnya tidak sepenuhnya identik
Tentu saja repositori yang paling sempurna adalah ini
Dulu saya bangga bisa menghapus 20 ribu baris kode per bulan. Beberapa tahun lalu saya mencoba melakukannya lagi bersama tim remote berisi 20 developer, tetapi pull request datang terlalu deras sehingga mustahil diikuti. Sekarang saya pair programming dengan Claude Code dan GPT, dan rasanya sangat mirip dengan situasi kedua. Menurut saya ada peluang refactoring yang cerdas di sini. Hanya saja, sepertinya dibutuhkan jauh lebih banyak konteks. Saya pernah mencoba hal seperti ini pada kode legacy dengan Cursor dan Claude opus 4.1, tetapi bahkan satu juta token pun tidak cukup. Mungkin pendekatannya bisa berupa menerjemahkan antara LLM personal dan LLM bersama, tetapi saya penasaran apakah ada yang punya pengalaman seperti itu
Sepertinya tidak banyak orang yang mengajukan pertanyaan yang sangat penting ini: "berapa jumlah kode minimum yang secara absolut diperlukan untuk mengimplementasikan fitur X secara penuh?" Tentu saja mustahil menjawabnya dengan tepat, tetapi cara berpikir seperti ini membantu membentuk pola pikir yang efisien. Sebaliknya, orang justru banyak tertarik pada hal-hal seperti verifikasi formal yang sebenarnya tidak terlalu penting secara praktis. Verifikasi formal tanpa mempertimbangkan jumlah kode minimum yang layak justru bisa menjadi pemborosan dan tidak bermakna. Dan biasanya orang mengira kode yang ditulis engineer itu pasti bagus, padahal kenyataannya sebagian besar justru menambah abstraksi dan kompleksitas yang tidak perlu sehingga pekerjaan malah bertambah. Sebagian besar software engineering justru bernilai negatif. Tentu saja ada campuran nilai positif dan negatif, sehingga menilainya menjadi lebih sulit