- Pendiri Redis, antirez, sering memanfaatkan AI dan LLM, tetapi menilai bahwa kemampuan pemecahan masalah manusia saat ini masih jauh lebih unggul daripada LLM
- Ia mengalami langsung keterbatasan LLM saat memperbaiki bug kompleks yang terjadi pada Redis Vector Sets
- Algoritme yang disarankan LLM cenderung berhenti pada solusi yang standar atau sederhana
- Pendekatan kreatif dari developer manusia lebih unggul dalam menghadirkan solusi inovatif yang sulit dicapai LLM
- LLM sangat berguna untuk memverifikasi ide atau menjadi lawan diskusi, tetapi kreativitas pada akhirnya tetap ada pada manusia
Pendahuluan: perbandingan manusia dan LLM
- Saya sama sekali tidak memiliki sentimen negatif terhadap AI dan LLM
- Sudah lama saya menggunakan LLM dalam keseharian, untuk menguji ide, review kode, mencari alternatif, dan berbagai keperluan lain
- Tingkat AI saat ini jelas sudah praktis dan memiliki banyak keunggulan, tetapi saya menekankan bahwa jaraknya dengan kecerdasan manusia masih besar
- Saya menulis ini karena merasa perlunya pembahasan AI yang seimbang belakangan ini makin sulit dilakukan
Kasus bug Redis Vector Sets
- Baru-baru ini saya sedang memperbaiki bug terkait Vector Sets di Redis
- Saat rekan-rekan Redis sedang tidak ada, saya menambahkan perlindungan ekstra terhadap kerusakan data file (RDB/RESTORE)
- Fitur ini pada dasarnya nonaktif secara default, dan merupakan lapisan pengaman tambahan untuk mencegah kerusakan meski checksum lolos
- Masalah muncul saat mengoptimalkan kecepatan serialisasi representasi graf dari struktur data HNSW ke RDB
- Daftar koneksi antar-node disimpan sebagai bilangan bulat, lalu dipulihkan kembali menjadi pointer saat deserialisasi
- Karena karakteristik implementasi HNSW itu sendiri (menjamin keterhubungan timbal balik), jika graf atau memori rusak, masalah berikut bisa terjadi
- Tercatat bahwa A terhubung ke B, tetapi B tidak terhubung kembali ke A (misalnya karena kesalahan penomoran)
- Saat node B dihapus, pelanggaran koneksi timbal balik dapat membuat link A→B tetap tertinggal, sehingga saat kemudian menelusuri B->A, muncul bug use-after-free
- Setelah data dimuat, perlu dilakukan verifikasi bahwa semua link memenuhi sifat 'saling terhubung'
- Jika memakai algoritme murni, kompleksitasnya O(N^2). Pada data skala besar (~20 juta vektor), kecepatan loading terukur turun dari 45 detik menjadi 90 detik, alias dua kali lebih lambat
Penerapan LLM dan keterbatasannya
- Saya berdiskusi dengan Gemini 2.5 PRO untuk menanyakan metode yang lebih efisien, lalu meninjau saran dari LLM
- Saran pertama LLM: urutkan daftar node tetangga lalu gunakan binary search (metode yang sudah sangat dikenal)
- Karena efek perbaikannya tidak besar, saya meminta ide tambahan, tetapi tidak mendapatkan jawaban yang lebih baik
- Alternatif yang saya usulkan: memakai hash table untuk mendaftarkan dan menghapus pasangan link (A:B:X, setelah diurutkan dan perbedaan dua arah dihilangkan)
- LLM menilai ini ide yang bagus, tetapi menyebut kelemahan seperti performa pembuatan key dan performa hashing
- Saya lalu menambahkan gagasan untuk meningkatkan efisiensi dengan memproses key berukuran tetap memakai
memcpy tanpa snprintf
Kreativitas manusia vs keterbatasan LLM
- Saya lalu mengusulkan ide untuk menerapkan teknik XOR pada accumulator tanpa hash table
- Pasangan pointer (beserta informasi level) di-XOR ke accumulator; jika koneksi timbal balik terpenuhi maka nilainya saling meniadakan (0), sedangkan jika ada yang hilang akan tersisa pola tertentu
- Namun saya juga menyoroti kemungkinan collision dan sifat pointer yang dapat diprediksi (dan LLM juga setuju soal ini)
- Perbaikan lanjutan: menggabungkan seed acak/hashing (
murmur-128 dan seed urandom), lalu menerapkan XOR ke accumulator 128-bit
- Pada akhirnya, cukup cek apakah nilai accumulator adalah 0 untuk menentukan apakah koneksi timbal balik terpenuhi
- LLM menilai metode ini juga tangguh terhadap error umum maupun penyerang eksternal, sekaligus efisien
Kesimpulan
- Pada akhirnya, saya menyelesaikan analisis untuk memutuskan apakah metode ini cukup andal untuk diadopsi
- Kasus ini menegaskan bahwa pendekatan kreatif dan nonstandar dari developer manusia lebih unggul daripada jawaban terbatas yang diberikan LLM
- LLM sangat berguna sebagai alat verifikasi ide dan mitra diskusi intelektual ('bebek pintar')
- Namun, dalam hal menghasilkan solusi kreatif final, keunggulan manusia tetap jelas
7 komentar
redis bakal segera tertinggal ya
Rasanya seperti balapan antara sepeda dan lari.
antirez adalah developer manusia 1%. Saya pikir developer manusia 1% akan tetap lebih unggul daripada LLM. Tapi untuk 99% sisanya, saya tidak yakin.
Saya beberapa kali mencoba melakukan troubleshooting dengan AI, tetapi semuanya gagal dan pada akhirnya saya sendiri yang menyelesaikan masalahnya.
LLM tampak canggih dan kreatif karena dilatih dari tulisan-tulisan seperti itu, dan saya rasa juga karena banyak ilmuwan memverifikasi pengetahuan tersebut demi meningkatkan kualitas data latih agar hasilnya lebih baik.
Namun seiring waktu, tren berubah atau dibutuhkan kreativitas yang berbeda tergantung situasinya, jadi pada akhirnya bukankah orang yang menggunakannya tetap harus mengerahkan kreativitas sesuai dengan kondisinya sendiri..
Opini Hacker News
Rasanya ini sangat sesuai dengan pengalaman saya. Sebenarnya nilai besar yang diberikan asisten LLM kepada saya adalah perannya sebagai ‘rubber duck’ yang cukup cerdas. Kadang ‘bebek’ ini juga membantah pendapat saya, bahkan membuat pemikiran saya jadi lebih tajam. (Apa itu rubber duck debugging?) Tapi menurut saya pertanyaan inti yang ingin dilewati semua orang adalah, ‘apakah nilai seperti ini masih akan bertahan dua tahun dari sekarang?’ Saya sendiri juga tidak tahu jawabannya
Bagi saya LLM bukan rubber duck, melainkan semacam ‘mesin jawaban salah’. Ada pepatah bahwa cara terbaik mendapatkan jawaban di internet adalah memposting jawaban yang salah, dan bagi saya itulah peran LLM. Kalau saya menyuruh LLM mengerjakan hal yang sederhana tapi menyebalkan, hasilnya sering sangat salah, sampai saya malah kesal dan akhirnya mengerjakannya sendiri dengan tenaga amarah
Perannya seperti bebek yang terlalu percaya diri, menunjukkan keyakinan yang jauh berlebihan dibanding kemampuan aslinya. Saya sudah terlalu sering melihat orang tersesat setelah berbicara dengan LLM
Buat saya LLM mirip junior developer yang bekerja di bawah saya, yang paham API tapi kurang akal sehat dalam arsitektur. Karena khawatir ada kesalahan aneh, saya meninjau sebagian besar PR sampai 3~4 kali sebelum dilempar ke review tim. Sisi bagusnya, saya jadi bisa mengalihkan otak ke masalah lain
Apakah nilai seperti ini akan tetap ada dua tahun lagi? Bagi saya, kekhawatiran yang lebih besar daripada masalah ‘saya ingin melewati percakapan ini’ adalah, ‘apakah kita bisa sampai dua tahun ke depan?’ Dunia sekarang terlalu tidak stabil, sampai bentuknya enam bulan lagi pun sulit diprediksi
Bagi saya LLM terasa seperti rekan pair programming. Ada teman untuk mendiskusikan ide, meninjau kode, dan memberi alternatif. Saya juga bisa belajar dengan mencoba fitur-fitur yang sebelumnya tidak saya tahu
Melihat kolom komentar ini, terasa ada sedikit suasana bahwa semua orang berharap pada pernyataan seperti ‘manusia tetap dibutuhkan’, ‘LLM tidak bisa debugging’, atau ‘LLM menyesatkan’. Itu memang benar, tetapi pembuatan kode otomatis yang dua tahun lalu masih mustahil sudah berkembang sangat pesat, dan sekarang pun lajunya tetap cepat. Ke depan mungkin laju peningkatannya melambat seperti ‘hukum Pareto’, tetapi saya yakin kemajuannya tetap akan berlanjut. Baru-baru ini di r/fpga saya bercerita bahwa saya berhasil membuat testbench versi pertama dengan LLM, lalu sangat terkejut melihat orang-orang yang bahkan belum mencobanya langsung menolak kemungkinan itu sendiri
Sikap seperti ini sangat umum di kalangan profesional. Saya juga sempat ke /r/law dan setelah mendengar komentar Dario Amodei soal AI di bidang hukum, saya langsung merasakan suasana yang refleksif meremehkannya. Mungkin ini semacam mekanisme adaptasi atau kenyamanan pada keadaan sekarang, tetapi menurut saya ini sangat buruk bagi kesiapan menghadapi perubahan ekonomi dan sosial di masa depan
Mirip seperti masa ketika assembly adalah dasar utama, lalu saat bahasa pemrograman muncul para programmer mengejeknya sebagai tidak efisien, kurang fleksibel, dan terlalu disederhanakan, terlepas dari benar atau tidaknya. Fenomena seperti ini adalah reaksi yang alami dan tidak terlalu berkaitan dengan nilai nyata teknologi baru itu sendiri
LLM sempat tumbuh sangat cepat, tetapi model-model terbaru belakangan justru terasa seperti mundur. Untuk pembuatan test code hasilnya bagus, tetapi kalau LLM dipakai terlalu dalam untuk tugas seperti implementasi fitur baru, hasilnya malah jadi aneh. Untuk proyek baru atau web app sederhana, ia bekerja baik, tetapi untuk refactoring kode besar atau legacy serta penambahan fitur, efektivitasnya tidak besar. Misalnya, saya cukup sering melihat Claude atau ChatGPT mengarang-ngarang seluruh API D3
Pada akhirnya, Anda sedang membuat pengganti diri Anda sendiri, sementara rekan-rekan Anda bergerak lebih hati-hati
ChatGPT-4o menunjukkan kemampuan luar biasa dalam menulis VHDL. Hari ini pun saya merasakan hasil yang mengagumkan saat membuat prototipe low-level controller
Konteks yang dibutuhkan untuk menulis software sungguhan dengan benar terlalu besar bagi LLM. Software pada dasarnya adalah ‘bisnis yang dikodekan’. Bagaimana LLM bisa tahu semua syarat khusus yang dijanjikan tim sales ke pelanggan, atau aturan implisit tiap departemen? Ruang masalah yang bisa diselesaikan LLM saat ini masih umum dan terbatas. Begitu melibatkan lebih dari dua kelas atau lebih dari 20~30 file, bahkan LLM papan atas pun kehilangan arah dan fokus. Karena tidak bisa mempertahankan konteks, code churn yang tidak perlu jadi parah. Kalau LLM benar-benar ingin menggantikan developer, ia harus mampu menerima jauh lebih banyak konteks, mengumpulkan konteks dari seluruh organisasi, dan menjaga alur pemikiran dalam proyek jangka panjang. Saat masalah-masalah seperti ini benar-benar mulai terpecahkan, barulah saya akan mulai benar-benar khawatir
Setiap kali orang membahas apakah LLM akan menggantikan developer, mereka lupa bahwa software engineering yang nyata mencakup jauh lebih banyak hal daripada menulis kode. Menulis kode justru bagian yang kecil. Yang penting adalah social skill, analisis kebutuhan, dan mencari tahu apa yang sebenarnya diinginkan pelanggan, padahal pelanggan sendiri sering tidak tahu jelas apa yang mereka mau, sehingga engineer yang harus bersusah payah menggali itu. Kalau itu saja sulit bagi manusia, LLM jelas tidak mungkin bisa melakukannya
Pada akhirnya ini adalah soal feedback loop, yaitu proses iterasi cepat saat pelanggan benar-benar mencoba lalu memberi masukan. UI chat sangat bagus untuk feedback loop pelanggan, dan agent bisa menghasilkan versi baru dengan cepat. LLM sudah cukup mampu melakukan abstraksi, berbagai sistem komponen, desain struktur keseluruhan, hingga analisis kebutuhan. Intinya adalah seberapa cepat iterasinya. Ketangguhan model dan IQ-nya terus meningkat. Seluruh software engineering sudah masuk tahap otomatisasi. Mungkin lima tahun lagi, manusia akan menjadi bottleneck besar jika tidak dibantu. Kalau tidak terintegrasi secara mendalam dengan AI, kita pasti tertinggal
Ini juga masalah yang pernah muncul saat demam offshoring (outsourcing developer ke luar negeri) di era 2000-an. Tim luar negeri sulit mengajukan permintaan perubahan atau mengangkat masalah, jadi mereka hanya membuat sesuai perintah, dan akhirnya semuanya hanya menumpuk. Sepertinya hal serupa akan terjadi pada AI. Hasilnya pun kemungkinan akan mirip
LLM dari awal memang tidak melakukan software engineering itu sendiri. Tapi itu bukan masalah utama. Faktanya, banyak program sukses berjalan baik tanpa ‘software engineering’. Dalam lingkungan yang tidak peduli dengan struktur biaya cloud, hal ini bahkan lebih benar. Malah ke depan saya rasa orang yang punya naluri teknis seperti IT business partner akan bisa membuat seluruh app tanpa bantuan software engineer sama sekali. Di industri energi hijau, itu sudah jadi kenyataan setiap hari. Namun masalahnya akan meledak saat dibutuhkan pemeliharaan, skalabilitas, dan efisiensi. Baru pada titik itu hal-hal seperti ‘pakai list atau generator di Python’ menjadi penting, dan engineering sungguhan mulai dibutuhkan
Lima tahun lagi mungkin kita hampir tidak lagi mendesain kode. Dibanding setahun lalu, jumlah pengetikan kode saya sudah turun drastis. Tapi ini hanya sebagian dari proses, bukan berarti developer akan hilang sepenuhnya
Di sisi lain, peran ‘coder’ biasa memang banyak sedang tergantikan. Memang di situlah LLM sangat kuat. Ada banyak coder tanpa otak yang hanya melihat tiket seperti “terima API ini lalu keluarkan nilai itu”, tanpa benar-benar memahami kebutuhan pelanggan atau melakukan analisis, dan bagian ini sedang dibersihkan dengan cepat. Software engineering yang sesungguhnya adalah ranah yang sama sekali berbeda, tetapi jangan abaikan bahwa permintaan untuk coder sederhana dulu memang sangat besar
Poin yang sangat penting adalah bahwa hanya manusia yang memiliki kemampuan untuk menangani konsep abstrak program dan pemecahan masalah secara kreatif. Programmer adalah arsitek logika, dan komputer adalah alat yang mengubah pola pikir manusia menjadi instruksi. Alat dapat meniru manusia dan cukup baik dalam menghasilkan kode untuk tugas tertentu, tetapi belum bisa menggantikan peran desain abstrak fundamental dan pembangunan itu sendiri. Jika model nantinya tidak hanya menulis kode, tetapi juga membangun keseluruhan proyek berdasarkan spesifikasi, maka peran developer sendiri akan berubah lagi
Kita selalu perlu melihat ‘apa yang lebih baik’ per tugas. Dalam pekerjaan yang repetitif dan berbasis rumus, seperti mencocokkan sintaks CSS atau cara memanggil library terkenal, LLM sudah jauh lebih baik daripada saya. Dulu ‘event kecil yang campur aduk’ seperti ini banyak memakan waktu saya, tapi sekarang hampir bisa diselesaikan seketika, dan saya sangat puas
Untuk styling yang mendasar (lebih dari CSS dasar), hasil LLM justru kurang bagus. Kalau efek yang diinginkan sulit dijelaskan dengan jelas, atau pekerjaannya menjadi halus dan subtil, ia sering gagal memberikan hasil yang paling penting dan malah terjebak hanya pada satu pendekatan
Untuk hal yang saya kurang kuasai (SQL), LLM jauh lebih baik; tetapi untuk hal yang saya pahami dengan baik (CSS), justru lebih buruk. Standarnya jadi terlihat jelas
Saya setuju dengan pernyataan “lebih baik daripada kebanyakan developer”, dan juga bahwa LLM terlihat lebih baik hanya karena banyak orang tidak bisa CSS. Sebenarnya ini salah paham yang muncul karena banyak orang membenci CSS, tidak mempelajarinya, lalu terpaksa menggunakannya. Kalau perusahaan tidak mampu merekrut ahli CSS sungguhan dan ingin cari jalan murah, saat itulah LLM jadi alternatif; kalau punya sumber daya untuk mencari orang yang benar-benar ahli, tentu LLM tidak sebanding. Pada akhirnya saingan LLM adalah developer yang kurang kompeten
Di bahasa utama atau area yang belum benar-benar saya kuasai, autocomplete dari LLM sangat membantu. Namun jika kita hanya bergantung pada LLM tanpa melatih ‘kemampuan ingatan refleks’, ada risiko kita kekurangan kemampuan untuk mengevaluasi saran alat ini, lalu berhenti pada solusi yang lemah
Saya senang banyak orang mengkhawatirkan ‘kode yang bagus’, tetapi saya takut pada kenyataan bahwa mungkin itu tidak lagi berarti. Industri software sudah lama dikuasai dunia bisnis, dan saya bahkan tidak yakin sejak kapan tepatnya itu terjadi (apakah sejak Bill Gates menulis open letter pada 1976?). Masalah sebenarnya adalah para pemegang saham dan eksekutif semakin tidak peduli pada kode selama laba naik. Tanpa perlawanan budaya dari developer atau pengguna, struktur ini sepertinya akan terus berlanjut
Menanggapi pernyataan bahwa tanpa perlawanan budaya dari developer/pengguna semuanya selesai, saya ingin bilang bahwa ada juga banyak perusahaan yang membuat kode bagus, jadi tidak semua tempat berantakan. Masalahnya bukan kualitas kode, melainkan persoalan etika: apakah kita setuju dengan tujuan bisnis kapitalistik. Yang paling penting adalah keseimbangan antara software yang indah dan realitas. Saya juga developer sekaligus founder, suka open source dan engineering, tetapi pada saat yang sama saya juga ingin hidup cukup nyaman
Kode adalah penggerak bisnis. Kode buruk berujung pada bisnis buruk. Ada perbedaan yang jelas antara tim hosting (physical firewall, vmware, proxy, dan semacamnya) dengan public cloud (QEMU, netfilter, peralatan sederhana, dan sebagainya). Siapa yang menguasai siapa, tidak ada yang bisa memprediksi masa depan
Tadi malam saya menghabiskan waktu bergulat dengan o3. Saya belum pernah membuat Dockerfile seumur hidup, jadi saya berharap cukup memberi o3 repositori GitHub agar semuanya beres otomatis, tetapi malah menghabiskan berjam-jam untuk debugging hasilnya. Ia sering menambahkan hal yang bahkan tidak ada, menghapus yang tidak ada, atau mencampuradukkannya, bahkan bingung dengan konsep dasar seperti perbedaan
python3danpython. Akhirnya saya kesal, mencari dokumentasi Google Docs, dan langsung beres. AI memang alat yang hebat, tapi bukan obat mujarab, dan pasti harus ada seseorang yang tetap ‘terjaga’Perusahaan yang memakai LLM·AI untuk meningkatkan produktivitas kerja karyawan akan berkembang, sedangkan perusahaan yang mencoba langsung mengganti karyawan akan gagal. Dalam jangka pendek, CEO/eksekutif mungkin puas dengan hasil sesaat sambil menggerogoti pertumbuhan masa depan
Itu jawabannya. LLM memang tepat dipakai sebagai asisten programmer, dan penggantian total tidak realistis. Jalan yang benar adalah menerima teknologinya secukupnya
Ide bahwa mengganti karyawan bisa menaikkan nilai jangka pendek dan menguntungkan perusahaan cukup menarik. Artinya, dalam jangka menengah dan panjang itu bisa merugikan perusahaan, tetapi untuk sementara harga saham mungkin saja naik
Asisten kode adalah alat umum yang wajib dimiliki, bukan senjata untuk menggantikan manusia. Di zaman ketika pesaing pun bisa membeli langganan AI yang sama, manusia tidak bisa digantikan begitu saja
Berbagi pengalaman lapangan — dulunya developer, sekarang lebih banyak jadi manajer tapi masih menulis kode. Asisten LLM memang membantu, tetapi kadang juga merepotkan. Saat tiba-tiba membanjiri saya dengan saran kode yang tidak terduga, arahnya bisa melenceng dari niat saya, dan waktu untuk meninjaunya jadi habis. Mungkin ini soal pengaturan, tapi saya ingin default-nya diubah agar hanya muncul saat saya memanggilnya langsung lewat perintah. Satu hal yang pasti, meskipun saya menyerahkan penulisan seluruh kode atau fungsi ke LLM, saya tetap selalu melewati proses review sendiri
Editor Zed punya fitur mode ‘saran halus’ seperti ini (lihat detail). Saya berharap semua editor menyediakan mode seperti ini
Akhir-akhir ini, karena di startup saya mengerjakan banyak hal, saya jadi kurang suka UI yang dibuat LLM. Sebagai building block dasar itu berguna, tetapi kalau saya menyerahkan blok kode panjang sekaligus ke Claude, saya tetap perlu sangat banyak pengerjaan ulang sampai hasilnya benar-benar sesuai yang saya mau
https://freederia.com Seperti situs ilmuwan AI, mereka akan mempertahankan hubungan koeksistensi.