- Ada pengembang yang kesulitan menciptakan nilai yang jelas dengan memanfaatkan coding LLM
- Sebagian pengguna tidak puas dengan kualitas output dari LLM
- Untuk persyaratan yang spesifik atau masalah yang kompleks, LLM cenderung tidak memenuhi harapan
- Di sisi lain, untuk otomatisasi sederhana atau tugas berulang, ada tingkat kemudahan tertentu yang dirasakan
- Para pengembang sedang mencari cara untuk memperbaiki prompt engineering maupun workflow mereka
Diskusi tentang kesulitan menggunakan coding LLM dan cara meningkatkannya
Nilai LLM yang terbatas
- Belakangan ini banyak pengembang bereksperimen dengan coding LLM seperti ChatGPT, GitHub Copilot, Claude, dan lainnya untuk berbagai keperluan
- Namun, cukup banyak pengguna yang merasa belum mendapatkan peningkatan produktivitas yang nyata sesuai harapan
- Terutama untuk penulisan algoritme yang kompleks, penataan kode skala besar, atau perancangan arsitektur proyek, kode rekomendasi dari LLM sering kali terfragmentasi atau tidak efisien
Keluhan tentang kualitas output
- Sebagian pengembang menilai kode yang diberikan LLM mengandung bug atau menghasilkan keluaran yang tidak akurat karena tidak cukup memahami konteks
- Sering kali penjelasan atau analisisnya kurang memadai, atau kodenya gagal mencerminkan kompleksitas dan konteks proyek dengan baik
Bantuan pada area penggunaan sederhana
- Untuk hal-hal seperti pembuatan snippet kode pendek, tugas berulang, atau penyelesaian masalah sintaks sederhana, ada kemudahan yang jelas dari sisi otomatisasi tingkat dasar
- Pemanfaatannya untuk tugas rutin seperti unit test, refactoring, atau perbaikan gaya kode juga mendapat penilaian yang baik
Upaya untuk perbaikan
- Sebagian pengembang secara aktif menerapkan teknik prompt engineering untuk mendapatkan hasil yang lebih baik
- Mereka juga sedang bereksperimen dengan cara memanfaatkan LLM yang sesuai dengan workflow masing-masing, serta menggabungkannya dengan berbagai alat open source
Kesimpulan dan pembelajaran
- Untuk saat ini, diakui bahwa LLM belum bisa menjadi solusi serbaguna untuk semua kebutuhan pengembangan
- Komunitas dan para pengembang terus berbagi pengalaman sambil mencari strategi pemanfaatan yang efisien dan cara mengatasi keterbatasannya
1 komentar
Opini Hacker News
Rasanya ada dua tipe developer. Satu tipe yang bilang LLM adalah superpower penuh untuk coding dan produktivitas mereka naik 100x, lalu tipe lain yang melihatnya sebagai alat yang cukup rewel, butuh banyak campur tangan dan usaha hanya untuk mendapat hasil yang biasa saja. Tapi kalau memang tipe pertama benar-benar mendapat lonjakan produktivitas yang revolusioner dari LLM, bukankah orang-orang itu seharusnya sudah mendominasi pasar dan menyingkirkan para pesaing?
Untuk pekerjaan greenfield, saya memang merasa produktivitas bisa naik sampai terasa seperti 100x berkat LLM. Misalnya, menambahkan struktur dasar ke aplikasi React seperti beberapa halaman, Redux store, autentikasi, dan sebagainya bisa dihasilkan dengan cepat hanya dalam hitungan menit. Kalau saya bilang, "sekarang tambahkan X", biasanya hasilnya cukup bagus. Tapi untuk maintenance sistem yang sudah ada, penambahan fitur kompleks, atau situasi yang butuh pengetahuan domain, LLM tidak terlalu berguna. Untuk autocomplete kode atau melengkapi fungsi masih bagus, tetapi saat masuk ke tahap implementasi fitur secara utuh, batasannya cepat terasa. Dalam kasus seperti itu, waktu untuk menyuruh LLM kurang lebih sama dengan waktu kalau saya coding sendiri. Jadi biasanya saya menulis dulu stub code dengan struktur yang saya inginkan, lalu membiarkan LLM hanya mengisi bagian kosongnya. Orang-orang yang bilang LLM memberi produktivitas 100x tampaknya baru bertemu bagian yang mudah, atau belum benar-benar menabrak bagian sulit. Pada praktiknya, 90% pekerjaan itu mudah, dan 10% terakhir itulah yang benar-benar sulit, sementara LLM gagal di bagian itu
Sedikit sinis, tapi orang yang mengklaim produktivitas 100x sebenarnya hanya mengalikan angka kecil dengan 100. Pada tahap riset, LLM sangat membantu. Misalnya, belum lama ini saya harus menulis kode aljabar linear yang secara eksplisit dikhususkan untuk domain tertentu, dan karena tidak bisa memakai library seperti LAPACK, saya harus mengimplementasikannya sendiri. Dalam situasi seperti ini, memakai LLM sebagai pengganti buku referensi yang merangkum informasi yang saya butuhkan sekaligus benar-benar bisa memangkas waktu riset 100x. Tapi saat implementasi kode saya serahkan ke LLM, muncul kesalahan-kesalahan halus yang sulit disadari kalau bukan ahlinya. Hal yang mungkin saja lolos kalau saya masih junior. Karena saya menganggap code review itu penting, saya rasa sebaik apa pun LLM nantinya, kecepatan menulis kode itu sendiri tidak akan meningkat drastis. Namun, pada tahap eksplorasi dan peringkasan untuk menentukan kode seperti apa yang harus ditulis, LLM memang sangat mempercepat. Pada akhirnya, inovasi dan ide kreatif adalah nilai sejati di dunia ini, dan itu tetap ranah manusia. LLM akan menjadi pembantu penting, tetapi saya percaya kode bernilai tinggi tetap harus ditulis sendiri
Sebenarnya ada juga orang yang tidak masuk ke salah satu dari dua kubu itu. Bukan 100x produktif, tapi juga bukan alat yang terasa sangat menyiksa. Saya sudah lebih dari 30 tahun coding secara profesional, dan selalu saja ada hal yang perlu dicari lagi, atau bahasa dan sintaks tertentu yang sering terlupa. Apalagi banyak pekerjaan yang menuntut kita bolak-balik memakai beberapa bahasa. Dulu saya harus terus membuka buku referensi, manual, bahkan sumber yang lebih merepotkan lagi. Setelah mesin pencari seperti Google muncul, keadaan sedikit membaik, dan platform seperti Stack Overflow lebih efisien lagi. Sekarang LLM adalah satu langkah maju berikutnya. Saran autocomplete kadang justru langsung menjadi petunjuk yang saya cari. Tentu hal yang tidak perlu saya abaikan, tapi antarmuka chat jauh lebih enak karena saya bisa bertanya dengan cara yang lebih dialogis dibanding mencari di Google atau SO
Saya belajar matematika dengan Math Academy, ChatGPT, dan YouTube, terutama 3Blue1Brown. Tanpa kombinasi ini, prosesnya akan terasa menyakitkan, tapi sekarang justru menyenangkan. Dulu saya pernah mengambil mata kuliah serupa di University of Amsterdam saat ChatGPT belum secerdas sekarang, dan saat itu jauh lebih sulit. ChatGPT bisa menjawab pertanyaan yang bahkan sulit dijawab pengajar, dan itu sangat cocok untuk saya yang baru bisa benar-benar terhubung dengan matematika kalau paham latar budaya di baliknya agar bisa lebih kreatif dalam memecahkan masalah. Misalnya, ketika saya bertanya kenapa huruf m dipakai untuk sudut, ia menjelaskan bahwa itu secara historis berasal dari measure. Jadi sekarang saya bisa kembali fokus pada inti matematikanya. Rumus cepat untuk menghitung varians juga dijelaskan dengan mudah oleh ChatGPT. Ini bukan alat untuk menguasai dunia, tapi saya jadi bisa mempelajari hal-hal yang dulu mungkin tidak sempat saya pelajari. Tentu YouTube dan Math Academy juga berperan besar
LLM memberi superpower kepada orang yang bekerja cukup luas di banyak bidang dan bukan ahli di setiap bagiannya. Kalau Anda hanya mendalami satu bidang tertentu dan selalu bekerja di sana, manfaatnya tidak terlalu besar. Misalnya, menulis Dockerfile dengan LLM itu luar biasa dalam situasi ketika hal itu cuma dibutuhkan kira-kira sekali per proyek dan tidak ada spesialis deployment khusus. Kesalahan sintaks kecil dan masalah remeh juga bisa diselesaikan lebih cepat daripada dengan Google. Menyuruh LLM menganalisis trade-off arsitektur lalu tetap mengambil keputusan akhir sendiri juga membantu menaikkan produktivitas. Hanya saja, ruang lingkupnya harus dipersempit dengan prompt agar LLM tidak melakukan hal bodoh, dan pada praktiknya ia sering membuat kesalahan absurd seperti mengarang API yang tidak ada, jadi tetap perlu perbaikan berulang. Meski begitu, bahkan dengan iterasi, keuntungan kecepatannya masih ada
Saya juga memakai LLM dengan banyak cara. Untuk debugging kecil, shell script, coding, pertanyaan, dan berbagai situasi lain. Untuk urusan pribadi, selain Claude dan OpenAI, saya memilih dari berbagai alat seperti Google atau Perplexity berdasarkan hasil yang paling bagus. Untuk pekerjaan, saya memakai Claude, OpenAI, dan Google lewat Copilot di VSCode atau lewat platform internal, dan sedikit bereksperimen dengan Copilot Studio. Saya sudah bekerja seperti ini lebih dari satu setengah tahun. Memang tidak semua alat saya pakai terus-menerus, tapi kesan umumnya seperti ini. Produktivitas saya memang naik berkat LLM. Saya bisa bereksperimen dalam berbagai bahasa pemrograman dan memahami beragam topik dengan lebih baik, jadi beberapa pekerjaan jelas menjadi jauh lebih mudah. Tetapi terlepas dari model dan versinya, ada kecenderungan yang sangat jelas bahwa begitu pekerjaan menjadi kompleks, keluar dari jalur umum, atau melampaui sekadar kombinasi sederhana, semuanya mulai gagal. Bahkan ada kalanya waktu untuk memperbaiki hasil ngawur dari LLM menghabiskan semua waktu yang sempat dihemat di awal. Jadi kesimpulan jujur saya saat ini: LLM berguna untuk autocomplete kode kecil, debugging, dan penjelasan, tapi hanya itu. Belum cukup untuk langsung mengancam pekerjaan kita
LLM sangat membantu ketika saya belajar library, API, atau bahasa baru. Misalnya, untuk hal seperti cara merender teks di OpenGL, jauh lebih cepat langsung bertanya ke LLM daripada membaca dokumentasi resmi yang besar dan berantakan. Atau ketika harus menulis boilerplate code yang repetitif dan membosankan tanpa ada referensi di codebase yang ada, LLM juga berguna. Tapi di area yang saya anggap sebagai 'pekerjaan' sesungguhnya, yaitu kode unik yang khas untuk layanan saya, LLM tidak terlalu berguna dalam arti "menuliskan kodenya untuk saya". Sebagai engineer senior, saya hampir tidak menghabiskan waktu untuk coding itu sendiri; yang penting adalah desain struktur, refaktor legacy, isu performa, debugging bug langka, dan sebagainya. LLM hanya mempercepat penulisan kode repetitif, jadi kalau Anda tidak membuat proyek baru dari nol setiap minggu, manfaatnya tidak terlalu besar. Kalau Anda masih banyak menulis boilerplate, mungkin selain mengandalkan LLM, ada baiknya juga memikirkan solusi yang lebih mendasar
Untuk membaca dokumentasi resmi yang berantakan dan menjelaskannya, LLM jauh lebih baik daripada programmer biasa. Di bidang ini, jelas ada nilai tambah. Saya juga merasa memang ada bahasa yang boilerplate-nya terlalu banyak
Tidak ada peluru perak, dan bagian yang benar-benar sulit adalah konseptualisasi. Mythical man-month adalah teks penting, jadi layak dibaca lebih lanjut
Tidak ada peluru perak. Aneh juga kita terus lupa pada nasihat singkat Fred Brooks. Kalau kita tidak berekspektasi berlebihan dan memahami bahwa data latih dipenuhi kode buggy sehingga LLM juga tentu akan menghasilkan bug, LLM jadi jauh lebih berguna. Jangan lemparkan desain sepenuhnya padanya; pekerjaan awal seperti membagi fungsi sebaiknya tetap saya lakukan sendiri, lalu pakai LLM untuk mengurangi kerepotan di pekerjaan membosankan atau area yang asing. Namun, kalau saya harus bertanggung jawab atas kode yang dihasilkan LLM, maka pengetahuan dan verifikasi saya sendiri tetap wajib. Sekalipun kode dari LLM terlihat sempurna, cacat bisa saja tersembunyi, jadi saya harus terus belajar, meningkatkan skill, dan tetap curiga. Sikap untuk tidak pernah menelan mentah-mentah itu penting
Begitu skala masalah membesar, jelas LLM mulai tidak berguna. Untuk pekerjaan repetitif atau find & replace yang rumit, LLM sangat bagus. Mengisi method CRUD untuk resource API dan kode sehari-hari lain yang jelas dan rutin juga sangat berguna. Belakangan ini saya juga menyuruh Claude Opus 4 me-review patch saya, dan kadang ia benar-benar menangkap kesalahan serta mengingatkan saya pada hal-hal yang harus saya lakukan. Tapi begitu melewati ambang kompleksitas tertentu, kegunaan LLM turun tajam. Misalnya, kalau perubahan harus dilakukan di banyak file yang cukup besar, saya biasanya sudah bisa menyimpulkan sendiri file mana yang perlu diubah. Meski begitu, memakai LLM sebagai 'rubber duck' tetap oke. Kalau AI berhasil membantu, bagus; kalau tidak, saya lanjut sendiri. Pada akhirnya, LLM cuma membantu di awal, sementara sebagian besar revisi memang tetap harus saya kerjakan sendiri. Kalau LLM setidaknya bisa menyiapkan kerangkanya lalu saya poles sesuai keinginan, itu masih lebih mudah daripada menulis semuanya dari nol. Kalau LLM tampak jelas kesulitan, saya tidak memaksanya. Kalau ia salah menebak karena spesifikasinya ambigu, saya tunjukkan, dan kalau tetap gagal, saya selesaikan sendiri
Pengalaman saya juga mirip. Saya menemukan nilai LLM pada hal-hal seperti ini. Ia bisa menghasilkan komponen atau halaman React yang cukup terisolasi dengan sangat baik, terutama kalau memakai library UI populer. Pure function yang terdefinisi dengan baik juga bisa dibuat dengan cukup andal, dan mudah diverifikasi. Boilerplate dari framework terkenal juga benar-benar mudah dibuat dengan baik. Tapi orang-orang di sekitar saya sering membanggakan pengalaman end-to-end yang luar biasa, sedangkan saya sendiri tidak mengalaminya, sampai rasanya agak membuat gila. Dalam penggunaan normal sekalipun dengan usaha besar, LLM benar-benar ambruk saat diberi satu unit fitur yang utuh. Dengan alat seperti aider, saya bahkan tidak bisa membuat fitur template email sederhana di Next.js. Kalau fitur itu dipecah jadi langkah-langkah kecil, hasilnya sedikit membaik, tapi lama-lama code yang sudah ada malah rusak. Bahkan setelah saya jelaskan masalahnya, semakin banyak prompt, hasilnya justru makin aneh. Pada akhirnya saya coba memperbaikinya manual, tapi kodenya sudah benar-benar berantakan
Teman-teman vibe coder pernah bilang ke saya bahwa "standar saya terlalu tinggi". Menurut saya, vibe coder pada dasarnya tidak benar-benar meninjau kode, jadi mereka memang tidak punya standar kualitas yang jelas. Kalau vibe coding benar-benar berhasil, tempat seperti Google AI seharusnya sudah memperbaiki produknya jauh lebih cepat daripada manusia berkat anggaran GPU dan TPU yang besar serta model AI terbaru. Kalau itu benar-benar terjadi, pekerjaan kita tidak akan lebih dulu terasa makin mudah; kita justru akan lebih dulu mengetahuinya lewat berita tentang sesuatu yang luar biasa dan tak terduga, dan baru jauh setelah itu sadar bahwa penyebabnya adalah AI
LLM bagus untuk kode sekali pakai. Untuk pengembangan, maintenance, debugging, dan perbaikan, semuanya tidak semudah itu. Karena sebagian besar kode pada praktiknya adalah kode 'sekali habis pakai', bukan benar-benar produk, LLM cocok untuk area itu. Bahkan kalau kita bawa konsep fast food, pabrik perakitan, atau produksi otomatis, tetap ada perbedaan besar. Barang buatan mesin pabrik bisa dipercaya karena dibuat benar lebih dari 99,99% waktu. Tetapi pada LLM, saya harus memverifikasi setiap langkah satu per satu, dan kalau tidak diverifikasi, biasanya memang tidak akan bekerja. Mustahil LLM menyelesaikan pekerjaan secara sukses 24 jam penuh tanpa pengawasan. Itulah sebabnya ia belum merebut pekerjaan kita sekarang juga
Saya sama sekali tidak pernah berniat menyerahkan satu masalah kompleks secara penuh ke LLM lalu tinggal menerima hasilnya. Itu bukan kekuatan LLM. Nilai sejatinya ada pada memberi 'petunjuk' untuk membantu kemajuan dan melompati bagian-bagian sederhana tapi memakan waktu. Beberapa hari lalu saya harus membuat string log, dan LLM langsung mengusulkan kode dengan format yang lebih rapi daripada yang saya bayangkan, sehingga pekerjaan 15 menit bisa selesai dengan sangat baik dalam 30 detik. Kemenangan-kemenangan kecil seperti inilah yang menumpuk dan menciptakan nilai