Coding dengan Memanfaatkan LLM (Musim Panas 2025)
(antirez.com)- Pembaruan pengalaman pemanfaatan LLM dari pengembang Redis, antirez
- LLM terdepan seperti Gemini 2.5 PRO dan Claude Opus 4 memperkuat kemampuan developer
- Dengan memanfaatkan LLM, efisiensi kerja bisa meningkat lewat berbagai cara seperti menghilangkan bug, menguji ide, dan memperluas pengetahuan
- Pengalaman menangani bidang nonspesialis atau teknologi baru dengan bantuan LLM secara lebih mudah menjadi mungkin
- Namun, untuk kualitas keseluruhan dan pengelolaan kode, kolaborasi 'manusia + LLM' adalah kuncinya
- Untuk memanfaatkan LLM secara optimal, pemberian konteks yang memadai dan kemampuan komunikasi yang jelas sangat penting
Perubahan dalam Pengembangan dengan LLM dan Poin-Poin Utama
LLM terdepan (Gemini 2.5 PRO, Claude Opus 4, dan lainnya) berperan memperluas kemampuan programmer dengan bertumpu pada pemahaman yang sangat luas dan kemampuan menangani kode dalam skala besar
- Jika dapat menjelaskan masalah dengan jelas dan terbiasa dengan komunikasi berulang
- Kita bisa menghilangkan bug sebelum rilis (contoh: pada kasus implementasi Vector Sets di Redis, bug langsung ditemukan lewat code review Gemini/Claude)
- Kita bisa dengan cepat menguji apakah sebuah ide bekerja, sambil menulis kode eksperimental dan mengevaluasi performanya
- Pair-design berbasis pengalaman dan insting menjadi mungkin, dengan pengetahuan spesialis LLM yang kaya berpadu dengan intuisi manusia
- Jika memberi instruksi yang jelas kepada LLM, sebagian implementasi kode bisa diselesaikan dengan cepat
- Adaptasi teknis yang cepat juga dimungkinkan di bidang yang asing (misalnya kode assembly 68000 untuk Amiga)
Dalam tulisan lama 'LLMs dan pemrograman di awal 2024', kegunaan LLM sudah sempat dibahas, tetapi selama 1,5 tahun terakhir LLM berkembang sangat pesat
Untuk memanfaatkan LLM sebaik mungkin, baik manusia maupun LLM memerlukan kemampuan dan kebiasaan tertentu, sehingga prinsip-prinsip terkait hal ini menjadi penting
Menahan Diri dari Vibe Coding dan Prinsip Kolaborasi Manusia + LLM
Saat ini LLM sangat unggul sebagai pengganda kemampuan developer, tetapi belum mencapai tingkat di mana ia bisa menangani seluruh pekerjaan secara mandiri sendirian
- Untuk proyek kecil sekali jalan seperti testing atau utilitas sederhana, desain yang sepenuhnya dilakukan LLM masih memungkinkan
- Namun, pada proyek besar dan tidak biasa, penggunaan LLM secara tunggal sangat berisiko menimbulkan masalah seperti kompleksitas, kode yang tidak perlu, dan kelemahan struktural
- Kolaborasi LLM + manusia menunjukkan peningkatan produktivitas terbesar, tetapi prasyaratnya adalah komunikasi yang efektif serta pengalaman dalam mengelola LLM
- Jangan menyerahkan tugas kompleks hanya kepada LLM; dibutuhkan strategi yang selalu melibatkan manusia secara aktif dalam proses
Pentingnya Memberikan Konteks yang Cukup kepada LLM
Agar LLM benar-benar memahami arah pengembangan atau perbaikan masalah, memberikan informasi konteks yang luas adalah hal yang wajib
- Sebaiknya sertakan makalah, codebase yang dituju (sebisa mungkin keseluruhannya), serta maksud pekerjaan
- Informasi penting meliputi tujuan implementasi, pendekatan yang tidak perlu atau rapuh, ide inti yang layak diwujudkan, target, kondisi invarian, gaya kode, dan sebagainya
- Misalnya, saat menangani teknologi baru yang belum dikenal LLM (contoh: Redis vector sets), jika dokumen README disertakan dalam konteks, LLM bisa langsung memberi jawaban setingkat ahli
Memilih LLM dan Cara Menggunakannya
LLM yang paling terkenal belum tentu benar-benar menghasilkan hasil terbaik
- Untuk coding, Gemini 2.5 PRO dan Claude Opus 4 sangat efektif
- Gemini 2.5 PRO sangat unggul dalam mendeteksi bug kompleks dan memecahkan masalah
- Claude Opus 4 kuat dalam menulis kode baru, dan pengalaman penggunanya juga sangat baik
- Menggunakan kedua model secara bergantian dapat meningkatkan pemahaman dalam desain yang kompleks
- Jika harus memilih satu saja, rekomendasinya adalah Gemini 2.5 PRO
- Syarat yang perlu dipatuhi saat menggunakan LLM
- Hindari penggunaan code agent atau agent terintegrasi di dalam IDE
- Biarkan LLM melihat langsung seluruh konteks (kode, dokumen, dan sebagainya) agar menghasilkan jawaban terbaik
- Jika menggunakan fitur yang hanya memperlihatkan sebagian konteks seperti RAG (berbasis ekstraksi pengetahuan), performa akan menurun
- Pada setiap tahap, manusia perlu menyalin/menempel kode secara manual sambil melacak alurnya secara langsung
Kesimpulan – Mempertahankan Kendali adalah Kunci
Kemunculan agent yang menulis kode sendirian mungkin sudah tidak lama lagi, tetapi pada saat ini, cara paling tajam untuk menghasilkan kode adalah kolaborasi yang dipimpin manusia dengan LLM
- Peran manusia dalam memutuskan ‘apa’ dan ‘bagaimana’ tetap menjadi inti
- Dengan memanfaatkan LLM, kita bisa berkembang sambil mempelajari teknologi atau konsep baru di luar batas pengetahuan yang ada
- Jika kode tetap dikendalikan secara langsung, konsistensi desain dan implementasi bisa dijaga, sekaligus meminimalkan ketidakpastian akibat kesalahan LLM
- Memeriksa perkembangan performa agent secara berkala juga merupakan strategi yang bijak
- Pada tahap ini, menghindari pemanfaatan LLM bisa membuat kita tertinggal dari perubahan, sehingga cara memanfaatkannya secara seimbang menjadi sangat penting
1 komentar
Komentar Hacker News
Saya merasa prihatin melihat model LLM tertutup seperti Gemini 2.5 PRO atau Claude Opus 4 makin menjadi standar; saya sangat positif terhadap kemajuan LLM dan kekuatannya sebagai alat, tetapi sulit memahami mengapa para developer—entah figur terkenal atau bukan—terus menganggap wajar bahwa untuk tetap bisa memrogram mereka harus bergantung pada layanan berbayar pihak ketiga; dulu kita bisa ngoding hanya dengan open source dan alat gratis; saya khawatir beberapa tahun lagi ketergantungan pada LLM berbayar akan terasa sesulit sekarang jika harus ngoding tanpa IDE atau vim; argumen seperti “$200 per bulan itu bukan apa-apa” tidak menyentuh persoalan mendasarnya
Model terbuka yang bisa dijalankan secara lokal saat ini masih kurang dari sisi kualitas, dan yang lebih penting, biaya operasionalnya jauh lebih besar; ketika model setara Claude 4 bisa dijalankan di komputer pribadi secara ekonomis, saat itulah banyak orang akan mencobanya; untuk sekarang, model seperti Kimi K2 memang bisa berjalan di dua Mac Studio 512GB, tetapi harga perangkat kerasnya saja sekitar $20,000
Model berlangganan pada awalnya terasa menawarkan efisiensi harga yang sangat luar biasa, tetapi lama-kelamaan harga naik dan kualitas turun, hingga akhirnya kita terkunci pada layanannya; jadinya seperti episode "Common People" dari Black Mirror
Secara pribadi saya merasa masa depan di mana semua developer mutlak tersubordinasi pada LLM berbayar sulit terjadi; dalam jangka panjang, orang akan menyadari bahwa memproduksi kode dalam jumlah besar itu sendiri adalah masalah; kode adalah utang, dan jika kode yang tidak stabil atau lambat terus menumpuk, utang itu juga membesar; AI tidak akan hilang, tetapi setelah hype-nya mereda, pemahaman tentang di mana dan bagaimana menggunakannya akan meningkat; saya juga penasaran apa yang terjadi saat dana investasi mengering; OpenAI dan Anthropic tidak profitabel dan membutuhkan aliran modal terus-menerus untuk mempertahankan kondisi sekarang; jika evolusi LLM mentok di level saat ini dan itu memang batasnya, dana investasi juga akan keluar, dan saat itu biaya penggunaan bisa naik, atau layanannya bisa hilang sepenuhnya
Secara realistis saya tidak menganggap ini masalah besar; jika tidak ada alasan nyata berupa peningkatan produktivitas, tidak ada alasan untuk terus terikat pada layanan yang mahal dan tidak ramah; model terbuka juga terus membaik, jadi kalau jaraknya dengan model terbuka tidak besar, tidak perlu terus memakainya; jika perkembangan LLM tidak berhenti dan terus melaju tajam, maka kita juga tidak akan kompetitif lagi dengan cara lama, jadi harus beralih ke area lain; kesimpulannya saya rasa tidak perlu terlalu khawatir; saya juga merasa valuasi perusahaan model besar sangat dilebih-lebihkan dibanding realitasnya
Menambahkan soal bisa ngoding dengan open source dan alat gratis: JetBrains adalah perusahaan yang lebih tua daripada banyak rekan kerja saya, dan Visual Basic/C++/Studio dari MS dulu mempermudah pengembangan Windows, tetapi semuanya berbayar
Saya tidak setuju dengan ungkapan "PhD-level knowledge"; program PhD bukan bertujuan menyerap pengetahuan yang sudah ada, melainkan inti utamanya adalah belajar bagaimana melakukan riset; ini poin yang sering disalahpahami dalam diskusi AI, sehingga istilah pengetahuan setingkat doktor menjadi kabur maknanya
Selain bahwa PhD adalah proses mempelajari riset, intinya juga apakah seseorang bisa mengajukan pertanyaan; LLM lebih mirip “pekerja malas dengan pengetahuan melimpah” dan tidak mengeksplorasi hipotesis sambil bertanya sendiri; dari pengalaman nyata, saya pernah meminta Claude Code(Max Pro) mengomentari jumlah assertion dalam test, lalu muncul bug berdasarkan asumsi yang salah dari rencana awal; hanya setelah saya menyuruhnya menulis ulang rencana sendiri barulah ia menemukan alasannya dan memperbaikinya; misalnya, objek ORM memiliki nilai null karena tidak ada refresh setelah commit, dan objek yang dimuat dari sesi DB lain tetap tersisa setelah sesi ditutup, sehingga menimbulkan masalah itu
Setuju, ia punya pengetahuan setingkat ahli, tetapi LLM tidak bisa melakukan apa yang manusia lakukan dengan baik dalam kadar yang sama; misalnya LLM bisa langsung menulis program cemerlang dari awal sampai akhir, tetapi kesulitan melakukan perbaikan iteratif
Bahkan jika kita paham bahwa PhD lebih dari sekadar pengetahuan, hadirnya cara mudah mengakses pengetahuan itu tetap sangat bernilai; di perusahaan lama saya, LLM kadang memberi jawaban yang cukup berguna untuk pertanyaan rumit yang biasanya hanya bisa dijawab oleh PhD (kasarnya, pertanyaan seperti “apa yang terjadi jika tegangan dengan arah tertentu diterapkan pada batas dua material?”)
Setelah mendapatkan PhD, orang tidak lantas lebih memedulikan mata kuliahnya; pada akhirnya yang penting adalah telah belajar bagaimana melakukan riset
Saya rasa diskusi tentang coding berbasis LLM wajib menyebut domain yang dibahas dan bahasa pemrograman yang digunakan; kedua variabel itu jauh lebih berpengaruh daripada cara memakai LLM; kalau seseorang suka atau tidak suka coding dengan LLM, pertama-tama kita harus bertanya masalah di area apa yang mereka pecahkan, lalu mencoba menyelesaikan masalah itu sendiri dengan AI agar benar-benar memahami posisi masing-masing; kalau tidak, yang muncul hanya percakapan melelahkan seperti “itu karena kamu memakainya salah” atau “saya sudah coba tapi kurang bagus”
Berdasarkan pengalaman bekerja selama beberapa bulan terakhir dengan fokus pada agentic coding, saya setuju dengan semua isi postingan itu; LLM tercanggih memang paling mudah dipakai untuk saat ini, tetapi saya berharap model terbuka akan segera menyusul; kita juga bisa meminta LLM merekomendasikan pendekatan baru atau mengusulkan metode yang sudah kita tahu; kadang LLM cenderung membuat hal jadi lebih rumit, jadi tinggal dideteksi lebih awal atau diminta refactor; setiap kali model baru keluar, situasinya juga akan berubah lagi; tidak semua pekerjaan selalu butuh model paling mutakhir; untuk feature sederhana atau bug fix, Copilot juga cukup bagus sebagai titik awal; saya harap semua orang bisa menikmati proses mencoba berbagai hal dan belajar di tengah perubahan baru ini
Saya sudah memakai GitHub action dari Claude untuk implementasi sekitar 10–20 issue dan review PR, dan memang betul-betul hit and miss, jadi saya setuju bahwa ini lebih tepat dipakai sebagai alat augmentasi daripada otomatisasi tanpa pikir panjang; perubahan kecil dan feature/refactor skala kecil dengan test yang matang hampir selalu berhasil secara otomatis; kalau dijalankan lewat action, saya bisa mengerjakan hal lain, itu kelebihannya (lebih enak lagi kalau issue-nya juga ditulis Claude); tetapi untuk skala menengah ke atas, sering muncul hasil yang kelihatannya meyakinkan padahal sebenarnya tidak jalan; ini bisa jadi salah saya karena coverage test kurang, tetapi memang sering terjadi; meski issue ditulis lebih rinci atau prompt divariasikan, hasilnya tetap mengecewakan; untuk pekerjaan besar apalagi, jelas sulit; fitur review PR lumayan berguna untuk pekerjaan kecil/menengah, tetapi banyak juga pengecekan yang tidak berguna; kesimpulannya, LLM masih jauh dari bisa ngoding sendiri; untuk pekerjaan kecil, cara paling efisien adalah membiarkannya menulis issue lalu menunggu PR muncul; untuk sebagian besar pekerjaan saya (skala menengah), produktivitas memang jelas naik karena saya cukup memberi arah ke Claude dan hampir tidak perlu ngoding sendiri; saya juga sempat memakai Gemini, tetapi kalau dibiarkan sendiri kodenya berubah-ubah pada level yang sulit diprediksi; di kantor kami juga memakai Copilot untuk review PR, tetapi efeknya nyaris tidak ada; untuk codebase besar, mungkin Gemini bisa lebih berguna
Berbeda dengan OP, setelah mendalami area ini secara intens selama sebulan, saya merasa Gemini 2.5 PRO dan Opus 4 memberi hasil lebih baik untuk diskusi abstrak seperti arsitektur, lalu implementasi kode individual lebih efisien jika diserahkan ke Sonnet; 2.5 PRO dan Opus sering berputar-putar di sekitar jawaban sambil mengoreksi diri berulang kali, sedangkan Sonnet bergerak lebih lugas menuju jawaban, meski membutuhkan instruksi yang cukup detail
Itu sangat masuk akal; dalam praktiknya Sonnet/Opus 4 memang bisa lebih kuat pada hasil terbaik, tetapi dalam beberapa hal konsistensi atau alignment-nya masih tertinggal dibanding Sonnet 3.5v2 (kadang juga disebut 3.6) atau bahkan 3.7; model juga merupakan objek yang kompleks, jadi tergantung domain, model yang “terlihat lebih lemah” justru bisa bekerja lebih baik; selain itu, lingkungan percakapan interaktif dan lingkungan berorientasi agen memakai teknik reinforcement learning yang berbeda, jadi performa model bisa berubah tergantung cara penggunaannya
Dari data statistik internal yang nyata juga terkonfirmasi bahwa Opus dan Gemini 2.5 pro berkinerja lebih buruk daripada Sonnet 4 di lingkungan realistis tautan statistik terkait
Saya juga punya pengalaman serupa; Gemini 2.5 Pro saya pakai di AI Studio untuk memverifikasi atau mematangkan ide desain besar, lalu saat requirement dibawa ke Claude Code, biasanya ia mengodingkannya dengan rapi; saya juga baru-baru ini mencoba Gemini CLI, tetapi kemampuan coding-nya jauh tertinggal dibanding Claude Code; ada banyak syntax error, ia tidak bisa keluar dari loop, dan hasilnya bertele-tele serta cepat sekali bergerak sehingga sulit diikuti; sebaliknya, Claude Code sangat unggul dalam debugging; untuk pemecahan masalah “gambaran besar”, DeepSeek R1 juga layak dicoba; memang sangat lambat, tetapi tingkat keberhasilannya tinggi
Ada yang membagikan contoh nyata tentang bagaimana AI/LLM kadang menulis kode yang sangat tidak efisien tautan blog terkait
Saya pernah mengalami bahwa jika pertama-tama saya meminta LLM hanya menjelaskan pekerjaan yang diinginkan, lalu saya memberi feedback di tengah proses dan mengulang beberapa kali, kualitas kode yang keluar setelah itu jauh lebih baik; efektif juga jika rencana detailnya dikonfirmasi dulu sebelum mulai
Dari pengalaman saya, di frontend, pekerjaan yang repetitif, sederhana, dan mudah diverifikasi boleh saja diserahkan ke vibe coding, tetapi biasanya saya memakai LLM sebagai sparring partner untuk me-review kode saya dan menilai berbagai alternatif; meski rekomendasinya kadang mengada-ada atau cacat secara logis, saya tetap puas karena itu membantu saya agar tidak melewatkan hal-hal yang terlalu obvious; itu juga memperbaiki kebiasaan saya yang cenderung mencoba solusi berlebihan untuk masalah yang sebenarnya sudah rumit dan kusut
Saya tidak paham persis apa yang dimaksud OP dengan cara kerja yang dia katakan; masa iya maksudnya menempelkan file C redis secara manual ke jendela web chat Gemini Pro?