- Diskusi saat ini tentang LLM berlangsung tanpa dasar kuantitatif yang jelas
- Pengalaman tiap pengguna sangat terfragmentasi, dan elemen penting seperti lingkungan penggunaan nyata atau pengetahuan latar belakang hampir tidak pernah dibagikan
- Karena sifat non-deterministik, tugas yang sama pun bisa menunjukkan hasil berbeda dari waktu ke waktu, sehingga ada keterbatasan pada keandalannya
- Klaim berlebihan dari para pemimpin industri mendorong penerimaan tanpa kritik dan ekspektasi yang berlebihan
- Penulis sendiri juga menggunakan berbagai alat AI dalam keseharian, dan membagikan pengalaman nyata bahwa hasil yang diinginkan hanya didapat dengan peluang sekitar setengahnya
Perdebatan Seputar LLM dan Cara Pandang terhadap Teknologi
Kritik terhadap LLM dan suasana yang terbentuk
- Dalam perdebatan terbaru tentang AI, khususnya LLM (large language model), sudut pandang kritis sering diremehkan sebagai "pendapat orang yang tidak benar-benar memahami teknologi"
- Di Hacker News dan tempat lain, respons seperti "kalau masih bertanya pada AI, berarti tidak paham esensinya" terus berulang
Kesenjangan pengalaman antar pengguna
- Ada perbedaan pendapat antara pengguna yang merasa LLM "cukup membantu sampai taraf tertentu" dan pengguna yang merasa "sudah mencoba segala cara, tapi tetap tidak terlalu berguna"
- Alasan perbedaan ini muncul adalah karena tolok ukur dan informasi konkret tentang pengalaman tidak dibagikan
- digunakan pada proyek seperti apa
- kondisi codebase (proyek baru, kode yang sudah matang, source privat, dan sebagainya)
- tingkat keahlian pengguna, serta seberapa relevan keahlian itu dengan masalah yang dihadapi
- upaya tambahan yang diperlukan sampai hasil buatan LLM benar-benar dipoles dan diterapkan, serta kurangnya detail konkret lain
Sulitnya membandingkan pengalaman dan non-determinisme
- Bahkan jika seorang pengguna membagikan semua informasi secara rinci, membandingkan pengalaman dengan pengguna lain tetap hampir mustahil
- LLM dan agen otomasi pada dasarnya non-deterministik
- meski diminta menyelesaikan masalah yang sama dengan cara yang sama, hasilnya bisa berbeda setiap kali
- banyak faktor berubah seperti jenis proyek, model yang digunakan, alat, bahasa, dan lainnya, sehingga verifikasi yang konsisten sulit dilakukan
Pemimpin industri dan ekspektasi yang dibesar-besarkan
- Ada banyak kasus ketika pemimpin industri terlalu menekankan capaian LLM
- Contoh: seorang pemimpin industri membagikan pengalaman bahwa bug lama bisa diperbaiki dengan sangat mudah menggunakan "Claude Code", lalu mendapat sambutan luas tanpa membagikan detail
- Ukuran kode, tingkat kesulitan bug, ada tidaknya pekerjaan tambahan, bahasa pemrograman dan framework yang digunakan, serta informasi inti lainnya dihilangkan, sementara hanya pesan yang sangat positif yang menyebar
- Kasus seperti ini mencatat lebih dari 1,8 ribu respons positif dan 204 repost, sehingga pemasaran yang dibesar-besarkan mudah menyebar
Pengalaman penggunaan dan kesadaran akan realitas
- Penulis juga menggunakan berbagai alat AI seperti v0 dari Vercel, Claude Code, Midjourney setiap hari
- membuat aplikasi pemantauan dengan SwiftUI tanpa pengetahuan tentang Swift
- membuat poster acara secara otomatis dengan Midjourney
- menulis fungsi server MCP berbasis Elixir, dan pengalaman serupa lainnya
- Namun tingkat keberhasilannya hanya sekitar 50%, dan hasilnya tidak pernah benar-benar konsisten
- Ada saat ketika LLM terasa seperti sihir, tetapi pada kenyataannya ia hanyalah model statistik yang non-deterministik
- Dalam situasi seperti ini, penulis menilai diskusi industri masih terjebak pada dikotomi (sihir vs. rekayasa) semata
Kesimpulan
- Lanskap LLM dan AI cenderung lebih menyukai imajinasi, ekspektasi, dan keyakinan yang dibesar-besarkan tanpa sistem verifikasi yang pasti dan jelas
- Penting untuk tidak berhenti berpikir kritis dan terus berusaha memverifikasi fungsi serta efektivitasnya secara rinci
- Hal yang penting dalam diskusi adalah berbagi informasi yang konkret dan kuantitatif
- Diperlukan sudut pandang yang seimbang dalam melihat keterbatasan dan potensi LLM
1 komentar
Komentar Hacker News
Saya merasa frustrasi karena para eksekutif di tempat saya bekerja mendengar omongan soal peningkatan produktivitas 10x. Bahkan beberapa di antaranya datang langsung dari para early adopter di perusahaan kami. Tapi ekspektasi seperti itu terlalu tinggi. Hukum Amdahl juga berperan di sini, karena sebagian besar waktu saya dihabiskan bukan untuk coding, melainkan untuk berpikir dan berkomunikasi. Kalaupun coding benar-benar jadi 10x lebih cepat (yang dalam banyak kasus juga tidak begitu), produktivitas total paling hanya naik 10~15%. Itu tetap hasil yang lumayan bagus, tapi jelas bukan 10x
Mungkin karena pekerjaan saya sekarang terasa lebih seperti R&D, LLM memberi keuntungan besar pada bagian "berpikir" sama seperti pada "coding" (untuk komunikasi saya bisa menanganinya sendiri dengan baik). Menggunakan LLM untuk pekerjaan berpikir rasanya mirip seperti saat menguasai pencarian web 20 tahun lalu. Dulu saya harus tahu apa yang ingin dicari, sekarang LLM bahkan membantu mencari tahu apa yang harus dicari duluan (dan kadang mencarikannya juga). Hal-hal yang dulu saya kategorikan sulit sekarang jadi mudah diselesaikan berkat LLM. Saat ini sekitar sepertiga pencarian web saya dilakukan lewat ChatGPT o3. Saya bahkan tidak bisa membayangkan melepaskannya sekarang. Selain itu, ada juga faktor psikologis besar ketika LLM membantu merapikan pikiran saya yang belum matang dan menjadi lawan diskusi. Karena itu banyak hal terasa jauh kurang menakutkan, dan perbedaan itu juga besar
Di perusahaan saya situasinya mirip. Klaim peningkatan produktivitas dari para early adopter internal sering kali diukur dengan cara yang sangat sempit, atau hitung-hitungannya sendiri agak longgar
Ada kemungkinan LLM memberi efek akselerasi yang lebih besar pada developer senior daripada junior (karena junior belum tentu bisa membedakan kode bagus dan buruk). Satu senior yang memakai workflow LLM yang sudah dioptimalkan mungkin bisa mencapai produktivitas setara sepuluh junior zaman dulu. Bahkan untuk developer yang kurang bagus, hasilnya bisa membuat produktivitas efektif jadi negatif karena menyita waktu senior. Junior yang lumayan pun sering tetap tertahan di pekerjaan repetitif yang kini sudah lebih baik dilakukan oleh LLM. Karena itu saya termasuk yang melihat bahwa pekerjaan ini bisa benar-benar hilang
Jika penggunaan alat LLM hanya menaikkan produktivitas 10~15%, lalu biaya alat LLM membuat biaya tenaga kerja naik 10~15%, saya rasa tidak ada keunggulan khusus di situ. Biaya total produksi tetap harus diperhitungkan
Untuk proyek pribadi, saya bisa dengan mudah merasa hampir 10x lebih cepat. Tapi di perusahaan, ada diskusi lintas tim, perubahan requirement, review PR, dan lain-lain, jadi lingkungannya tidak cocok. Desain yang sangat teroptimasi dan pola standar seperti ini hanya mungkin di startup kecil atau proyek solo. Begitu melibatkan banyak orang, mencapai kesepakatan saja sudah sulit. Agar AI bisa memberi hasil terbaik, semuanya harus distandardisasi, tapi kenyataannya selalu ada sedikit ketidaksesuaian di mana-mana, jadi sulit mendapatkan efek sebesar itu di organisasi nyata. Kalau beberapa developer yang sangat sejalan bekerja sama, mungkin 10x masih mungkin, tapi di lingkungan korporat hampir mustahil. Saya justru melihat AI lebih cocok untuk middle management dan project planning
Pihak yang dikeluhkan penulis itu ya saya. Saya meluncurkan produk greenfield saat ChatGPT masih sangat kurang matang. Setelah itu saya pakai Claude dan copy-paste antara web chat sampai XCode, lalu beralih ke Cursor. Error build memang sering terjadi, tapi produktivitas saya tetap naik setidaknya 3x. Sekarang performa agent makin bagus dan Claude 4 juga sudah keluar, jadi saya hampir tidak coding lagi. Saya berperan sebagai Architect/Manager dan cukup mengarahkan agent dengan keahlian saya. Sudah berbulan-bulan di startup saya tidak menulis satu baris kode pun sendiri. Saya tetap meninjau semuanya sebelum mengajukan PR dan menguji dengan ketat, tapi kombinasi Cursor+Sonnet benar-benar gila. Jumlah baris kode tidak penting, malah para ahli codebase lama yang sudah lama bekerja sering bertanya ke saya soal bug-bug kecil. Berkat Claude saya bahkan sempat ikut mengerjakan pekerjaan developer frontend, jadi sekarang saya berhati-hati. Saya tidak cuma melempar query, tapi memaksanya melewati riset yang teliti, perencanaan, dan eksplorasi langkah demi langkah. Pengetahuan domain tetap wajib. Meski begitu, saya heran ada orang yang belum bisa memanfaatkannya seberguna ini. Rasanya saya melihat dua artikel seperti ini setiap minggu
Pengalaman saya mirip, hanya lingkungannya agak berbeda (mahasiswa PhD). Dulu saya skeptis terhadap LLM, tapi setelah Claude Code cara kerja saya berubah total. Meski begitu, kurasi tetap sepenuhnya tanggung jawab saya sendiri (itu soft skill penting yang dipelajari di program PhD, dan juga karena LLM cepat kehilangan tujuan atau konteks, atau tidak bisa mengingatnya). Kalau komunikasinya presisi, dengan CC saya bisa mengatur komputasi dengan cara yang dulu tidak mungkin. Ini bukan berarti pemrograman jadi lebih mudah, melainkan muncul bentuk kerja yang benar-benar berbeda
Saya penasaran seperti apa proses verifikasi/pemeriksaan nyatanya, misalnya cara cepat memeriksa kode dari LLM yang tidak bisa langsung dipercaya, apakah LLM juga menulis unit test, berapa panjang prompt rata-ratanya, dan sebagainya
Ada kritik soal apakah output LLM langsung dipercaya. LLM tidak bisa memahami konteks keseluruhan proyek dan sering berhalusinasi, jadi tetap perlu diverifikasi
Saya merasa kualitas kode dari LLM secara keseluruhan masih sangat kurang. Karena harus berkali-kali diperbaiki, sering kali malah lebih cepat jika saya menulisnya sendiri. Tapi untuk refactoring mekanis skala besar, agent sangat berguna. Daripada menulis vim macro yang rumit atau script AST, saya memanfaatkan agent
Secara pribadi, gagasan tidak menulis satu baris kode pun selama berbulan-bulan terdengar sangat membosankan
Ini justru mengonfirmasi ulang klaim dalam tulisan blog itu (tidak bisa diverifikasi, klaim hasil luar biasa, dan sebagainya). Akunnya juga tampak baru dibuat
Menurut saya, sebagian besar tenaga kerja industri jasa yang nyata itu berupa pekerjaan manual seperti memindahkan spreadsheet Excel atau memindahkan data antara CRM/email dan Excel. Di perusahaan besar, mungkin ada pegawai tetap yang melakukan pekerjaan repetitif seperti ini sampai seratus kali lebih banyak daripada software engineer. Jadi tidak masalah kalau LLM tidak bisa OCaml; jika sedikit saja lebih baik daripada manusia di Excel, nilainya sudah sangat besar. Dengan sesuatu seperti MCP untuk menghubungkan email-CRM-Excel dan mengotomatiskannya, tingkat error atau halusinasi juga bisa turun drastis. Manusia sendiri juga tidak deterministik, jadi determinisme tidak terlalu penting untuk proses semacam ini. LLM dan crypto benar-benar berbeda dari sisi utilitas maupun adopsi. Ini mengingatkan saya pada penyebaran smartphone. Teman-teman saya yang nonteknis pun sekarang memakai LLM untuk berbagai hal
Saya rasa membandingkannya dengan crypto tidak terlalu konstruktif. Secara teknis keduanya sama sekali tidak berkaitan. Tapi memang ada gejala overtrust pada teknologi. Bagi orang yang bahkan belum pernah bersentuhan dengan otomatisasi dasar, LLM bisa terlihat seperti fiksi ilmiah. Bidang ini belum pernah semainstream ini sebelumnya. Ke depannya saya rasa ini akan menjadi semacam wild west yang dipenuhi campuran keberhasilan, kegagalan, beragam opini, dan pengalaman lapangan. Hal baiknya, kini dunia sudah memungkinkan teman saya untuk langsung bereksperimen dengan ide aplikasi mereka sendiri
Para FTE (Full-time Employee) yang melakukan pembersihan data manual juga punya tanggung jawab untuk memverifikasi hasil, memenuhi tenggat, dan menanggung tanggung jawab hukum. LLM tidak bisa memeriksa pengecualian sementara seperti konteks di luar sistem, misalnya nilai seharusnya 0 karena hari libur. Untuk verifikasi seperti itu, mempekerjakan satu FTE jelas masih ada nilainya
Saya penasaran apakah rasio 100 FTE kerja manual data pipeline untuk setiap 1 software engineer itu hanya berlaku di perusahaan tertentu. Saya tidak melihat sebagian besar pekerjaan back-office/data entry memang sebanyak itu. Saya setuju AI akan berdampak besar, tapi saya ragu terhadap klaim bahwa hampir seluruh pekerjaan white-collar itu pada dasarnya cuma email dan data entry
Saya rasa ini meremehkan kompleksitas jenis pekerjaan semacam itu
Dari sudut pandang programmer yang sudah pensiun, saya tidak bisa membayangkan mempercayakan tanggung jawab mission-critical pada kode yang dihasilkan secara probabilistik. Kalau sedikit diperbaiki lalu dipakai, saya masih bisa mengerti. Untuk area di luar coding seperti brainstorming, pemikiran kreatif, dan dukungan riset, LLM sungguh mengagumkan. Saya memperlakukan LLM sebagai mitra berpikir. Memang ada kesalahan, tapi biasanya mudah ditangkap dengan memverifikasi ke sumber lain atau meminta LLM lain meninjaunya
Saya juga tipe yang sangat skeptis secara default, tapi setelah benar-benar memakainya, hasilnya melampaui ekspektasi saya di semua sisi. Dalam hitungan jam saya bisa mendorong proyek yang seharusnya butuh beberapa bulan dari prototipe sampai rilis. Hal-hal yang memang bisa saya lakukan jadi jauh lebih cepat, dan hal-hal yang tidak bisa saya lakukan sendiri (yang biasanya perlu outsourcing atau rekrutmen) pun bisa saya kerjakan dengan biaya kecil dan cepat. Tentu tidak sempurna, dan ada hal-hal yang menjengkelkan (mengabaikan instruksi eksplisit, berbohong, dan sebagainya), tapi bagi saya ini game changer
Memakai LLM sebagai mitra berpikir sempat terasa berhasil untuk sementara, tapi pada titik tertentu saya merasa sisi delusional-nya mulai terlihat. LLM sangat pandai membuat kita salah paham seolah-olah ia punya pengetahuan atau penalaran. Ini lebih berbahaya terutama di bidang yang saya sendiri tidak kuasai. Dengan search engine, saya masih bisa membandingkan kredibilitas lewat sumbernya, sedangkan dengan LLM itu tidak bisa. Menangkap kesalahan juga tidak selalu mudah
Sebagai developer dengan pengalaman 40 tahun, saya mulai memakai LLM beberapa bulan lalu dan cara kerja saya berubah besar. Tempelkan pesan error dari log, dan dalam satu menit sudah ada perbaikan; brainstorming desain, usulan solusi baru, dan sebagainya. Saya tetap memverifikasi kodenya, tapi saya masih kagum setiap hari pada akurasi dan kecerdasannya. (Ini sama sekali berbeda dari crypto)
Saya memang berada di kubu skeptis terhadap LLM, tapi pada dasarnya semua kode yang ditulis manusia juga bersifat probabilistik. Karena itu ada code review, unit test, pair programming, guideline, dan lain-lain. Output dari LLM maupun manusia sama-sama tidak boleh dipakai tanpa kritik. Hanya saja, saya khawatir LLM bukan sihir, dan akan disalahgunakan untuk menambah boilerplate sambil mengabaikan nilai jangka panjang seperti efisiensi, keamanan, atau refactoring, padahal justru di luar area-area yang benar-benar membantu itu risikonya besar
Menurut saya, data science adalah bidang yang paling cocok untuk kemampuan terbaik LLM. IO-nya jelas sehingga hasilnya mudah diverifikasi. Kalau kita paham karakteristik data tertentu, kita juga bisa dengan mudah menyuruhnya membuat kode pengujian. Jika konteks diperlukan, Claude Code membawa perubahan besar. Contohnya: mengekstrak banyak pesan di dalam tiap paket UDP dari file PCAP, melakukan filtering, pattern matching, memisahkan data untuk testing, dan sebagainya. Kalau saya bilang, "tolong tuliskan unit test untuk semua fungsi ini", LLM bahkan bisa melakukan self-verification
Saya sudah memakai LLM hampir setiap hari selama setahun, dan 90% waktunya ia menyelesaikan masalah saya. Saya tidak tahu kapan opini negatif tentang AI/LLM perlu dianggap serius. Dalam pengalaman saya, tidak pernah ada praktik memasukkan seluruh codebase lalu berharap keajaiban; saya hanya mengajukan pertanyaan yang presisi dan spesifik, tentang hal yang memang saya pahami, lalu menerapkan solusinya dengan cara yang bisa diverifikasi. Kalau tidak seperti itu, berarti LLM digunakan dengan cara yang salah. Untuk benar-benar mengalami "sihirnya", kuncinya justru pada penggunaan kecil, rutin, dan konsisten dalam keseharian
Dengan gaya parodi pembaca cuaca, ada yang menyindir seperti "selalu berhasil dengan probabilitas 60%". Saya sendiri juga memakai GPT dan Claude lewat Cursor setiap hari. GPT o3 bagus untuk pencarian pengetahuan umum, sedangkan Claude kadang gagal. Modelnya sendiri terasa bodoh, tapi sesekali tetap menangkap inti persoalan. Kalau kita sendiri tahu apa yang diinginkan dan bisa menjinakkan LLM dengan baik, saya rasa alat ini bisa dipakai secara produktif
Ada juga pendapat bahwa klaim "dalam pengalaman saya, 90% berhasil" itu sendiri sulit dipercaya
Penulis tampaknya marah pada komentar para polemis yang tidak akurat. Menurut saya, justru para pengguna yang tiap hari berhadapan dengan masalah dan keterbatasan LLM—yang sekaligus menjadi promotornya—sangat paham akan batasan itu. Masalah seperti terjemahan, transkripsi, dan pembuatan kode (hingga skala tertentu), yang dulunya mustahil atau nyaris mustahil, kini sudah benar-benar atau hampir sepenuhnya terselesaikan
Apakah terjemahan, transkripsi, dan pembuatan kode benar-benar nyaris mustahil dulu? Google Translate, Whisper, dan alat-alat lama juga sudah ada, demikian sanggahan yang muncul
Yang benar-benar menyingkap cacat nyata justru para detractor (pengkritik), sementara para promoter malah memuji LLM tanpa kritik seolah ia serba bisa
Belakangan saya merasa penggunaan istilah AGI dan AI sangat kabur, terutama di makalah ilmiah. Minimal saya berharap setiap makalah menjelaskan definisinya sendiri dengan jelas. Jika AGI didefinisikan dengan tegas, maka secara logis kita juga bisa membuktikan apakah AI tertentu memenuhi definisi itu. Mungkin ini tampak tidak terlalu berguna secara praktis, tapi tetap jauh lebih baik daripada memakai istilah kosong. Sekarang rasanya istilah AGI dipakai sambil menghindari definisi. Di Wikipedia disebut sebagai "hampir semua tugas kognitif yang setara atau melampaui manusia", tapi itu tidak mungkin diukur. Jadi saya bertanya-tanya kenapa istilah setipis ini masih dipakai
Tidak semua orang harus memakai arti yang sama. Cukup punya standar sendiri untuk kata AGI (meskipun mayoritas tidak sepakat). Bagi saya, crypto awalnya berarti cryptography. Standar arus utama dan standar pribadi saya bisa saja berbeda
Jika AI punya definisi, mungkin itu adalah "sesuatu yang belum berhasil diwujudkan lalu disebut AI", sambil memberi tautan ke penjelasan AI effect
Baru-baru ini perusahaan kami mulai memanfaatkan LLM. Tugas pertama adalah mentranskripsikan 20 ribu panggilan layanan pelanggan dan mengekstrak datanya (produk pembanding, masalah, use case representatif, dan sebagainya). Riset yang dulu butuh beberapa minggu kini selesai dalam beberapa jam. Kami bahkan menyusun strategi bisnis baru dan benar-benar mendapatkan nilai besar darinya. LLM sangat unggul sebagai mesin pemrosesan bahasa alami. Memang ada banyak promosi berlebihan, tapi bagi kami ini benar-benar membantu secara nyata. Ini cuma alat, jadi saya juga tidak merasa perlu membuktikannya kepada siapa pun
Saya rasa hype yang berlebihan itu tidak sepenuhnya tidak berbahaya. Itu bisa menimbulkan dampak negatif seperti distorsi pasar, investasi berlebihan, perampingan organisasi, dan ekspektasi yang mustahil dipenuhi. Artikel seperti ini perlu untuk mendinginkan pasar dan ekspektasi. Orang yang menjual LLM biasanya tidak bicara soal merangkum panggilan pelanggan, melainkan skenario yang dilebih-lebihkan tentang menggantikan tenaga kerja
Rasanya hanya orang yang belum pernah menangani pemrosesan data dalam jumlah besar dengan cara yang andal saja yang bilang LLM tidak berguna. Sekarang bahkan terjemahan pun bisa ditangani jauh lebih kontekstual
Tokoh-tokoh tepercaya di industri teknologi juga mengatakan secara langsung bahwa GenAI sangat membantu produktivitas pengembangan. Skalanya memang luas, dari 5% sampai 100%. Minimal kita harus menerimanya sebagai alat yang cukup berguna. Saya rasa kita tidak perlu angka-angka spesifik seperti baris kode, byte, CPU, dan sebagainya untuk membuat klaim seperti itu
Teknologi LLM pada akhirnya memang akan menemukan tempat penggunaan yang tepat, tetapi sudah terlalu banyak orang yang menyalahgunakannya sehingga rasanya tidak bisa diputar balik lagi. Terlalu banyak developer pemula akan gagal sambil mengambil risiko, dan terlalu banyak investasi akan terbuang sia-sia. Perusahaan-perusahaan pun tampaknya sudah telanjur all-in sehingga tidak bisa mundur lagi