- Martin Fowler baru-baru ini menunjukkan bahwa survei tentang cara pemanfaatan LLM dapat menghasilkan kesimpulan yang terdistorsi karena tidak mencerminkan alur penggunaan yang sebenarnya
- Untuk pertanyaan tentang masa depan pemrograman atau stabilitas pekerjaan, belum ada seorang pun yang benar-benar tahu, dan penting untuk bereksperimen sendiri serta membagikan pengalaman
- Industri AI jelas sedang berada dalam fase gelembung, tetapi seperti semua inovasi teknologi dalam sejarah, bahkan setelah gelembung pecah pun perusahaan yang bertahan seperti Amazon bisa tetap muncul
- Hakikat LLM adalah halusinasi (hallucination), dan proses melemparkan pertanyaan dalam beberapa variasi lalu membandingkan jawabannya sendiri sudah berguna
- LLM secara signifikan memperluas permukaan serangan sistem perangkat lunak, dan khususnya agen browser diperingatkan memiliki risiko struktural yang pada dasarnya tidak bisa dibuat aman
Cara menggunakan LLM dan produktivitas pengembang
- Belakangan ini diskusi tentang dampak AI pada pengembangan perangkat lunak tahap awal berlangsung sangat aktif
- Sebagian besar pemanfaatan LLM berfokus pada fitur pelengkapan otomatis tingkat lanjut (dalam bentuk co-pilot)
- Namun, orang-orang yang paling efektif menggunakan LLM justru cenderung memilih cara memanfaatkan LLM agar bisa langsung membaca dan mengubah file kode sumber
- Survei yang mengabaikan perbedaan cara penggunaan LLM berisiko besar menafsirkan data ke arah yang keliru
- Selain itu, perbedaan kemampuan antar berbagai model LLM juga membuat interpretasi hasil menjadi lebih sulit
Pekerjaan pemrograman dan masa depan LLM
- Pertanyaan tentang masa depan pemrograman, kebutuhan akan engineer junior, dan masa depan engineer berpengalaman sering diajukan
- Tidak mungkin memberi jawaban yang jelas untuk hal ini, dan situasinya masih belum sampai pada tahap metode penggunaan LLM yang efektif benar-benar mapan
- Diperlukan pendekatan eksperimental serta sikap mengamati dan membagikan pengalaman workflow konkret dari orang lain
- Mencoba langsung dan berbagi pengalaman adalah cara adaptasi yang paling bijak
Fenomena gelembung di bidang AI·LLM
- Menanggapi pandangan bahwa AI adalah gelembung, dijelaskan bahwa setiap inovasi teknologi selalu disertai fenomena gelembung
- Gelembung pada akhirnya pasti pecah, dan kegagalan investasi juga akan terjadi
- Namun, waktu berakhirnya gelembung dan besarnya penciptaan nilai tidak bisa diprediksi
- Meski gelembung pecah, tidak semua perusahaan akan hilang, dan sebagian masih bisa terus bertumbuh
- Saat gelembung dot-com, pets.com dan Webvan bangkrut, tetapi Amazon adalah contoh perusahaan yang bertahan dan terus berkembang
Karakteristik halusinasi pada LLM
- Fenomena halusinasi (Hallucination) pada LLM bukanlah cacat, melainkan sifat yang melekat
- LLM pada akhirnya adalah alat untuk menghasilkan halusinasi yang berguna
- Sebaiknya ajukan pertanyaan yang sama beberapa kali dengan variasi redaksi untuk mendapatkan dan membandingkan beberapa jawaban
- Jika memerlukan jawaban berupa angka, penting untuk memeriksa variabilitas antar respons dengan pertanyaan berulang
- Tidak tepat meminta LLM menjawab langsung masalah yang bisa dihitung secara deterministik
Masuknya non-determinisme ke rekayasa perangkat lunak
- Rekayasa perangkat lunak tradisional dirancang dan diimplementasikan dalam lingkungan yang deterministik
- Engineer struktur dan proses merancang toleransi dengan mempertimbangkan non-determinisme (ketidakpastian) di dunia nyata
- Adopsi LLM bisa menjadi titik balik ketika rekayasa perangkat lunak memasuki dunia non-determinisme
Perbandingan LLM dengan pengembang junior
- LLM sering dianalogikan sebagai rekan kerja junior
- Namun LLM kerap mengatakan "semua tes lulus", padahal pada kenyataannya sering muncul tes yang gagal
- Jika itu manusia, perilakunya akan cepat berkembang menjadi masalah kepegawaian
Peningkatan ancaman keamanan dan masalah agen browser
- LLM secara luas memperbesar permukaan serangan sistem perangkat lunak
- 'Trifecta yang mematikan (Trifecta)' yang ditunjukkan Simon Willison adalah akses ke data privat, komunikasi eksternal, dan paparan pada konten yang tidak tepercaya
- Melalui perintah tersembunyi di halaman web (misalnya teks putih 1pt, dan sebagainya), LLM bisa ditipu untuk membocorkan informasi sensitif
- Agen berbasis browser sangat berisiko, dan tindakan berbahaya seperti transfer rekening melalui perintah eksternal dimungkinkan
- Willison menyampaikan pendapat bahwa ekstensi browser tipe agen pada dasarnya tidak mungkin dibuat aman
Kesimpulan
- LLM membuka kemungkinan baru dalam pengembangan perangkat lunak, tetapi cara penggunaan dan keterbatasannya harus dipahami dengan jelas
- Gelembung memang tak terelakkan, tetapi melaluinya perkembangan teknologi yang berkelanjutan tetap dimungkinkan
- Pengembang perlu memaksimalkan potensi LLM melalui pendekatan eksperimental dan pertimbangan keamanan
3 komentar
Bahkan hanya memikirkannya saja sudah membuat sesak…
Saya sangat setuju 100% terutama dengan analogi junior itu. Kategori kesalahan yang dibuat berbeda dari manusia... Menurut saya itu analogi gagal yang sangat representatif.
Opini Hacker News
Mantan rekan saya, Rebecca Parsons, sudah lama mengatakan bahwa halusinasi LLM bukanlah bug, melainkan justru fitur intinya. Pada dasarnya, yang dilakukan LLM adalah menghasilkan halusinasi yang berguna. Setiap kali mendengar klaim seperti ini, saya merasa istilah "halusinasi" sedang didefinisikan ulang seenaknya lalu dianggap sebagai wawasan baru. "Halusinasi" selama ini berarti membuat detail yang terdengar meyakinkan seolah-olah berasal dari persepsi, padahal tidak berkaitan dengan kenyataan, tetapi logika ini pada dasarnya sama saja dengan mengatakan "output". Bukan berarti ada hal baru dalam fakta bahwa LLM menghasilkan output; hanya label yang dulu dianggap 'buruk' ditempelkan ke keseluruhan tindakan agar terlihat baru
Saya rasa Fowler tidak benar-benar sedang mendefinisikan ulang istilah "halusinasi". Justru ia menekankan secara ironis bahwa halusinasi adalah cara kerja yang mendasar dari sistem ini. Seperti mengatakan "kerusakan sampingan adalah hal yang esensial pada bom"; ini tidak perlu dipahami secara harfiah
Klaim ini dimaksudkan untuk mengoreksi dikotomi keliru seperti “LLM menghasilkan kebenaran, atau menghasilkan halusinasi”. Cara pandang seperti ini membuatnya seolah-olah jika halusinasi dikurangi, yang tersisa hanyalah kebenaran, padahal sebenarnya semua output adalah sejenis halusinasi. Hanya saja sebagian di antaranya mencerminkan realitas atau sesuai dengan harapan sehingga tampak benar. Ini seperti melempar dadu lalu ketika angka yang kita inginkan muncul kita berkata, "dadunya membaca niat saya". Seperti monyet tak terbatas yang mengetik pada mesin tik tak terbatas dan suatu hari menghasilkan Hamlet, hanya saja probabilitasnya dinaikkan lewat AI
Saya menganggap pendapat itu menarik. Pengakuan bahwa LLM tidak bisa mengetahui apakah yang dihasilkannya akurat atau tidak memberi konteks praktis bagi orang yang memanfaatkan LLM dalam pengembangan perangkat lunak
Saya merasa tidak nyaman menjelaskan fenomena ini dengan kata "halusinasi". Ketika seseorang mengarang omong kosong yang terdengar meyakinkan tanpa dasar apa pun, kita menyebutnya "bullshit", dan LLM pada dasarnya mirip seperti itu. Jika didekati dari sudut pandang "bullshit", kritik terhadap penggunaan LLM justru menjadi agak kurang bermakna. Pada akhirnya, jika aspek LLM seperti ini membuat Anda tidak nyaman, Anda juga tidak akan bisa bekerja dengan manusia. Sebaliknya, jauh lebih sulit mendefinisikan ulang kata "bullshit". Meski begitu, saya rasa tulisan itu sendiri memang cocok sebagai kumpulan pikiran yang agak terpencar, dan penulisnya juga tidak tampak sedang mencoba berbicara secara otoritatif
Intinya memang disampaikan dengan canggung, tetapi maksud sebenarnya adalah bahwa tidak ada perbedaan yang jelas antara output 'halusinasi' dan output lainnya. Ini seperti dua hasil query dalam RDBMS yang pada dasarnya sama. Ini pengamatan yang bermakna
Di perusahaan kami, rasanya kode yang 90% oke tapi 10% rusak, yang nyaris mendekati kualitas yang diinginkan, sedang berlimpah. Produksi kode memang meningkat, tetapi kualitasnya jelas menurun karena tidak ada yang benar-benar bisa mengikutinya. Ini bukan proses mendekati target secara perlahan, melainkan langsung melonjak ke 90%, lalu waktu habis untuk membiasakan diri dengan kode yang asing dan terus merevisinya. Mungkin tetap lebih cepat daripada sebelumnya, tetapi selisih nyata antara dua cara itu bisa jadi tidak sebesar yang dibayangkan. Yang paling membuat saya tidak puas adalah saya lebih suka membuat sesuatu yang baru daripada menghabiskan waktu memperbaiki kode yang tidak familier
Saya juga jauh lebih suka membuat sesuatu yang baru. Tetapi ada juga orang yang lebih menikmati cara kerja baru yang cepat dan spontan ini. Saya sempat terpaksa mencobanya sebentar, merasa asing, lalu menghapus semuanya dan membangunnya ulang secara manual dengan bantuan AI, dan justru itu yang benar-benar memberi kepuasan. Satu-satunya kode hasil AI yang sampai sekarang belum 100% saya pahami adalah query SQL yang kompleks, tetapi query SQL bisa diverifikasi dengan cepat dan tidak memiliki efek samping tak terduga, jadi masih oke
Fenomena ini terasa sangat mirip dengan apa yang terjadi ketika ukuran tim bertambah dari 3 orang menjadi 10 orang. Tiba-tiba ada banjir kode yang tidak Anda kenal, konsistensi arsitektur menurun, dan ketergantungan pada kebijakan serta CI meningkat. Perbedaan LLM adalah mentoring atau memecat tidak ada artinya. Cara efektif menggunakan LLM adalah orang yang memakainya harus bertanggung jawab 100% atas hasil yang dihasilkan. Artinya, ia harus memahami kode yang dihasilkan dengan jelas, tetapi sulit memastikan hal itu benar-benar terjadi
LLM sangat hebat dalam menghasilkan kode boilerplate secara otomatis. Ini membuat orang jadi malas merapikan boilerplate. Jika PR berisi kode dalam jumlah besar, proses review juga menjadi sulit. GitHub pun tidak cocok untuk mereview terlalu banyak baris sekaligus. Akibatnya, developer junior/mid-level hanya berkutat membereskan boilerplate dan kesempatan belajar mereka berkurang. Jika terus begini, kualitas kode akan cepat memburuk
Mengutip aforisme Perlis nomor 7: ‘Menulis program yang salah lebih mudah daripada memahami program yang benar’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
Saya setuju dengan pendapat bahwa "kualitas jelas menurun", dan fenomena seperti ini kemungkinan akan makin parah. Pada akhirnya, hanya dengan memahami konsep trade-off dalam ekonomi kita bisa menilai apakah benar ada ‘laba bersih’. Banyak orang tampaknya melupakan bahwa tidak ada makan siang gratis
Framing Rebecca Parsons bahwa “halusinasi adalah fitur inti LLM” benar-benar sangat masuk akal bagi saya. Saya juga pernah mencoba menjelaskan ini ke orang-orang sekitar, dan kalimat itu merangkum tepat apa yang ingin saya sampaikan
Saya juga menjelaskan LLM kepada keluarga dan teman dengan mengibaratkannya sebagai aktor atau performer. LLM hanya berakting sesuai karakternya, dan menggunakan fakta hanya ketika fakta itu diperlukan<br>https://jstrieb.github.io/posts/llm-thespians/
Kutipan lama “Semua model itu salah. Hanya saja, ada model yang berguna.” terasa sangat pas di sini
Kecerdasan adalah kemampuan menyaring informasi yang tidak perlu. Baik itu pikiran maupun persepsi, sama saja
Saya lupa siapa yang mengatakan ini, tetapi output LLM selalu merupakan halusinasi. Hanya saja, lebih dari 90% hasilnya kebetulan benar
Saya sempat merasa LLM akan mengambil pekerjaan kita, tetapi kemudian sadar bahwa justru ia bisa menciptakan segunung pekerjaan yang nantinya harus kita perbaiki. Sekarang saya justru memakainya dengan baik sebagai alat bantu praktis seperti Claude Code, dan makin merasakan bahwa ini alat pelengkap, bukan pengganti
Saya pernah melihat saran, “kalau meminta jawaban numerik ke LLM, tanyakan sampai tiga kali”. Cara ini juga berlaku untuk manusia. Saat interogasi, polisi meminta cerita yang sama tiga kali, atau malah secara terbalik. Jika seseorang berbohong atau ingatannya kabur, ia bisa ketahuan saat mengulang. Dalam wawancara juga, jika Anda meminta seseorang menjelaskan topik yang sama dengan tiga cara berbeda, Anda bisa memeriksa apakah ia benar-benar memahaminya
Teknik ini juga bisa membingungkan orang yang tidak bersalah hingga terdengar seperti sedang berbohong. Jadi harus diterapkan dengan hati-hati
Cara seperti ini hanya valid dalam kondisi tertentu. Ada banyak kasus di mana semakin sering seseorang mengingat dan menyampaikan kembali memori, semakin terdistorsi jadinya. Saat polisi terus-menerus mengajukan pertanyaan yang sama dalam interogasi, kadang itu memang sengaja untuk memancing inkonsistensi dalam pernyataan. Bahkan untuk informasi yang sama, jika seseorang dipaksa menjawab terlalu sering dan dengan banyak variasi, pada akhirnya ia bisa membuat kesalahan. Dan kita juga harus selalu waspada bahwa penanya bisa mengarahkan jawaban ke arah yang ia inginkan
Space Shuttle NASA menggunakan triple modular redundancy. Ini untuk berjaga-jaga jika prosesor atau memori rusak akibat radiasi kosmik<br>https://llis.nasa.gov/lesson/18803
Saya merasakan produktivitas yang cukup tinggi dengan LLM. Ini bukan sekadar autocomplete sederhana; penghematan waktunya terasa besar. Namun saya juga khawatir bahwa jika dipakai terlalu bebas, akan muncul utang tersendiri. Secara pribadi, saya cukup berhasil membangun fitur secara bertahap bersama Claude Sonnet atau GPT-5 dengan pendekatan Test Driven Development (TDD). Belum banyak tulisan atau diskusi tentang pendekatan seperti ini, tetapi setelah membaca tulisan Martin saya merasa mengerti alasannya. Para master TDD yang benar-benar hebat tampaknya bukan tipe yang berbondong-bondong masuk ke otomatisasi kode LLM; biasanya mereka bangga pada seni menulis kode atau komunikasi antarmanusia. Karena itu, pengetahuan praktis yang kaya seperti dulu masih belum banyak. Ke depan, akan terbuka ‘padang rumput’ baru untuk cara menulis perangkat lunak dengan alat LLM, dan saya berharap banyak pelajaran akan terkumpul. Referensi: https://news.ycombinator.com/item?id=45055439
Sudah sewajarnya developer memverifikasi dan mengecek langsung kode yang dibuat LLM. Jangan meminta terlalu banyak kode sekaligus; lebih baik memanfaatkan LLM dalam unit yang lebih kecil. Saya juga menjalankan unit test sendiri. Jika LLM menjalankan test lalu mengatakan ‘berhasil’, itu belum tentu nyata. Saya baru percaya jika saya sendiri yang menjalankannya
Saya setuju dengan pendapat bahwa “halusinasi adalah fitur LLM”
Saya ingin menggambarkan LLM sebagai makhluk yang hidup di dunia yang hanya tersusun dari teks dan kombinasi. Kata dengan kata, cerita dengan cerita, itulah seluruh dunia bagi mereka. Karena itu, mereka paling mahir menciptakan cerita baru. Cerita mereka kadang tidak akurat dan saling bertentangan, sehingga pada akhirnya bergantung pada tebakan. LLM mungkin tidak benar-benar bisa menghitung angka, tetapi ia mengenali pola seperti ‘2 datang setelah 1 dan 3 lebih besar dari 2’. Seperti manusia memakai kalkulator, mereka juga bisa melakukan komputasi lewat alat. Ke depan, agar AI benar-benar dipercaya, yang perlu ditambahkan bukan mesin aritmetika, melainkan "epistemic engine" yang membantu penalaran, pencegahan kontradiksi, dan pembedaan fakta yang pasti
Dari sudut pandang itu, agen LLM bisa dilihat hanya sebagai sarana untuk memfilter hasil halusinasi
Saya lebih setuju dengan pernyataan, “Output dari semua model (bahasa besar) adalah halusinasi. Hanya saja sebagian di antaranya berguna.” Rasio halusinasi yang berguna itulah yang sangat tinggi hingga memicu ledakan AI
Saya rasa itu sudut pandang yang terlalu disederhanakan
Inilah juga alasan istilah “halusinasi” selalu memicu perdebatan. Istilah itu memberi kesan seolah ada hasil yang ‘bukan’ halusinasi, padahal pada dasarnya semua output LLM dihasilkan tanpa pemikiran
Saat ini, untuk memanfaatkan LLM dengan baik, developer senior perlu meresponsnya secara logis agar hasil yang diinginkan bisa keluar. Jika nanti developer junior menghilang, saya penasaran siapa yang akan menggantikan peran senior. Pada akhirnya saya memperkirakan LLM akan cukup mampu memrogram sendiri. Pada tahap sekarang, AI jelas alat bantu yang bagus. Bukan pengganti
Terkait saran untuk bertanya ke LLM beberapa kali, bagi pengguna macOS saya merekomendasikan memanfaatkan workflow Alfred. Tekan command + space lalu ketik 'llm <prompt>', maka beberapa LLM yang Anda inginkan seperti perplexity, deepseek (lokal), chatgpt, claude, grok, dan lainnya bisa dijalankan sekaligus dalam tab browser. Ini memungkinkan cross-check antar LLM seperti yang dibicarakan Fowler dengan cepat dan efisien, dan seiring sering dipakai Anda akan mulai paham LLM mana yang kuat untuk tugas tertentu