Pembuatan Kode LLM Dapat Menyebabkan Melemahnya Kepercayaan

• Belakangan ini, pembuatan kode berbasis LLM semakin banyak digunakan di kalangan pengembang
• Kode yang dihasilkan secara otomatis memicu meningkatnya kekhawatiran terhadap kualitas dan keandalan kode
• Pengembang mengalami meningkatnya kesulitan pemeliharaan proyek akibat kurangnya pemahaman terhadap kode dan verifikasi yang tidak memadai
• Meluasnya penggunaan kode yang tidak dapat dipercaya berdampak pada seluruh ekosistem perangkat lunak
• Seiring kemajuan teknologi, kebutuhan untuk menyiapkan cara memastikan keandalan semakin ditekankan

---

Gambaran Umum

Jay membahas di blognya dampak teknologi pembuatan kode berbasis LLM (large language model) yang belakangan muncul terhadap praktik pengembangan perangkat lunak. Perkembangan alat-alat ini memang meningkatkan efisiensi pengembangan, tetapi pada saat yang sama juga memunculkan persoalan keandalan dan kualitas kode.

Meningkatnya Teknologi Pembuatan Kode LLM

• Di lapangan pengembangan, alat pembuatan kode otomatis yang memanfaatkan LLM menyebar dengan cepat
• Alat ini memberikan produktivitas tinggi dalam implementasi fitur yang kompleks maupun pekerjaan coding yang berulang
• Memiliki keunggulan untuk pembuatan prototipe cepat serta mengurangi beban saat mempelajari bahasa baru

Masalah Keandalan

• Kode yang dihasilkan LLM tidak selalu berjalan sesuai yang dimaksud
• Niat dan logika desain di dalam kode sering kali tidak jelas sehingga proses pemahaman dan verifikasi menjadi sulit
• Jika proses review dan pengujian kurang memadai, ada kemungkinan muncul bug atau kerentanan yang tidak terduga

Pemeliharaan Proyek dan Dampak terhadap Ekosistem

• Muncul masalah kurangnya dokumentasi dan penjelasan yang tidak memadai untuk kode yang dibuat otomatis
• Pengembang kesulitan memahami prinsip kerja kode sehingga kompleksitas pemeliharaan meningkat
• Ada risiko budaya pengembangan perangkat lunak yang andal menjadi terkikis

Kesimpulan dan Saran

• Teknologi pembuatan kode berbasis LLM bersifat inovatif, tetapi memastikan keandalan adalah tugas yang sangat penting
• Saat mengadopsi kode yang dihasilkan otomatis, perlunya verifikasi yang lebih kuat dan code review yang sistematis ditekankan
• Dalam jangka panjang, penting untuk menyiapkan standar guna melindungi kepercayaan dalam ekosistem komputasi

[GN⁺]

Opini Hacker News

• Berbagi tautan archive.is, berfungsi juga di browser lawas dan JavaScript hanya diperlukan untuk melewati CloudSnare

• Teman saya sering berkata, "inovasi terjadi secepat tingkat kepercayaan." Sejak GPT3 muncul, kalimat itu terus terngiang di kepala saya. Verifikasi itu mahal, dan kepercayaan adalah cara utama untuk menurunkan biaya itu. Tapi saya tidak tahu bagaimana membangun kepercayaan terhadap LLM. Ia sangat fasih dalam coding maupun bahasa alami, tetapi pada saat yang sama juga bisa menyimpang ke arah yang, kalau dilakukan manusia, akan dianggap berniat buruk

  • Saya penulisnya: saya sangat suka kutipan itu. Itu merangkum dengan sangat ringkas apa yang saya jelaskan dalam beberapa paragraf. Dunia di mana sekarang kita harus memverifikasi semuanya satu per satu, terus terang sangat melelahkan dan lambat
  • Kita tidak bisa punya kepercayaan penuh pada hasil LLM. Tapi kita bisa melakukan penyaringan dan pembatasan daya rusaknya. Pada akhirnya akan mengerucut ke standar seperti memfilter input pengguna, melakukan penetration testing, menyimpan rahasia di file dot, lalu mengikuti "best practice" dan "kepatuhan regulasi SOC-AI". LLM terlalu berguna untuk diabaikan. Kepercayaan juga dibangun selangkah demi selangkah. Manusia sendiri juga jauh dari andal, dan kalau dibandingkan dengan mobil swakemudi, sepertinya kita akan sampai pada titik di mana LLM bisa menghasilkan kode yang lebih sedikit bug-nya daripada manusia dalam aturan yang sudah ditetapkan. Setelah itu, yang tinggal hanyalah memperbaiki kompleksitasnya sedikit demi sedikit
  • "Inovasi terjadi secepat tingkat kepercayaan" rasanya perlu dijelaskan lebih jauh. Saat listrik, penerbangan, atau radioaktivitas pertama kali ditemukan, apakah sudah ada tingkat kepercayaan seperti itu? Dalam sains, kepercayaan dibangun sambil berjalan

