Pembuatan Kode LLM Dapat Menyebabkan Melemahnya Kepercayaan
(jaysthoughts.com)- 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
1 komentar
Opini Hacker News
https://archive.is/5I9sB
Berfungsi bahkan di browser lama, dan tidak membutuhkan JavaScript kecuali saat melewati CloudSnare
Seorang teman selalu bilang, “inovasi terjadi pada kecepatan kepercayaan,” dan sejak GPT-3 kalimat ini terus terngiang
Verifikasi itu mahal, dan sarana utama untuk menurunkan biaya itu adalah kepercayaan. Saya tidak tahu bagaimana caranya membuat LLM dapat dipercaya. Baik dalam kode maupun bahasa alami, ia sangat fasih, tetapi pada saat yang sama juga rela masuk ke lubang kelinci yang bercabang tanpa akhir seperti fraktal, dan menunjukkan perilaku yang pada manusia akan dianggap berniat jahat
Dunia baru tempat segala sesuatu harus selalu diverifikasi ini cukup melelahkan, dan terus terang sangat lambat
Ini terlalu berguna untuk diabaikan, dan kepercayaan selalu dibangun bata demi bata. Kita juga tidak boleh lupa bahwa manusia sejak awal tidak terlalu dapat dipercaya. Seperti mengemudikan mobil, kemampuan menghasilkan kode dengan lebih sedikit bug di atas jalan yang sudah didefinisikan sebelumnya sepertinya akan segera melampaui manusia, lalu setelah itu tinggal pertarungan dasar untuk memperbaiki kompleksitas
Dalam sains, kepercayaan dibangun sambil berjalan
Di tempat kerja, saya mengalami hal seperti ini dengan cara yang berbeda dari yang saya duga. Seorang rekan dan saya berada di bawah tekanan untuk menunjukkan progres, dan kami memutuskan untuk buru-buru menggabungkan refactoring yang cukup besar yang sedang saya kerjakan. Itu masih draft PR, tetapi kami menggabungkannya demi momentum, dan minggu berikutnya muncul beberapa bug di area kode yang belum diuji
Saat debugging, rekan saya mengungkapkan bahwa ia berasumsi saya pasti menulisnya dengan AI, dan mengatakan frustrasi mencoba memahami hasil buatan AI setelah kejadian. Namun kode ini tidak menggunakan AI. Memang saya menggunakan AI untuk menulis kode, tetapi kode yang satu ini saya tulis manual sambil memikirkan keseluruhan desain dengan saksama. Bug-bugnya bukan cacat mendasar pada refactoring, melainkan kelalaian kecil yang muncul saat menyesuaikan kode lama dengan API yang berubah
Pada akhirnya, karena saya bisa membicarakan ketegangan itu secara eksplisit dengan rekan saya, ini menjadi pengalaman membangun kepercayaan. Bisa dibilang kami menghadapi kekuatan dari apa yang sedang terjadi sekarang dengan cukup lembut. Jika menengok ke belakang, saya bersyukur ini terselesaikan seperti itu, dan saya bisa membayangkan di lingkungan kerja lain situasinya bisa jauh lebih berantakan. Kita harus berhati-hati
Sekitar 4 tahun lalu saya pernah mempermalukan diri sendiri cukup parah. Sebuah koran lokal menerbitkan artikel berisi klaim absurd tentang seseorang dengan foto sebagai bukti utama, dan saya langsung mengirim email ke editornya menjelaskan mengapa saya yakin gambar itu dimanipulasi. Logika saya bertumpu pada kesalahpahaman saya sendiri: saya keliru menafsirkan fakta bahwa orang tersebut berpose dengan beberapa orang di acara meet-and-greet dengan posisi dan postur yang hampir tidak berubah. Sang editor tersinggung dan membalas dengan nada mengejek, lalu ketika saya tidak mundur, ia menyadari saya bukan provokator melainkan cuma bodoh, dan membagikan video lengkap yang belum dipublikasikan tempat foto itu berasal. Saat itu saya meminta maaf sedalam-dalamnya dan juga berdonasi, dan selama setahun setelahnya ego saya mengecil secara layak
Bahkan sebelum mengirim email, karena saya tidak ingin membuat tuduhan palsu, saya membagikan foto itu kepada teman-teman yang tenang dan meminta pendapat mereka. Mereka juga menyimpulkan bahwa gambar itu kemungkinan besar dimanipulasi, jadi saya cukup percaya diri. Sekarang saya secara implisit memercayai koran itu dan orang-orang terkait, tetapi bahkan untuk meyakinkan satu orang saja ternyata butuh usaha yang benar-benar besar
Sulit memahami premisnya. Jika kita memercayai seseorang karena ia menulis kode yang bagus, kepercayaan itu dipelajari karena kode orang itu berjalan dengan baik, bukan karena di dalam pikirannya ada suatu model mental apriori yang “menghasilkan kode bagus”
Jika seseorang menggunakan LLM untuk membuat kode tanpa bug, kita akan memercayainya. Jika seseorang menggunakan LLM untuk membuat kode yang penuh bug, kita tidak akan memercayainya. Apa bedanya dengan ketika orang itu membuat kode hanya dengan kepalanya sendiri?
Karena LLM, menjadi sangat sulit untuk segera menilai kualitas developer yang mengirim patch hanya dari kode yang diajukan. Jika kita tidak bisa menakar orang di seberang itu tipe seperti apa, kita kembali ke “tanpa kepercayaan” dan harus meninjau semuanya dengan sangat teliti. Dengan kata lain, tidak ada lagi “jalan pintas review” yang aman, dan ini bisa menyakitkan di tempat-tempat yang selama ini menjalankan pekerjaan dengan mengandalkan sinyal semacam itu. Jika tim sudah kompeten dan sangat tepercaya, masalah ini tidak berlaku, dan konsepnya sendiri kemungkinan besar akan terasa asing
Jika kontributor menjelaskan perubahan dengan baik, kita lebih memercayainya. Jika ia pernah melakukan pekerjaan hebat sebelumnya, kita lebih memercayainya. Jika ia mengelola unit perubahan dengan baik, seperti commit yang masuk akal, kita lebih memercayainya. Jika ia memilih masalah yang tepat, misalnya memperbaiki bug sebelum menambahkan fitur baru, kita lebih memercayainya. Jika ia menunjukkan bahwa ia bisa memelihara kode yang ada, bukan sekadar menambahkan sesuatu di atasnya, kita lebih memercayainya. Jika ia berkontribusi secara rutin, kita lebih memercayainya
Masalahnya sering kali adalah kesalahan komunikasi. Bagi pekerja, tugasnya mungkin jelas, tetapi karena konteks sering di-reset, sulit memastikan LLM juga mengetahui gambaran besarnya; jika ada ambiguitas, LLM mudah membuat asumsi bodoh. Menurut saya, cara deep research 4o meminta informasi tambahan sebelum melakukan sesuatu seharusnya menjadi standar juga dalam pembuatan kode. Itu bisa mencegah segunung masalah
Dalam beberapa kasus, ini sederhana: apakah rutin ini mengembalikan nilai yang diinginkan atau tidak. Namun dalam situasi lain, jauh lebih rumit karena kita harus memperkirakan bagaimana ia akan berinteraksi dengan bagian lain dari sistem dan apa saja edge case yang tidak mudah terlihat. Dalam situasi seperti itu, untuk menulis kode yang “tanpa bug”, penulis harus memahami implikasi kodenya; jika developer tidak memahami secara persis apa yang dilakukan kode yang ditulis LLM, ia juga tidak bisa memahami implikasinya. Maka beban itu berpindah ke reviewer, dan beban kerja reviewer bertambah. Itulah premisnya
Aturan praktis yang baik adalah menolak saja pekerjaan yang melibatkan LLM, dan mengabaikan juga komunikasi yang ditulis LLM. Bahkan untuk orang yang memakai bahasa Inggris sebagai bahasa asing, menurut saya bahasa Inggris mereka yang “terbata-bata” jauh lebih baik daripada ChatGPT yang berbicara mewakili mereka. Seiring masalah-masalah serius LLM menjadi makin jelas, saya rasa kebijakan seperti ini akan menjadi standar umum, dan saya berharap begitu
LLM membuat pekerjaan buruk jenis apa pun tampak seperti pekerjaan bagus yang meyakinkan. Jadi masuk akal untuk secara otomatis mendiskon hasil kerja orang yang menggunakan AI.
Dulu salah satu kerabat saya pernah terbukti sebagai penipu. Setelah ketahuan, saya memutus kontak dan mengatakan bahwa saya tidak mengenalnya, lalu ia berkata, “Aku adalah orang yang sama yang sudah kamu kenal selama 10 tahun.” Saya menjawab, “Mungkin saja. Tapi baru sekarang saya sadar bahwa selama ini saya sama sekali tidak tahu siapa orang itu, dan ke depannya pun tidak akan bisa tahu.”
Kita semua berasumsi bahwa orang-orang dalam hidup kita tidak secara aktif berusaha mencelakai kita. Ketika kepercayaan itu rusak, rusaknya sangat parah. Siapa pun yang memakai AI tidak bisa mengklaim, “ini pekerjaan saya.” Karena kita tidak bisa tahu apakah itu memang pekerjaan Anda. Orang yang memakai AI juga tidak bisa mengklaim bahwa itu pekerjaan yang bagus kecuali ia memahaminya secara menyeluruh, dan kemungkinan besar ia tidak memahaminya secara menyeluruh. Saya mendapati cukup banyak mahasiswa saya mengaku telah membaca dan memahami tulisan saya, padahal sebenarnya tidak. Bagaimana jika saya adalah AI, dan mereka mengambil pekerjaan saya lalu memasang nama mereka sendiri sebagai penulis? Mereka tidak akan bisa menjelaskan, membela, atau menindaklanjuti apa pun. Masalah seperti ini sudah ada sebelum AI, tetapi sekarang menjadi sepuluh kali lebih buruk.
Saya adalah orang yang telah mencurahkan “lebih dari 10 ribu jam” untuk pemrograman aplikasi kompleks sebelum LLM yang berguna muncul. Selama bertahun-tahun, setiap malam saya menggali dokumentasi dan kode sumber orang lain, sepenuhnya tenggelam dalam upaya menguasai full-stack. Pada akhirnya, keterlibatan total itu berujung pada burnout parah, kesehatan saya memburuk, dan pernikahan saya pun terguncang. Tak lama setelah merilis aplikasi, saya harus benar-benar berhenti selama 3 tahun untuk pulih, dan saya yakin tidak akan pernah bisa mengambilnya kembali.
Setelah mendengar banyak cerita bahwa LLM sudah cukup bagus dalam kode, saya dengan hati-hati kembali ke depan komputer, dan di titik itu pengalaman saya sangat berbeda dari kekhawatiran tersebut. Saya tidak bisa setuju dengan pernyataan bahwa “orang yang memakai AI tidak bisa mengklaim ‘ini pekerjaan saya’.” Saat saya memakai LLM, saya adalah perancang sekaligus pemeriksa akhir. Saya mengarahkan visi, merancang sistem, dan meninjau setiap baris yang dihasilkan LLM dengan alat diff. Baru-baru ini saya membuat model optimisasi yang kompleks untuk mesin estimasi bisnis bersama LLM. Menggunakan model optimisasi sungguhan memang selalu merupakan cara yang “benar”, tetapi dahulu itu mungkin menuntut kerja keras berbulan-bulan untuk mempelajari setiap detail pustaka dan membaca kode orang lain. Kali ini selesai dalam seminggu. Apakah ini terasa seperti pekerjaan saya? Sepenuhnya ya. Saya hanya punya asisten yang tak kenal lelah dan hebat, tetapi kadang cacat.
Pengalaman saya juga berlawanan dengan pernyataan bahwa pengguna “tidak akan memahaminya secara menyeluruh.” Untuk memakai LLM secara efektif pada hal yang tidak sepele, dibutuhkan pemahaman dasar yang lebih dalam agar bisa mengarahkan LLM dan menangkap kesalahan halus yang sering muncul. Tanpa pengalaman bertahun-tahun saya, saya tidak akan bisa memimpin pengembangan multi-modul yang kompleks, men-debug keluarannya, atau mengetahui bahwa pekerjaan yang tampak bagus dan meyakinkan sebenarnya salah dengan cara seperti masalah N+1.
Saya bersimpati dengan pengalaman sebagai pengajar. Masalah mahasiswa berpura-pura paham dengan alat semacam ini nyata dan sulit. Di dunia akademis, tujuannya adalah proses belajar, yakni memperoleh sebagian substansial dari 10 ribu jam itu. Namun di dunia profesional, tujuannya adalah hasil, dan ini adalah alat baru yang kuat untuk mendapatkan hasil yang lebih baik. Saya tidak tahu bagaimana guru harus mengajar mahasiswa dalam realitas baru ini, tetapi menjelek-jelekkan penggunaan LLM mungkin bukan pilihan terbaik.
Bagi saya, ini bukan membuat pekerjaan buruk tampak bagus. Ini membuat pekerjaan hebat kembali mungkin dilakukan, sekaligus mengembalikan hidup saya. Ini mengembalikan kegembiraan craft pengembangan perangkat lunak tanpa menghancurkan saya dan keluarga saya, dan sekarang hidup saya jauh lebih seimbang, untuk itu saya bersyukur.
Bagi saya, kondisinya sudah seperti itu. Saya sudah sangat sering membaca “maaf sudah terlewat, Anda sepenuhnya benar.” Kira-kira 8–9 dari 10 kali.
Di sisi lain, saya terus melihat orang menyalin kode buatan LLM berbayar tanpa berpikir, lalu marah besar ketika tidak berjalan seperti yang diharapkan. Sebagai catatan, itu masih opsi yang lebih baik. Karena sesuatu yang jelas-jelas rusak lebih baik daripada sesuatu yang dari luar tampak seolah berfungsi.
Meski begitu, mesin prediksi belum bisa melakukan rekayasa sungguhan. Jika tidak secara spesifik diperintahkan untuk memakai sesuatu seperti Python generator, kemungkinan besar kode yang keluar akan memakan memori sangat besar. Sayangnya itu tidak jauh berbeda dari banyak programmer Python yang saya kenal, tetapi ini juga contoh yang tepat betapa buruknya LLM seperti yang dikatakan. Sisi positifnya, ini membuat orang benar-benar menulis spesifikasi yang lebih rinci daripada satu baris “tambahkan fitur”.
Bagi kami, tempat agen AI paling berguna adalah kode legacy yang tidak diprioritaskan siapa pun. Ada pengekstrak data yang ditulis pada milenium sebelumnya, yang memakai sekitar 200 koordinat hardcoded untuk mengekstrak data dari jenis dokumen tertentu yang masuk lewat faks. Dokumennya tidak berubah selama kira-kira 30 tahun sehingga bekerja dengan baik, tetapi baru-baru ini berubah, dan Copilot membutuhkan sekitar 30 detik untuk memperbaiki koordinatnya. Bagi manusia, kemungkinan besar itu akan menjadi pekerjaan seharian yang sangat membosankan. Namun saya sama sekali tidak tahu bagaimana industri kita akan melatih para ahli di era vibe coding.
Melawan LLM itu seperti buang air kecil melawan arah angin
LLM dengan pendekatan saat ini tampaknya membuat developer lebih produktif. Untuk developer yang kurang berpengalaman, manfaatnya mungkin bahkan lebih besar dibandingkan developer berpengalaman. Peningkatan produktivitas, mungkin peningkatan produktivitas berkali-kali lipat yang sangat besar, tidak akan ditinggalkan hanya karena hambatan yang dibuat oleh orang-orang yang menentang teknologi karena alasan tertentu
Sekalipun ada contoh alat produktivitas baru yang menimbulkan kerugian besar, misalnya bug yang membuat layanan besar down cukup lama, teknologi itu tidak akan dihentikan jika memang memberikan produktivitas yang signifikan. Bekerja bersama teknologi dan memitigasi kelemahannya adalah satu-satunya jalan yang masuk akal. Dan mitigasi itu tidak boleh berupa sekumpulan aturan yang sepenuhnya menghapus keuntungan produktivitas dari teknologi baru tersebut. Mitigasi harus bekerja bersama teknologi ke arah peningkatan adopsi teknologi; jika tidak, mitigasi itu akan diakali
Dari pengalaman saya, orang-orang yang dengan tegas mengatakan produktivitasnya naik 10x berkat LLM umumnya adalah developer frontend yang relatif junior, atau developer serial startup yang terus-menerus membuat aplikasi baru dari nol. Tentu saja itu use case yang sepenuhnya valid, tetapi karena itu developer frontend junior dan developer embedded C senior mudah saling tidak nyambung saat membahas peningkatan produktivitas AI
Alih-alih mengatakan bahwa satu-satunya hal yang masuk akal adalah bekerja bersama teknologi dan memitigasi kelemahannya, cukup gunakan dengan lebih bijak. Misalnya, apakah gagasan AI “agent” itu sendiri bagus? Insiden Copilot baru-baru ini[0] membuat MS dan AI terlihat seperti bahan tertawaan. Ada kemungkinan bahwa upaya untuk membuat AI bekerja secara otonom itu sendiri tidak terlalu bijaksana
Analogi terbaru adalah blockchain dan kripto. Suka atau tidak, melihat keberhasilan Coinbase dan lainnya, jelas bahwa blockchain menemukan use case yang nyata tetapi sempit. Namun pada masa hype kripto, ada orang-orang yang mengatakan hal seperti “kami akan melacak rantai pasok biji kopi dengan blockchain”. Pada 2025 kedengarannya seperti lelucon berlebihan di Twitter, tetapi pada 2020 IBM benar-benar mencoba menjual hal seperti ini[1]. Suatu hari nanti, saat menengok ke belakang, mungkin kita akan melihat bahwa AI agent atau sebagian aplikasi generative AI saat ini adalah blockchain kopi dari gelembung ini
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
Namun ini bukan berarti kombinasi model/manusia memenuhi kebutuhan pengguna dengan lebih efektif. Artinya adalah menghasilkan “lebih banyak kode”. Tidak ada LLM yang mengeluarkan sekumpulan perubahan yang menghapus 2000 baris kode. Jadi kita bisa tahu bahwa pernyataan “membuat engineer lebih produktif” berbicara tentang jumlah kode yang dihasilkan
Anda seolah-olah menggambarkan argumennya sebagai dikotomi memakai LLM atau tidak, padahal penulis terutama membahas mitigasi risiko. Sebagai analogi, penulis hanya menunjukkan bahwa beberapa mobil meledak dan mengatakan bahwa karena kuda dulu tidak meledak, kita perlu membuat mobil lebih jarang meledak sebelum menjalankan pabrik lem; tetapi Anda tampaknya menganggap penulis pada dasarnya menentang pengembangan mobil itu sendiri
Sekarang pun ada rasa enggan menggunakan GPT, sementara belakangan rekan-rekan saya mengatakan “kata ChatGPT” atau “kode ini dibuat oleh ChatGPT”. Saya merasa bangga menulis kode sendiri dan tidak memakai GPT, tetapi pada saat yang sama saya memakai Google dan Stack Overflow. Bisa dibilang itu juga versi GPT yang lebih lambat
Tampaknya penulis melewatkan fakta bahwa aktor yang tidak sempurna dan probabilistik pun bisa membuat sistem deterministik yang dapat dipercaya
Kita tidak akan memercayai alat garbage collection berdasarkan keandalan penulisnya, melainkan akan memercayainya setelah melihat apakah, melalui pengujian yang luas, alat itu terbukti melakukan apa yang dimaksudkan. Kita bisa dengan mudah membayangkan kepercayaan akan melemah ke depannya, dan akibatnya pengembangan berbasis pengujian tampaknya akan makin mendapat momentum. Jangan percaya; verifikasilah.
Pertanyaan yang lebih penting adalah: siapa yang menguji pengujiannya sendiri? Dalam pengembangan tradisional, semua logika diimplementasikan dua kali. Sekali di kode, sekali di pengujian. Pengujian memeriksa kode, dan sebaliknya kode secara implisit memeriksa pengujian. Cukup sering terjadi bug ternyata ada di pengujian, bukan di kode aplikasi. Kita tidak bisa begitu saja memercayai pengujian secara membabi buta sambil menunggu agen menemukan cara mereplikasi bug pengujian itu ke dalam kode.
Mengambil contoh garbage collection, tentu saja suatu hari sistem agentic mungkin bisa menjalankan sesuatu lalu memolesnya lewat test harness, perbaikan bug, dan sebagainya. Namun bayangkan memakai model sebagai garbage collector/alat itu sendiri. Misalnya, setiap kali sweep, Anda melemparkan memori program ke model dan memerintahkannya membebaskan blok yang tidak diperlukan. Kita sama sekali tidak bisa percaya bahwa model akan mengidentifikasi blok memori yang benar dengan tepat, dan tidak ada “patch” atau “fine-tuning” apa pun yang akan membawanya ke sana
Pada abstraksi lama seperti JVM, jika keluaran deterministik—dalam hal ini assembly yang dikeluarkan JIT—salah, bug itu ditambal dan abstraksi tersebut tidak akan memiliki cacat yang sama lagi. LLM tidak seperti itu. Ketika membicarakan alat pengembangan masa lalu yang mengubah seluruh sifat industri, bagi saya perbedaan ini sangat penting. Saya tidak mengatakan LLM tidak akan berdampak besar pada cara kerja di masa depan. Saya hanya melihat bahwa kita sudah memasuki wilayah yang benar-benar belum diketahui, dengan sangat sedikit preseden historis.
Soal pengembangan berbasis pengujian akan makin mendapat momentum juga, saya tidak mengerti mengapa TDD selalu disajikan seperti peluru ajaib yang memperbaiki semua masalah dalam membangun perangkat lunak. Jumlah kasus yang saya lihat ketika TDD dimulai dari pengujian yang keliru lalu menghasilkan perangkat lunak yang keliru sebenarnya sampai memalukan.
Yang harus dispesifikasikan adalah hasil akhirnya, bukan prosesnya. Mengharapkan kontributor memahami patch adalah ide yang baik
Namun menganjurkan atau mewajibkan junior menghindari alat bantu LLM untuk sementara selama masa onboarding adalah ide yang buruk sekali. Onboarding punya banyak masalah penyiapan lingkungan yang acak, dan LLM sering kali cukup kuat untuk hal-hal seperti ini. Ini juga soal mengejar pemahaman kode dan dokumentasi, dan ada alat pencarian/ringkasan teks yang sangat bagus untuk dibagikan.
Rasanya sangat jelas bahwa jika semua kesulitan dan kompleksitas dalam hidup dihilangkan secara mulus, tak lama kemudian ketika menghadapi kesulitan atau kompleksitas, kita sama sekali tidak akan tahu harus berbuat apa. Apakah hanya saya yang berpikir begitu?
Saya baru pertama kali mendengar fenomena yang penulis sebut tebing AI, yaitu LLM “mendekati jawaban benar selama beberapa waktu, lalu akurasinya anjlok setelah beberapa lama.” Apakah orang lain juga pernah mengalaminya?
Generator saat ini cenderung membuatnya makin kompleks seiring waktu, bukan makin sederhana. Sayalah yang selalu memberi prompt agar LLM merombaknya menjadi lebih sederhana, atau merombaknya sendiri ketika sudah terlalu kompleks untuk ditangani LLM. Jadi setidaknya pada LLM generasi saat ini, jika Anda sekadar “melepas kendali LLM” dan membiarkannya melakukan apa saja, tampaknya cukup tak terhindarkan ia akhirnya membuat kekacauan besar bergaya Rube Goldberg, lalu Anda yang harus membersihkannya
Mengaitkannya dengan inti tulisan, orang berpengalaman akan cepat menyadari ketika LLM mulai menyeret Anda ke laut lepas, dan meskipun sempat terbawa agak jauh, ia bisa menemukan jalan kembali ke perairan dangkal. Pemula akan keluar dari kedalamannya sendiri dan tersesat di laut bahkan sebelum menyadari apa yang terjadi.
Bayangkan ada 10 ribu token yang 99% benar sebagai input konteks. Setiap kali LLM menjawab, ia menambahkan 1000 token yang 90% benar. Setelah beberapa kali bolak-balik mengoreksi LLM, jendela konteks sebagian besar terisi oleh sisa-sisa keluaran LLM sendiri. Yang lebih buruk, kesalahannya terakumulasi. Bahkan 90% yang benar pun hanya ekstrapolasi yang benar atas pembahasan tentang kode yang salah, dan LLM memberi bobot lebih besar pada token yang lebih baru. Masalah yang sama juga muncul dalam prosa.
Pada model penalaran, masalah ini bisa makin parah. Karena seluruh proses berpikir ada di dalam konteks, dan jika pemikirannya benar-benar menyimpang, ia menanam benih beracun yang memberi makan pembusukan. Akan bagus jika ada semacam pemangkasan konteks yang bisa memotong konteks yang tidak relevan saat muncul. Saat ini, ketika saya merasakan pembusukan mulai terjadi, saya membuat ringkasan dan memindahkannya ke instans baru.
Pada alat agentic seperti claude code, codex, dan gemini cli, masalah ini jauh lebih kecil. Karena mereka mengelola jendela konteksnya sendiri dan bisa menjalankan alat pengembangan untuk melakukan sanity check sendiri.
Proses ini melatih kebiasaan mendokumentasikan status pekerjaan saat ini agar agen baru bisa mengejar ketertinggalan.