Halusinasi dalam kode adalah bentuk kesalahan LLM yang paling tidak berbahaya

• Banyak pengembang mencoba menggunakan LLM untuk menulis kode, lalu mengalami halusinasi (hallucination) dan kehilangan kepercayaan
  • LLM sering kali mengarang metode atau library yang tidak ada
  • Namun, halusinasi dalam kode adalah jenis halusinasi yang paling tidak berbahaya
• Yang paling berbahaya adalah ketika LLM menghasilkan kesalahan tetapi tidak langsung terdeteksi oleh compiler atau interpreter
  • Metode yang dihalusinasikan akan langsung memunculkan error saat dijalankan sehingga mudah ditemukan
  • Pesan error juga bisa dimasukkan kembali ke LLM agar diperbaiki secara otomatis
• Berbeda dari halusinasi pada teks biasa, kode bisa diperiksa kebenarannya melalui eksekusi
• LLM dengan fitur perbaikan error otomatis
  • Alat seperti ChatGPT Code Interpreter, Claude Code menjalankan kode yang ditulis LLM, mendeteksi error, lalu memperbaikinya sendiri
  • Menilai kode yang ditulis LLM tanpa menjalankannya terlebih dahulu adalah hal yang tidak efisien
• Sebagian pengembang ingin menolak teknologi ini hanya karena LLM menghasilkan metode yang dihalusinasikan
  • Namun, untuk menggunakannya secara efektif, pembelajaran dan eksperimen adalah hal yang wajib
  • Penulis telah meneliti penulisan kode berbasis AI selama lebih dari 2 tahun, dan masih terus mempelajari teknik baru
• Pengujian manual terhadap kode itu wajib
  • Fakta bahwa kode berjalan normal tidak menjamin bahwa perilakunya sesuai harapan
  • Review kode atau pengujian otomatis saja tidak bisa sepenuhnya memverifikasi ketepatan kode
  • Proses menjalankan dan memverifikasinya secara langsung adalah hal yang wajib
  • Kode yang dihasilkan LLM biasanya sangat mudah dibaca, sehingga bisa membuat orang lengah
  • Kode buatan manusia pun sama; jangan dipercaya sebelum benar-benar dijalankan sendiri
• Cara mengurangi halusinasi
  • Gunakan model lain: pilih model dengan data pelatihan yang lebih kaya untuk platform tertentu
    • Contoh: Claude 3.7 Sonnet (thinking mode diaktifkan), OpenAI o3-mini-high, GPT-4o (termasuk Python Code Interpreter)
  • Manfaatkan konteks: walaupun LLM tidak mengenal library tertentu, ia bisa mempelajari polanya jika diberi contoh kode
    • Baru-baru ini hal ini efektif saat menggunakan fitur integrasi GitHub Claude
  • Pilih teknologi yang stabil: memilih library yang sudah lama ada meningkatkan kemungkinan LLM bisa menanganinya dengan baik
    • Manfaatkan filosofi Boring Technology
• Pentingnya code review
  • Artikel ini membantah klaim bahwa "kalau semua kode yang ditulis LLM harus direview, lebih cepat menulisnya sendiri"
  • Pernyataan seperti itu juga bisa menunjukkan kurangnya kemampuan melakukan code review
  • Mereview kode yang dihasilkan LLM bisa menjadi kesempatan bagus untuk meningkatkan kemampuan
• Bonus: umpan balik dari Claude 3.7 Sonnet
  • Penulis meminta Claude 3.7 Sonnet meninjau draf blog dalam "extended thinking mode"
  • Ia meminta, "tolong tinjau apakah logika tulisan ini meyakinkan, apa yang bisa diperbaiki, dan apakah ada hal yang terlewat"
  • Claude membantu melembutkan nada draf tersebut
  • Tautan percakapan umpan balik Claude

[GN⁺]

Opini Hacker News