• Saya mengalami topik ini dengan cara yang tak terduga di kantor. Karena tekanan hasil cepat, seorang rekan dan saya menggabungkan refactor besar yang saya kerjakan meski PR-nya masih bersifat sementara. Setelah itu muncul bug di kode yang belum teruji. Saat debugging, rekan saya mengaku ia mengira saya menulisnya dengan AI, dan ia frustrasi karena mencoba memahami kode buatan AI itu belakangan. Padahal kode itu saya tulis sendiri dengan teliti, dan penyebab bug-nya hanyalah kesalahan kecil dalam proses perubahan API sederhana. Justru dari pengalaman ini, saya bisa secara alami menampakkan ketegangan soal kepercayaan dengan rekan saya dan membicarakannya secara konstruktif. Kalau dipikir sekarang, pengalaman membangun kepercayaan seperti ini cukup bermakna, dan kalau lingkungannya berbeda mungkin bisa menjadi jauh lebih rumit. Rasanya memang harus selalu berhati-hati

• Saya kurang paham premisnya. Kepercayaan bahwa seseorang menulis kode yang baik datang dari pengalaman nyata bahwa orang itu menulis sendiri dan hasilnya memang bagus. Kalau pakai LLM tapi tetap menghasilkan kode tanpa bug, saya percaya; kalau pakai LLM dan tetap ada bug, saya tidak percaya. Saya tidak melihat bedanya dengan kalau dia menulis hanya dengan otaknya sendiri

  • Saya penulisnya: maksud saya adalah, di lingkungan dengan kepercayaan rendah seperti tim besar dengan tingkat kepercayaan sedang atau open source, LLM makin membuat sulit menilai kemampuan pengembang hanya dari kode yang dia kirim. Karena kita tidak bisa menangkap kecenderungan orangnya, akhirnya semua kode harus diperiksa teliti dalam mode "tanpa kepercayaan sama sekali". Jalan pintas yang dulu dipakai untuk review cepat tidak lagi berlaku, dan bagi organisasi yang sudah terbiasa dengan budaya itu, ini bisa sangat menyakitkan. Kalau timnya memang sudah sangat saling percaya, masalah ini mungkin sama sekali tidak terasa relevan
  • Dulu kalau A=B, maka B yang tinggi berarti A juga baik. Sekarang menjadi A+Ai=B, jadi meskipun B tinggi, A belum tentu tinggi. Dan karena AI saat ini bersifat probabilistik, cukup sering malah hasilnya lebih buruk daripada tidak melakukan apa-apa
  • Anda bilang "percaya hanya pada kode yang berjalan baik", tetapi dasar kepercayaan itu adalah bahwa pengembang sudah tahu sebelumnya bahwa kodenya benar-benar bebas bug. Namun pada sistem yang kompleks, untuk memahami bagaimana kode itu berinteraksi dengan bagian lain dan kasus tepi apa yang bisa muncul, penulis kodenya harus memahami seluruh konteks. Jika LLM yang menulis kodenya dan pengembang tidak benar-benar memahami isinya, maka beban verifikasi itu berpindah ke reviewer dan berujung overload. Itulah intinya
  • Kalau coding dengan LLM, beberapa kali berhasil lalu orang jadi terlalu percaya diri dan mulai lalai menguji. Dalam praktiknya, banyak masalah muncul dari kesalahan komunikasi. Pekerja mungkin memahami tugas besarnya dengan jelas, tetapi LLM sulit menjaga state dan cenderung membuat asumsi yang tidak masuk akal ketika konteksnya ambigu. Saya berharap pendekatan seperti 4o, yang terus lebih dulu meminta informasi tambahan, menjadi standar di semua model pembuat kode; rasanya itu bisa mencegah sangat banyak masalah
  • Kepercayaan dibangun bukan cuma dari apakah sesuatu berjalan atau tidak. Orang juga menilai dari kemampuan menjelaskan perubahan dengan jelas, riwayat kontribusi yang bagus, ukuran perubahan yang tepat (misalnya commit dengan cakupan yang pas), pemilihan prioritas masalah (memperbaiki bug dulu lalu menambah fitur), kemampuan memelihara kode yang ada, konsistensi aktivitas, dan sebagainya

