- Belakangan ini, developer menghabiskan lebih banyak waktu untuk memodifikasi dan menyempurnakan kode yang dihasilkan LLM (large language model)
- Seperti halnya kode legacy yang sudah ada, untuk mengubah kode dengan aman kita perlu lebih dulu memahami apa yang diimplementasikan dan mengapa dibuat seperti itu, tetapi kode dari LLM membuat proses ini semakin sulit
- Sebagian tim memang melakukan review dan pengerjaan ulang kode secara memadai sehingga lajunya melambat, tetapi banyak tim justru langsung memasukkan kode yang bahkan sulit dibaca dan hanya diuji seadanya ke repositori
- Hal ini melahirkan “utang pemahaman (Comprehension Debt)”, yang pada akhirnya akan kembali sebagai biaya waktu yang lebih besar ketika kode perlu diubah
- LLM umumnya bisa dipakai untuk menyelesaikan masalah sampai sekitar 70%, tetapi tidak bisa menghindari “Doom Loop” berupa kegagalan berulang, dan pada akhirnya situasi ketika manusia harus langsung memahami dan memperbaiki kode akan tetap tak terelakkan
Masalah kode yang dihasilkan LLM dan utang pemahaman
- Di lapangan pengembangan saat ini, penggunaan alat pembuat kode otomatis berbasis LLM seperti ChatGPT, Copilot terus meningkat
- Alat-alat ini dapat menghasilkan kode kompleks dengan cepat bahkan tanpa pengetahuan atau pemahaman langsung dari developer
- Namun dalam proses tersebut, niat, batasan, dan cara kerja kode sering kali tidak dipahami dengan jelas sehingga muncul akumulasi 'utang pemahaman'
Apa itu utang pemahaman (Comprehension Debt)
- Utang pemahaman berarti kondisi ketika anggota tim tidak cukup memahami kualitas, struktur, dan tujuan kode
- Dalam jangka pendek hal ini bisa meningkatkan kecepatan pengembangan, tetapi dalam jangka panjang berisiko memicu berbagai efek samping seperti kenaikan biaya pemeliharaan, munculnya bug, dan keterbatasan perluasan fitur
Risiko tambahan dari kode buatan LLM
- Kode yang dihasilkan LLM dengan cepat memberikan hasil tanpa komentar yang jelas maupun konteks yang memadai
- Sangat mungkin muncul masalah kurangnya berbagi pengetahuan antaranggota tim serta rendahnya kompatibilitas dengan sistem yang sudah ada
- Jika terus-menerus bergantung pada kode dari LLM, hal ini dapat menyebabkan penurunan keandalan kode di seluruh proyek
Perbandingan dengan utang teknis
- Utang teknis yang ada selama ini merupakan hasil kompromi yang disadari developer, sedangkan utang pemahaman berbasis LLM bisa terakumulasi tanpa disadari, sehingga jauh lebih berbahaya
- Masalahnya sulit dikenali, dan pelacakan penyebab maupun penyelesaiannya menjadi lebih rumit
- Saat menyelesaikan masalah, pengalaman “Doom Loop” (siklus buruk ketika LLM terus dijalankan berulang kali tetapi tetap gagal) sering terjadi
Kesimpulan dan implikasi
- Pada akhirnya, manusia tetap harus membaca dan memperbaiki kode secara langsung
- Saat memanfaatkan LLM, upaya mendokumentasikan dan membagikan agar seluruh anggota tim memahami konteks dan maksud kode menjadi sangat penting
- Diperlukan mekanisme di tingkat organisasi seperti penguatan code review, penambahan komentar dan dokumentasi, serta sesi berbagi pengetahuan
- Tanpa pengelolaan utang pemahaman, keunggulan alat otomatisasi justru dapat berubah menjadi risiko jangka panjang
- Secara keseluruhan, industri sedang duduk di atas gunung utang pemahaman yang membesar dengan cepat
8 komentar
Saya juga selalu berpikir bahwa AI tidak bisa sepenuhnya mengambil keputusan, jadi untuk semua kode saya yang memutuskan dan juga memeriksa sendiri apakah hasilnya sudah baik.
Menurut saya, ini memang paling pas hanya untuk membuat snippet di bawah 10 baris (mis. parsing JSON, implementasi sorting). Bahkan kalau dipakai sebatas ini saja, rasanya tetap bisa menghemat waktu secara drastis.
Membuat kerangka dengan bantuan AI sih tidak masalah, tapi memoles detail sampai akhir sepertinya memang sangat sulit.
Saya juga pribadi cukup sering merasakan efek samping ketika menulis 0 sampai 90 dengan LLM, jadi belakangan ini sebisa mungkin saya mengerjakan sendiri dari 0 sampai 90, lalu terutama memanfaatkannya dalam proses menuju 90 sampai 100, dan saya puas dengan pendekatan itu.
Opini Hacker News
Ketergantungan pada LLM makin besar, dan saya mengalami bahwa masalah-masalah yang sebelumnya sudah ada justru makin memburuk
Sambil memperkenalkan konsep "pembangunan teori" dari Naur, ia menyoroti bahwa ketika tim pengembang sebuah program dibubarkan, program tersebut pada dasarnya berada dalam keadaan mati
Ia juga menyebut argumen Lamport bahwa 'programming ≠ coding', dan menekankan bahwa esensi pemrograman adalah membangun teori tentang 'apa' dan 'bagaimana' sesuatu akan dicapai
Saya rasa, semakin seorang programmer tidak membangun model atau teori yang diperlukan, semakin besar kecenderungannya untuk merasa LLM membantunya dengan cepat
Saya justru pernah mengalami bahwa saat benar-benar menjauh dari komputer dan teknologi, saya bisa menciptakan nilai yang lebih besar dalam proyek perangkat lunak
Ketika kita tahu persis apa yang diinginkan, kecepatan pengembangan melonjak drastis, dan pada saat seperti itu LLM menjadi sangat berguna
Jika tujuannya jelas, halusinasi LLM juga bisa langsung dikenali
Saya tidak menganggap pendekatan menatap kanvas kosong lalu mulai begitu saja sebagai sesuatu yang efektif
LLM bisa membantu memulai, tetapi kalau salah langkah sering malah terseret ke arah yang tidak relevan
Masalah yang paling sulit justru pernah saya pecahkan sambil memasak di dapur dan memikirkannya
Salah satu alasan saya sedikit lebih berhasil daripada rekan-rekan dalam memanfaatkan AI coding adalah karena bahkan sebelum LLM hadir, saya sudah terbiasa membuat prototipe sesuatu dengan cepat, lalu berulang kali merombak total strukturnya atau membuangnya
Pendekatan seperti ini (prototyping cepat, refactoring berkelanjutan, dan sebagainya) cukup dikenal, tetapi banyak engineer cenderung ingin mendesain semuanya sempurna sejak awal, atau terus menambal prototipe tanpa benar-benar memperbaikinya
Bersama AI, implementasi paralel dalam beberapa versi juga bisa dilakukan dengan murah, sehingga kita dapat bereksperimen dan membandingkan berbagai versi, lalu pada akhirnya membentuk teori atau desain program yang lebih kuat dengan lebih cepat dan efektif
AI mempersingkat loop semacam ini, dan memungkinkan fokus lebih besar pada review hasilnya, sehingga proses pengembangan menjadi jauh lebih efisien
Keterkaitan antara konsep 'pembangunan teori' dan 'utang pemahaman' pada kode LLM terasa mengesankan
Saya rasa ini berkaitan mendalam bukan hanya dengan pemrograman, tetapi juga dengan proses berpikir dan memahami pada manusia
Kode, teks, atau gambar yang dihasilkan LLM hanyalah hasil di permukaan, dan tanpa membangun atau mengalami sendiri teori di baliknya, pemahaman kita mau tak mau akan berhenti di tingkat permukaan
Bahkan jika suatu hari LLM mampu melakukan pembangunan teori itu sendiri, rasanya tetap kurang bermakna jika yang ada hanya pemahaman artifisial tanpa keterlibatan langsung manusia dalam prosesnya
Ada kekhawatiran bahwa semakin nyaman mesin berpikir untuk kita, semakin perlahan kemampuan <memahami> manusia akan mengalami kemunduran
Saya setuju dengan argumen Lamport, sekaligus berpikir bahwa AI juga dapat membantu sampai batas tertentu dalam proses 'pembangunan teori'—yakni pemahaman terhadap codebase, algoritme, dan keseluruhan sistem—baik bagi tim yang ada sekarang maupun tim penerus saat serah terima
Mungkin sulit menggantikan seluruh pengetahuan secara penuh, tetapi saya berharap AI bisa menutup sebagian celah itu
Saya pernah mengalami situasi ketika seluruh developer lama sudah pergi lalu tim baru mengambil alih proyek, dan semua pengetahuan tim sebelumnya seperti menguap sehingga kami mengalami masa yang sangat berat
Kami berusaha memahami desain aslinya, malah menghasilkan banyak bug, dan akhirnya bersusah payah menulis ulang serta memperluas sebagian besar kode
Namun, bahkan di tengah kesulitan seperti itu, justru ada proses menapaki sendiri banyak isu desain tersebut
LLM sering kali menghasilkan solusi yang berjalan, tetapi kode yang keluar sering jauh lebih kompleks daripada yang sebenarnya dibutuhkan
Saat pertama kali ditulis, kita paling memahami apa masalahnya sehingga kompleksitasnya mudah dihilangkan, tetapi belakangan kode rumit itu bisa disalahpahami seolah memang wajib ada, sehingga menjadi jauh lebih sulit untuk benar-benar menyederhanakannya
Maintainer kode sering kekurangan konteks atau pengetahuan latar, sehingga tidak menyadari bahwa alternatif yang lebih sederhana sebenarnya mungkin dilakukan
Pertama, berikan prompt yang jelas agar LLM tidak terdorong menghasilkan keluaran yang terlalu rumit
Kedua, kita harus selalu menyampaikan aturan, pelatihan, atau konteks bahwa masalah harus diselesaikan sesederhana mungkin
Terakhir, untuk solusi rumit yang sudah dihasilkan, cukup minta lewat prompt tambahan agar kompleksitasnya dikurangi
Masalah LLM menghasilkan kode dalam jumlah besar yang sulit di-debug memang nyata
Ada prinsip bahwa 'tim yang peduli kualitas harus mereview dan memahaminya dengan cukup', tetapi kecepatan generasi kode terlalu tinggi sehingga review sering tak mampu mengejar, menjadi bottleneck, atau malah berubah menjadi persetujuan formalitas
Di sekitar saya, orang terus menambahkan proses review, tetapi pendekatan seperti ini efektif paling-paling untuk developer junior, dan AI tidak belajar sehingga isu yang sama terus berulang
LLM membutuhkan sangat banyak konteks, tetapi kebanyakan orang memakainya hanya dengan sedikit sekali informasi, seperti "buatkan fungsi yang menyelesaikan masalah ini"
Pada akhirnya, semua orang sedang menumpuk gunungan kode yang tidak dipahami siapa pun (tech debt)
Yang secara mendasar dibutuhkan adalah 'primitive' yang dapat menyampaikan konteks dengan lebih efektif kepada LLM tentang mengapa ini harus dibuat, latar belakang dan niat apa yang mendasarinya, serta preseden apa yang perlu dicerminkan
Jika code review menjadi bottleneck, saya tetap berpikir itu lebih baik daripada coding dan review sama-sama menjadi bottleneck
Alat untuk melengkapi proses ini (lint, fuzzing, testing, dan lain-lain) sudah ada
Bagi orang yang kurang mampu melakukan arsitektur seluruh proyek atau membaca serta menganalisis kode dengan cepat, era LLM bisa terasa sulit, tetapi kemampuan seperti itu bisa dikembangkan, dan seiring waktu semua orang akan beradaptasi
Saya menyukai bidang ini, jadi saya menyambut tantangan baru dengan positif
Saya punya pengalaman membuat berbagai file instruction
.md, memasukkan aturan coding yang harus dipatuhi agent, jebakan yang wajib dihindari, tautan ke dokumen standar coding, lalu terus memperbaruinyaModel seperti Gemini dan Claude cukup lumayan mengikuti instruksi berbasis dokumen seperti ini, tetapi kadang masih mengulang kesalahan yang sama (misalnya, di C++ sudah diminta untuk tidak memakai
auto, tetapi tetap dilanggar)Ke depan, saya berharap kemampuan model dalam menangani umpan balik seperti ini akan makin berkembang
Pada akhirnya, saya merasa kompromi idealnya adalah keluar dari 'vibe coding', manusia tetap memperhatikan struktur kode dan interaksi antar unit secara langsung, sementara AI difokuskan pada sintaks dan pengetikan; pendekatan ini meningkatkan produktivitas sekaligus menjaga developer tetap memegang arah keseluruhan
Setelah saya mengubah cara berpikir dalam menyusun prompt dan konteks, intuisi saya dalam memanfaatkan LLM berkembang jauh
Saya mulai mendekatinya dari sudut pandang mempersempit ruang probabilitas hasil melalui prompt dan konteks
Proses ini juga sangat efektif untuk menyuntikkan teori kode agar dapat digunakan ulang
Namun, menyiapkan konteks seperti ini membutuhkan banyak usaha dan pemikiran, dan sampai sekarang pun tidak mudah menemukan batas antara bagian yang lebih baik diimplementasikan sendiri dan titik di mana lebih baik didelegasikan ke LLM
Saya setuju dengan komentar bahwa 'primitive-nya berbeda', dan menurut saya unit yang benar-benar penting adalah 'test'
Biarkan model menulis test sekaligus saat membuat kode, dan selalu periksa apakah test tersebut mudah dibaca
Kode hanya boleh di-merge jika seluruh test lulus
Infrastruktur test harus terus ditingkatkan agar keseluruhan test suite tidak menjadi terlalu lambat
Ciri kode legacy zaman dulu adalah tidak punya test, dan hal yang sama berlaku juga di era LLM
Mengenai komentar bahwa 'ini menjadi bottleneck', bahkan saat menempelkan kode dari StackOverflow pun saya selalu membacanya dan meninjaunya dulu sebelum dipakai, jadi pada akhirnya manusialah bottleneck-nya
Tanpa melalui proses seperti itu, pada dasarnya kode tersebut memang tidak bisa digunakan
Di podcast Dwarkesh Patel baru-baru ini, tamunya merekomendasikan novel <A Deepness In The Sky>, dan ketika saya benar-benar membacanya, saya terkesan dengan bagaimana sistem komputer ribuan tahun di masa depan dan pengetahuan legacy dari masa lalu memainkan peran penting
Ini novel yang sangat bagus dan menarik karena membahas nilai kode legacy dan pengetahuan organisasional
Podcast: https://www.youtube.com/watch?v=3BBNG0TlVwM
Info buku: https://amzn.to/42Fki8n
Sangat disayangkan Vernor Vinge telah meninggal, dan rasanya ide-idenya justru makin memberi inspirasi yang realistis seiring waktu
Bagian yang menggambarkan proses menjadi programmer di masa depan yang jauh benar-benar menarik
Karena jumlah library dan package yang sangat banyak, kemampuan utamanya bukan lagi menulis kode baru, melainkan menemukan dan menggabungkan modul yang sudah ada
Memahami nuansa dan interpretasi detail dari kode yang sudah ada digambarkan sebagai keahlian yang sesungguhnya
Sepertinya "A Deepness In The Sky" adalah buku kedua dalam serinya, jadi saya penasaran apakah tetap aman dibaca tanpa membaca buku pertamanya terlebih dahulu
Saya bertanya apakah tidak masalah langsung membaca buku ini
Sebagian besar developer tidak memahami sampai tingkat assembly atau machine code
Bahasa tingkat tinggi telah menjadi lapisan utama untuk komunikasi dan kolaborasi antarmanusia
Dengan kemunculan LLM, lapisan itu sedang terdorong ke arah pengembangan berbasis bahasa alami dan spesifikasi
Pada akhirnya, saya rasa bahasa tingkat tinggi telah berevolusi selama puluhan tahun hingga hampir menjadi bentuk optimal untuk menyampaikan spesifikasi perilaku program
Jika kita mencoba lebih banyak abstraksi lewat bahasa alami, akan terjadi kehilangan informasi, sedangkan jika turun ke bahasa tingkat rendah, semuanya menjadi terlalu bertele-tele
Lompatan ke bahasa alami bukan sekadar perubahan lapisan abstraksi, melainkan cara yang secara fundamental benar-benar baru
Alat-alat sebelumnya (assembler, compiler, framework, dan sebagainya) semuanya berbasis logika yang di-hardcode dan bisa diverifikasi secara matematis, tetapi sejak LLM kita seolah melompat ke dunia yang bercampur antara ketidakpastian, tebakan, bahkan halusinasi
Banyak developer JavaScript bahkan tidak benar-benar memahami konsep tingkat tinggi seperti struktur data yang tepat, DOM, atau Node API secara mendalam
Terjadi ketergantungan berlebihan pada lapisan abstraksi, hingga sampai pada kondisi tidak benar-benar memahami cara kerja internalnya
Orang luar pun wajar bertanya, "sebenarnya apa yang sedang Anda lakukan di sini?"
Fenomena ini pada dasarnya sudah diterima sebagai hal sehari-hari
Dengan analogi ini, dijelaskan bahwa karena pada akhirnya tak ada yang benar-benar tahu isi dalam kode, tidak ada perbedaan yang sangat esensial ketika LLM yang menulisnya
Memang benar spesifikasi dalam bahasa alami punya peran, tetapi saya rasa tetap perlu ada teknologi lapisan perantara yang memiliki semantik yang ketat
Sebagai contoh, dalam kombinasi Rust dan LLM, sistem tipe yang kuat menutup keadaan-keadaan tidak valid, dan meski waktu compile lebih lama, hasil akhirnya sering kali memang sesuai dengan yang diinginkan
Ada budaya di komunitas Rust bahwa "kalau sudah bisa compile, biasanya akan berjalan", dan meskipun bug logika tetap bisa muncul, ruang kesalahan praktis menjadi lebih sempit
Idealnya, akan bagus jika ada bahasa pemrograman ketat yang mendefinisikan makna logis secara presisi beserta spesifikasi seperti prasyarat dan pascakondisi, lalu LLM berperan mengubah bahasa alami menjadi spesifikasi formal
Bahasa alami pada dasarnya memang tidak jelas dan mengandung ambiguitas
Jika dalam bahasa pemrograman muncul ambiguitas saat parsing, itu dianggap bug serius, tetapi dalam bahasa alami ambiguitas justru menjadi sarana komunikasi seperti puisi, nuansa, dan isyarat
Sifat deterministik dari bahasa tingkat tinggi bukan satu-satunya perbedaan
Determinisme bukan segalanya dalam pemrograman, dan kode yang tidak jelas maknanya dari sudut pandang manusia pun tetap bisa sangat deterministik
Artinya, sumbu 'abstraksi tinggi/rendah' dan 'deterministik/probabilistik' adalah dua persoalan yang sepenuhnya berbeda
Bagi saya dan tim kami, ini terlihat seperti gelombang besar pekerjaan yang akan datang
Selama hampir 8 tahun kami mempertahankan bisnis dengan menyelamatkan kode legacy, tetapi belakangan permintaan menurun karena perusahaan mulai mengandalkan LLM untuk coding
Namun saya memperkirakan jika kami bisa bertahan sekitar 18 bulan lagi, akan datang peluang besar berupa banjir permintaan untuk membereskan tech debt berbasis LLM yang menumpuk dalam waktu singkat
Kerusakan dari utang yang ditinggalkan Claude dengan klaim "sekarang kodenya sudah production level" akan segera terlihat
Saya mendengar kisah dari kenalan yang mereview PR buatan LLM
Sekilas itu PR yang fungsinya tampak berjalan sempurna, tetapi ketika diperiksa bagian dalamnya, ternyata trik yang dipakai hanyalah memanipulasi cache tanpa benar-benar memperbarui backend
Butuh banyak usaha untuk meyakinkan manajer bahwa kode seperti ini tidak boleh di-merge
Akhirnya saya jadi curiga bahwa ada cukup banyak software 'vibe coded' di dunia yang hanya terlihat berfungsi di permukaan
Dalam kasus seperti ini, saya malah berpikir lebih baik langsung di-merge saja dan biarkan mereka mengalami sendiri dampak buruknya
Orang biasanya baru benar-benar sadar setelah merasakan sendiri akibat dari keputusan yang salah
Tanpa umpan balik, pembelajaran tidak terjadi, dan manajer seperti itu justru berisiko makin kehilangan sense of reality, menaikkan ekspektasi dan tekanan yang tidak masuk akal pada tim developer, lalu memicu siklus buruk di mana karyawan kelelahan dan terus diganti
Saya penasaran bagaimana seorang engineering manager yang bukan ahli teknis bisa bertahan lama di industri
Dalam 15 tahun terakhir saya hampir tidak pernah melihat manajer yang benar-benar nonteknis
Jika manajer seperti ini menimbulkan masalah, saya rasa itu harus dilaporkan ke CTO, CEO, owner, investor, dan sebagainya
Bukan hanya kode LLM, kode yang ditulis orang lain pun membuat siapa saja harus membayar 'utang pemahaman'
Bahkan di perusahaan besar seperti Google, engineer baru tetap memerlukan waktu berbulan-bulan untuk memahami sesuatu sebelum bisa cepat membuat perubahan besar pada algoritme
Namun, kode yang dirancang manusia dengan baik jelas lebih mudah dipahami dibandingkan hasil keluaran LLM
Kita bisa mendapatkan penjelasan langsung dari orangnya, dan meskipun LLM juga bisa memberi jawaban yang terdengar meyakinkan, tetap ada perbedaan pada konteks yang sebenarnya
Saya juga sudah banyak mencoba 'vibe coding', tetapi pada akhirnya karena model mental terhadap kode tidak pernah terbentuk, waktu memang seperti dihemat, namun saat benar-benar harus debug justru kerugian waktunya lebih besar
Mustahil juga menyusun seluruh desain secara sempurna sejak awal dalam dunia nyata
Dan saya rasa ukuran seperti 'baris kode yang diakui' tidak cukup bisa dipercaya sebagai dasar produktivitas atau penghematan waktu
Kode yang bergantung pada LLM jelas lebih efektif bila dipakai sambil ditinjau dengan hati-hati dan dibentuk sedikit demi sedikit menjadi bentuk yang tepat
Proses seperti ini justru terasa lebih mirip 'pair programming'
Ditekankan bahwa memakai hasil keluaran LLM secara langsung tanpa peninjauan apa pun ("vibe coding") tidak mungkin benar-benar efisien
Dengan mengutip Hukum Kernighan, dikatakan bahwa "debugging dua kali lebih sulit daripada menulis kode"
Karena itu, jika LLM yang menghasilkan kode, saya berpikir mungkin perlu LLM yang dua kali lebih pintar untuk melakukan debugging-nya
Pengalaman saya tidak selalu seperti itu; saya tetap harus selalu berada di kursi pengemudi
Saya terutama memakai Claude Code, dan setiap kali ia membuat kesalahan saya harus menunjukkannya dengan jelas agar diperbaiki, atau secara spesifik menandai area yang bermasalah
LLM tidak tahu sendiri kesalahan apa yang telah dibuatnya, jadi rasanya seperti bekerja dengan developer junior
Artinya, debugging itu sendiri masih bisa dilakukan pada tingkat kecerdasan yang sama, tetapi LLM tidak mampu mengenali masalahnya sendiri
Terkait pernyataan bahwa "debugging membutuhkan orang yang dua kali lebih pintar", saya rasa ini mungkin berhubungan dengan perbedaan mode 'kedalaman berpikir' pada LLM
Untuk fungsi yang kompleks, saya menggunakan cara meminta LLM lebih dulu menulis atau melampirkan komentar kode yang menjelaskan dengan jelas niat dan pendekatannya dalam laporannya sebelum menulis kode
Ada komentar yang mengatakan bahwa bahkan saat mengambil dan memakai kode yang ditulis pengembang lain, tetap perlu review, jadi tidak berbeda dengan kasus
llm, tetapi menurut saya tidak begitu. Dalam kasus manusia, hal-hal seperti reputasi, nama baik, imbalan, dan hukuman tetap bekerja. Mungkin kalau bekerja sepertillmsekarang, orang itu akan langsung dipecat.Saya selalu berpikir, "AI tidak mengambil alih tanggung jawab sebagai gantinya."
Saya rasa hari ketika penggunaan AI untuk menulis kode akan dilarang sudah tidak lama lagi. Kedengarannya mungkin tidak masuk akal, tetapi saya yakin itu akan menjadi kenyataan.