- Sudah sekitar 2 tahun sejak alat bantu coding berbasis LLM dirilis
- Sebagian pengembang melaporkan produktivitas meningkat hingga 5x sampai 10x
- Namun, tidak ada bukti yang jelas bahwa produktivitas seluruh industri perangkat lunak telah meningkat 5–10x
- Dalam praktiknya, alat LLM sulit diandalkan untuk pekerjaan yang lebih dari sekadar menambahkan fitur boilerplate sederhana ke codebase
- Kebanyakan programmer tidak tahu cara menggunakan alat LLM secara efektif atau tidak tertarik
Mengapa peningkatan produktivitas terkonsentrasi hanya pada pengguna tertentu
- Jika produktivitas memang meningkat 5x sampai 10x, kemungkinan besar hal itu terbatas pada sebagian kecil pengguna mahir atau pengembang berpengalaman yang sangat piawai memanfaatkan LLM
- Tidak ada tanda bahwa seluruh industri perangkat lunak tiba-tiba menghadirkan jauh lebih banyak fitur berguna atau mengalami peningkatan kualitas yang mencolok
- Penulis sendiri hampir tidak merasakan dampak LLM selama 1–2 tahun terakhir
Sebenarnya proyek seperti apa yang dimungkinkan oleh LLM?
- Tidak jelas proyek apa saja yang benar-benar terwujud berkat kemampuan LLM
- Bahkan dalam hasil riset, hampir tidak ditemukan contoh konkret (refactoring COBOL adalah satu-satunya contoh yang disebut)
- Produk berbasis LLM dari lab AGI pun tidak menunjukkan hasil yang terlalu mengesankan
- Masih sebatas menyediakan fitur dasar seperti unggah PDF di kotak percakapan
- Masih kurang dalam membuat LLM berinteraksi mulus dengan beragam perangkat lunak dan tipe data
Pertanyaan: apakah benar ada bidang yang produktivitasnya meningkat?
- Tidak ada bukti yang jelas tentang proyek apa yang dirilis lebih cepat berkat LLM
- Tidak terlihat jejak bahwa suatu bidang tertentu dalam ekosistem perangkat lunak tumbuh 10x
Yang diinginkan adalah bukti nyata yang jelas
- Jenis informasi berikut tidak diperlukan
- Klaim samar tentang peningkatan produktivitas 10x
- Penyebutan indikator ekonomi abstrak atau kenaikan jumlah kode yang dihasilkan
- Contoh pembuatan alat atau fitur sederhana berbasis LLM
- Contoh sepele seperti "membuat klon Snake dengan ChatGPT"
Teori: kemungkinan LLM sebenarnya tidak meningkatkan produktivitas nyata
- Waktu justru habis untuk memperbaiki dan menyelesaikan masalah pada kode hasil generasi LLM
- Jika codebase besar yang dihasilkan LLM melewati tingkat kompleksitas tertentu, perbaikannya bisa menjadi mustahil sehingga akhirnya harus ditulis ulang dari nol
- Sekalipun LLM membuat perangkat lunak baru, besar kemungkinan kebanyakan hanya menjadi alat sekali pakai atau kode pembuktian konsep yang tidak dipakai
- Bahkan bila jumlah kode dalam perangkat lunak yang benar-benar berguna meningkat, ada risiko bertambahnya fitur yang tidak perlu atau bloatware
- Ada kemungkinan programmer tertipu oleh pengalaman seperti "sulap" karena mendapatkan hasil instan dari LLM
Kisaran peningkatan produktivitas yang realistis
- Berdasarkan pengalaman penulis, LLM hanya berguna dalam kasus tertentu seperti berikut
- Menulis fitur kecil
- Membantu mempelajari library atau codebase tertentu
- Menjalankan pekerjaan refactoring sederhana
- Besar peningkatan produktivitas kemungkinan hanya sekitar 10–30%
- Memaksimalkan produktivitas tampaknya akan sulit sebelum AGI (kecerdasan umum buatan) hadir
[Komentar Richard Horvath]
Situasi ketika LLM bisa memberikan peningkatan kecepatan 10x
- Menulis skrip kecil yang berdiri sendiri
- Sangat efektif untuk tugas sederhana (misalnya skrip bash untuk manipulasi file, kode Excel VBA)
- Mudah ditulis hanya dari penjelasan singkat dan juga mudah diverifikasi
- Bisa dibuat tanpa pengetahuan mendalam tentang bahasanya
- Tidak perlu memikirkan pemeliharaan, modularisasi, unit test, dan sebagainya
- Terutama sangat efektif untuk pekerjaan yang berkaitan dengan regex
- Mempercepat pembelajaran saat bekerja dengan stack yang belum familiar
- Bisa cepat memahami class dan method dari library baru
- Walau kodenya tidak sepenuhnya berjalan, tetap memberi pendekatan pemecahan masalah
- Sangat mengurangi waktu yang sebelumnya habis untuk mencari dokumentasi atau materi pembelajaran
- Namun, kode yang dihasilkan tetap perlu diperbaiki dan di-refactor sendiri
Tipe orang yang melaporkan peningkatan produktivitas 10x kemungkinan termasuk kategori berikut
- Pengetahuan pengembangnya rendah
- Jika kemampuan coding dasarnya kurang, kode yang dibantu LLM bisa terlihat jauh lebih baik dibanding sebelumnya
- Namun dalam kasus seperti ini, kode dari LLM justru berpotensi memberi dampak negatif dalam jangka panjang
- Harus sering membuat solusi kecil yang terpisah-pisah
- Tugas seperti otomasi Excel atau menulis shell script di DevOps sangat cocok untuk LLM
- Sering bereksperimen dengan berbagai stack dan library
- Ini lebih relevan untuk pekerjaan yang berfokus pada eksperimen daripada kerja jangka panjang pada satu stack tertentu
- Terjadi Anchoring Effect
- Karena LLM memberi hasil instan pada tugas tertentu, orang bisa dengan mudah melebih-lebihkan dampaknya sebagai peningkatan produktivitas jangka panjang
[Komentar Davidmanheim]
- Dari sudut pandang orang yang menulis kode di perusahaan pada umumnya maupun dari sisi manajemen, peningkatan produktivitas dari LLM memang bisa sangat terbatas
- Ini dapat dijelaskan lewat sudut pandang Theory of Constraints:
- Misalkan sebelumnya pekerjaan selesai melalui alur berikut:
- Business Analyst → memakan 1 hari
- QA tester → memakan 1 hari
- Programmer → memakan 1 hari
- Walaupun produktivitas programmer meningkat 2x atau 5x, waktu total pekerjaan tidak berkurang
- Karena tahap lain (analisis bisnis dan QA) menjadi bottleneck, kecepatan keseluruhan proses tetap sama
- Perlu restrukturisasi proses perusahaan
- Untuk memaksimalkan peningkatan produktivitas dari LLM, seluruh proses di perusahaan perlu disusun ulang
- Namun saat ini restrukturisasi seperti itu baru mulai dilakukan di sebagian perusahaan saja
[Komentar faul_sname]
- Dengan LLM, ia merasakan hasil yang sangat baik terutama dalam pembuatan mockup UI:
- Sebelumnya, pembuatan mockup UI memakan sekitar 10% dari total waktu kerja
- Berkat LLM, kecepatan pembuatan mockup UI meningkat sekitar 5x
- Namun, total waktu kerja itu sendiri tidak berkurang
- Sebaliknya, detail dan interaktivitas mockup UI meningkat drastis
- Lebih banyak iterasi menjadi mungkin, sehingga kualitas produk akhirnya membaik
- "Kode yang akan dibuang" tidak selalu berarti tidak berguna
- Bahkan prototipe atau kode pembuktian konsep pun bisa berkontribusi pada pengembangan produk akhir yang lebih baik
- Selain itu, LLM juga bisa memberi jawaban untuk error tertentu yang sulit ditemukan lewat mesin pencari
- Contoh: "cara mengatasi error yang muncul pada pekerjaan yang berjalan di stack xyz"
- Membantu debugging dalam konteks stack tertentu dan konfigurasi Kubernetes yang spesifik
- Kenaikan produktivitas total diperkirakan sekitar 10–30%
- Namun, peningkatan ini tidak merata di semua jenis pekerjaan
- Ada peningkatan kecepatan yang terobosan pada tugas tertentu (misalnya mockup UI, debugging, dan sebagainya)
- Tidak ada hasil berarti pada pekerjaan yang kompleks atau kode legacy
- Peningkatan produktivitas paling terasa di awal proyek, lalu efektivitasnya menurun pada tahap pemeliharaan yang kompleks
- Karena itu, batasan utamanya di sini bukan kekurangan agency, melainkan masalah context management
[Komentar Noosphere89]
- Mengutip pandangan Ajeya Cotra, ia menyebut beberapa poin berikut tentang dampak LLM terhadap peningkatan produktivitas programmer:
- Produktivitas AI pada pekerjaan coding lebih tinggi dari perkiraan
- AI menunjukkan hasil yang cukup besar dalam tugas coding
- Namun pada pekerjaan di luar coding, performanya jauh lebih lemah
- Karena itu, dampak industrial AI secara keseluruhan masih terbatas
- Tautan pernyataan terkait Ajeya Cotra
- Terkait klaim bahwa "untuk mendapatkan hasil jangka panjang diperlukan AGI":
- Dalam jalur perkembangan AI saat ini, kemampuan umum (Generality) ternyata lebih sedikit dari yang diperkirakan
- Performa AI sering kali meningkat tajam pada tugas tertentu, atau justru menunjukkan kelemahan di area tertentu
- Karena ketimpangan performa ini, konsep AGI (kecerdasan umum buatan) mungkin menjadi kurang berguna daripada yang diperkirakan
[Komentar yo-cuddles]
- Contoh orang yang menangani robotic process automation (RPA) di kantor saya
- Ia sangat yakin bahwa dirinya jauh lebih produktif
- Namun kenyataannya pekerjaannya tidak efisien dan kurang andal, sehingga orang lain membuang waktu untuk memperbaiki hasil kerjanya
- Rekan-rekannya bahkan ingin menyingkirkannya dari alur kerja
- Orang sering tidak mampu mengukur produktivitas dirinya dengan tepat, dan hanya peka terhadap jenis keberhasilan atau kerugian tertentu:
- Fokus pada hasil yang mencolok
- Jika sebuah tugas selesai cepat dengan cara otomatis, rasa pencapaiannya langsung terasa besar
- Karena hasil cepat langsung terlihat, itu dianggap sebagai efek positif
- Biaya jangka panjang sulit disadari
- Biaya waktu yang muncul setelah pekerjaan selesai tidak mudah dilacak
- Terutama jika masalahnya diperbaiki orang lain, biayanya makin tidak terlihat
- Sekalipun error dari pekerjaan otomatis sudah diperbaiki, pemborosan waktu yang ditimbulkannya tetap sulit dirasakan
- Masalah yang ditimbulkan kode LLM sulit dikenali karena alasan berikut:
- Sulit melacak dengan tepat bahwa penyebab bug adalah kode buatan LLM
- Orang lain bisa menghabiskan waktu tambahan untuk memperbaiki masalah tersebut
- Sering kali akar masalah tidak disadari, dan pengguna tidak menyadari bahwa penyebabnya adalah penggunaan alat otomatis
- Rasa puas karena "selesai lebih cepat berkat otomatisasi" terasa besar, tetapi "waktu yang terbuang karena otomatisasi" sulit dirasakan
- Meski penggunaan LLM telah meluas, peningkatan produktivitas di tingkat industri secara keseluruhan tetap belum terlihat jelas
- Orang mengklaim "2x lebih produktif", tetapi sebenarnya produktivitas bisa saja justru turun karena masalah tersembunyi
- Dengan kata lain, waktu dan sumber daya yang habis untuk menyelesaikan masalah tidak terlihat, sehingga persepsi keberhasilannya menjadi berlebihan
6 komentar
Rasanya mirip dengan pengalaman saya.
Dalam kasus-kasus seperti di atas, waktu yang dihemat cukup banyak. Dengan kombinasi Google + Stack Overflow pun sering kali tidak mudah ditemukan, dan khususnya di Stack Overflow, kalau ada satu jawaban biasanya selalu banyak sanggahan di komentar, atau ternyata itu cara implementasi versi lama sehingga tidak boleh dipakai lagi, dan hal-hal seperti itu sering kali sangat menjengkelkan...
Produktivitas 10x sepertinya muncul saat membuat prototipe.
Saya lagi manis-manisnya.
> Sebagian besar programmer tidak tahu cara menggunakan alat LLM secara efektif atau tidak tertarik padanya
Banyak developer di sekitar saya ternyata tidak begitu tertarik pada teknologi. Mereka menghabiskan sebagian besar waktunya untuk menonton YouTube Shorts yang baru atau berulang secara mekanis.
Opini Hacker News
Bekerja di sebuah perusahaan teknologi populer di Seattle, dan penggunaan AI dipaksakan. Pimpinan melacak seberapa banyak pengembang menggunakan AI, dan bahkan secara pribadi menanyakan alasan tidak menggunakan AI lebih banyak. Saya percaya penting untuk menggunakan alat yang tepat untuk pekerjaan yang tepat, dan AI tidak selalu cocok
Ada pepatah lama bahwa 10% terakhir dari proyek perangkat lunak memakan 90% waktu. AI berguna pada 90% awal, tetapi tidak membantu pada 10% terakhir
Di FAANG, LLM digunakan dengan integrasi ke IDE, dan ada efek positif kecil
Sebagai contoh pengembang yang benar-benar mengalami peningkatan 10 kali lipat, ada kasus Pieter Levels yang mengkodekan simulator penerbangan multipemain 3D hanya dalam beberapa hari
Pernah mencoba menggunakan LLM untuk menghasilkan kode, tetapi pada awalnya produktivitas justru menurun
Sebagai anggota tim yang mengembangkan Copilot Autofix di GitHub, kami memberikan saran perbaikan berdasarkan peringatan CodeQL
Kualitas jawaban dari asisten coding LLM sangat dipengaruhi oleh kemampuan komunikasi programmer
Asumsi bahwa produktivitas perangkat lunak tidak meningkat 5-10 kali lipat mungkin saja keliru
Terjemahan ringkasan opini Hacker News untuk poin terakhir tampaknya keliru, yaitu "anggapan bahwa produktivitas software tidak meningkat 5–10 kali lipat mungkin salah". Jika melihat teks aslinya, ringkasan yang lebih wajar tampaknya adalah kira-kira: "mengatakan bahwa produktivitas software meningkat 5–10 kali lipat didasarkan pada asumsi yang keliru tentang peningkatan produktivitas".