• Zaman itu sudah tiba. Saya terlalu sering melihat kalimat seperti, "maaf saya melewatkan poin itu, Anda benar." Rasanya 8 atau 9 kali dari 10. Di sisi lain, saya juga sering melihat orang yang sekadar copy-paste kode buatan LLM tanpa makna, lalu marah ketika hasilnya tidak sesuai harapan. Sebenarnya itu lebih baik. Menurut saya, sesuatu yang rusak dengan jelas lebih baik daripada sesuatu yang kelihatannya benar di permukaan

  • Dalam pengalaman saya, LLM sering cenderung memodifikasi kode agar tes lolos, bukan benar-benar memenuhi requirement
  • Apakah kalian memakai LLM lewat chatbot di browser? Kami memakai AI agent dengan akses langsung ke kode, dan ia jauh lebih sedikit bicara serta sering mengerjakan hal yang lebih baik daripada junior di sekitar saya. Ia bagus untuk tugas-tugas singkat dan spesifik, jadi biasanya cukup perlu code review lalu hampir langsung dipakai. Tentu saja prediction engine itu tidak benar-benar paham engineering. Misalnya, kalau tidak diminta secara eksplisit, ia sering menghasilkan kode Python yang memakan memori sangat besar alih-alih memakai generator. Tapi banyak pengembang Python di sekitar saya juga sering membuat kesalahan serupa. Justru karena itu, ia membantu mendorong penulisan spesifikasi yang jelas alih-alih sekadar "tambah fitur". Tempat paling berguna bagi AI agent adalah kode legacy yang tak ingin disentuh siapa pun. Dulu ada sistem yang mengekstrak data dari dokumen faks menggunakan 200 koordinat, sudah dipakai tanpa perubahan selama lebih dari 30 tahun, lalu baru-baru ini format dokumennya berubah. copilot mengubah koordinat itu dalam 30 detik. Kalau manusia, itu bisa makan setidaknya sehari. Tapi saya tidak tahu bagaimana orang bisa menjadi ahli dalam era coding seperti ini
  • 8 atau 9 kali dari 10 itu terlalu berlebihan. Itu statistik yang sepenuhnya dibuat-buat

• Alat abstraksi sebelumnya mengurangi kompleksitas sambil menjadikan "ketepatan" abstraksi itu sebagai premis dasar. Tentu saja tidak sempurna dan ada bug, tetapi itu masalah implementasi, bukan kesalahan yang melekat pada hakikatnya. Begitu ditambal, ia cenderung menjadi lebih kokoh. Sebaliknya, LLM adalah mesin prediksi probabilistik yang hanya menunjukkan akurasi pendekatan untuk jangka waktu tertentu. Yang diabaikan penulis adalah bahwa kita tetap bisa membangun sistem deterministik yang bisa dipercaya dari agent probabilistik yang tidak sempurna. Contohnya, kita mempercayai tool garbage collection bukan karena percaya pada penulis tool itu, melainkan karena tool tersebut sudah cukup diuji dan terbukti bekerja sesuai yang diinginkan. Ke depan, saya rasa test-driven development akan menjadi makin kuat. Bukan kepercayaan, melainkan verifikasi

  • Mengira semua masalah bisa ditangkap dengan pengujian otomatis itu naif. Ada terlalu banyak hal seperti konkurensi, manajemen sumber daya, dan kerentanan keamanan yang sulit diotomatisasi. Dan siapa yang akan memverifikasi tes itu sendiri? Kode dan tes sama-sama mengimplementasikan logika, dan kadang sumber bug justru muncul di sisi tes, bukan di kode. Tes juga tidak boleh dipercaya mentah-mentah
  • Saya penulisnya: di sini saya lebih fokus pada tool-nya sendiri daripada efek tool tersebut. Misalnya, kalau model itu sendiri bertindak langsung sebagai garbage collector, menerima memory dump program lalu memutuskan blok mana yang tidak perlu dan harus dibebaskan, saya tidak akan pernah bisa mempercayai penilaiannya selamanya. Sehebat apa pun ditambal atau di-fine-tune, tetap ada batasnya. Kalau pada output deterministik seperti JVM muncul error, sekali ditambal maka error itu hilang permanen. Pada LLM tidak begitu. Menurut saya, perbedaan inilah titik percabangan mendasar antara abstraksi lama dan dunia LLM. Saya yakin LLM akan sangat berdampak pada industri, tetapi karena contoh historisnya terbatas, ini benar-benar wilayah yang belum dikenal
  • Bagian "sistem deterministik yang tepercaya muncul dari faktor probabilistik (mesin entropi)" terdengar cukup radikal bagi saya. Dan TDD selalu diperkenalkan seolah alat serba bisa yang menyelesaikan semua masalah. Padahal saya sudah melihat, dalam jumlah yang memalukan, pengalaman membangun perangkat lunak yang salah karena tesnya salah