• Penulis setuju dengan tulisan sebelumnya, tetapi tidak setuju dengan tulisan kali ini

  • Tidak setuju dengan pendapat bahwa "jika semua kode yang ditulis LLM harus ditinjau, maka lebih cepat jika saya menulisnya sendiri"
  • Tidak setuju dengan klaim bahwa investasi pada kemampuan membaca, memahami, dan meninjau kode orang lain masih kurang
  • Peninjauan berbeda tergantung pada keahlian dan tingkat kepercayaan terhadap penulis, dan meninjau kontribusi anonim adalah hal yang berbeda
  • Penting untuk menyimpulkan dan membandingkan niat serta pendekatan kode, dan dalam kasus LLM cakupannya terbatas
  • Motivasi itu penting, dan tidak semua pengembang menyukai code review
  • Kode dari LLM tidak memiliki aspek sosial, dan perubahan tetap harus ditinjau orang lain

• Bahkan jika kode yang dihasilkan LLM berjalan dengan baik, sulit menemukan bug atau cacat logika jika bukan kita yang menulisnya

  • Jika pemrograman dipandang bukan sebagai implementasi rencana yang dirancang dengan baik, melainkan sebagai menyusun potongan-potongan, maka ada kekhawatiran terhadap algoritme yang menyusun potongan lewat tebakan
  • LLM tidak menanggung risiko yang dapat diterima manusia, dan mungkin tidak memahami makna blok kode dalam konteks tertentu

• Kode hasil generasi LLM memang rapi, tetapi justru membuat lebih banyak waktu habis untuk QA dan pekerjaan merapikan

  • Kode yang berjalan baik dan tanpa error tidak berarti ia melakukan hal yang benar
  • Menjalankan dan menguji kode saja tidak dapat membuktikan ketepatannya; perlu penalaran logis

• The Primeagen dan Casey Muratori meninjau output generator kode LLM terbaru

  • Seharusnya pengembangan menjadi mudah jika diberi tugas yang terwakili dengan baik dalam data pelatihan LLM
  • Dalam praktiknya, pengembangan berulang justru mengerucut pada kode yang tidak berguna, dan LLM makin lama makin tidak mampu membuat kemajuan

• Kategori kesalahan lain yang Simon lewatkan adalah halusinasi ketika model melupakan fungsionalitas

  • Dibanding sisi positif bahwa kode bisa dikompilasi, sisi negatif ketika fungsi inti terlupakan jauh lebih sulit ditangani
  • Fungsionalitas dapat sedikit berubah tergantung pada kode yang diperkirakan berada di luar jendela percakapan/konteks

• Metode yang dihalusinasikan hanyalah hambatan kecil, dan ketika orang mengeluh soal ini diasumsikan mereka hanya meluangkan waktu minimum untuk belajar menggunakan sistem secara efektif

  • Itu adalah asumsi yang sangat keliru, dan orang melihat halusinasi lalu berpikir, "jika hal termudah pun tidak bisa dilakukan dengan konsisten, maka hal yang lebih sulit juga tidak bisa dipercaya"

• Halusinasi itu sendiri bukan risiko terbesar yang ditimbulkan LLM

  • Risiko yang lebih besar adalah chatbot dapat membujuk manusia untuk menyakiti diri sendiri
  • Kasus seperti itu sudah pernah terjadi, dan penulis tidak ingin membagikan ide tentang apa yang bisa lebih berbahaya lagi

• Ini hanya kurang berbahaya dalam konteks terbatas pada error kompilasi

  • Jika programmer sampai menciptakan seluruh library demi menghindari upaya mencari solusi yang sebenarnya, itu akan jauh lebih menjengkelkan
  • Jika halusinasi dianggap sekadar perlambatan, maka itu meremehkan apa yang seharusnya benar-benar dilakukan LLM

• Perlu banyak upaya untuk mendapatkan hasil yang baik dari LLM

  • Ini menembus hype yang berlebihan
  • Muncul pertanyaan tentang untuk apa LLM benar-benar berguna, dan apa yang bisa diharapkan jika perlu belajar bertahun-tahun hanya untuk mendapatkan hasil yang tidak dapat diandalkan

• Pengalaman menulis kode untuk menemukan klinik 'utama' pasien di pusat medis

  • Harus mencari janji temu terbaru dengan hanya mempertimbangkan janji temu klinis
  • Jika tidak ada janji temu klinis, harus mencari janji temu terbaru dari semua jenis
  • Kode ditulis dengan mengurutkan data, tetapi saat ChatGPT mendokumentasikannya, ia memahami urutannya secara terbalik
  • Ini adalah kesalahan yang jauh lebih buruk daripada sekadar "kode tidak berjalan"