• Kebencian terhadap LLM tidak ada gunanya. Saat ini LLM memang meningkatkan produktivitas pengembang. Setidaknya lebih bermanfaat bagi pengembang yang pengalamannya lebih sedikit. Tool yang sangat meningkatkan produktivitas tidak akan ditinggalkan apa pun kata orang. Tentu, bahkan jika muncul kasus kerusakan besar seperti layanan besar down lama karena bug besar, kalau produktivitas dianggap penting, teknologinya tidak akan berhenti. Satu-satunya jalan realistis adalah menyelesaikan atau memitigasi kelemahan itu sambil tetap berjalan bersama teknologinya. Dalam proses itu, kalau langkah mitigasi merusak peningkatan produktivitas, orang akan mencari jalan memutar, dan yang akhirnya menetap adalah langkah pelengkap yang selaras dengan teknologi

  • Klaim bahwa "LLM meningkatkan produktivitas pengembang" sangat bergantung pada orang dan situasi. Dalam pengalaman saya, yang bilang "produktivitas 10x" biasanya junior frontend atau pengembang startup yang sering membuat aplikasi tahap awal. Tentu itu contoh yang bagus, tetapi pengembang seperti itu dan senior embedded C sering seperti berbicara dalam bahasa yang sama sekali berbeda. Jadi perdebatan produktivitas AI sering kali sebenarnya percakapan dengan konteks yang berbeda. Dan dari sisi "pemanfaatan yang masuk akal", saya juga ragu apakah konsep AI agent itu sendiri bagus. Kalau melihat insiden Copilot, yang jadi bahan olok-olok adalah MS dan AI sekaligus. Pendekatan memberi AI pekerjaan secara otonom belum tentu selalu cerdas. Mirip seperti blockchain yang penuh contoh klaim berlebihan pada masa puncak crypto, tetapi ada juga kasus seperti Coinbase yang benar-benar menemukan niche bermakna. Pada 2020, IBM bahkan mengklaim mengelola rantai pasok biji kopi dengan blockchain (dilihat dari tahun 2025 sekarang terdengar seperti lelucon Twitter, tapi saat itu mereka serius). Pada akhirnya, AI agent saat ini, dan aplikasi AI generatif lainnya, bisa saja nanti dikenang sebagai contoh hype yang berlebihan insiden Copilot artikel Forbes
  • Ungkapan "lebih produktif" terus muncul, tetapi itu tidak mengatakan apakah kombinasi manusia/AI pada akhirnya lebih sesuai dengan kebutuhan pengguna; itu hanya berarti "lebih banyak kode diproduksi". Saya belum pernah mendengar cerita bahwa LLM membuat PR yang menghapus 2.000 baris kode. "Peningkatan produktivitas engineer" pada praktiknya berarti menulis lebih banyak kode
  • Salah paham kalau mengira maksud penulis sepenuhnya kritis. Ini bukan pilihan biner antara memakai atau tidak memakai LLM, melainkan fokus pada manajemen dan mitigasi risiko. Analogi sederhananya, ini bukan menentang pengembangan mobil, melainkan mengatakan bahwa karena mobil bisa meledak, kita perlu lebih fokus mengurangi ledakan itu
  • Saya merasa tulisan aslinya bukan sekadar "keluhan tak bermakna", melainkan kekhawatiran realistis tentang jebakan yang mudah membuat lengah saat bekerja bersama LLM dan usulan langkah pelengkap di dalam tim
  • Dulu saat React pertama kali muncul, saya menyesal karena tidak mempelajarinya. Saya juga masih punya resistensi terhadap GPT, dan orang-orang di sekitar saya sering bilang "chatGPT yang bilang begitu" atau "ini kode chatGPT". Saya bangga bisa coding dengan susah payah sendiri. Saya tidak memakai GPT, tetapi sebenarnya Google atau stackoverflow juga bisa dianggap sebagai GPT yang lambat

• Daripada kebijakan seperti "menjamin bahwa kode kontribusi bukan hasil LLM, orisinal, dan dipahami sepenuhnya" atau "sebagian besar harus dikerjakan manual", lebih baik fokus pada hasil akhirnya. Meminta kontributor benar-benar memahami perubahannya itu bagus. Tapi kebijakan seperti "junior harus menahan diri atau dilarang memakai tool LLM untuk jangka waktu tertentu" menurut saya kurang bagus. LLM sangat membantu untuk masalah setup environment onboarding yang berantakan. Selain itu juga bagus untuk memahami kode/dokumentasi, serta berguna sebagai alat pencarian teks dan peringkasan

  • Sebenarnya onboarding adalah proses belajar menyelesaikan masalah lingkungan acak. Kalau semua kesulitan dan kerumitan itu dihilangkan lewat otomatisasi, saya khawatir nanti tidak ada lagi yang tahu harus berbuat apa dalam situasi seperti itu. Penasaran apakah cuma saya yang merasa begitu

• Saya baru pertama kali mendengar konsep "AI Cliff" (fenomena ketika akurasi LLM tiba-tiba anjlok). Penasaran apakah orang lain juga pernah mengalaminya

  • Saya sering mengalaminya. Ketika kompleksitas kode melewati titik ambang, LLM tidak mampu lagi menampung seluruh konteks di "kepalanya" dan mulai bertingkah ngawur. Peran saya adalah mengelola kompleksitas yang akan dilihat LLM. LLM saat ini cenderung membuat struktur semakin kompleks seiring waktu. Biasanya saya minta refactor untuk menyederhanakan, atau kalau sudah terlalu rumit saya rapikan sendiri. Kalau terus dibiarkan, LLM pada akhirnya menciptakan kekacauan ala Rube Goldberg raksasa yang akhirnya harus dibersihkan manusia. Pengembang berpengalaman bisa cepat menyadari seberapa jauh LLM mulai melenceng dan bisa segera menarik kembali arah kerja, tetapi pemula bisa benar-benar tersesat bahkan sebelum sadar ada masalah
  • Saya menyebutnya context drunk. Misalnya konteks input 10 ribu token dan 99% benar, lalu LLM memberi jawaban 1.000 token yang hanya 90% benar. Kalau bolak-balik terus, sebagian besar context window akhirnya dipenuhi pengulangan output LLM yang kurang akurat itu. Error menumpuk, dan karena informasi terbaru punya bobot lebih besar, hasilnya makin lama makin ngawur. Ini terjadi bukan cuma pada kode, tapi juga pada prosa
  • Saya menyebutnya context rot. Saat konteks menumpuk, kualitas output menurun. Semakin banyak obrolan sampingan atau isi yang melenceng, semakin cepat kualitasnya memburuk. Terutama ketika chain of thought (COT) tertinggal di konteks, kalau alur pikirnya mulai nyasar maka jejak itu memperparah keadaan. Secara pribadi saya berharap ada fitur pruning yang bisa memangkas hanya sebagian konteks. Saya sendiri menghadapi context rot dengan merangkum manual lalu membawanya ke sesi baru
  • Saya hanya mengalaminya pada antarmuka chat seperti vibe coding, dan jauh lebih jarang pada tool berbasis agent karena mereka mengelola sendiri context window kode dan menjalankan dev tooling langsung untuk sanity check
  • Saya sering me-reset sesi AI kerja, jadi jarang merasakan 'AI cliff'. Tetapi ketika menulis novel, panjang dan konsistensi konteks itu penting, dan pernah ada momen ketika AI tiba-tiba tidak bisa lagi menjaga kepribadian karakter dengan benar lalu bereaksi aneh. Karena tidak bisa dipulihkan, itu pengalaman yang sangat asing

• Penulis aslinya bilang ia tidak akan merangkum tulisan banyak orang, tetapi tampaknya sebenarnya itulah yang terjadi. Meski begitu, akan bagus kalau ada penanda file yang berisi kode buatan AI di PR. Jenis kesalahan pada kode LLM dan kode manusia berbeda, jadi kalau bisa direview terpisah akan menghemat waktu. Penasaran apakah ada yang pernah mengalami kebijakan seperti ini di organisasi besar, atau apakah sudah ada tool otomatisnya. Kalau perusahaan mengukur proporsi kode hasil LLM, mungkin tool semacam itu sudah ada demi metrik yang lebih rinci

  • Saya penulisnya: sebenarnya belum banyak diskusi yang jelas tentang kepercayaan dalam tim dan LLM, jadi saya belum melihat contoh yang benar-benar terdokumentasi. Saya sendiri tidak yakin apakah itu karena saya bekerja di lingkungan yang salah untuk masalah seperti ini, atau karena memang sulit menemukannya di arus utama